Authentifizierung eines IoT Geräts via Kryptochip

Mit der wachsenden Beliebtheit von IoT Geräten und Wearables richtet sich auch der Fokus von Hackern auf diese Plattformen. In den letzten Jahren sind viele gravierende Sicherheitslücken entdeckt und ausgenutzt worden, wie zum Beispiel die Mira Botnet Attacke in 2016 oder die Lücken in den Herzschrittmacher von St. Jude in 2017.

Die meisten Attacken basieren auf unzureichender Sicherheit von IoT Devices, welche zum Beispiel mit Standardpasswörtern oder ohne verschlüsselte Kommunikation auf den Markt gebracht werden. Das Problem dabei ist, dass sich moderne Sicherheitsalgorithmen nicht auf Geräten mit begrenztem Speicher und Rechenleistung implementieren lassen. Eine Lösung dazu bilden dedizierte Kryptochips, welche in ein IoT Gerät eingebaut werden können und somit eine vollständige Securitysuite zur Verfügung stellen.

Authentifizierung

Wir beschäftigen uns nun mit zwei Geräten: Einem IoT Gerät und einem Server. Das IoT Gerät möchte eine sichere Kommunikation mit dem Server aufbauen, doch der Server will dieses Gerät zuerst authentifizieren, bevor eine solche sichere Kommunikation aufgebauen wird. Diese Geräteauthentifizierung ist neben der eigentlichen Verschlüsselung ein zentrales Problem, welches gelöst werden muss. Ein IoT Gerät muss beweisen können, dass es dasjenige ist, für welches es sich ausgibt.

Dabei sind zwei Teile zentral:

• Ein Gerätezertifikat agiert als digitale ID. Dieses beinhaltet Infos über das Gerät, sodass der Server z.B. Zugriff auf verschiede Applikationen oder Services geben oder verweigern kann. Zudem wird ein öffentlicher Schlüssel (public key) sowie eine Signatur einer CA (Certificate Authority) mitgespeichert. Diese beiden Konzepte werden später genauer behandelt.
• Der zweite Teil ist das Lösen einer «Challenge», welche der Server dem Gerät senden kann, um die Authentizität zu beweisen. Eine solche Challenge ist so konstruiert, dass sie nur vom zum Zertifikat zugehörigen Gerät korrekt gelöst werden kann, dazu später aber mehr.

Abbildung 1: IoT Authentifizierung

Abbildung 1 zeigt das Grundkonzept einer Authentifizierung von einem IoT Gerät mit einem Server.

1. Bevor die eigentliche Authentifizierung stattfinden kann, muss das IoT Gerät ein Schlüsselpaar (privater und öffentlicher Schlüssel) generieren, den öffentlichen Schlüssel zusammen mit Zusatzinformationen wie z. B. dem Namen des Geräts usw. an eine Certificate Authority senden, und sich das Zertifikat unterschreiben lassen. Das Zertifikat wird überprüft und unterschrieben und ist von nun an vor unzulässigen Anpassungen geschützt. Jede Instanz, welche dieser CA vertraut und dessen öffentliccher Schlüssel kennt, kann dies validieren. Dieser Schritt nennt sich Provision und wird normalerweise in einer sicheren Umgebung vor der Auslieferung des Produkts durchgeführt. Dies ist nur einmalig nötig oder genauer gesagt nur nach Ablauf der Zertifikatslebensdauer erneut nötig. Ein solches Zertifikat kann dann folgendermassen aussehen:

   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number: 7 (0x7)
           Signature Algorithm: ecdsa-with-SHA256
           Issuer: C=CH, ST=ZH, O=Noser, CN=CA
           Validity
               Not Before: May  9 10:54:53 2019 GMT
               Not After : May  8 10:54:53 2020 GMT
           Subject: C=CH, ST=ZH, O=Noser, CN=Iota
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
                   pub:
                       04:be:cb:6f:6d:22:fa:af:89:56:f3:a5:4e:2e:75:
                       c6:9a:a7:b8:e9:c4:81:04:29:1b:c2:c1:2e:11:c3:
                       ba:7c:f2:42:75:ec:bf:4b:0d:33:cf:d3:f3:fe:9f:
                       29:c0:85:6a:36:34:af:4f:df:f6:ed:62:44:b7:cb:
                       47:18:1c:3c:36
                   ASN1 OID: prime256v1
                   NIST CURVE: P-256
           X509v3 extensions: ...
       Signature Algorithm: ecdsa-with-SHA256
            30:44:02:20:4c:71:81:49:9c:10:c9:c1:f7:84:59:d5:ee:5e:
            29:6c:09:c6:87:07:0f:00:8a:6e:fb:65:1a:47:48:17:7f:8e:
            02:20:62:ab:0d:f8:e5:93:89:7c:6a:90:06:16:45:28:e3:cc:
            5b:48:92:6f:d7:a8:ea:fe:f6:be:e1:d2:d9:4b:47:be

