Wir haben doch etwas zu verbergen: Schlüssel mit OP-TEE verschlüsseln
Moderne Linux Systeme müssen häufig zwecks Authentifizierung bei einer Cloud- basierten Infrastruktur oder einer On-Premise Maschine eigene kryptografische Schlüssel speichern. Statt der Verwendung eines Trusted Platform Modules (TPM), bieten moderne ARM Prozessoren die TrustZone-Technologie an, auf deren Basis ebenfalls Schlüssel oder andere Geheimnisse gespeichert werden können. Dieses Paper zeigt die Nutzung des Open Portable Trusted Execution Environments (OP- TEE) mit der Standardkonformen PKCS#11 Schnittstellen und i.MX6 Prozessoren von NXP als Beispiel.
Durch die weitreichendere Vernetzung von Systemen und die Anforderungen an diese, auch mit anderen Systemen reden zu können, sehen wir einen immer größeren Anwendungsfall für eingebettete Linux-Systeme. Diese bringen bereits alle nötigen Komponenten und Bibliotheken mit, um über Netzwerkschnittstellen mit anderen Komponenten kommunizieren zu können. Ein Problempunkt ist häufig die Authentifizierung des Systems, das Gerät selbst soll sich kryptografisch authentifizieren können, eine Extraktion der kryptografischen Daten soll allerdings nicht möglich sein.
Die bisher häufig gewählte Vorgehensweise ist ein Trusted Platform Module (TPM), welches die kryptografischen Daten erzeugt, speichert und für kryptografische Operationen zur Verfügung stellt. Dabei stellt das TPM sicher, dass der private Teil des Privat/Öffentlichen Schlüsselpaares nicht aus diesem extrahiert werden kann.
TrustZone, OP-TEE und seine Funktionen
Auflistung der ARM exception Level (32-Bit). Der schwarze Balken in der Mitte zeigt die Trennung zwischen Secure World und Normal World, sodass die Kommunikation nur über den Secure Monitor stattfinden kann.
Als Alternative bietet sich die Verwendung der ARM TrustZone Technologie an. Moderne ARMv7 Prozessoren implementieren die TrustZone als separaten Prozessorzustand, sogenannter Secure Mode, bei dem z.B. der Arbeitsspeicher vor Zugriffen durch den normalen Prozessorzustand geschützt ist. Dies ermöglicht es, ähnlich zu einem TPM, im Secure Mode ein privat/öffentliches Schlüsselpaar zu erzeugen und nur den öffentlichen Teil an den normalen Prozessorzustand abzugeben.
Als Nutzung der TrustZone bietet sich das Open Portable Trusted Execution Environment (OP-TEE) an. Veröffentlicht unter der Open Source BSD Lizenz fallen nur die Integrationsaufwände für das eigene System an. Es implementiert die Global Platform TEE Spezifikation und kann somit Applikationen starten, die gegen diese programmiert wurden. Die Applikationen werden als Trusted Applications (TA) bezeichnet. Wichtig ist, dass OP-TEE kein klassisches Betriebssystem ist, sondern nur eine Umgebung, in welcher Datenverarbeitungsvorgänge sicher ausgeführt werden können. Es besitzt selbst keine Eigenschaften wie z.B. Scheduling. Des Weiteren verfügen aktuelle Varianten von OP-TEE über eine optionale PKCS#11 TA, welche eine PKCS#11 Standard konforme Schnittstelle bereitstellt, um im Secure Mode Schlüssel zu generieren, Zertifikate abzulegen und die dort abgelegten Schlüssel zu verwenden.
Über die PKCS#11 Schnittstelle ist dann eine Einbindung über die eigene Anwendung möglich. Dabei wird auf der Anwendungsseite OpenSSL verwendet, zusammen mit der sogenannten PKCS#11 Engine aus der libp11 Bibliothek. Diese Engine stellt die Schnittstelle zwischen PKCS#11 und einer TLS basierten Authentifizierung her. Auch ist damit z.B. die Einbindung eines Webserver Zertifikats oder der Import vorhandener Schlüssel möglich.
Kommunikation der Nutzer Applikation mit einer Trusted Applikation im OP-TEE. Dabei verwendet die Nutzer Applikation die libteeclient Bibliothek, welche das Aufsetzen der geteilten Speicherbereiche sowie das serialisieren der Parameter übernimmt. Der Kernel reicht diese dann ans OP-TEE weiter welches den Aufruf an die korrekte Trusted Applikation übergibt.
Für das Speichern von Daten hält OP-TEE zwei Möglichkeiten bereit. Dabei können zum einen die Daten verschlüsselt an das Linux System zurückgegeben werden, dieses legt die verschlüsselten Daten im Dateisystem ab. Weiterhin ist OP-TEE in der Lage, ein Feature moderner eMMC Speicher zu verwenden, die sogenannten Replay Protected Memory Blocks. Dabei wird einmalig bei der Inbetriebnahme des Systems ein Schlüssel mit der eMMC ausgetauscht, welcher anschließend für die Authentifizierung von Transaktionen wie Lesen und Schreiben verwendet wird. Durch die zusätzliche Authentifizierung ist dieser Bereich vor dem Zurückspielen alter, aber valider verschlüsselter Daten geschützt. Koordiniert wird das Speichern der Daten im Linux System vom Tee-Supplicant, einem Daemon, der für die Verwendung durch OP-TEE im Linux System gestarteti wird.
Integrationsschritte für i.MX-Prozessoren
Beispiel einer sicheren Boot-Kette mit OP-TEE, Barebox, FIT Images und DM-Verity. Das BootROM verifiziert dabei Barebox & OP-TEE, welche wiederrum einen kryptografischen Schlüssel enthalten um das FIT Image zu verifizieren. Der Kernel verwendet dann dm-verity auf einem read-only file system um sicherzustellen das keine Daten modifiziert wurden.
Als nächstes betrachten wir die notwendigen Integrationsschritte für OP-TEE auf einem i.MX6-Prozessor. Die Verwendung von OP-TEE auf beliebten Systemen, wie z.B. Raspberry-Pi 3, ist zwar möglich, aber für den Produktiveinsatz nicht ratsam, da die Raspberry-Pi Plattform nicht in der Lage ist, Bereiche des Arbeitsspeichers nur für den Zugriff aus dem Secure Mode zu unterteilen. Für diese Unterteilung ist auf dem i.MX6 Prozessor der TrustZone Address Space Controller (TZC-380), eine Standardperipherie Einheit von ARM zuständig. Diese wird von OP-TEE so konfiguriert, dass die letzten 32MiB des Arbeitsspeichers ausschließlich aus dem Secure Mode verwendbar sind. Des Weiteren benötigt OP-TEE einen Hardware Unique Key (HUK), dieser pro Prozessor einzigartige Schlüssel wird verwendet, um weitere Schlüssel abzuleiten, wie z.B. den Schlüssel, welcher zum Verschlüsseln der zu speichernden Daten verwendet wird. Auf einem Raspberry Pi 3 wird der Default Key bestehend aus Nullen verwendet, da es dort keine Möglichkeit gibt, einen für den Secure Mode einzigartigen Schlüssel zu erstellen. Fast alle i.MX6 Prozessoren (mit Ausname des i.MX6ULL/SLL) besitzen ein Crypotographic Accelerator and Assurance Module (CAAM). Dieses ist in der Lage, einen für den Secure Mode einzigartigen Hash zu erzeugen, welcher als HUK verwendet wird. Zusätzlich ist es möglich, ein Register innerhalb der CAAM zu schreiben, welches dafür sorgt, dass nach dem Schreiben ein anderer Hash erzeugt wird. Ein Zurücksetzen des Registers ist dabei nur durch einen Reset des Systems möglich. Wichtig ist zu beachten, dass dieser Hash nur für Systeme einzigartig ist, welche sich im High Assurance Boot (HAB) Modus befinden. Dies ist die von NXP implementierte Variante des Authentifizierten Bootens, bei dem der ROM-Code den zu startenden Bootloader authentifiziert. Sollte der HAB Modus nicht eingeschaltet und aktiviert worden sein, verwendet die CAAM statt des pro Prozessor einzigartigen Master Keys (MK) einen Testschlüssel, welcher für alle Prozessoren gleich ist. Daher ist eine sichere Verwendung von OP-TEE nur möglich, wenn das System per HAB gestartet wird.
Als nächstes auf der Liste stehen die am System on Chip (SoC) angebundenen Peripheriegeräte. Häufig ist nicht nur der Prozessor in der Lage, auf den Arbeitsspeicher zuzugreifen, auch die Peripherie-Geräte können als Direct Memory Access (DMA) Master Daten aus dem Arbeitsspeicher lesen und schreiben. Im Falle der i.MX6 Prozessoren ist dafür die Central Security Unit (CSU) verantwortlich. Dort werden sowohl der Zugriffsmodus für die Einheit selbst als auch die notwendigen Berechtigungen für den Zugriff auf eine Einheit festgelegt. So ließe sich als Beispiel eine serielle Schnittstelle des SoCs allein aus dem Secure Mode und damit aus dem OP-TEE zugreifbar machen. Die Standard Konfiguration für den i.MX6UL im OP-TEE ist das Einstellen aller Peripheriegeräte auf einen Normal Mode Zugriff. Dadurch kann zum Beispiel die Grafikeinheit nicht mehr auf den für den Secure Mode zugewiesenen Arbeitsspeicher zuzugreifen.
Zusammenfassung
Nach Erläuterung der Problemstellung wurden die Fähigkeiten und Limitationen von OP-TEE aufgezeigt sowie die enthaltene PKCS#11 TA kurz erläutert. Danach folgte eine Erklärung der nötigen Integrationsschritte, um OP-TEE mit i.MX6-Prozessoren sicher einsetzen zu können. Dabei wurden vor allem die nötigen Schritte zur Absicherung des Arbeitsspeichers vor fremden Zugriffen erläutert.
Weiterführende Links
Using OP-TEE to Authenticate IoT Devices
Deploying IoT devices into the field poses the question of how to authenticate these devices against your own services. While software authentication of bootloader, kernel, and filesystems ensures that only trusted software is run on the device, preventing extraction of authentication data from the device requires the use of a Trusted Platform Module (TPM) or equivalent mechanisms. This blog post introduces OP-TEE and PKCS#11 as a software alternative.
Wie man (k)ein Betriebssystem für Produkte baut
Distributionen wie Raspbian lassen die passgenaue Zusammenstellung eines Betriebssystems kinderleicht aussehen. Image herunterladen, Pakete installieren, noch ein paar Änderungen - fertig. Alles wie auf dem Laptop oder Server. Warum ein Betriebssystem aus einer klassischen Distribution im Produkt-Kontext zur Katastrophe führen kann, beleuchtet der Vortrag "Raspbian vs. Build-Systeme: Das richtige Werkzeug für solide Produkte".
Komplexität beherrschen mit Open Source
Vor ein paar Tagen ist etwas spannendes passiert: Ich habe mein allererstes Embedded System wiedergesehen - eine nach nunmehr ca. 34 Jahren defekte Schrittmotorsteuerung für die Teleskope der Volkssternwarte Rothwesten, die ich in den Sommerferien in der 12. Klasse gebaut habe. Schaut man sich die Entwicklung von damals bis hin zu unseren aktuellen industriellen Embedded Systems an, wird schnell klar, warum sowas heute nur noch mit Open Source Software sinnvoll beherrschbar ist.
Pengutronix at FrOSCon 2024
Am 17. und 18. 08. 2024 ist es wieder soweit: Die FrOSCon findet an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin statt - und Pengutronix ist wieder als Partner dabei.
umpf - Git on a New Level
Moderne Softwareentwicklung ohne begleitende Versionsverwaltung wie Git ist heutzutage unvorstellbar - Änderungen am Quellcode sollen schließlich nachvollziehbar dokumentiert und beliebige Verssionsstände jederzeit einfach reproduziert werden können. Für Arbeiten an komplexeren Projekten wie etwa dem BSP ("Board Support Package") eines eingebetteten Systems mit mehreren Entwicklungssträngen skaliert ein bloßes Aufeinanderstapeln der einzelnen Änderungen jedoch nicht.
Netdevconf 0x16
Nach längerer Zeit mit nur Online-Events findet 2022 auch die Netdev 0x16, eine Konferenz rund um die technischen Aspekte von Linux Networking, hybrid statt - online und vor Ort in Lissabon.
CLT-2022: Voll verteilt!
Unter dem Motto "Voll verteilt" finden die Chemnitzer Linux Tage auch 2022 im virtuellen Raum statt. Wie auch im letzten Jahr, könnt ihr uns in der bunten Pixelwelt des Workadventures treffen und auf einen Schnack über Linux, Open Source, oder neue Entwicklungen vorbei kommen.
Konferenzen 2021: Ein Rück- und Ausblick
Neben den Verbesserungen rund um Embedded-Linux-Software und der Weiterentwicklung des Linux-Kernels hat das Team von Pengutronix im letzten Jahr die Gelegenheit genutzt, dass viele Konferenzen vom eigenen Schreibtisch aus erreichbar waren. Dadurch konnten wir unsere Erfahrungen und Ideen noch breiter mit der Community teilen und auch an Konfrenzen Teilnehmen, die für uns sonst Flugstunden entfernt lägen.
Smart City - vom Rapid Prototyping bis zur Tragfähigen Infrastruktur
Wir wollen zum Bundesweiten Digitaltag am 18.6.2021 das Thema "Smarte Städte" ein bisschen von der technischen Seite beleuchten, aber keine Angst: es bleibt für alle verständlich.