-
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.
-
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 erster Teil von Bootcode, welcher auf einem Chip gespeichert
ist, ausgeführt,
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. Während
die vorliegende Technologie in Verbindung mit diesen Ausführungsformen
beschrieben werden wird, wird es verstanden werden, dass diese nicht
dafür vorgesehen
sind, die Erfindung auf diese Ausführungsformen einzuschränken. Im
Gegenteil, die Erfindung ist vorgesehen, alle Alternativen, Modifikationen
und Äquivalente
einzuschließen,
die enthalten sein können
in dem Umfang der Erfindung, wie sie durch die anhängenden
Ansprüche
definiert ist. Ferner werden in der folgenden detaillierten Beschreibung
der vorliegenden Technologie zahlreiche spezifische Details dargelegt, um
für ein
gründliches
Verständnis
der vorliegenden Technologie zu sorgen. Jedoch sollte es sich verstehen,
dass die vorliegende Technologie ohne diese spezifischen Details
ausgeübt
werden kann. In anderen Fällen
wurden gut bekannte Verfahren, Prozeduren, Komponenten und Schaltungen
nicht im Detail beschrieben, um nicht unnötigerweise Aspekte der vorliegenden
Technologie zu verschleiern.
-
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 on 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 140 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, wird 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
herauszykliert, 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 Systemspeicherschlü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 140 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 150, 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 418. 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. 0×80
gefolgt durch zusätzliche
0×00 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 615 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.
-
Die
vorangegangenen Beschreibungen von spezifischen Ausführungsformen
der vorliegenden Technologie wurden präsentiert zum Zwecke der Illustration
und Beschreibung. Sie sind nicht beabsichtigt, erschöpfend zu
sein oder die Erfindung auf die präzisen offenbarten Formen zu
beschränken
und offensichtlich sind viele Modifikationen und Variationen im
Licht der vorstehenden Lehren möglich.
Die Ausführungsformen
wurden gewählt
und beschrieben, um am besten die Prinzipien der vorliegenden Technologie
und ihrer praktischen Anwendung zu erklären, um dadurch andere Fachleute
in die Lage zu versetzen, die vorliegende Technologie und vielfältige Ausführungsformen
mit vielfältigen
Modifikationen, so wie sie für
die bestimmte in Erwägung
gezogene Verwendung geeignet sind, am besten zu verwenden. Es ist
beabsichtigt, dass der Umfang der Erfindung definiert ist durch
die hieran anhängenden
Ansprüche
und ihre Äquivalente.