2. Nun beginnt die eigentliche Authentifizierung. Das IoT Gerät, nennen wir es Iota, möchte dem Server beweisen, dass es sich um Iota handelt. Dazu sendet es das Zertifikat, welches den Gerätenamen Iota beinhaltet und von der CA unterschrieben wurde, an den Server. Dieser kann überprüfen, ob die Signatur der CA stimmt, der Gerätename der richtige ist und das Zertifikat somit valid ist. Als Analogie dazu dient eine ID Kontrolle an einem Eingang, bei welchem überprüft wird, ob die ID nicht gefälscht ist und es sich um einen Namen handelt, welcher Zugang bekommen soll.
3. Der Server weiss nun, dass das Zertifikat valid ist, jedoch nicht, ob das Gerät auch zugehörig zum Zertifikat ist. Dieses könnte ja «gestohlen» sein und eine Anfrage könnte somit von einem falschen Gerät aus kommen. Dazu generiert der Server eine Challenge, welche im Verfahren, welches wir genauer anschauen werden ein beliebiges Datenpaket sein kann, zum Beispiel die Textnachricht «hallo…»
4. Diese Nachricht wird vom Server an Iota gesendet. Iota signiert die Nachricht mit seinem privaten Schlüssel. Diese Signatur wird zurück an den Server gesendet. Wichtig dabei ist, dass nur Iota selbst den privaten Schlüssel besitzt. Dieser darf nie das Gerät verlassen oder lesbar sein, ansonsten könnte jedes Gerät, welches den Schlüssel besitzt, die Challenge ebenso lösen.
5. Da der Server das Zertifikat des Geräts besitzt, kann er mit dem darin enthaltenen öffentlichen Schlüssel die Signatur als Antwort validieren und somit herausfinden, ob die Challenge gelöst wurde oder nicht. Sobald dies erfolgreich der Fall ist, kann in einem weiteren Schritt eine sichere Kommunikation hergestellt werden.

Public Key Kryptografie

Eine ausführliche Erklärung von Public Key Kryptografie sprengt den Rahmen dieses Blogeintrags, die wichtigsten Konzepte werden jedoch kurz aufgeführt.

Abbildung 2: Grundprinzip ECDSA Signatur

Das im vorherigen Abschnitt mehrmalig verwendete Mittel zur Authentifizierung ist die Signatur. Das Prinzip dabei ist, dass eine Nachricht mit einem privaten Schlüssel verschlüsselt wird und jede Instanz, welche den dazugehörigen öffentlichen Schlüssel (z. B. via dem Gerätezertifikat) besitzt, diese Signatur überprüfen kann. Jeder öffentliche Schlüssel validiert dabei genau einen privaten Schlüssel. Ein falsches Schlüsselpaar liefert somit immer ein invalides Resultat.

