Ganz sichere Verbindungen

Teil 1: Ein Anwendungsfall für ein Hardware-Security-Modul

Eine TLS-gesicherte Verbindung zwischen einem Server und einem Client gehört mittlerweile bei mehr als 50% aller Websites im Internet zum Standard. Um die Vertraulichkeit und die Authentizität der übertragenen Daten aufrechtzuerhalten bedarf es entsprechender Maßnahmen, um den oder die privaten Schlüssel Server- und ggf. Client-seitig zu schützen.

Der Use Case, auf den wir in diesem Blogpost eingehen, sieht wie folgt aus: es geht um das Ausliefern von Updates an IoT Devices unseres Kunden. Dabei ist der Auslieferungsprozess der Firmware Images zweigeteilt. Das Gerät kontaktiert zuerst einen Firmware Update Server, der Metainformationen zu vorhandenen Updates ausliefert, u.A. inklusive der Schlüssel, mit denen die Firmware Images verschlüsselt sind, sowie URLs, unter denen die Firmware-Fragmente von den IoT-Geräten heruntergeladen werden können. Auf die genaue technische Umsetzung werden wir in einem zweiten Blogpost eingehen.

Der Kunde hat ein Service Center, in dem eine größere Anzahl von Updates für die Devices durchgeführt werden. Um dessen Netzwerkanbindung zu entlasten, soll ein on-premise Caching Server im Service Center installiert werden, der die o. g. verschlüsselten Firmware-Fragmente nach einmaligem Download für weitere Updates cachen kann. Es galt, folgende Herausforderungen zu meistern:

  • Die IoT Devices sollen dem Cache Server genauso vertrauen, wie dem Server, von dem diese regulär die Firmware-Fragmente beziehen
  • Da der Cache Server nicht in einem abgeriegelten Rechenzentrum betrieben werden kann und soll, muss das benötigte Schlüsselmaterial gegen unbefugte Verwendung abgesichert werden. Das Standardmittel hierfür ist die Verwendung eines Hardware Security Moduls (HSM)

Lösungsansatz

Wie bereits erwähnt soll der Prozess für die IoT Devices vollständig transparent ablaufen. Dabei werden die IoT Devices in das Netzwerk des Service Centers eingebunden. Sollte ein IoT Device nun nach einem Update fragen, so soll das Device an den on-premise Caching Server weitergeleitet werden. Im geplanten Setup passiert dies durch eine DNS-Umleitung, die in einem lokalen DNS-Server des Betreibers vom Service Center konfiguriert wird.

Abbildung 1, Überblick über unseren Lösungsansatz
Abbildung 1, Überblick über unseren Lösungsansatz

Größere Ansicht

Nr Beschreibung
1 Das IoT Device erfragt im internen Netzwerk einen DHCP Lease.
2 Zusammen mit dem DHCP Lease bekommt es die DNS-Komponente als DNS Server gesetzt.
3 Das IoT Device erfragt die Verfügbarkeit eines Updates beim Firmware-Service. Die Adresse des Firmware Services löst der DNS Server regulär auf.
4 Sollte ein Firmware-Update zur Verfügung stehen, so liefert der Firmware Service die Metainformationen zu diesem an das IoT Device zurück. Diese Metainformationen enthalten, wie in der Einleitung schon erwähnt, Links auf einzelne Fragmente der Firmware in einem CDN, sowie die Schlüssel, um diese Fragmente zu entschlüsseln.
5 Das IoT Device fragt jetzt nacheinander die Links zu den Firmware-Fragmenten an, die es vom Firmware Service bekommen hat.
6 Beim Auflösen der Domain in den erhaltenen Links über den lokalen DNS Server erhält das IoT Device anstelle der IP-Adresse des CDNs die IP-Adresse des Caching Servers zurück.
7 Das IoT Device fragt nun beim Caching Server die Firmware-Fragmente nacheinander an. (Liegt das jeweilige Fragment bereits im Cache, so wird mit Schritt Nr. 8 fortgefahren.) Hierbei emuliert der Caching Server das CDN. Für das IoT Device ist nicht ersichtlich, dass es nicht mit dem CDN, sondern mit dem Caching Server spricht.
7a Sollte das vom IoT Device angefragte Firmware-Fragment nicht im Cache vorliegen, so lädt dieser das jeweilige Firmware-Fragment einmalig vom CDN herunter.
7b Das CDN liefert das angefragte Firmware-Fragment an den Cache Server aus.
8 Der Cache Server liefert nun das vom IoT Device angefragte Firmware-Fragment dem eigenen Cache aus.

