In vielen Bereichen müssen Hersteller garantieren, dass ein Gerät über einen gewissen Zeitraum funktioniert und die definierten Spezifikationen erfüllt. Das betrifft vor allem die Bereiche, in denen ein Ausfall eines Geräts schwerwiegende Folgen haben kann, also zum Beispiel die Luftfahrt oder die Medizintechnik.
Die dabei durch den Hersteller angestrebte Manipulationssicherheit soll unter anderem gewährleisten, dass die funktionale Sicherheit (Safety) nicht durch Dritte beeinflusst wurde und etwaige Regularien (Wartungszyklen, Nutzungszeiträume etc.) nachweisbar eingehalten wurden bzw. eine durchgeführte Manipulation nachträglich erkennbar ist.
Ein Beispiel wäre ein Reinigungs- oder Desinfektionsgerät für ein hier nicht näher spezifiziertes Objekt, welches nach 1000 erfassten Reinigungs- oder Desinfektionszyklen gewartet werden muss, um sicherzustellen, dass die Reinigungs- oder Desinfektionsleistung noch den definierten/geforderten Grenzwerten entspricht. Eine Überschreitung dieser Zyklen könnte beispielsweise zu einer unzureichenden Reinigungs- oder Desinfektionsleistung führen, was in der Medizintechnik beispielsweise gravierende Auswirkungen auf den damit behandelten Patienten haben oder das damit bearbeitete Objekt langfristig beschädigen könnte. Um dies zu verhindern, könnte das Gerät sowohl bei Überschreitung der vorgegebenen Zyklen als auch bei einer versuchten Manipulation dieser den weiteren Betrieb einstellen, bis ein Servicetechniker die ordnungsgemäße Funktionalität wieder sicherstellen kann. Das eingesetzte Gerät muss dazu beispielsweise die Anzahl der Verwendungen oder die Betriebsdauer erfassen, um den Betrieb dann zu einem passenden Zeitpunkt einstellen zu können.
Um sicherzustellen, dass solche Werte nicht manipuliert werden können, werden zumeist spezielle Sicherheitschips (Secure Element) verbaut, wie zum Beispiel der ATECC508A von Microchip.
Ein Secure Element oder Sicherheitschip bietet die Möglichkeit, Schlüsselmaterial, Zertifikate, Daten und Konfigurationen sicher zu speichern. Im Normalfall kann das Schlüsselmaterial nicht wieder ausgelesen werden. Es werden dann verschiedene kryptografische Funktionen angeboten, die vom Chip übernommen werden. Zum Beispiel können Signaturen mit dem hinterlegten Schlüsselmaterial berechnet werden. Dabei werden die zu signierenden Daten an den Chip gesendet und dieser berechnet dann die Signatur und sendet diese zurück. Das Schlüsselmaterial wird für die Berechnung verwendet, muss jedoch den Chip nicht verlassen.
Der ATECC508A bietet zusätzlich einen Zufallszahlgenerator, Speicher zum Speichern von beliebigen Daten und zwei Zähler. Für die unterschiedlichen Segmente des Speichers können verschiedene Schutzattribute gesetzt werden, die zum Beispiel keine Änderungen der gespeicherten Daten mehr erlauben.
Ein Zähler hat zwei Funktionen: eine, um den aktuellen Zählerwert um eins zu erhöhen, und die andere, um den aktuellen Wert auszulesen. Ein Zurücksetzen des Zählers ist nicht möglich.
Im Falle des ATECC508A wird die Kommunikation zum Hauptchip des Geräts über einen I2C Bus realisiert. Die Kommunikation zwischen dem Hauptchip des Geräts und dem Secure Element ist erst einmal unverschlüsselt. Für das Schreiben und das Lesen des Speichers können jedoch Schlüssel hinterlegt werden. Die Kommunikation wird dann mit diesen Schlüsseln und einer XOR-Verschlüsselung verschlüsselt.
Welche Fallstricke gibt es bei der Implementierung eines Secure Elements? Ist die Manipulationssicherheit bereits dadurch gewährleistet, dass das Secure Element nicht manipuliert werden kann?
Bei den folgenden Themen sind häufig Probleme anzutreffen:
Ein Secure Element stellt normalerweise einen sicheren Ort für Schlüsselmaterial bereit. Beim Einsatz von symmetrischer Verschlüsselung, wie zum Beispiel beim verschlüsselten Schreiben oder Lesen des Speichers beim ATECC508A, muss das Schlüsselmaterial zusätzlich auch im Hauptcontroller des Geräts gespeichert werden. Um den Schlüssel sicher zu speichern, benötigt der Hauptcontroller einen geschützten Speicherbereich, der nicht ohne Weiteres ausgelesen werden kann. Ein Ablegen des Schlüssels in der Firmware birgt daher ein großes Risiko, dass ein Angreifer das Schlüsselmaterial extrahieren kann.
Um das Auslesen zu verhindern, müssen in der Regel auch alle Debug-Schnittstellen (z. B. JTAG, SWD) des Hauptcontrollers deaktiviert sein. Über die Debug-Schnittstellen kann zumeist auf den Speicher des Hauptcontrollers zugegriffen werden. Alternativ kann ein Angreifer mit dem Debugger direkt in den Programmablauf eingreifen und das Schlüsselmaterial extrahieren. Zusätzlich sollte bedacht werden, dass die Schlüssel bei der Provisionierung für jedes Gerät individuell gewählt werden. Gelingt es einem Angreifer, aus einem Gerät die Schlüssel zu extrahieren, so kann er nicht auf den Speicher aller baugleichen Geräte zugreifen.
Es scheint, als seien die vorhandenen Zähler prädestiniert für das manipulationsfreie Zählen von Betriebsstunden. Eine Implementierung, die nach jeder zuvor definierten Bedingung den Counter erhöht, scheint auf den ersten Blick nicht manipulierbar.
Ein Angreifer, der jedoch das Gerät manipuliert und eine Machine-in-the Middle-Position auf dem I2C Bus einnimmt, kann allerdings beispielsweise den Befehl zum Erhöhen des Zählerwerts einfach nicht vom Hauptcontroller an den ATECC508A weiterleiten. Der Zählvorgang findet folglich nie statt. Da ein Angreifer in der Position auch die Antwort des ATECC508A an den Hauptcontroller manipulieren kann, ist eine Überprüfung des Zählerwerts ebenfalls manipulierbar.
Wird der I2C Bus zwischen Hauptcontroller und ATECC508A nicht in einer überprüfbar sicheren Umgebung betrieben, so müssen weitere Schritte zur Verifizierung des Zählvorgangs implementiert werden. Dabei kann eine weitere spezielle Funktion des ATECC508A helfen, die den Zähler erhöht, wenn ein hinterlegter Schlüssel verwendet wird. Hierdurch kann man eine kryptografisch verifizierbare Aktion auf dem ATECC508A auslösen und in Folge dessen einen authentifizierten Zählvorgang.
Bei einem Penetrationstest eines solchen Geräts muss die Kommunikation zwischen dem Secure Element und dem Hauptcontroller untersucht werden, um Fehler in der Implementierung zu erkennen. Dabei sind folgende Schritte notwendig:
Um den Kommunikationsablauf einfacher zu verstehen, hat die SySS eine Erweiterung für die Software Saleae Logic 2 entwickelt (https://github.com/SySS-Research/logic2-atecc508-extension), die eine solche I2C-Kommunikation mit dem ATECC508A aufgliedert.
Konnten die beiden Schlüssel zum verschlüsselten Lesen und Schreiben des Speichers aus dem Hauptcontroller extrahiert werden, so werden die Schreib- und Lesevorgänge direkt entschlüsselt dargestellt. Das erlaubt es den Mitarbeitern des Schwerpunktteams der SySS für Embedded Security (ES), die Implementierung des Secure Elements zu verstehen, Fehler im Ablauf zu identifizieren und Maßnahmen zur Gewährleistung eines möglichst sicheren Betriebs zu empfehlen.
Sie interessieren sich für einen Penetrationstest eines Geräts mit Secure Element oder anderer Hardware- bzw. IoT-Komponenten? Unser Team für Embedded Security ist gerne für Sie da. Schreiben Sie uns einfach eine kurze Nachricht an anfrage(at)syss.de.
27.01.2025
- 28.01.2025
Hack4: Angriffe gegen VoIP-Infrastrukturen
03.02.2025
Secu5: Planung und Durchführung von Penetrationstests
04.02.2025
- 05.02.2025
Hack7: Sicherheit und Einfallstore bei Webapplikationen
05.02.2025
Secu6: Krisenkommunikation bei IT-Sicherheitsvorfällen
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de | IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Direkter Kontakt
+49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN
+49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer