Dieser Gedanke war für unsere Überlegungen, wie wir unseren RevPi Core internetfähig machen, der Maßstab aller Entscheidungen. Pannen, wie es sie zuletzt bei großen Herstellern im Smart Home Sektor gab, wollen wir möglichst mit unseren Konzepten vermeiden. Aber beißt sich das nicht mit dem Open Source Gedanken? Wie kann man ein System vor Manipulation und Angriffen durch Hacker schützen, wenn man alle Geheimnisse offenlegt?
Nun, wir haben sicher nicht das „Security-Rad“ neu erfunden, aber wir haben versucht mit modernsten Techniken Open Source und Security zu verbinden. Schließlich geht das ja im normalen Internetverkehr auch: Du kannst nachlesen, wie das HTTPS-Protokoll genau funktioniert und selber prüfen, ob es Deinen Sicherheitsanforderungen genügt. Und trotzdem kann niemand (na ja, sagen wir mal in vertretbarer Zeit und mit einfach zu beschaffenden Mitteln) Deinen Datenverkehr zwischen Browser und Server manipulieren oder abhören, wenn Du HTTPS verwendest.
Das Grundprinzip: HTTPS
Ja, auch ein großer Teil der Revolution Pi Security basiert auf HTTPS (Hyper Text Transfer Protocol
Secure), also der verschlüsselten Variante des Internet-Protokolls HTTP, mit dem der ganze
Datenverkehr zwischen Browsern und Webservern abgewickelt wird. Wenn Du besser verstehen möchtest, was dieses Protokoll eigentlich macht und warum es sicher ist, dann lies die allgemeine Einführung zu https am Ende des Artikels (gekennzeichnet durch die blaue Schrift).
Immer wenn Daten über das HTTP Protokoll zwischen dem RevPi Core und dem Internet ausgetauscht werden, setzen wir HTTPS ein. Unser Core basiert ja auf dem Compute Module von Raspberry Pi. Die Rechenleistung dieses Moduls ist begrenzt und die Verifizierung des Zertifikats oder die Berechnung von asymmetrischen Schlüsseln benötigt große Rechenleistungen, weil sehr sichere Schlüssel dabei verwendet werden. Wir entlasten den Broadcom-Rechenkern dabei, indem wir viele der benötigten Kryptofunktionen auf der Hardware des im RevPi Core eingebauten Cryptochips von Atmel ablaufen lassen. Außerdem enthält dieser Chip weltweit eindeutige Schlüssel, die wir für Sicherheitsfunktionen einsetzen. Weitere eindeutige Schlüssel, die wir bei der Produktion erzeugen, sind in diesem Chip sicher abgelegt und können nicht manipuliert werden. Über diese Schlüssel können wir unter anderem Softwarelizenzen von Drittanbietern (z.B. logi.cals) eindeutig einer bestimmten Hardware zuordnen.
Der Webserver des RevPi Core
Der RevPi Core verwendet einen Webserver (Apache), über den zum Beispiel eine Login-Webseite des Gerätes abrufbar ist. Das Gerät bietet über dieses Login einfache Grundeinstellungen an. Auch die SCADA-Software SpiderControl und andere Software von Drittanbietern nutzen den Webserver des RevPi Core. Der Webserver verwendet dabei ein Zertifikat, welches jeden individuellen RevPi Core eindeutig authentifiziert. Dabei besorgt sich der RevPi Core in bestimmten Abständen ein aktuelles Zertifikat über den kostenfreien Dienst „Let’s Encrypt“. Der Vorteil dieser Vorgehensweise besteht primär darin, dass ohne die üblichen zusätzlichen Kosten durch Zertifizierungsstellen (Zertifizierende Autorität, sogenannte „CA“) gängige Browser diese Zertifikate ohne Rückfrage beim Nutzer vertrauenswürdig einstufen – und zwar über die eingebaute Liste von vertrauenswürdigen Zertifizierungsstellen. Um sich bei Let’s Encrypt zu authentifizieren erwartet dieser Dienst, dass der Server auf dem Revolution Pi DNS (Domain Name Server) unter seiner Domain einen von Let’s Enrypt bereitgestellten Authentifizierungsschlüssel hinterlegt. Dieser DNS ist übrigens ein weiterer Service, den wir unseren Kunden bereitstellen. Nur registrierte und autorisierte RevPi Core Geräte sind über diesen Service von außen über einen eindeutigen (automatisch vergebenen) Domain-Namen erreichbar, sofern dieser Zugriff durch die Firewall des zwischengeschalteten Routers freigegeben ist. Damit dies auch bei wechselnder IP Adresse des lokalen Internetzugangs noch funktioniert, läuft auf dem RevPi Core eine Task, die in regelmäßigen Abständen dem DNS die aktuelle IP bekanntgibt („Dyn-DNS“). Dieser Zugriffsweg von „außen“ (WAN) auf einen RevPi Core (LAN) funktioniert aber bei vielen Routern nicht ohne Veränderung der Konfigurationseinstellungen. Dies wiederum erlauben die IT Richtlinien vieler Unternehmen nicht. Daher haben wir einen weiteren Zugriffsweg geschaffen, den wir im nächsten Kapitel erklären.
Übrigens: Jeder RevPi Core hat bei seiner Auslieferung auf seiner Login-Webseite ein individuelles Passwort, welches von dem einmaligen Schlüssel im Cryptochip abgeleitet ist. Dieses Passwort kannst Du mit einem kleinen Hilfsprogramm am HDMI Bildschirm des RevPi Core oder „headless“ über SSH im LAN auslesen.
Wie komme ich aus dem Internet auf meinen RevPi Core Webserver?
Viele Standorte haben strikte IT Richtlinien, die einen http(S) Zugriff von außen (WAN) auf einen Server im LAN einschränken. Die Router lassen das mit ihrer Firewall schlichtweg nicht zu. Hinzu kommt, dass viele Standorte WAN-Zugänge mit dynamischer IP-Zuweisung nutzen. Wir haben dieses Problem so gelöst:
Wenn in der Systemkonfiguration der WAN-Zugang eingeschaltet wurde, nimmt der RevPi Core beim Starten automatisch über HTTPS und Port 443 (der von einer Firewall in der Regel immer offen gehalten wird) Kontakt mit dem RevPi Verbindungsservice im Internet auf. Das ist ein Dienst, der auf hoch verfügbaren Servern läuft. Dort muss der RevPi Core sich authentisieren. Nur wenn Du zuvor auf unserer Plattform nach dem Login diesen Dienst für Deine RevPi Core Geräte freigeschaltet hast (das muss für jede Seriennummer geschehen), erlaubt der Verbindungsservice einen Verbindungsaufbau mit unserem Server. Zwischen Server und RevPi Core wird dann ein sogenannter Tunnel aufgebaut. Deine Firewall muss solche Tunnel natürlich zulassen, was in der Regel für einen Verbindungsaufbau von „innen“ nach „außen“ (in Richtung Internet) auch so ist. Der RevPi Core ist dann kontinuierlich mit dem RevPi Verbindungsservice verbunden und wartet auf einen Client (=Dich mit Deinem Browser).
Du kannst Dich nun mit einem Browser über HTTPS ebenfalls auf einer Login-Seite des RevPi Verbindungsservers anmelden und bekommst eine Liste aller für Dich verfügbarer RevPi Cores angezeigt. Du klickst auf eines der gelisteten Geräte und automatisch öffnet sich ein Browserfenster mit der Login-Webseite Deines ausgewählten RevPi Core. Dein Browser und Dein RevPi Core kommunizieren ab dann über HTTPS miteinander und weder unser RevPi Verbindungsserver noch irgendein anderer Rechner können diese Kommunikation abhören. Da bei dem Verbindungsaufbau der Kryptochip nach seinem eindeutigen Schlüssel abgefragt wird und dieser über HTTPS abhörsicher übertragen wird, stellt der Verbindungsserver sicher, dass Du wirklich mit Deinem RevPi Core verbunden bist.
Alternativ ist natürlich auch möglich, über eine feste IP oder Dynamische DNS Zuordnung Deinen RevPi Core ganz „normal“ von „außen“ zu erreichen (falls die IT-Richtlinien Deines Standortes das zulassen).
Andere Prozesse mit Webzugriff
Im RevPi Core gibt es andere Prozesse, die indirekt über HTTPS kommunizieren (zum Beispiel Zugang zu der Linemetrics Cloud über das REST-Protokoll, OPC-UA über SOAP oder der Zugang zu unserem SMS-Server). Andere Prozesse, wie der MQTT-Client verwenden ihre eigenen Sicherheitsfunktionen. Aber dazu mehr in einem späteren Newsletter.
Und wie geht das nun mit diesem HTTPS?
Bei HTTPS wird jedes Datenpaket in nicht lesbarer (verschlüsselter) Form über das Internet geschickt, sonst könnten unterwegs nämlich alle zwischengeschalteten Rechner mitlesen oder Daten verändern. Sender und Empfänger verwenden einen gemeinsamen sogenannten Session-Schlüssel (der nur für eine Sitzung gültig ist), um ihre Daten zu verschlüsseln. Dieser Schlüssel ist so komplex, dass er mit heutigen Hochleistungsrechnern nicht in dem Zeitraum einer Internetsitzung zu knacken ist. Nun gibt es aber dabei ein Problem: Sender und Empfänger brauchen ja beide denselben Schlüssel, den aber niemand anders in die Hände bekommen darf. Ihn einfach so über das Internet zu verschicken, wäre eine dumme Strategie. Deshalb läuft das bei HTTPS viel komplizierter: Wenn ein Browser Kontakt zu einem Web-Server aufnimmt, der HTTPS als Protokoll anbietet, so praktizieren die beiden Partner das Prinzip des sogenannten „Diffie-Hellman-Schlüsselaustausches“. Dieses Verfahren war übrigens das erste sogenannte asymmetrische Kryptoverfahren, das der Öffentlichkeit durch eine Publikation 1976 zugänglich gemacht wurde. Du siehst: Wir sind nicht die Einzigen, die Open Source nicht im Widerspruch zur Kryptografie sehen!
Öffentliche und private Schlüssel
„Asymmetrisch“ heißt, dass beim Schlüsseltausch am Anfang beim Sender und Empfänger kein gemeinsamer geheimer Schlüssel vorhanden ist, sondern dass es öffentliche Schlüssel gibt, die jeder kennen darf und zugehörige private Schlüssel, die jeweils nur einer der beiden kennt. So ein Paar aus öffentlichem und privatem Schlüssel gehört funktionell immer zusammen. Aber bevor wir das weiter betrachten, musst Du noch einen anderen Begriff verstehen: Eine weitere wichtige Rolle spielen bei diesem Verfahren sogenannte „Einweg-Funktionen“, mit denen Du in die eine Richtung schnell Ergebnisse berechnen kannst, aber die sich nicht so einfach umkehren lassen wie zum Beispiel „x = a * y“. Ein gutes Beispiel für solche Einwegfunktionen ist ein dickes Telefonbuch aus Papier: Kennst Du den Namen eines Teilnehmers, so kannst Du in weniger als einer Minute seine Telefonnummer mit so einem Buch ermitteln. Um aber aus der Nummer den Namen zu ermitteln, hilft das Buch nur bedingt – Du würdest Wochen dafür brauchen. Diese Einwegfunktionen sind nun deshalb wichtig, weil die Schlüsselpaare aus öffentlichen und zugehörigen privaten Schlüsseln solche Einweg-Funktionen für die Ver- und Entschlüsselung verwenden und deshalb für Nachrichten nur in die eine oder andere Richtung funktionieren: Wenn Du mit einem privaten Schlüssel eine Nachricht verschlüsselst, dann kann der Besitzer vom zugehörigen öffentlichen Schlüssel diese Nachricht zwar entschlüsseln, aber er kann keine Nachricht damit verschlüsseln, die sich mit demselben Schlüssel wieder entschlüsseln lassen. Umgedreht geht das natürlich auch: Wenn Du mit einem öffentlichen Schlüssel eine Nachricht verschlüsselst, kann der Empfänger sie nur mit dem zugehörigen privaten Schlüssel entschlüsseln.
Zertifikate
Eine andere wichtige Komponente bei solchen asymmetrischen Verfahren sind „Zertifikate“. Im Grunde geht es dabei um Vertrauen. Wie kannst Du beim Verbindungsaufbau darauf vertrauen, dass Dein Gegenüber der ist, der er vorgibt zu sein? Wenn Dein Browser einen HTTPS-Webserver kontaktiert, sendet dieser Server ein Zertifikat. Das ist eine Art Brief mit digitalem Siegel. Dein Browser fragt Dich nun, ob Du diesem Siegel und damit dem Inhalt des „Briefes“ vertraust. Die Tatsache, dass Du das selten auf dem Bildschirm miterlebst, liegt einfach nur daran, dass die Browser schon von Hause aus eine Liste von Zertifikaten kennen, die sie als vertrauenswürdig einstufen. In dem Zertifikat stehen nun der Name des Absenders und einige andere Daten drinnen. Diese Angaben im Zertifikat werden mit einem privaten Schlüssel zu einer Signatur (dem „Siegel“) verrechnet. Der Sender (Webserver) hat sein signiertes Zertifikat von einer „Autorität“ (Zertifizierungsstelle, CA) erhalten, der alle Beteiligten vertrauen. Das könnte zum Beispiel die englische Königin sein, ist aber eher eine der weltweit anerkannten Firmen für Internettechnik (z. B. Symantec). Diese Autorität ist alleine im Besitz eines privaten Schlüssels, mit dem sie die Signatur von Zertifikaten berechnen kann, die von ihr ausgestellt werden. Diese CA veröffentlicht für alle zugänglich einen öffentlichen Schlüssel, mit dem sich die Echtheit der Signatur und deren Zugehörigkeit zum Inhalt des Zertifikates und damit zum Absender eindeutig prüfen lassen.
Ok, nun weißt Du dank des Zertifikates, dass Du mit dem richtigen Server gerade eine HTTPS-Verbindung aufbaust. Nun folgt der asymmetrische Schlüsseltausch zwischen Server und Browser.
Ein Sitzungsschlüssel entsteht
Im Zertifikat vom Webserver steht ein von diesem Server erstellter öffentlicher Schlüssel, der bereits mit dem Server-Zertifikat beim Browser gelandet ist. Den zugehörigen privaten Schlüssel kennt ausschließlich der Server. Nachdem der Browser das Zertifikat vom Server nun als authentisch verifiziert hat, verwendet er diesen öffentlichen Schlüssel, um ein gemeinsames Geheimnis, das sogenannte „PMS“ (Pre-master-Secret, eine frisch erzeugte Zufallszahl) zu verschlüsseln und sendet dieses an den WebServer. Niemand außer dem Server kann das „PMS“ entschlüsseln, denn mit seinem öffentlichen Schlüssel kann man zwar das PMS schreiben, nicht aber lesen (Einweg-Funktion!). Und niemand außer dem Webserver könnte mit dem verschlüsselten PMS etwas anfangen, weil der nur der Server mit seinem privaten Schlüssel dieses PMS lesen kann.
Der Browser kennt nun das PMS, ebenso der Server. Beide können daraus (und aus zuvor beim Verbindungsaufbau übermittelten Zufallszahlen) das gemeinsame Geheimnis (MS, Master Secret) berechnen. Und genau dieses MS ist dann der „symmetrische“ Sitzungsschlüssel, den nur Browser und Server kennen können, mit dem alle Nachrichten in der Sitzung verschlüsselt werden. Niemand anders kann mithören und niemand kann etwas unbemerkt verändern. Und dank des Zertifikates kann der Browser darauf vertrauen, dass er mit dem richtigen Server spricht.