Kernel Panic - Board on Fire   /     [Podcast] Kernel Panic - Board on Fire ~~> #004: OP-TEE und TrustZone - Geheimnisträger in der CPU

In dieser Folge erzählt Rouven Czerwinski uns was OP-TEE ist, was es mit ARM TrustZone zu tun hat und wie beides zusammen arbeitet um Geheimnisse in einem Prozessor abzulegen.

Geheimnisse können in diesem Fall zum Beispiel kryptographische Schlüssel sein, mit denen sich ein Embedded-Gerät gegenüber einem Server authentifiziert.

Diese Folge ist die erste von vier Techweek-Folgen in denen wir eine Pause von den Schauergeschichten machen und stattdessen frei über ein interessantes Thema tratschen.

Über den Kernel Panic - Board on Fire Podcast

In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann. So auch in der Welt der Software. In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen. Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch auftretenden Geistern im System führt, um bröckelnde Software, deren Quellcode schon vor Jahren verloren gegangen ist, und manchmal auch um ganz was anderes.

Shownotes

Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken orientieren:

00:00 Vorstellung und einleitende warme Worte. Diese Folge wird eine von vier Techweek-Folgen, also während der Pengutronix Techweek aufgenommenen Folgen. Zur Techweek nimmt sich die ganze Firma eine Woche Zeit um sich mit interessanten technischen Themen, abseits der üblichen Kundenarbeit, zu befassen. 02:00 Rouven erzählt von den Projekten an denen er bisher gearbeitet hat. Das heißt von Embedded-Development-Automatisierung mit labgrid über Software-Security mit OP-TEE bis zu seiner aktuellen Spezialisierung als Grafikentwickler. 10:30 Was ist OP-TEE, wo kommt es zum Einsatz und warum will man es benutzen? Ein Einsatzzweck ist es eine sichere Ablage für kryptographisches Schlüsselmaterial zu haben, bei dem der Private Key niemals das Gerät verlassen soll. Das ist z.B. relevant wenn ein Gerät, das irgendwo im Feld steht, sich gegenüber einem Cloud-Backend authentifizieren soll. 13:00 Ist das nicht auch was ein TPM (Trusted Platform Module) erreichen soll? Ungefähr. TPMs kommen aus dem x86 Desktop/Laptop/Server-Umfeld und OP-TEE aus dem ARM und Embedded-Umfeld. TPMs sind in der Regel separate Chips, während OP-TEE das TrustZone Feature von ARM CPUs nutzt, um auf dem selben Prozessor zu laufen wie das eigentliche Betriebssystem und die Anwendungssoftware. 15:00 Wann "läuft" OP-TEE? TL;DR: Wenn es aufgerufen wird. Neben OP-TEE und z.B. einem Linux läuft auf der CPU auch noch ein Secure Monitor, der OP-TEE und Linux jeweils Bereiche des Speichers zuweist und Möglichkeiten bereitstellt damit OP-TEE und Linux kommunizieren können. Im normalen Betrieb sind dann OP-TEE und Linux gleichzeitig im Speicher geladen und Linux kann über den Secure Monitor Funktionen im OP-TEE aufrufen. 23:00 Wie speichert OP-TEE geheimes Material wie z.B. Schlüssel obwohl im SoC (System on Chip) kaum Speicher (flüchtig und permanent) zur Verfügung steht? Es muss nur ein kryptographischer Schlüssel im SoC selbst gespeichert werden mit dem Daten verschlüsselt werden bevor sie z.B. auf eine eMMC ausgelagert werden. 25:00 Wie das Ablegen der Schlüssel passiert ist hardwareabhängig. Auf NXP i.MX Prozessoren muss man wenn man OP-TEE nutzen möchte auch Secure Boot/Verified Boot nutzen. Dazu wird ein Hashwert eines Public Keys in den Fuses des Prozessors abgelegt und es werden nur Bootloader gestartet, die mit diesem Public Key signiert sind. 29:30 Warum überhaupt OP-TEE wenn man doch sowieso Secure Boot macht und damit auch sicherstellen kann, dass nur ein signiertes Linux gestartet wird? Weil Linux ein sehr großes Softwareprojekt ist und deshalb eher Sicherheitslücken enthält als das vergleichsweise kleine OP-TEE. 31:00 Wie verhindert OP-TEE, dass geheime Daten den Prozessor verlassen, z.B. beim Schreiben in den externen RAM? Soweit möglich wird interner SRAM verwendet. Wird mehr Speicher benötigt werden nicht mehr genutzte Bereiche aus dem SRAM verschlüsselt und in den externen RAM ausgelagert. 35:30 Die Datenleitungen zum externen RAM sind nicht die einzige Möglichkeiten Daten des OP-TEE auszulesen. Es ist auch wichtig Peripherieeinheiten wie der Grafikeinheit eines SoCs, der JTAG Debug-Einheit oder den DMA-Einheiten den Zugriff auf OP-TEE-Speicher zu verbieten. Wie das passiert ist (mal wieder) hardwareabhängig. Ob die Einstellungen auch funktionieren muss man ausgiebig testen. 44:00 Verweis auf Talks und anderes Online-Material und Outro.