Ein solches Verfahren ist zum Beispiel das ECDSA (Elliptic Curve Digital Signature Algorithm) Verfahren. Dabei wird als Vorbereitung eine beliebige Nachricht in einen sogenannten Digest mit fixer Länge gehasht (SHA256 ist eine Implementierung eines solchen Hashingverfahren).

Mit diesem Digest und einem privaten Schlüssel wird eine mathematisch “einfache” Rechnung durchgeführt. Das Resultat ist die Signatur der ursprünglichen Nachricht. Dieser Vorgang ist insofern irreversibel, als dass ein riesiger (riesig im Sinne von: Heutzutage nicht möglicher) Rechenaufwand nötig wäre, um aus der Signatur und dem Digest den privaten Schlüssel zu errechnen.

Der Trick dabei ist jedoch, dass mit dem fast gleichen Verfahren (der Validierung statt Signierung) eine Nachricht mit zugehöriger Signatur überprüft werden kann. Dabei wird nicht der private, sondern der öffentliche Schlüssel (welcher im Gerätezertifikat gespeichert ist) verwendet. Dies erlaubt einem beliebigen Gerät, zum Beispiel unserem Server, das Validieren der Signatur.

Abbildung 3: Validieren einer Signatur

Kryptochip

Das bisher besprochene Verfahren ist nicht spezifisch für ein IoT Device, sondern gilt für alle Geräte, welche eine Public Key Kryptografiesuite installiert haben. Wie zu Beginn besprochen, fehlen genau diese oft auf IoT Geräten und es ist deshalb erforderlich, auf einen Kryptochip zurückgreifen. Zwei Konzepte sind dabei zentral:

1. Das Schlüsselpaar (privater und öffentlicher Schlüssel) wird direkt auf dem Kryptochip generiert. Dies ermöglicht, dass der private Schlüssel den Chip nie verlässt und zusätzlich vor unerlaubtem Zugriff geschützt werden kann. Der öffentliche Schlüssel hingegen, kann dem IoT Gerät zugesendet werden, welches dann die Zertifikatsgenerierung übernimmt.
2. Alle Kryptooperationen und Algorithmen finden auf dem Kryptochip statt. Dies ist nötig, falls das IoT Gerät diese Algorithmen gar nicht oder zumindest nicht gleich effizient und schnell berechnen kann. Zudem bringt es eine erhöhte Sicherheit, da zertifizierte Algorithmen in Hardware implementiert sind. Falls das Schlüsselpaar auf dem Chip generiert wurde, müssen die Algorithmen zwingend auf dem Chip ausgeführt werden, da nur dieser Zugriff auf den privaten Schlüssel besitzt.

Abbildung 4 zeigt eine Übersicht aller Schlüssel, welche für die Authentifizierung nötig sind und wo sich diese befinden. Der wichtigste Punkt dabei ist, dass der private Schlüssel auf dem Kryptochip bleibt und nur von diesem verwendet wird. Das Zertifikat, welches den öffentlichen Schlüssel beinhaltet, kann auf dem IoT Gerät gespeichert werden. Zudem wird ein CA öffentlicher Schlüssel oder Zertifikat gespeichert, sodass optional auch das IoT Gerät den Server, mit welchem später die Authentifizierung stattfindet, überprüfen kann.

Abbildung 4: Schlüssel unter Verwendung eines Kryptochips

Fazit

Ein Kryptochip kann noch für viele weitere Operationen als nur die Authentifizierung verwendet werden.

• Kryptografische Verschlüsselungsmethoden wie z.B. ECDH und AES
• Kryptografisch sicherer Zufallszahlengenerator

Zudem kann dieser konfiguriert werden, sodass nur eingeschränkter Zugriff auf die Schlüssel möglich ist (z.B. nur eine bestimmte Anzahl Aufrufe, …). In jedem Fall bieten Kryptochips eine sichere und effiziente Möglichkeit, die Sicherheit von IoT Geräten zu erhöhen.