So erhält also das IoT Device die jeweiligen Firmware-Fragmente nacheinander vom on-premise Cache Server.

Kleiner Exkurs in asymmetrische Kryptographie, Zertifikate und TLS

Um die Verbindung zwischen den IoT Devices und dem Server abzusichern, wird TLS über HTTP verwendet.

Hier soll keine tiefergehende Erklärung von TLS-Eigenschaften erfolgen. In diesem Kontext ist es wichtig zu wissen, dass:

  1. TLS auf asymmetrischen kryptographischen Verfahren aufbaut. Bei diesen wird jeweils ein öffentlicher Schlüssel und ein privater Schlüssel verwendet. Will z. B. ein Teilnehmer (nennen wir ihn Bob) eine verschlüsselte Nachricht an einen andere Teilnehmerin (nennen wir sie Alice) schicken, so verschlüsselt Bob diese mit dem öffentlichen Schlüssel von Alice. Diese Nachricht kann anschließend nur Alice mit ihrem privaten Schlüssel entschlüsseln. Alice kann dabei nicht sicherstellen, dass die Nachricht auch von Bob stammt. Sie kann diese von jedem empfangen, der Ihren öffentlichen Schlüssel besitzt. Möchte Bob oder Alice sicherstellen, dass die Nachricht auch von Bob an Alice geschickt wird, muss Bob sich gegenüber Alice authentisieren. Bob kann dies dadurch erreichen, indem er die Nachricht an Alice mit seinem privaten Schlüssel signiert. Nun kann Alice, sofern sie Bobs öffentlichen Schlüssel hat, mit diesem prüfen, ob Bob der Sender der Nachricht gewesen ist.

  2. Zertifikate zum Einsatz kommen und diese es ermöglichen, eine Vertrauensbeziehung zum privaten Schlüssel des jeweiligen Teilnehmers aufzubauen. Also ob der öffentliche Schlüssel, den man verwendet auch wirklich dem jeweiligen Teilnehmer gehört, der den privaten Schlüssel besitzt. Damit sind wir im PKI-Kontext. Um bei Alice und Bob zu bleiben, kann Bob vor dem Verschicken der Nachricht an Alice mit Hil­fe des Zertifikats sichergehen, dass der private Schlüssel auch wirklich Alice gehört und niemand außer Alice die Nachricht entschlüsseln kann. Ebenfalls kann Alice mit Hilfe des Zertifikats von Bob prüfen, ob die Signatur stimmt und dass damit die Nachricht von Bob stammt.

Dieses Sicherstellen wird dadurch erreicht, dass die Zertifikate von Alice und Bob von Instanzen, den so genannten Certificate Authorities (CA), ausgestellt sind, denen beide vertrauen und die keine Zertifikate an Dritte, z.B. Malory ausstellen, die sich als Alice oder Bob ausgeben wollen. Wäre dies nicht gegeben, so könnte Malory sich Alice' und Bobs Zertifikat besorgen und Bob sowie Alice das eigene Zertifikat geben, in dem Malory sich als Alice, respektive Bob ausgeben würde. Damit würde Bob unwissend Nachrichten schicken, die Malory entschlüsseln und lesen könnte und weiter unter Verwendung von Alice' Zertifikat für Alice verschlüsseln und an sie schicken. Alice würde hier glauben, die Nachricht käme von Bob. Dies ist,vereinfacht, das Prinzip einer Man-In-The-Middle-Attacke (MitM).

