Bundesamt für Sicherheit in der Informationstechnik

M 4.483 Einsatz kryptographischer Prozessoren bzw. Koprozessoren (Trusted Platform Module) bei eingebetteten Systemen

Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Entwickler, Beschaffer, Planer

Bei eingebetteten Systemen kann ein zusätzlicher Mikrocontroller verwendet werden, um kryptographische Algorithmen und Protokolle abzuarbeiten, z. B. um Hash-Funktionen und Signaturverifikation zu beschleunigen. Dieser kommuniziert mit dem System-Mikrocontroller über die Gültigkeit der Firmware-Authentifizierung.

Ab einem hohen Schutzbedarf der Vertraulichkeit oder der Integrität ist diese Kommunikation gegen Hardwareattacken widerstandsfähig zu machen, indem

  • die Leiterbahnen auf den inneren Lagen der Leiterplatte verlaufen,
  • dynamische Signale (Impulse) verwendet werden, um dem Haupt-Mikrocontroller einen erfolgreichen Bootvorgang zu signalisieren und
  • nach Möglichkeit mehrere Pins mit unterschiedlichen dynamischen Signalen verwendet werden.

Das Prinzip von Trusted Computing wird durch die Trusted Computing Group (TCG) anhand einer Reihe von Ankern für Vertrauen in einem System definiert. Wichtige Anker im Zusammenhang mit eingebetteten Systemen sind die Root of Trust for Measurement (RTM), die Root of Trust for Storage (RTS), sowie die Root of Trust for Reporting (RTR). Die Aufgabe der RTM ist es, als Anker für die Erhebung der Konfiguration einer Plattform zu dienen. Sie wird noch initialisiert, bevor das Betriebssystem gestartet wird. Beim Starten des RTM misst diese die Konfiguration der Hardware-Plattform während diese initialisiert wird, sowie die erste gestartete Software-Komponente. Danach ist sie beendet und führt keine weiteren Aktionen mehr durch. Es lassen sich also alle Änderungen an der Plattform oder der zuerst gestarteten Software-Komponente, etwa dem Bootloader, erkennen. Veränderungen an danach gestarteten Software-Komponenten, wie dem Betriebssystem oder Applikationen, werden damit nicht erkannt. Der Mechanismus für diesen Zweck verlangt, dass jede Software-Komponente die jeweils als nächstes zu startende Software-Komponente misst und die Korrektheit feststellt. Somit entsteht eine sogenannte "Trusted Chain of Measurement". Die RTM stell hierbei den Beginn der Kette dar. Die Messwerte werden mittels kryptografischer Funktionen zu Hashwerten reduziert und in gesicherten Speicherbereichen als Referenzwerte abgelegt. Die Root of Trust for Storage dient dazu, Daten sicher zu speichern und die Root of Trust for Reporting dazu sicherheitsrelevante Informationen korrekt wiederzugeben.

Eingebettete Systeme sind zwar spezialisierte Geräte aber im Gegensatz zur reinen Hardwareimplementierung ( ASIC ) universelle Rechner. Deshalb ist es auch bei eingebetteten Systemen sinnvoll und nötig, Gerätekonfiguration, Software und Daten genauer zu prüfen, ob sie verändert wurden. Die Informationen in Systemen mit hohen Anforderungen an die Integrität sollten durch den Einsatz kryptographischer Prozessoren oder Hardware-Sicherheitsmodule (Trusted Platform Module) durch das verarbeitende System authentisiert werden. Bei eingebetteten Systemen mit Kommunikationsfunktionen sollte es möglich sein, Geräte sicher zu identifizieren und mit diesen Geräten vertrauenswürdig zu kommunizieren. Darüber hinaus sollen verlässlich Zustandsinformationen über ein Gerät eingeholt werden können. Insbesondere darf es dabei nicht möglich sein, dass ein Gerät die Identität eines anderen Gerätes duplizieren kann oder dass ein Gerät Statusinformationen eines anderen Gerätes anstelle seiner selbst ausliefert.

Vertrauensanker und darauf basierende Überprüfungen können bei eingebetteten Systemen meist einfacher realisiert werden als bei einem Standard-Rechner, beispielsweise wenn Firmware zusammen mit dem Read-Only Dateisystem squashfs genutzt wird und Konfiguration und Zustand getrennt von der Software gespeichert werden. Ein RTM kann dann die komplette Firmware messen, bevor sie gestartet wird, und es muss keine komplexe Vertrauenskette aufgebaut werden. Betriebssysteme müssen dadurch nicht angepasst werden und das Laufzeitverhalten ändert sich nicht. Auch ist es nicht nötig, jede Software-Komponente einzeln zu messen. Es kann das gesamte Firmware-Image gemessen und gegen einen Referenzwert abgeglichen werden.

Prüffragen:

  • Falls ein zusätzlicher Mikrocontroller für die kryptographischen Berechnungen verwendet wird, ist dessen Kommunikation mit dem System-Mikrocontroller ausreichend abgesichert?

  • Sind für das eingebettete System die nötigen Vertrauensanker realisiert?

  • Ist für das eingebettete System eine Chain of Trust realisiert?

Stand: 15. EL Stand 2016