Ganz sichere Verbindungen

Philipp Haußleiter

Dimitrij Drus

Felix Schumacher

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.

Größere Ansicht

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.

Größere Ansicht

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

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:

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:

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

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.