Embedded Security
Manipulationssicher
Fortsetzung des Artikels von Teil 1
Manipulationssicher
Eine gesicherte Hardwareverbindung zwischen dem Hersteller und der SA ist bereits hergestellt worden. Der Hersteller loggt sich über ein passwortgeschütztes Konto in die SA-Umgebung ein, um der SA zu beweisen, dass er der Kunde ist, der er zu sein behauptet, was über das CA-Zertifikat abgeglichen werden kann. Korrelieren beide Teile dieser Information, dann kann die SA den Code per Upload entgegennehmen.
Bild 2 erklärt den Hash-Prozess. Die Hash-Funktion bildet große Datensätze auf kleinere, ebenfalls Schlüssel genannte, ab. Die Produktsoftware wird entweder mit SHA-1 oder SHA-256 in ein 160-Bit-Wort beziehungsweise ein 256-Bit-Wort »gehasht«.
Die Signatur erzeugt ein RSA-Algorithmus durch Kombinieren des privaten Codesignaturschlüssels des Herstellers mit dem Hash-Ergebnis. Diese Signatur geht über die sichere Verbindung wieder an den Hersteller zurück. Diese beiden Komponenten kommen dann zusammen mit der Produktsoftware in einen externen Flash-Speicher. Mit dem gleichen Verfahren wird die im Flash-Speicher abgelegte Produktsoftware gehasht, wodurch ein verschlüsselter Wert entsteht (R1). Andererseits findet der RSA-Algorithmus auf die im Flash abgelegte Signatur mit dem öffentlichen, im Endprodukt abgelegten Codesignaturschlüssel Anwendung. Dies ergibt den Wert R2.
Jobangebote+ passend zum Thema
Dieser öffentliche Schlüssel wird dann mit dem geheimen privaten Schlüssel gepaart, das heißt, dass R1 und R2 eine mathematische Beziehung aufweisen müssen (Bild 3). Sind die Werte gleich, so bedeutet das, dass der im integrierten Flash-Speicher abgelegte Code nicht modifiziert worden ist und somit dem ursprünglichen, in der Herstellungsphase eingeschriebenen Code entspricht.
Unterscheiden sie sich, dann heißt das, dass die Produktsoftware geändert wurde und dass angesichts einer solchen unerwünschten Änderung der Bootvorgang abzubrechen ist. Dieses Konzept erfordert einige Vorkehrungen.
Könnte ein Hacker die privaten beziehungsweise öffentlichen Schlüssel ändern, so könnte er neue Produktsoftware mit einer neuen, mit dem privaten Schlüssel des Hackers gehashten Signatur laden. Das Endprodukt könnte dann booten und denselben Vergleichsprozess mit einem neuen Schlüsselpaar für die Schadsoftware durchlaufen.
Der Mechanismus für das sichere Booten kann das neue Software-Upgrade nicht erkennen, weil der Vergleich ja mit der Paarung eines öffentlichen Schlüssels und des privaten Schlüssels des Hackers durchgeführt wurde. Der öffentliche Schlüssel sollte also stets gut geschützt sein. Deshalb werden öffentliche Schlüssel im ROM oder im OTP abgelegt, je nachdem, ob Flexibilität oder eine möglichst kompakte Realisierung im Vordergrund stehen. Weiterhin muss der Hersteller sicherstellen, dass während des Bootens Zugriffsversuche auf das Produkt erfolglos bleiben, mit denen die Bootsequenz geändert oder die Sicherheitsaspekte der authentifizierten Software umgangen werden könnten.
Die Realisierung in ROM, das auf dem Chip integriert ist, kann dies verhindern. Integrität und Authentifizierung bestimmen also die Sicherheit des Bootprozesses maßgeblich. Die Realisierung eines sicheren Bootvorgangs ist relativ komplex, denn es geht darum, das geistige Eigentum, die Unabhängigkeit und die finanziellen Belange des Herstellers zu schützen. Wichtige Faktoren sind die Zuverlässigkeit und die Vertrauenswürdigkeit der CA - diese bilden ganz eindeutig die Grundlage dieses Konzepts, zusammen mit dem Schutz der entsprechenden Elemente wie der Schlüssel. Ist diese Vertrauenswürdigkeit nicht gegeben, so ist die Sicherheit des Bootvorgangs sehr leicht zum Scheitern verurteilt, mit allen negativen Folgen für Geschäft, Finanzen und Technik.
- Manipulationssicher
- Manipulationssicher
- Manipulationssicher
- Manipulationssicher
Lesen Sie mehr zum Thema