Bei TLS unterscheidet man Verbindungen mit serverseitiger Authentifizierung und gegenseitiger Authentifizierung (mTLS). Bei der erstgenannten Art kann nur der Client die Identität des Servers anhand des Serverzertifikates prüfen. Bei der zweiten erfolgt die Prüfung gegenseitig. Der Server kann nun auch die Identität des Clients anhand des Clientzertifikates prüfen. Technisch erfolgt die Prüfung nach dem Basic Path Validation-Algorithmus, der in RFC-5280 beschrieben ist. Ein wesentlicher Teil dieser Prüfung befasst sich mit dem Aufbau der s. g. Zertifikatsketten – vom erhaltenen Teilnehmer-Zertifikat bis zu einem hinterlegten Vertrauensanker (CA-Zertifikat), um die Vertrauenswürdigkeit des Teilnehmer-Zertifikates zu verifizieren. Ein Weiterer befasst sich mit den Attributen eines Zertifikates, die u. A. besagen, für welche Zwecke und für welche Domains, Letzteres bei serverseitigen Zertifikaten, das jeweilige Zertifikat ausgestellt ist.

Abbildung der Interaktionen

Im Folgenden beschreiben wir die verschiedenen Zertifikate und erklären, wie der Cache Server für die IoT Devices transparent Updates zwischenspeichert.

Abbildung 2, Zertifikate: Beschreibung der unterschiedlichen Zertifikate und ihrer Verwendung für die Kommunikation
Abbildung 2, Zertifikate: Beschreibung der unterschiedlichen Zertifikate und ihrer Verwendung für die Kommunikation

Größere Ansicht

Zertifikat Beschreibung
A Das sog. Client-Zertifikat des Devices. Dieses wird von einer dedizierten CA ausgestellt und ist spezifisch für jedes IoT Device. Es wird verwendet, damit sich Devices gegenüber Servern der Plattform als berechtigte Devices authentifizieren können.
B Das Server-Zertifikat des Firmware Services. Mit diesem weist sich der Firmware Service als authentischer Server für die Auskunft über Firmware-Updates aus. Es wird ebenfalls von der dedizierten CA ausgestellt.
C Das Server-Zertifikat des CDNs. Hierbei handelt es sich um ein Zertifikat, das man selber beim CDN hinterlegt, so dass es Teil der eigenen Zertifikatsinfrastruktur (PKI) ist. Es wird ebenfalls von einer dedizierten CA ausgestellt und weist das CDN unter Referenzierung der CDN-Domain als die Stelle aus, von der Firmware-Fragmente heruntergeladen werden können.
D Das Zertifikat, das für den Cache Server ausgestellt wird. Es weist dieselbe CDN Domain aus, wie das Zertifikat unter C. Es wird vom Cache Server benutzt, um sich gegenüber dem IoT Device als CDN auszugeben.

Die einzelnen Schritte der Interaktion zwischen den verschiedenen Komponenten werden in der folgenden Tabelle erläutert:

Nr Beschreibung
1 Das IoT Device fragt beim Firmware Service an, ob ein Update vorhanden ist. Da der Firmware Service bei vorhandenem Update mit den Links und den Schlüsseln für die sensiblen Firmware-Fragmente antwortet, soll sich hier auch das IoT Device gegenüber dem Firmware Service authentifizieren. Hierfür findet die Kommunikation über mTLS statt. Das IoT Device vertraut dem Zertifikat des Firmware-Services (B) (über das hinterlegte CA-Zertifikat) und umgekehrt (A) (ebenfalls über das hinterlegte CA-Zertifikat).
2 Wenn sich sowohl der Firmware Service als auch das IoT Device über mTLS gegenseitig authentifiziert haben und ein Update vorhanden ist, so werden die Links zu den Fragmenten des Updates im CDN sowie die symmetrischen Schlüssel zur Entschlüsselung dieser Fragmente über den mTLS-Kanal an das IoT Device übertragen.
3 Das IoT Device versucht nun, nacheinander die Firmware-Fragmente des Updates vom CDN herunterzuladen. Durch die bereits beschriebene DNS-Umleitung redet es allerdings nicht mit dem CDN sondern stattdessen mit dem Cache Server. An dieser Stelle würde normalerweise das Gerät die Verbindung unterbrechen, denn es erwartet, dass sein Gegenüber sich mit dem Zertifikat des CDNs (C) ausweist. Allerdings stuft das Device das Zertifikat des Cache Servers (D) auch als vertrauenswürdig ein, weil dieses sowohl von einer vertrauenswürdigen CA, als auch für die selbe Domain ausgestellt ist. Hier findet also das Prinzip einer Man-In-The-Middle-Attacke Anwendung, damit der Cache Server sich zwischen das IoT Device und das CDN schalten kann. Wenn der Cache Server das angefragte Firmware-Fragment bereits lokal gespeichert hat, wird direkt mit Schritt 4 fortgefahren.
3a Wenn der Cache Server das angefragte Firmware-Fragment noch nicht lokal gespeichert hat, fragt es dieses beim CDN an. Hierfür vertraut dieser dem Zertifikat des CDNs (C).
3b Da die Firmware-Fragmente im CDN verschlüsselt abgelegt sind und in den Schritten (1) und (2) sichergestellt wurde, dass die Schlüssel nur an ein authentifiziertes Gerät ausgehändigt werden, muss die Übertragung der Firmware-Fragmente nicht über mTLS zu erfolgen. Das CDN braucht daher keinem speziellen Zertifikat zu vertrauen, sondern antwortet einfach allen Anfragen mit dem jeweiligen Firmware-Fragment.
4 Wenn der Cache Server das vom IoT Device angefragte Firmware-Fragment lokal vorliegen hat, wird dieses einfach an das IoT Device ausgeliefert. Das IoT Device kann das Fragment dann mit den in den Schritten (1) und (2) erhaltenen Schlüsseln entschlüsseln und sich, nachdem dieser Prozess für alle Fragmente abgeschlossen ist, updaten.

