Internet der Dinge

Schutz für vernetzte Geräte durch sicheres Booten und Kryptographie

< zurück

Seite: 3/5

Anbieter zum Thema

Ein einfacherer Ansatz zur Personalisierung der Vertrauensbasis greift auf keinen vorgegebenen Schlüssel zurück. Folglich muss der öffentliche CVK entweder in einen internen Speicher geladen werden, der nur von vertrauenswürdiger Software aus diesem internen Speicher heraus beschrieben werden kann, oder in einen nicht modifizierbaren Speicher wie etwa One-Time-Programmable- (OTP-) Speicher oder verriegelten Flash-Speicher (EEPROM) in einer sicheren Umgebung.

Eine vertrauenswürdige Umgebung stellt sicher, dass der beabsichtigte öffentliche Schlüssel nicht durch einen falschen Schlüssel ausgetauscht wird, denn die Vertrauensbasis kann diesen Schlüssel nicht verifizieren. Dieser Schlüssel muss ferner durch eine Prüfsumme (CRC-32 oder Hash) geschützt sein, um Integritätsprobleme mit diesem Schlüssel sicher auszuschließen.

Bildergalerie

Um wertvollen OTP-Speicher zu sparen, kann alternativ der Schlüssel selbst in einem ungeschützten Speicher abgelegt werden, während die Prüfsumme im internen OTP-Speicher gespeichert wird.

Im Zuge dieses Personalisierungsvorgangs lassen sich auch weitere Mikrocontroller-Optionen permanent einstellen, so etwa die Deaktivierung der JTAG-Schnittstelle. So nützlich dieses Interface während der Entwicklung sein mag, muss es doch bei den Bauelementen für die Serienfertigung außer Betrieb gesetzt werden, da sonst die Vertrauensbasis umgangen werden kann.

Deployment und Wartung im Feld

Das Deployment von Geräten, die auf einem sicheren Bootvorgang basieren, unterscheidet sich grundsätzlich nicht von anderen Geräten. Um allerdings im Feld neuen ausführbaren Code zu laden, muss dieser mit dem privaten Schlüssel des Software Approvers signiert und auf einem geeigneten Weg (etwa über eine lokale Schnittstelle oder eine Netzwerkverbindung) in das Gerät gelangen.

Wird der vom Software Approver zum Signieren des Codes verwendete Schlüssel kompromittiert, kann der zugehörige öffentliche CVK ebenfalls im Feld ausgetauscht werden, sofern der neue Schlüssel mit einem Public-Key-Verifikationsschlüssel signiert wurde, der zuvor in das Gerät geladen wurde. (Bei diesem Schlüsselverifikations-Schlüssel handelt es sich um einen sogenannten Revocation-then-Update-Schlüssel.)

Ein Kompromittieren des Master Root Keys (MRK) ist dagegen nicht zielführend, da sich dieser Schlüssel nicht im Feld ersetzen lässt. Geeignete Konventionen für das Management des privaten Schlüssels mindern dieses Risiko.

Der öffentliche Schlüssel wird in einem Bereich des Flash-Speichers abgelegt, der verriegelt ist, also nicht mehr modifiziert werden kann. Wenn die Integrität des vorab programmierten öffentlichen Schlüssels oder des sicheren Bootvorgangs auf einem Verriegelungsmechanismus im Flash- oder OTP-Speicher beruht, hängt die Stärke der Integrität rein von der Stärke dieser Verriegelungstechnik ab. Jeder Angreifer, der diese Technologie überwindet, kann auch die Integrität des Geräts selbst bezwingen.

Artikelfiles und Artikellinks

(ID:43237786)

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung