Avatar of Felix Schumacher
Avatar of Philipp Hau├čleiter
Avatar of Dimitrij Drus

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 Artikel 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 unten verlinkten 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

Tabelle 1
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

Tabelle 2
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:

Tabelle 3
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.
  • 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.

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 in diesem Blog Post.

TAGS