Hier wird schnell ersichtlich, dass das Zertifikat des Cache Servers (D) ein hohes Risiko in sich birgt. Denn wer den privaten Schlüssel für dieses Zertifikat besitzt, kann sich dem IoT Device gegenüber als vertrauenswürdig ausgeben und so die Intellectual Property unterwandern oder auch Exploits auf dieses aufbringen. Dieser private Schlüssel ist daher besonders schützenswert. Ein guter Weg, Schlüsselmaterial vor Fremdzugriff zu schützen, ist ein HSM. Das ist besonders in diesem Fall wichtig, da der Cache Server in einer nicht vertrauenswürdigen Umgebung betrieben wird.

Absicherung des Systems durch ein HSM

HSM: Hardware Security Module

Ein HSM ist für sich gesehen ein komplett eigener Computer mit einem besonders geschützten Prozessor, dessen Daten in einem geschützten Speicherbereich gehalten werden. Diese Daten sind zum Beispiel private Schlüssel, die für kryptographische Operationen benötigt werden.
Die Besonderheit ist, dass das Schlüsselmaterial ein HSM niemals verlässt. Sämtliche Interaktionen finden über API Calls statt. Es wird also immer ein Command->Result Pattern umgesetzt. Die Verbindung zwischen der Software des Systems und der Hardware selbst ist als Modul für eine OpenSSL Engine umgesetzt.

Exkurs: Die Architektur von OpenSSL

OpenSSL ist eines der Werkzeuge der Wahl, wenn es darum geht, mit Zertifikaten und Verschlüsselung zu arbeiten. Zum einen ist es standardmäßig auf den meisten unixoiden Systemen vorinstalliert, zum anderen gibt es eine Reihe von anderen Sofwarepaketen, die OpenSSL voraussetzen.

Eine Komponente von OpenSSL, welche eher unbekannt ist, wenn man sich nicht direkt verwenden muss, sind OpenSSL Engines. Eine Engine ist laut API Dokumentation:

These functions create, manipulate, and use cryptographic modules in the form of ENGINE objects. These objects act as containers for implementations of cryptographic algorithms, and support a reference-counted mechanism to allow them to be dynamically loaded in and out of the running application.

Letztendlich ist eine Engine ein Modul, das eine spezifische API implementiert und dynamisch zur Laufzeit geladen werden kann.

Schaut man sich die Architektur von OpenSSL in der Übersicht an, wird deutlich, dass eine Engine eine andere Implementierung einer Crypto API darstellt:

Abbildung 3, Übersicht der Architektur von OpenSSL
Abbildung 3, Übersicht der Architektur von OpenSSL

Größere Ansicht

Die API-Methoden, durch die mit einer OpenSSL Engine interagiert werden kann, sind in der Dokumentation ebenfalls aufgelistet:

RSA_METHOD - for providing alternative RSA implementations
DSA_METHOD, DH_METHOD, RAND_METHOD, ECDH_METHOD, ECDSA_METHOD,
STORE_METHOD - similarly for other OpenSSL APIs
EVP_CIPHER - potentially multiple cipher algorithms (indexed by ‚nid‘)
EVP_DIGEST - potentially multiple hash algorithms (indexed by ‚nid‘)
key-loading - loading public and/or private EVP_PKEY keys

Wir wir sehen, sind hier sämtliche Funktionen, die zur Handhabung von kryptographischen Primitiven benötigt werden, abstrahiert.

Wichtig für OpenSSL ist nur, dass sie vorhanden sind. Wie genau die eigentliche Implementierung innerhalb der Engines aussieht, ist für OpenSSL nicht relevant.

Verwendet werden die Engines unter anderem bei der Einbindung von Hardware-Security-Modulen (HSMs).

Das Yubi-HSM2 und sein Connector

Die Firma Yubico hat sich vor einiger Zeit durch ihren Yubikey als Werkzeug für Two Factor Authentication (2FA) einen Namen gemacht. Neben dieser Authentication Hardware bietet Yubico weiterhin ein HSM-Modul an, das mittlerweile mit dem YubiHSM 2 in der zweiten Version auf dem Markt ist. Das YubiHSM 2 ist ebenfalls (wie der Yubikey selbst) als USB Dongle umgesetzt.
Über ein SDK kann das HSM direkt eingebunden werden. Sämtliche Software Komponenten sind OpenSource

Die Systemarchitektur des YubiHSM 2 besteht aus mehreren Teilen:

Abbildung 4, Die einzelnen System-Komponenten eines HSM Setups
Abbildung 4, Die einzelnen System-Komponenten eines HSM Setups

Größere Ansicht

  • nginx und die OpenSSL pkcs11 Engine sind jeweils Software-Komponenten, die mit dem Paket-Manager des Betriebssystems installiert werden können. Die genaue Konfiguration wird in einem weiteren Blog Post beschrieben.
  • Das YubiHSM pkcs11 Modul ist Teil des YubiKey SDKs und vermittelt als Client zwischen der OpenSSL Engine API und dem YubiKey Connector.
  • Der YubiKey Connectorist eine Server-Anwendung, die über eine HTTP API eine Interaktion mit dem YubiKey HSM-Modul erlaubt. Da sich auf einem HSM mehrere Profile ablegen lassen, ist auch ein Szenario denkbar, in dem mehrere Systeme über ein YubiHSM pkcs11-Modul mit einem YubiKey Connector sprechen (sprich: mehrere Web Server „reden“ mit einem HSM System).
  • Der YubiKey Connector selbst ist in Go implementiert. Über die Standardbibliothek libUSB spricht dieser dann auch die YubiKey HSM Hardware an. Wie bereits erwähnt, werden wir dies noch genauer in einem nachfolgenden Blog Post beleuchten.

Fazit

  • Man sollte die Maßnahmen auf Basis eines vernünftigen Threat-Management-Prozesses umsetzen, um die Risiken zu verstehen. Ein privater Blog hat sicherlich andere Sicherheitsanforderungen als eine Online-Banking-Plattform.
  • Bei hohem Risiko sollte das Schlüsselmaterial nicht ungeschützt auf der Platte des Servers abgelegt werden.
  • Man sollte eine gute Begründung haben, um in die Sicherheit einer Verbindung einzugreifen.

Sollte ein hohes Risiko vorliegen und trotzdem ein guter Grund vorliegen, in die Sicherheit der Verbindung einzugreifen, ist das YubiHSM eine Möglichkeit, um das Schlüsselmaterial nicht leicht zugänglich auf der Platte zu speichern. Die genaue Konfiguration, Umsetzung und die Lösung von aufgetretenen Problemen beschreiben wir im nachfolgenden Blog Post.

Foto von Evgeny Smirnov auf Unsplash.

TAGS

Comments

Please accept our cookie agreement to see full comments functionality. Read more