-
Hintergrund der Erfindung
-
Sicherheitsmechanismen werden von immer höherer Wichtigkeit in der Elektronik. Die Hersteller von Systemen und Vorrichtungen, die in Systemen verwendet werden, wünschen zu kontrollieren, wie Systeme und Vorrichtungen verwendet werden (zum Beispiel nicht autorisierte Verwendungen zu stoppen) und Programme (zum Beispiel Betriebssysteme und Anwendungen) und Inhalt von einer Vervielfältigung, nicht autorisierter Modifikation und dergleichen zu schützen. Entsprechend können die Hersteller von Vorrichtungen es nötig haben, Vorrichtungsniveausicherheitsmechanismen und/oder Systemniveausicherheitsmechanismen zu liefern. Die Vorrichtungs- und/oder Systemsicherheitstechniken können es auch nötig machen, Endbenutzersicherheitsmechanismen zu liefern, um zu kontrollieren, wie Systeme und Vorrichtungen verwendet werden (zum Beispiel nicht autorisierte Verwendungen stoppen) und um Programme (zum Beispiel Betriebssystemen und Anwendungen) und Inhalt vor Vervielfältigung, nicht autorisierten Modifikationen und dergleichen zu schützen.
-
Die Herstellung von Elektronik kann auch zahlreiche Entitäten mit sich bringen. Zum Beispiel kann ein Vorrichtungshersteller eine gegebene Vorrichtung designen, jedoch die tatsächliche Herstellung der Vorrichtungen outsourcen. Ähnlich kann ein Systemhersteller das System designen, aber die tatsächliche Herstellung des Systems outsourcen. Obwohl einige Parteien einander trauen können, können nicht alle Parteien allen anderen Entitäten trauen, die in das Design und die Herstellung von Systemen und Vorrichtungen involviert sind. Zum Beispiel können die Vorrichtungs- und Systemhersteller einander trauen, jedoch der Vorrichtungshersteller kann möglicherweise dem Montagehaus, welches von dem Systemhersteller verwendet wird, nicht trauen oder kann es nicht wollen oder die Möglichkeit haben, das Montagehaus, welches von dem Systemhersteller verwendet wird, zu überwachen, um sicherzustellen, dass dem Montagehaus mit Zugang zu Software, Firmware, Konfigurationsparametern und/oder dergleichen getraut werden kann.
-
Entsprechend gibt es ein anhaltendes Bedürfnis für verbesserte Techniken, welche Vorrichtungs- und/oder Systemsicherheitsmechanismen liefern. Die Sicherheitsmechanismen sollten auch Schutz an verschiedenen Stufen der Herstellung von dem Vorrichtungsdesign zu der Systemherstellung liefern.
-
WO 2006/086301 A1 offenbart ein System und Verfahren zum Bereitstellen einer sicheren Boot-Architektur. Das System weist einen Prozessor, der eine atomare Zustandsmaschine hat, und einen physikalisch geschützten Speicherbereich auf. Die atomare Zustandsmaschine speichert einen Zustand des Prozessors in einer Zustandsspeicher-Abbildung bei einem Boot-Modus-Ereignis. Die atomare Zustandsmaschine authentifiziert auch ein Objekt eines Vor-BIOS-Boot-Vektor-Bereichs (Pre-BIOS Boot Vector Region, PBBVR) in Antwort auf das Boot-Modus-Ereignis. Der PBBVR kann in dem physikalisch geschützten Speicherbereich gespeichert werden. Die atomare Zustandsmaschine lädt den PBBVR von dem physikalisch geschützten Speicherbereich in einen Überlagerungsspeicherm wenn der PBBVR erfolgreich authentifiziert ist. Der Prozessor führt den PBBVR von dem Überlagerungsspeicher aus, wenn der PBBVR erfolgreich authentifiziert ist. Die atomare Zustandsmaschine kann auch ein Kandidaten-PBBVR-Upgrade-Bild empfangen, das Kandidaten-PBBVR-Upgrade-Bild authentifizieren, und den aktuellen PBBVR mit einem neuen PBBVR ersetzen, der in dem Kandidaten-PBBVR-Upgrade-Bild enthalten ist, wenn der neue PBBVR in dem Kandidaten-PBBVR-Upgrade-Bild authentifiziert ist.
-
US 2006/0174240 offenbart einen Mechanismus, der ermöglicht, dass Firmware auf sichere Weise aktualisiert wird. Zwei Attribute werden in dem aktuellen ROM verwendet, um auf ein virtuelles ROM-Modul zu verweisen. Die zwei Attribute sind ein Versionsattribut und eine Referenz zu einem separaten Attribut, das fähig ist, Aktualisierungen zu validieren. Der Aktualisierungsprozess aktualisiert den Nachrichtenhashwert, der mit dem ersten virtuellen ROM-Modul assoziiert ist, und das Versionsattribut, das mit dem ersten virtuellen ROM-Modul assoziiert ist. Der Aktualisierungsprozess erzeugt auch eine neue Kopie der korrespondieren Datei, die, wenn gehasht, zu dem neuen Nachrichtenhashwert „passen” wird.
-
WO 2008/009112 A1 offenbart ein Verfahren und System zum Authentifizieren und Sichern einer eingebetteten Vorrichtung. Das Verfahren verwendet eine sichere Boot-Prozedur und einen vollständig nicht-flüchtigen Speicher-Verschlüsselungsprozess, der ein Elliptische-Kurve-Pinstov-Vanston-Signatur (ECPV) Schema mit Nachrichtenwiederherstellung auf einem personalisierten BIOS und einem Master-Boot-Programm implementiert. Die Signatur weist Code auf, der wiederhergestellt wird, um einen Schlüssel zu entsperren, der im Gegenzug verwendet wird, um den nicht-flüchtigen Speicher zu entschlüsseln. Die Verwendung des ECPVS stellt eine implizite Verifizierung bereit, dass die Hardware an das BIOS gebunden ist, da der verschlüsselte Speicher nutzlos ist, außer wenn er ordnungsgemäß mit dem ordnungsgemäßen Schlüssel entschlüsselt ist.
-
US 6 185 678 B1 offenbart einen sicheren Starprogrammprozess, in dem der Startprogrammprozess als eine Kette von stufenweise höheren Abstraktionslevels sequenziert ist, und in dem jede Schicht benötigt wird, um eine digitale Signatur der nächsten Schicht zu überprüfen, bevor die Steuerung an sie weitergegeben wird.
-
Zusammenfassung der Erfindung
-
Vorrichtungen der vorliegenden Technologie sind auf Techniken zum sicheren Herunterladen von Bootcode in ein gesichertes System gerichtet. In einer Ausführungsform wird ein Verfahren gemäß den Merkmalen von Patentanspruch 1 ausgeführt, wobei ein erster Teil von Bootcode, welcher auf einem Chip gespeichert ist, ausgeführt wird, um eine sichere Vertrauenskette zu erstellen. Danach wird ein gesicherter Bootschlüssel erhalten und ein verschlüsselter Bootloader wird von einer Peripherievorrichtung gelesen. Der Bootloader wird entschlüsselt und authentifiziert unter Verwendung des sicheren Bootschlüssels. Wenn der Bootloader erfolgreich entschlüsselt und authentifiziert ist, wird er ausgeführt. Andernfalls wird die Vorrichtungskennung des Chips rundgesendet. In Reaktion auf das Rundsenden (engl. broadcasting) der Vorrichtungskennung wird eine selbstvalidierende Mitteilung empfangen. Die Mitteilung wird validiert unter Verwendung des sicheren Bootschlüssels und in ein Peripheriegerät zur Ausführung geladen, wenn die Mitteilung gültig ist.
-
Kurze Beschreibung der Zeichnungen
-
Ausführungsformen der vorliegenden Erfindung werden als Beispiel und nicht als Beschränkung in den Figuren der begleitenden Zeichnungen veranschaulicht und in welchen ähnliche Bezugszahlen sich auf ähnliche Elemente beziehen und in welchen:
-
1 ein Blockdiagramm eines exemplarischen Systems zum Implementieren von Ausführungsformen der vorliegenden Technologie zeigt.
-
2A–2D ein Flussdiagramm eines Verfahrens der Handhabung von Speicherschlüsseln während einer Vielzahl von Leistungszuständen der Vorrichtung zeigen, gemäß einer Ausführungsform der vorliegenden Technologie.
-
3A–3E ein Flussdiagramm eines Verfahrens des sicheren Updatens des Bootcodes der Vorrichtung ohne Kenntnis eines Bootschlüssels zeigt, gemäß einer Ausführungsform der vorliegenden Technologie.
-
4A–4B ein Flussdiagramm eines Verfahrens des sicheren Updatens des Bootcodes der Vorrichtung ohne Kenntnis eines Bootschlüssels zeigen, gemäß einer Ausführungsform der vorliegenden Technologie.
-
5A–5B ein Blockdiagramm eines Beispiel-Recovery-Modus-Systems gemäß Ausführungsformen der vorliegenden Technologie zeigt.
-
6 ein Blockdiagramm einer exemplarischen Recovery-Modus-selbstvalidierenden Mitteilung gemäß einer Ausführungsform der vorliegenden Technologie zeigt.
-
Detaillierte Beschreibung der Erfindung
-
Nun wird im Detail Bezug genommen auf die Ausführungsformen der vorliegenden Technologie, von welcher Beispiele in den begleitenden Zeichnungen veranschaulicht sind.
-
Bezug nehmend auf 1 ist ein exemplarisches System zum Implementieren von Ausführungsformen der vorliegenden Technologie dargestellt. Das exemplarische System 105 umfasst eine Vorrichtung 110 und eines oder mehrere Peripheriegeräte 115–130. Die Peripheriegeräte 115–130 können interne und/oder externe Peripheriegeräte wie zum Beispiel Tastatur, Cursorsteuerung, Kommunikationsport, Rechenvorrichtungs-lesbares Medium (CDRM) (zum Beispiel Festplattentreiber (Hard Disk Driver, HDD) 125, Direktzugriffsspeicher (Random Access Memory, RAM) 130) und/oder dergleichen sein. Die Peripheriegeräte 115–130 können an die Vorrichtung 110 durch einen oder mehrere Kommunikationskanäle gekoppelt sein. Die Vorrichtung 110 umfasst eine immer-an (always on, AO) Domäne 135 und eine oder mehrere steuerbare Leistungsdomänen 140, 145. Die AO-Domäne 135 hat immer Energie und, wenn anwendbar, Taktsignale angelegt, wenn die Vorrichtung angeschaltet ist. Die AO-Domäne kann eine Echtzeituhrfunktionseinheit, eine Leistungsmanagementcontrollerfunktionseinheit, eine Tastaturcontrollerfunktionseinheit und/oder eine Speicherregisterfunktionseinheit umfassen. Die steuerbaren Leistungsdomänen 140, 145 können eine oder mehrere steuerbare Versorgungspotentialdomänen 140 und/oder eine oder mehrere steuerbare getaktete Domänen 145 umfassen. Die eine oder mehreren steuerbaren Versorgungspotentialdomänen 140 können eine oder mehrere On-Chip-rechenvorrichtungslesbare Medien (CDRM) 150, eine oder mehrere allgemeine Prozessiereinheiten (zum Beispiel CPU) 155, eine oder mehrere spezialisierte Prozessiereinheiten (zum Beispiel GPU) 160, eine oder mehrere Funktionseinheiten (zum Beispiel fortgeschrittene Verschlüsselungsstandard(AES)maschine (advanced encryption standard (AES) engine)) 165 und eine oder mehrere Systemcontroller 170–180 aufweisen. Die eine oder mehreren steuerbaren getakteten Domänen 145 können eine oder mehrere spezialisierte Prozessiereinheiten und/oder Funktionseinheiten 185 umfassen. Entsprechend kann die Vorrichtung 110 als eine System-auf-einem-Chip-integrierte Schaltung (system an a chip (SOC) integrated circuit) bezeichnet werden.
-
Das On-Chip CDRM 150 speichert einen ersten Teil von Bootcode zum Konfigurieren der Vorrichtung und Laden anderer Teile des Bootcodes, Betriebssystems (OS), Interrupt Handler und Anwendungen von einem oder mehreren peripheren nicht flüchtigen CDRMs (z. B., HDD, Flash Medium) 125 in ein oder mehrere CDRMs (z. B. RAM) 130, welche zugreifbar sind für die allgemeinen und/oder spezialisierten Prozessiereinheiten 155, 160. Die allgemeine Prozessiereinheit (zum Beispiel CPU) 155 liefert die Rechenhardwareressource zum Ausführen allgemeiner Software-basierter Funktionalität der Vorrichtung 110. Solche Softwarefunktionalität kann ein Ausführen von Betriebssystem (OS) Software, Interrupt-Handling-Software, die der Vorrichtung hilft, auf externe Ereignisse zu antworten, Anwendungssoftware und dergleichen umfassen. Die spezialisierten Prozessoren (z. B. GPU) liefern Rechenhardwareressourcen zum Ausführen spezialisierter Funktionalitäten, wie beispielsweise eine Graphikprozessiereinheit (GPU) 160, Digitalsignalprozessieren, Videoencoder/Decoder und/oder dergleichen. Die Systemcontroller 170–180 liefern verschiedene Funktionalitäten zum Kommunizieren zwischen einem Funktionselement der Vorrichtung 110 mit den Peripheriegeräten 115–130.
-
Die Vorrichtung 110 des Systems 105 ist angepasst zum Handhaben von Speicherschlüsseln während einer Vielzahl von Leistungszuständen der Vorrichtung. Die Vorrichtung 110 ist auch angepasst zum sicheren Updaten des Bootcodes der Vorrichtung ohne Kenntnis eines Bootschlüssels. Zusätzlich ist die Vorrichtung 110 auch angepasst zum Liefern eines sicheren Recovery-Modus.
-
Nun Bezug nehmend auf die 2A–2D ist ein Speicherschlüsselhandhabungsverfahren während einer Vielzahl von Leistungszuständen der Vorrichtung gemäß einer Ausführungsform der vorliegenden Technologie dargestellt. Anfänglich führt die Vorrichtung 110 des Systems 105 ein Bootprogramm aus, zum Einrichten der Vorrichtung 110 zum Ausführen einer oder mehrere Anwendungen. Das Bootprogramm umfasst typischerweise eine oder mehrere Teile. Der erste Teil des Bootprogramms ist in dem On-Chip ROM 150 gespeichert und wird hierin als Boot-ROM-Code (BR) bezeichnet. Bei 202 wird der BR von der Prozessiereinheit 155 ausgeführt, um eine Vertrauenskette zu bilden. Während der Ausführung des BR werden ein sicherer Bootschlüssel (secure boot key, SBK), ein Vorrichtungsschlüssel (device key, DK) und eine Vorrichtungskennung (device identifier, DID) zugegriffen und der SBK wird in einen entsprechenden SBK-Schlüsselschlitz geladen, welcher zugreifbar ist durch eine Verschlüsselungs-/Entschlüsselungsmaschine, bei 204. Die Verschlüsselungs-/Entschlüsselungsmaschine unterstützt Lese-, Schreib-, Verschlüsselungs- und Entschlüsselungszugang zu den Schlüsselschlitzen. Beständige (persistente) oder „klebrige” Bits steuern den Lese- und Schreibzugriff zu dem Schlüsselschlitz, verhindern aber nicht den Zugang zu Verschlüsselungs-/Entschlüsselungsoperationen. Der SBK wird von dem Vorrichtungshersteller verwendet zum Schützen und Authentifizieren von Teilen des Bootcodes, welcher Off-Chip (z. B. in einem Peripheriegerät) gespeichert ist. In anderen Implementierungen ist der SBK ein sicherer Schlüssel, welcher von dem Vorrichtungshersteller ausgewählt ist und/oder von dem Systemhersteller ausgewählt/diesem bekannt ist. In einer Implementierung ist der SBK in ein SBK-Register, wie beispielsweise als On-Chip-Sicherungen programmiert. Deshalb ist der SBK modifizierbar, kann jedoch nicht auf einen vorigen Wert zurückgesetzt werden. In einer Implementierung ist der SBK nur durch einen gesicherten Code lesbar. In einer Implementierung ist der gesicherte Code ein BR-Code. In einer Implementierung ist der SBK ein 128 Bit-Schlüssel. In einer Implementierung ist der DK ein sicherer Wert, welcher dem Systemhersteller bekannt ist. In einer Implementierung ist der DK in ein DK-Register, wie beispielsweise On-Chip-Sicherungen programmiert. Deshalb ist der DK ebenfalls modifizierbar, aber kann nicht auf einen vorigen Wert zurückgesetzt werden. In einer Implementierung ist der DK nur durch einen gesicherten Code lesbar. In einer Implementierung ist der gesicherte Code ein BR-Code. In einer Implementierung ist der DK ein 32-Bit-Schlüssel. In einer Implementierung ist der DID ein vorrichtungsspezifischer Wert, welcher in On-Chip-Sicherungen durch den Hersteller programmiert und öffentlich zugänglich ist. In einer Implementierung ist der DID ein 64-Bit-Wert.
-
Bei 206 wird ein sicherer Systemschlüssel (secure system key, SSK) von dem SBK, DK und DID berechnet und geladen in einen entsprechenden SSK-Schlüsselschlitz, welcher zugreifbar ist durch die Verschlüsselungs-/Entschlüsselungsmaschine. Der sichere Speicherschlüssel (secure storage key, SSK) wird von dem Systemhersteller verwendet zum Schützen von kundendefinierten Daten. Der SSK wird berechnet von dem Vorrichtungshersteller-programmierten sicheren Bootschlüssel (SBK), dem Systemhersteller-programmierten Vorrichtungsschlüssel (DK) und der Vorrichtungshersteller-programmierten eindeutigen Vorrichtungskennung (unique device identifier, UID). Der SSK kann in einer Implementierung wie folgt berechnet werden: SSK = AES (SBK; DID^AES(SBK; DK))
-
Der Vorrichtungshersteller programmierte DID ist für jeden Chip verschieden. Entsprechend ist der SSK ebenfalls eindeutig für jeden Chip. Zusätzlich kann der SBK auch eindeutig sein für jeden Chip oder gemeinsam sein über mehrere Chips (zum Beispiel ein Los), wie von dem Systemhersteller bestimmt. Der DK kann ebenfalls eindeutig für jeden Chip oder gemeinsam über mehrere Chips sein.
-
Bei 208 wird der SSK in ein SSK-Register in der AO-Domäne 135 der Vorrichtung 110 geladen. Leeren (flushing) des SBK von dem SBK-Schlüsselschlitz hindert anderen Code, welcher nicht explizit mit dem SBK authentifiziert ist, an dem Durchführen von Verschlüsselungs-/Entschlüsselungsoperationen mit dem SBK. Bei 210 wird ein zusätzlicher Teil des Bootcodes, welcher als der Bootloader (BL) bezeichnet wird, von einem gegebenen Peripheriegerät gelesen, welches zum Speichern des Bootloaders spezifiziert ist. Der Bootloader, welcher auf dem Peripheriegerät gespeichert ist, ist verschlüsselt. Bei 212 wird der Bootloader entschlüsselt unter Verwendung des SBK, wodurch der Bootloader authentifiziert wird. Der Bootloader kann weiter authentifiziert werden unter Verwendung eines Auszuges, digitalen Zertifikates oder dergleichen basierend auf einer Authentifizierungstechnik. Entschlüsseln und Authentifizieren des Bootloaders unter Verwendung des SBK hält die sichere Vertrauenskette aufrecht.
-
Das SSK-Register in der AO-Domäne umfasst Sicherheitsregelungen, welche das Register gegen Lesen und Schreiben von außerhalb des BL schützen. In einer Implementierung umfasst das sicherheitskontrollierte SSK-Register persistente Lese- und Schreibbits. Wenn der SSK von dem BR bei 208 in das SSK-Register geladen wird, wird ein Leseklebebit gesetzt (den Lesezugriff deaktivierend), aber nicht das Schreibklebebit (nachfolgenden Schreibzugriff erlaubend), bei 214. Zusätzlich werden die SBK und SSK-Schlüsselschlitze durch persistente Lese-/Schreibbits geschützt, die durch den BR gesetzt werden, um einen Zugriff von außerhalb des BRs zu verhindern.
-
Bei 216 wird der BL durch die Prozessiereinheit 155 ausgeführt, wenn der BL erfolgreich entschlüsselt und authentifiziert ist. Während der Ausführung des BL werden eine oder mehrere Anwendungen von einem oder mehreren Peripheriegeräten gelesen, bei 218. In einer Implementierung können die Anwendungen in verschlüsselter Form gespeichert sein. Bei 220 werden verschlüsselte Anwendungen entschlüsselt unter Verwendung des SSK.
-
Bei 222 kann die Vorrichtung 110 dem Systemhersteller optional erlauben, den SSK zu ändern. Wenn der SSK durch den Systemhersteller geändert wird, wird der neue SSK in dem entsprechenden SSK-Schlüsselschlitz gespeichert und der SSK wird gespeichert in dem sicherheitskontrollierten Register in der AO-Domäne, bei 224. Da das Schreibbit bei 214 nicht gesetzt ist, wenn der SSK in das SSK-Register in der AO-Domäne geschrieben wird, kann der SSK von dem Systemhersteller geändert werden und kann wiederhergestellt werden, wenn die Verschlüsselungs-/Entschlüsselungsmaschine von einem niedrigen Leistungszustand zurückkehrt. Jedoch kann, wenn der SSK in dem SSK-Register der AO-Domäne bei 222 überschrieben wird, das persistente Schreibbit gesetzt werden, um weitere Überschreibungen zu verhindern. Schreibzugriff auf den Schlüsselschlitz, welcher den SSK hält, kann an diesem Punkt ebenfalls deaktiviert werden durch Setzen seines persistenten Schreibbits und dadurch Verhindern von weiteren Überschreibungen. Nachdem der SSK geändert ist, werden, wenn anwendbar, die Anwendungen ausgeführt, bei 226. Die Anwendungen können das OS, Interrupt-Routinen, Utilities und Benutzeranwendungen wie beispielsweise Musikspieler, Spiele, Zellulartelefone, GPS und dergleichen umfassen.
-
Bei 228 können eine oder mehrere Domänen, von denen eine die Verschlüsselungs-/Entschlüsselungsmaschine 165 umfasst, in einen niedrigen Leistungszustand zykliert werden. Ein neuerlicher Start (Re-Start) tritt auf, wenn die Domäne aus dem niedrigen Leistungszustand herauszykhert, bei 230. Während der Ausführung des BL in Reaktion auf den neuerlichen Start wird ein Code, welcher in einem oder mehreren Peripheriegeräten (zum Beispiel RAM) verbleibt, validiert und der Zugriff zu dem sicherheitskontrollierten SSK-Register in der AO-Domäne wird zurückgesetzt, um Lese- und Schreibzugriff zu erlauben, bei 232. Bei 234 wird der SSK von dem sicherheitskontrollierten SSK-Register der AO-Domäne in den SSK-Schlüsselschlitz gelesen. Wenn der SSK von dem SSK-Register in den entsprechenden Schlüsselschlitz für die Verschlüsselungs-/Entschlüsselungsmaschine durch den BL gelesen wird, werden das Lesesperr- und das Schreibsperr-persistente Bit gesetzt, bei 236. Danach werden eine oder mehrere Anwendungen von einem oder mehreren Peripheriegeräten gelesen, bei 238. In einer Implementierung können die Anwendungen in verschlüsselter Form gespeichert sein. Bei 240 wird jede verschlüsselte Anwendung entschlüsselt unter Verwendung des SSK. Bei 242 werden die Anwendungen ausgeführt.
-
Entsprechend behalten Ausführungsformen der vorliegenden Technologie vorteilhafterweise den Systernspeicherschlüssel (SSK) in der AO-Domäne bei und stellen den SSK zu der Verschlüsselungs-/Entschlüsselungsmaschine wieder her, wenn die Maschine wieder angeschaltet wird. Der SSK ist jedoch nur von dem BL zugreifbar, was eine sichere Vertrauenskette liefert. Zusätzlich erlauben Ausführungsformen optional, dass der SSK upgedatet wird.
-
Nun Bezug nehmend auf die 3A bis 3E ist ein Verfahren sicheren Updatens des Bootcodes der Vorrichtung ohne Kenntnis eines Bootschlüssels, gemäß einer Ausführungsform der vorliegenden Technologie, dargestellt. Wieder wird der BR ausgeführt (zum Beispiel Kaltboot) durch die Prozessiereinheit 150, um eine Vertrauenskette herzustellen, bei 302. Während der Ausführung des BR wird auf einen sicheren Bootschlüssel (SBK), einen Vorrichtungsschlüssel (DK) und eine Vorrichtungskennung (DID) zugegriffen und der SBK wird in einen entsprechenden SBK-Schlüsselschlitz geladen, welcher zugreifbar ist durch eine Verschlüsselungs-/Entschlüsselungsmaschine, bei 304. Das SBK-Register ist geschützt durch persistente Lese-/Schreibbits, die gesetzt werden durch den BR nach dem Prozessieren des SBK, um einen Zugriff von außerhalb des BR zu verhindern. Bei 306 wird ein sicherer Systemschlüssel (SSK) von dem SBK, DK und DID berechnet und geladen in einen entsprechenden SSK-Schlüsselschlitz, wie oben detaillierter beschrieben ist.
-
Bei 308 wird der SSK in ein SSK-Register in der AO-Domäne 135 der Vorrichtung 110 geladen. Bei 310 wird ein zusätzlicher Teil von Bootcode, welcher als der Bootloader (BL) bezeichnet wird, von einer gegebenen Peripherievorrichtung, welche für das Speichern des BL spezifiziert ist, gelesen. Der auf dem Peripheriegerät gespeicherte BL wird verschlüsselt. Bei 312 wird der Bootloader unter Verwendung des SBK entschlüsselt, wodurch der Bootloader authentifiziert wird. Der Bootloader kann weiter authentifiziert werden unter Verwendung einer auf einer Zusammenfassung, einem digitalen Zertifikat oder dergleichen basierenden Authentifizierungstechnik. Entschlüsselung und Authentifizierung des Bootloaders unter Verwendung des SBK erhält die sichere Vertrauenskette aufrecht.
-
Bei 314 wird der BL ausgeführt durch die Prozessiereinheit 155, wenn der BL erfolgreich entschlüsselt und authentifiziert ist. Während der Ausführung des BL wird der SBK von dem Schlüsselschlitz gelöscht (flushed), bei 316. Der SBK kann gelöscht werden durch Überschreiben mit allen Nullen oder einem anderen Mustern. Danach werden eine oder mehrere Anwendungen von einem oder mehreren Peripheriegeräten gelesen, bei 318. In einer Implementierung können die Anwendungen in verschlüsselter Form gespeichert sein. Bei 320 wird jede verschlüsselte Anwendung unter Verwendung des SSK entschlüsselt. Bei 322 werden die Anwendungen ausgeführt. Die Anwendungen können das OS, Interrupt-Routinen, Utilities und Benutzeranwendungen wie beispielsweise Musikspieler, Spiele, Zellulartelefone, GPS und dergleichen umfassen.
-
Bei 324 wird ein neuer Bootloader von einem Serviceprovider empfangen. Der neue Bootloader kann kodiert werden unter Verwendung von Verschlüsselung mit öffentlichem Schlüssel oder dergleichen. An einem Punkt danach wird die Vorrichtung erneut gestartet (z. B. kaltes Booten). Bei 326 wird der BR ausgeführt in Reaktion auf ein erneutes Starten. Während der Ausführung des BR werden ein sicherer Bootschlüssel (SBK), ein Vorrichtungsschlüssel (DK) und eine Vorrichtungskennung (DID) zugegriffen und der SBK wird in einen entsprechenden SBK-Schlüsselschlitz geladen, welcher zugreifbar ist durch eine Verschlüsselungs-/Entschlüsselungsmaschine, bei 328. Das SBK-Register ist geschützt durch persistente Lese-/Schreibbits, die durch den BR gesetzt werden nach dem Zugreifen auf den SBK zum Verhindern eines Zugreifens von außerhalb des BR. Bei 330 wird ein sicherer Systemschlüssel (SSK) von dem SBK, DK und DID berechnet und geladen in einen korrespondierenden SSK-Schlüsselschlitz, wie oben detaillierter beschrieben. Bei 332 wird der SSK in ein SSK-Register in der AO-Domäne 140 der Vorrichtung 110 geladen. Der neue Bootloader wird dann von dem Peripheriegerät gelesen, bei 334. Der neue Bootloader wird typischerweise in einem verschlüsselten Format gespeichert werden. Bei 336 wird der neue Bootlader, welcher von dem Serviceprovider empfangen wurde, authentifiziert. Bei 338 wird der neue Bootloader verschlüsselt unter Verwendung des SBK und gespeichert in dem gegebenen Peripheriegerät, welches zum Speichern des BL spezifiziert ist. Bei 340 wird der SBK von dem Schlüsselschlitz gelöscht. Das Leseklebebit für den SSK wird gesetzt (Lesezugriff deaktivierend), aber nicht das Schreibklebebit (nachfolgenden Schreibzugriff erlaubend), bei 342. Zusätzlich werden die SBK und SSK-Schlüsselschlitze geschützt durch persistente Lese-/Schreibbits, die durch den BR gesetzt werden, um einen Zugriff von außerhalb des BR zu verhindern.
-
Bei 344 wird der neue BL ausgeführt durch die Prozessiereinheit 155, wenn der neue BL erfolgreich entschlüsselt und authentifiziert ist. Bei 346 werden eine oder mehrere Anwendungen von einem oder mehreren Peripheriegeräten gelesen während der Ausführung des neuen BL. In einer Implementierung können die Anwendungen in einer verschlüsselten Form gespeichert sein. Bei 348 wird jede verschlüsselte Anwendung unter Verwendung des SSK entschlüsselt. Bei 350 werden die Anwendungen ausgeführt. Die Anwendungen können das OS, Interrupt-Routinen, Utilities und andere Benutzeranwendungen wie beispielsweise Musikspieler, Spiele, Zellulartelefone, GPS und dergleichen umfassen.
-
Das nächste Mal, wenn die Vorrichtung kalt gebootet wird, wird der neue BL geladen und ausgeführt. Entsprechend erlauben Ausführungsformen der vorliegenden Technologie vorteilhafterweise das sichere Updaten des Bootloadercodes ohne Kenntnis des sicheren Bootschlüssels.
-
Nun Bezug nehmend auf die 4A–4B ist ein sicheres Recovery-Verfahren gemäß einer Ausführungsform der vorliegenden Technologie dargestellt. Wieder wird der BR ausgeführt (z. B. kaltes Booten) durch die Prozessiereinheit 155 zum Etablieren einer Vertrauenskette, bei 402. Während der Ausführung des BR, werden ein sicherer Bootschlüssel (SBK), Vorrichtungsschlüssel (DK) und eine Vorrichtungskennung (DID) zugegriffen und der SBK wird in einen entsprechenden SBK-Schlüsselschlitz geladen, welcher zugreifbar ist durch eine Verschlüsselungs-/Entschlüsselungsmaschine, bei 404. Bei 406 wird ein sicherer Systemschlüssel (SSK) von dem SBK, DK und DID berechnet und in einen entsprechenden SSK-Schlüsselschlitz geladen, wie oben detaillierter beschrieben.
-
Bei 408 wird der SSK in ein SSK-Register in der AO-Domäne 135 der Vorrichtung 110 geladen. Bei 410 wird der BL von der gegebenen Peripherievorrichtung gelesen, welche spezifiziert ist zum Speichern des BL. Der auf dem Peripheriegerät gespeicherte BL ist verschlüsselt. Bei 412 wird der Bootloader entschlüsselt unter Verwendung des SBK, wodurch der Bootloader authentifiziert wird. Der Bootloader kann weiter authentifiziert werden unter Verwendung einer auf einer Zusammenfassung, einem Digitalzertifikat oder dergleichen basierenden Authentifizierungstechnik.
-
Wenn der BL erfolgreich entschlüsselt und authentifiziert ist, wird der BL ausgeführt durch die Prozessiereinheit 155. Jedoch, wenn die Lese- und/oder die entschlüsselten/authentifizierten Prozesse von 410, 412 fehlschlagen, tritt die Vorrichtung bei 414 in einen Recovery-Modus ein. Die Vorrichtung wird betrachtet als gesperrt oder vermauert, wenn sie versagt, den BL zu lesen und/oder zu entschlüsseln und authentifizieren. Zusätzlich, wenn die Vorrichtung noch in dem Herstellungsstadium ist, kann der Recovery-Modus verwendet werden, um zum ersten Mal den SBK, DK und/oder BL auf das System zu laden. Während des Recovery-Modus rundsendet die Vorrichtung 110 die DID der Vorrichtung 110 auf einem gegebenen Kommunikationskanal. In einer Implementierung ist der Kommunikationskanal ein universeller serieller Bus (USB) Link. Das System, welches die Vorrichtung 105 enthält, kann gekoppelt sein an einen Host 422 entweder direkt oder durch ein Netzwerk 505 und eine lokale Interface-Vorrichtung 510 wie in 5A und 5B veranschaulicht. Bei 420 empfängt eine Host-422-Vorrichtung die DID und bildet sie auf einen gegebenen SBK ab. Der Host 422 erzeugt dann eine selbstvalidierende Mitteilung unter Verwendung des gegebenen SBK und überträgt die selbstvalidierende Mitteilung zu der Vorrichtung 110, bei 424. In einer exemplarischen Implementierung umfasst die Mitteilung eine (unsichere) Länge 605, einen Hash 610, einen Zufalls-AES-Block 615, eine sichere Länge 620, Befehle und Daten 625, eine Nutzlast 630 und eine Blindgruppe (padding) (z. B. 0X80 gefolgt durch zusätzliche 0X00 Bytes, wenn benötigt) 635, wie in 6 veranschaulicht. Der Zufalls-AES-Block 615, die sichere Länge 620, Befehle und Daten 625, Nutzlast 630 und die Blindgruppe 635 werden kodiert unter Verwendung des SBK, welcher auf die DID abgebildet ist. Bei 426 wird die Mitteilung empfangen und validiert durch die Vorrichtung 110 unter Verwendung des SBK der Vorrichtung. In einer Implementierung ist die empfangene Mitteilung gültig, wenn die unsichere Länge 605 mit der sicheren Länge 620 übereinstimmt (zusammenpasst), der Hash 610 korrekt ist, der Befehl 625 gültig ist (z. B. gültige Befehlstypen für die gegebene Mitteilung), wenn die Größe der Mitteilung korrekt ist (wie durch den Befehl und die Daten spezifiziert), wenn die Größe der Nutzlast korrekt ist, wenn das Blindgruppenmuster korrekt ist, und/oder wenn die BR-Versionsnummer in den Befehl und Daten 625 mit der BR-Version auf der Vorrichtung 110 zusammenpasst. Wenn die Mitteilung validiert ist, lädt die Vorrichtung 110 die Mitteilung in eine Periphievorrichtung (z. B. RAM) und führt sie aus, bei 428. Der Recovery-Modus kann einen oder mehrere Befehle in der Mitteilung ausführen, Code ausführen, welcher in der Mitteilung enthalten ist, und/oder speichert BL-Code in der Mitteilung in eine gegebene Peripherievorrichtung, bei 428. Wenn BL-Code in der Mitteilung empfangen wird, wird der BL gespeichert in der gegebenen Peripherievorrichtung verschlüsselt unter Verwendung des SBK. Optional kann die Vorrichtung 110 von dem Host zusätzliche Daten herunterladen und authentifizieren. Die zusätzlichen Daten können unter Verwendung des SBK verschlüsselt und signiert werden, bevor sie zu der Peripherievorrichtung geschrieben werden. Auf diese Weise kann der Recovery-Modus vielfache Mitteilungsübertragungs- und Antwortsequenzen bereitstellen. Wenn die Mitteilung nicht validiert, kann die Vorrichtung 110 in eine Endlosschleife eintreten, welche einen System-Reset fordert, um fortzufahren.
-
Entsprechend erlauben Ausführungsformen der vorliegenden Technologie ebenso vorteilhaft das sichere Herunterladen von BL-Code in ein gesichertes System.
