DE102014204713A1 - Erzeugung von Schlüsseln unter Verwendung sicherer Hardware - Google Patents

Erzeugung von Schlüsseln unter Verwendung sicherer Hardware Download PDF

Info

Publication number
DE102014204713A1
DE102014204713A1 DE201410204713 DE102014204713A DE102014204713A1 DE 102014204713 A1 DE102014204713 A1 DE 102014204713A1 DE 201410204713 DE201410204713 DE 201410204713 DE 102014204713 A DE102014204713 A DE 102014204713A DE 102014204713 A1 DE102014204713 A1 DE 102014204713A1
Authority
DE
Germany
Prior art keywords
host device
key
client device
public key
signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE201410204713
Other languages
English (en)
Inventor
Michael J. Seymour
Kerry David Maletsky
Brad Phillip Garner
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Atmel Corp
Original Assignee
Atmel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Atmel Corp filed Critical Atmel Corp
Publication of DE102014204713A1 publication Critical patent/DE102014204713A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Eine Client-Vorrichtung, die mit einer Host-Vorrichtung gekoppelt ist, sendet einen übergeordneten öffentlichen Schlüssel und ein zugeordnetes Zertifikat an die Host-Vorrichtung. Der übergeordnete öffentliche Schlüssel, das Zertifikat und ein entsprechender übergeordneter privater Schlüssel werden in einer sicheren persistenten Ablage gespeichert, die in einer der Client-Vorrichtung zugeordneten sicheren Vorrichtung enthalten ist. Die Client-Vorrichtung empfängt von der Host-Vorrichtung Anweisungen zum Erzeugen eines Paars eines untergeordneten privaten und öffentlichen Schlüssels. Die Client-Vorrichtung erzeugt als Antwort auf den Empfang der Anweisungen auf der Grundlage einer innerhalb der sicheren Vorrichtung erzeugten ersten Zufallszahl einen untergeordneten privaten Schlüssel und einen dem untergeordneten privaten Schlüssel zugeordneten untergeordneten öffentlichen Schlüssel. Die Client-Vorrichtung berechnet an dem untergeordneten öffentlichen Schlüssel unter Verwendung des übergeordneten privaten Schlüssels eine erste Signatur. Die Client-Vorrichtung sendet den untergeordneten öffentlichen Schlüssel und die erste Signatur an die Host-Vorrichtung.

Description

  • TECHNISCHES GEBIET
  • Diese Offenbarung bezieht sich auf die Erzeugung kryptographischer Schlüssel unter Verwendung einer sicheren Hardwarevorrichtung.
  • HINTERGRUND
  • In einigen Systemen kann eine Client-Vorrichtung wie etwa eine Peripheriekomponente mit einer Host-Vorrichtung verbunden sein. Die Host-Vorrichtung kann zu verifizieren wünschen, dass die von der Client-Vorrichtung bereitgestellten Informationen richtig sind, während die Client-Vorrichtung zu bestätigen wünschen kann, dass sie mit einer kompatiblen Host-Vorrichtung verbunden ist.
  • ZUSAMMENFASSUNG
  • In einem Aspekt sendet eine Client-Vorrichtung, die mit einer Host-Vorrichtung gekoppelt ist, einen übergeordneten öffentlichen Schlüssel und ein zugeordnetes Zertifikat an die Host-Vorrichtung. Der übergeordnete öffentliche Schlüssel, das Zertifikat und ein entsprechender übergeordneter privater Schlüssel werden in einer sicheren persistenten Ablage gespeichert, die in einer der Client-Vorrichtung zugeordneten sicheren Vorrichtung enthalten ist. Der übergeordnete öffentliche Schlüssel und der übergeordnete private Schlüssel sind kryptographische Schlüssel und das Zertifikat ist ein kryptographisches Zertifikat.
  • Die Client-Vorrichtung empfängt von der Host-Vorrichtung Anweisungen zum Erzeugen eines Paars eines untergeordneten privaten Schlüssels und eines untergeordneten öffentlichen Schlüssels. Die Client-Vorrichtung erzeugt als Antwort auf den Empfang der Anweisungen auf der Grundlage einer innerhalb der sicheren Vorrichtung erzeugten ersten Zufallszahl einen untergeordneten privaten Schlüssel und einen dem untergeordneten privaten Schlüssel zugeordneten untergeordneten öffentlichen Schlüssel. Der untergeordnete private Schlüssel und der untergeordnete öffentliche Schlüssel sind kryptographische Schlüssel.
  • Die Client-Vorrichtung berechnet unter Verwendung des übergeordneten privaten Schlüssels an dem untergeordneten öffentlichen Schlüssel eine erste Signatur. Die erste Signatur ist eine kryptographische Signatur. Die Client-Vorrichtung sendet den untergeordneten öffentlichen Schlüssel und die erste Signatur an die Host-Vorrichtung.
  • Implementierungen können eines oder mehrere der folgenden Merkmale enthalten. Der untergeordnete private Schlüssel und der untergeordnete öffentliche Schlüssel können innerhalb der sicheren Vorrichtung erzeugt werden. Das Berechnen der ersten Signatur an dem untergeordneten öffentlichen Schlüssel unter Verwendung des übergeordneten privaten Schlüssels kann das Kombinieren einer Nonce mit dem untergeordneten öffentlichen Schlüssel unter Verwendung der sicheren Vorrichtung, um ein Digest zu erzeugen, umfassen. Das Digest kann mit der sicheren Vorrichtung zugeordneten Informationen kombiniert sein. Die sichere Vorrichtung kann die erste Signatur durch Ausführen einer Berechnung einer asymmetrischen kryptographischen Signatur unter Verwendung des übergeordneten privaten Schlüssels an der Kombination des Digests und den der sicheren Vorrichtung zugeordneten Informationen erzeugen.
  • Die der sicheren Vorrichtung zugeordneten Informationen können Zustandsinformationen der sicheren Vorrichtung und/oder Schlüsselablage-Konfigurationsinformationen und/oder Schlüsselablage-Zustandsinformationen und/oder Befehlsparameter enthalten.
  • Die Host-Vorrichtung kann durch die Client-Vorrichtung dadurch authentifiziert werden, dass sie ein in der sicheren Vorrichtung enthaltenes Bit setzt, das dem übergeordneten privaten Schlüssel zugeordnet ist, das angibt, dass die Host-Vorrichtung authentifiziert worden ist. Das Senden des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats an die Host-Vorrichtung und das Erzeugen des untergeordneten privaten Schlüssels können das Senden des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats an die Host-Vorrichtung und das Erzeugen des untergeordneten privaten Schlüssels auf der Grundlage des in der sicheren Vorrichtung gesetzten Bits umfassen.
  • Die Host-Vorrichtung kann von der Client-Vorrichtung den übergeordneten öffentlichen Schlüssel und das zugeordnete Zertifikat empfangen. Die Host-Vorrichtung kann die Gültigkeit des übergeordneten öffentlichen Schlüssels dadurch verifizieren, dass sie unter Verwendung eines öffentlichen Wurzelschlüssels, der einer Zertifizierungsstelle entspricht, der die Host-Vorrichtung und die Client-Vorrichtung vertrauen, die Signatur an dem zugeordneten Zertifikat prüft. Auf der Grundlage der Verifizierung des übergeordneten öffentlichen Schlüssels als gültig kann die Host-Vorrichtungen an die Client-Vorrichtung Anweisungen senden, wobei die Anweisungen die Client-Vorrichtungen anweisen, das Paar des untergeordneten privaten Schlüssels und des untergeordneten öffentlichen Schlüssels zu erzeugen. Die Host-Vorrichtung kann als Antwort auf das Senden der Anweisungen den untergeordneten öffentlichen Schlüssel und die erste Signatur empfangen. Die Host-Vorrichtung kann die Gültigkeit des untergeordneten öffentlichen Schlüssels dadurch verifizieren, dass sie die Richtigkeit der ersten Signatur unter Verwendung des verifizierten übergeordneten öffentlichen Schlüssels verifiziert.
  • Das Senden des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats an die Host-Vorrichtung kann auf der Authentifizierung der Host-Vorrichtung durch die Client-Vorrichtung beruhen. Die Client-Vorrichtung kann an die Host-Vorrichtung eine erste kryptographische Authentifizierungsabfrage senden, in der die erste kryptographische Authentifizierungsabfrage zum Authentifizieren der Host-Vorrichtung gesendet wird. Die Client-Vorrichtung kann eine Antwort auf die erste kryptographische Authentifizierungsabfrage empfangen, wobei die Antwort eine der ersten kryptographischen Authentifizierungsabfrage zugeordnete Anfangssignatur, die mit einem für die Host-Vorrichtung verfügbaren Autorisierungsschlüssel signiert ist, enthält, wobei eine Kopie des Autorisierungsschlüssels in der in der sicheren Vorrichtung enthaltenen sicheren persistenten Ablage gespeichert wird. Die Client-Vorrichtung kann die Richtigkeit der Anfangssignatur unter Verwendung der in der sicheren persistenten Ablage gespeicherten Kopie des Autorisierungsschlüssels verifizieren. Die Client-Vorrichtung kann die Host-Vorrichtung auf der Grundlage der Verifizierung der Richtigkeit der Anfangssignatur authentifizieren.
  • Die Host-Vorrichtung kann die erste kryptographische Authentifizierungsabfrage von der Client-Vorrichtung empfangen. Die Host-Vorrichtung kann auf den Authentifizierungsschlüssel, der für die Host-Vorrichtung verfügbar ist, zugreifen. Die Host-Vorrichtung kann unter Verwendung des Authentifizierungsschlüssels die Anfangssignatur an der ersten kryptographischen Authentifizierungsabfrage berechnen. Die Host-Vorrichtung kann die Anfangssignatur an die Client-Vorrichtung senden.
  • Die Client-Vorrichtung kann von der Host-Vorrichtung eine Nachricht empfangen, die eine zweite kryptographische Authentifizierungsabfrage enthält. Die Client-Vorrichtung kann unter Verwendung des durch die Client-Vorrichtung erzeugten untergeordneten privaten Schlüssels eine zweite Signatur an der zweiten kryptographischen Authentifizierungsabfrage berechnen. Die Client-Vorrichtung kann eine Antwort auf die kryptographische Authentifizierungsabfrage an die Host-Vorrichtung senden, wobei die Antwort die zweite Signatur enthält.
  • Die Host-Vorrichtung kann die zweite kryptographische Authentifizierungsabfrage an die Client-Vorrichtung senden.
  • Die Host-Vorrichtung kann eine Antwort auf die zweite kryptographische Authentifizierungsabfrage, die die zweite Signatur enthält, empfangen. Die Host-Vorrichtung kann die Richtigkeit der zweiten Signatur unter Verwendung des untergeordneten öffentlichen Schlüssels, der von der Client-Vorrichtung empfangen wird, verifizieren. Die Host-Vorrichtung kann den untergeordneten öffentlichen Schlüssel auf der Grundlage der Verifizierung der Richtigkeit der zweiten Signatur als einen vertrauenswürdigen Schlüssel speichern.
  • Implementierungen der obigen Techniken enthalten ein Verfahren, ein Computerprogrammprodukt und ein System. Das Computerprogrammprodukt ist geeignet in einem nichtflüchtigen maschinenlesbaren Medium verkörpert und enthält Anweisungen, die durch einen oder mehrere Prozessoren ausgeführt werden können. Die Anweisungen sind so konfiguriert, dass sie veranlassen, dass der eine oder die mehreren Prozessoren die oben beschriebenen Aktionen ausführen.
  • Das System enthält einen oder mehrere Prozessoren und in ein nichtflüchtiges maschinenlesbares Medium eingebettete Anweisungen, die durch den einen oder durch die mehreren Prozessoren ausgeführt werden können. Wenn die Anweisungen ausgeführt werden, sind sie dafür konfiguriert zu veranlassen, dass der eine oder die mehreren Prozessoren die oben beschriebenen Aktionen ausführen.
  • Die Einzelheiten der einen oder mehreren offenbarten Implementierungen sind in den beigefügten Zeichnungen und in der folgenden Beschreibung dargelegt. Weitere Merkmale, Aspekte und Vorteile gehen aus der Beschreibung, aus den Zeichnungen und aus den Ansprüchen hervor.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Blockschaltplan einer beispielhaften Client-Vorrichtung, die zum Erzeugen kryptographischer Schlüssel unter Verwendung eingebetteter Hardware verwendet werden kann.
  • 2 ist ein Blockschaltplan von Abschnitten innerhalb einer sicheren Zone einer sicheren Vorrichtung, die für kryptographische Operationen und für die kryptographische Speicherung verwendet wird.
  • 3 veranschaulicht ein Beispiel eines Systems, das zum Erzeugen kryptographischer Schlüssel durch eine Client-Vorrichtungs-Hardware, die mit einer Host-Vorrichtung gekoppelt ist, verwendet werden kann.
  • 4 ist ein Ablaufplan, der ein Beispiel eines Prozesses darstellt, durch den eine Client-Vorrichtung kryptographische Schlüssel unter Verwendung sicherer Hardware für die Kommunikation mit einer Host-Vorrichtung erzeugen kann.
  • 5 ist ein Ablaufplan, der ein Beispiel eines Prozesses darstellt, durch den eine Host-Vorrichtung von einer Client-Vorrichtung gesendete kryptographische Schlüssel verifiziert.
  • Gleiche Bezugszeichen in den verschiedenen Figuren bezeichnen gleiche Elemente.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In einigen Systemen sind verschiedene Hardwarekomponenten oder -vorrichtungen miteinander gekoppelt, um spezifische Operationen auszuführen. Einige der Vorrichtungen sind dafür konfiguriert, als die Host-Vorrichtung, d. h. als die primäre Vorrichtung, zu wirken, während andere Komponenten dafür konfiguriert sind, als Client-Vorrichtungen oder Peripherievorrichtungen zu wirken. Beispiele solcher Systeme enthalten eine Hauptplatine (Host-Vorrichtung), die mit ihr verbundene Zusatzkarten (Client-Vorrichtungen) aufweist, einen Laptop (Host-Vorrichtung), der eine mit dem Laptop verbundene Batteriegruppe (Client-Vorrichtung) aufweist, und einen elektronischen Drucker (Host-Vorrichtung), der in Patronensteckplätze eingeführte Druckerpatronen (Client-Vorrichtungen) aufweist.
  • In solchen Systemen kann die Host-Vorrichtung, die auch einfach als der Host bezeichnet wird, verifizieren, dass eine bestimmte mit dem Host verbundene Client-Vorrichtung, die auch einfach als der Client bezeichnet wird, der richtige Client für die Ausführung einer spezifischen Operation ist. Zum Beispiel kann ein Drucker sicherzustellen wünschen, dass in einen bestimmten Patronensteckplatz eine vom Hersteller genehmigte Farbpatrone geladen ist, da eine nachgebildete Farbpatrone den Druckkopf beschädigen kann. Die Client-Vorrichtung kann ihrerseits zu verifizieren wünschen, dass sie mit einer Host-Vorrichtung verbunden ist, die zur Verwendung der durch die Client-Vorrichtung bereitgestellten Dienste autorisiert ist. Zum Beispiel kann die Farbpatrone verifizieren, dass der Drucker, in den die Patrone eingeführt ist, das richtige Druckermodell ist, für das die Patrone zur Verwendung bestimmt ist.
  • Wenn der Host den Client verifiziert und/oder gegebenenfalls umgekehrt, wird zwischen dem Host und dem Client für die nachfolgende Kommunikation zwischen den beiden eine Vertrauensbeziehung aufgebaut. Eine solche Verifizierung entweder durch den Host oder durch den Client oder durch beide kann unter Verwendung kryptographischer Schlüssel ausgeführt werden, die sowohl dem Host als auch dem Client bekannt sind und die zum sicheren Austauschen von Anfangsinformationen zwischen den zwei Vorrichtungen, um eine Vertrauensbeziehung aufzubauen, verwendet werden.
  • In einigen Implementierungen können die kryptographischen Schlüssel unter Verwendung von Softwarehilfsmitteln bei der Client-Vorrichtung und/oder bei der Host-Vorrichtung erzeugt werden. Allerdings kann das Erzeugen der Schlüssel unter Verwendung von Software im Vergleich zur Hardwareschlüsselerzeugung eine weniger sichere Operation sein. Außerdem kann die Softwareschlüsselerzeugung langsamer als die Hardwareschlüsselerzeugung und folglich aufwendiger hinsichtlich der Systemleistung sein.
  • Einige Systeme können verfügen, dass die kryptographischen Hilfsmittel sicher an spezifische physikalische Eigenschaften der Client-Vorrichtung gebunden sind, um eine sichere bijektive Beziehung zwischen einer Client-Vorrichtung und ihren zugeordneten kryptographischen Operationen sicherzustellen. Dies kann wichtig sein, um zu verifizieren, dass die Konfigurations-, Versions- oder Modellinformationen, die in der Client-Vorrichtung gespeichert sind, nicht geändert worden sind. Der richtige und/der sichere Betrieb des Systems kann davon abhängen, dass die in der Client-Vorrichtung gespeicherten Informationen authentisch sind. Zum Beispiel werden medizinische Verbrauchsartikel üblicherweise mit Kalibrierungsinformationen versandt, die spezifisch für diese bestimmte Packung ausgelegt sind; nachladbare Batteriesysteme werden mit ihrer bestimmen Konfiguration/mit ihrer bestimmten Kapazität/mit ihren bestimmten Parametern programmiert, um eine Beschädigung und/oder einen Brand während des Ladens zu verhindern. Im Vergleich dazu, dass die Schlüssel unter Verwendung von Softwarehilfsmitteln erzeugt werden, kann es leichter sein, eine solche sichere bijektive Beziehung zwischen einer Client-Vorrichtung und ihren zugeordneten kryptographischen Schlüsseln zu erhalten, wenn die Schlüssel unter Verwendung der Client-Vorrichtungs-Hardware erzeugt werden.
  • Die Schlüssel können durch die Client-Vorrichtungs-Hardware unter Verwendung symmetrischer kryptographischer Algorithmen erzeugt werden, die das Speichern des symmetrischen Schlüssels (der häufig gemeinsam genutzt oder von einem gemeinsamen Geheimnis abgeleitet wird) sowohl in der Host-Vorrichtung als auch in den Client-Vorrichtungen umfassen. In einigen Systemen symmetrischer Schlüssel können die Schlüssel bei dem Client erzeugt werden und daraufhin sicher an den Host übertragen werden, was einen Sicherheitsorganisationsaufwand für die Übertragung der Schlüssel einführt. In einigen anderen Systemen symmetrischer Schlüssel muss der Host dieselben übergeordneten Geheimnisse wie der Client besitzen, um den bzw. die gemeinsam genutzten Schlüssel unabhängig zu erzeugen, was einen Organisationsaufwand für das Synchronisieren der Host-Vorrichtung und der Client-Vorrichtungen einführen kann. Die Anforderung, in Systemen, die eine Kryptographie symmetrischer Schlüssel verwenden, dieselben Geheimnisse zwischen der Client- und der Host-Vorrichtung gemeinsam zu nutzen, kann dazu führen, dass die Host-Vorrichtung mehr kostet, und verringert durch die Begrenzung des Verifizierungsraums für jene Entitäten, die das Geheimnis gemeinsam nutzen, die Skalierbarkeit.
  • Es kann nützlich sein, kryptographische Schlüssel unter Verwendung asymmetrischer kryptographischer Hilfsmittel in der Client-Vorrichtungs-Hardware zu erzeugen. Dies kann dadurch erreicht werden, dass die Client-Vorrichtung, z. B. am Händlerstandort, mit einem zufälligen privaten Schlüssel, der eindeutig ist und nur der Client-Vorrichtung bekannt ist, und mit einem durch eine vertrauenswürdige Zertifizierungsstelle (CA) erzeugten Zertifikat des entsprechenden öffentlichen Schlüssels initialisiert wird, bevor die Client-Vorrichtung eingesetzt wird. Die Host-Vorrichtung kann leicht Informationen über den öffentlichen Schlüssel der Client-Vorrichtung erhalten, ohne dass ein Geheimnis gemeinsam genutzt wird.
  • Die Client-Vorrichtung kann Nachrichten dadurch authentifizieren, dass sie sie mit dem privaten Schlüssel signiert. Während sie die Nachrichten signiert, kann die Client-Vorrichtung der Client-Vorrichtung zugeordnete Konfigurationsinformationen wie etwa Chipzustandsinformationen als Teil der Signatur aufnehmen. Falls der private Schlüssel und/oder die Konfigurationsinformationen wirksam geschützt werden, schafft ein solcher Mechanismus eine gutes Vertrauen, dass die signierten Informationen innerhalb der Vorrichtung, die den privaten Schlüssel hält, physikalisch dargestellt oder enthalten waren.
  • In diesem Zusammenhang bedeutet wirksam geschützt, dass eine wesentliche Anstrengung erforderlich wäre, um durch eine nicht autorisierte Komponente oder Entität den Wert des privaten Schlüssels und/oder die Konfigurationsinformationen zu erhalten. Die kryptographischen Schlüssel und die zugeordneten kryptographischen Operationen können unter Verwendung dedizierter Hardware in der Client-Vorrichtung wie etwa einer Hardwareauthentifizierungsvorrichtung zum Speichern der kryptographischen Informationen oder zum Ausführen der kryptographischen Operationen oder für beides wirksam geschützt werden. Die Hardwareauthentifizierungsvorrichtung kann eine sichere integrierte Schaltung (IC) sein, die auch als ein sicherer Chip oder als eine sichere Vorrichtung bezeichnet wird, die eine Logik zum Ausführen von Sicherheitsoperationen wie etwa zum Erzeugen von Startwerten für Sicherheitsauthentifizierungsabfragen und kryptographische Schlüssel; zum Berechnen der kryptographischen Schlüssel; zum Ausführen kryptographischer Hash-Operationen an Schlüsseln und Nachrichten zum Erzeugen von Nachrichtendigests; zum Erzeugen digitaler Signaturen an Nachrichtendigests unter Verwendung der kryptographischen Schlüssel zur Authentifizierung, Nachrichtenintegrität, Verschlüsselung oder irgendeiner geeigneten Kombination davon; zum Ausführen von Entschlüsselungsoperationen an verschlüsselten Nachrichten; und zum Verifizieren der Authentizität empfangener Nachrichten und Schlüssel durch Bestätigen der Richtigkeit zugeordneter digitaler Signaturen enthalten kann. Die sichere Vorrichtung kann einen sicheren Ablagebereich wie etwa einen Hardwarespeicher zum Speichern der kryptographischen Schlüssel und zugeordneter Informationen enthalten. Der sichere Speicherbereich kann ein temporärer Speicher oder ein persistenter Speicher oder eine geeignete Kombination beider sein.
  • In einigen Systemen, die sichere Hardware verwenden, die in Client-Vorrichtungen zum Erzeugen und Speichern kryptographischer Schlüssel eingebettet ist, kann es zusätzliche Prozeduren für robuste Sicherheit geben, die verwendet werden, um nachzuweisen, dass ein bestimmtes Paar eines privaten Schlüssels/öffentlichen Schlüssels zu der Client-Vorrichtung gehört, die den entsprechenden privaten Schlüssel zu halten behauptet, und dass das Paar des privaten Schlüssels/öffentlichen Schlüssels nicht durch eine nicht autorisierte Entität geändert worden ist.
  • Die zusätzlichen Sicherheitsprozeduren können durch Kombinieren einiger Hardwareeigenschaften der sicheren Vorrichtung mit den kryptographischen Schlüsseln, während die kryptographischen Operationen ausgeführt werden, implementiert werden. Auf diese Weise kann das System sicherstellen, dass in einer Vorrichtung sensible Informationen gespeichert werden, deren Ursprung und Sicherheitseigenschaften bekannt sind. Somit sind die Informationen auf der durch den Vorrichtungstyp gebotenen Sicherheitsebene geschützt. Außer den Daten sind die Mechanismen, die zum Sichern der Daten angewendet werden, ebenfalls geschützt, so dass die verifizierende Entität Kenntnis von den ausgewählten Sicherheitsoptionen haben kann und wissen kann, dass die ausgewählten Operationen ebenfalls sicher geschützt sind. Außerdem sollte die verifizierende Entität verifizieren können, dass der private Schlüssel nicht verwendet werden kann, um irgendwelche beliebig von außen bereitgestellten Daten zu signieren, die verwendet werden könnten, um die geschützten Informationen zu fälschen. Die sichere Vorrichtung kann dafür konfiguriert sein, außer der sicheren Ablage für die kryptographischen Schlüssel eine sichere Ablage für Konfigurations- und/oder Zustandsinformationen sicherzustellen, die der sicheren Vorrichtung oder der Client-Vorrichtung zugeordnet sind. Die Konfigurations- und/oder Zustandsinformationen, die der sicheren Vorrichtung zugeordnet sind, können verwendet werden, wenn durch die Vorrichtung Signaturen erzeugt werden.
  • In einigen Systemen kann der Client, bevor die kryptographischen Schlüssel für die Authentifizierung, Nachrichtenintegrität oder Datenverschlüsselung für Nachrichten, die von der Client-Vorrichtung an die verbundene Host-Vorrichtung gesendet werden, verwendet werden, verifizieren, dass die Host-Vorrichtung zum Interagieren mit dem Client autorisiert ist. In einigen Implementierungen kann die Verifizierung durch symmetrische kryptographische Mechanismen, z. B. unter Verwendung eines Autorisierungsschlüssels, der sowohl dem Client als auch dem Host bekannt ist, ausgeführt werden. Zum Beispiel kann der Autorisierungsschlüssel in die sichere Vorrichtung in dem Client eingebettet sein und kann er außerdem in eine Host-Vorrichtung, die zum Kommunizieren mit dem Client autorisiert ist, programmiert sein. Der Client kann die Berechtigung der Host-Vorrichtung unter Verwendung eines Authentifizierungsabfrage-Antwort-Mechanismus verifizieren, in dem eine Zahl durch den Host unter Verwendung des Berechtigungsschlüssels signiert wird. Wenn der Host verifiziert worden ist, kann der Client auf der Grundlage des privaten/öffentlichen Langzeitschlüssels, die in der sicheren Vorrichtung gespeichert sind, mit dem Erzeugen untergeordneter privater/öffentlicher Schlüssel für die Kommunikation mit dem Host fortfahren.
  • In einigen anderen Implementierungen kann die Verifizierung durch asymmetrische kryptographische Mittel, z. B. unter Verwendung eines Paars eines privaten Schlüssels/öffentlichen Schlüssels, ausgeführt werden. Zum Beispiel kann der private Schlüssel in eine Host-Vorrichtung programmiert werden und kann der entsprechende öffentliche Schlüssel in die sichere Vorrichtung in dem Client eingebettet werden. Der Client kann die Berechtigung der Host-Vorrichtung unter Verwendung eines Authentifizierungsabfrage-Antwort-Mechanismus, in dem eine durch den Client gesendete Zahl durch den Host unter Verwendung des privaten Schlüssels signiert wird, verifizieren. Der Client kann die Signatur an der Zufallszahl unter Verwendung des in die sichere Vorrichtung eingebetteten öffentlichen Schlüssels validieren.
  • In einigen Systemen kann die Host-Vorrichtung ebenfalls verifizieren, dass die Client-Vorrichtung im Besitz eines Paars eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels ist, die zur Sicherstellung der Kommunikation verwendet werden. Dies kann z. B. nützlich sein, um Replay-Angriffe zu verhindern, wie etwa einen Fall, in dem eine nicht autorisierte Client-Vorrichtung zuvor authentifizierte Nachrichten von einer autorisierten Client-Vorrichtung für die Host-Vorrichtung wieder einspielt. Die Host-Vorrichtung kann die Verifizierung unter Verwendung eines Authentifizierungsabfrage-Antwort-Mechanismus ausführen. Die Host-Vorrichtung sendet eine Authentifizierungsabfragenachricht an die Client-Vorrichtung, die die Authentifizierungsabfrage unter Verwendung des untergeordneten privaten Schlüssels signiert und die signierte Nachricht an den Host zurückgibt. Nachfolgend kann die Host-Vorrichtung unter Verwendung des untergeordneten öffentlichen Schlüssels verifizieren, dass die Client-Vorrichtung im Besitz des untergeordneten privaten Schlüssels ist.
  • In den folgenden Abschnitten werden Verfahren, Vorrichtungen und Systeme zum Erzeugen vertrauenswürdiger kryptographischer Schlüssel durch eine Client-Vorrichtung unter Verwendung asymmetrischer kryptographischer Hilfsmittel an Paaren privater/öffentlicher Langzeitschlüssel, die in einer in die Client-Vorrichtung eingebetteten sicheren Vorrichtung gespeichert sind, beschrieben. Die Verfahren, Vorrichtungen und Systeme können ebenfalls verwendet werden, um eine Host-Vorrichtung zu autorisieren, die mit der Client-Vorrichtung kommuniziert, wobei die Autorisierung der Host-Vorrichtung geschieht, bevor die Client-Vorrichtung die vertrauenswürdigen kryptographischen Schlüssel verwendet. Außerdem ermöglichen die Verfahren, Vorrichtungen und Systeme, dass der Host Kommunikationen von dem Client durch Verifizieren von Nachrichten von dem Client unter Verwendung asymmetrischer kryptographischer Hilfsmittel vertraut.
  • In den folgenden Abschnitten werden die Begriffe ”Client-Vorrichtung” und ”sichere Vorrichtung” austauschbar zur Bezugnahme auf dieselbe Entität, d. h. auf eine Client-Vorrichtung, in die eine sichere Vorrichtung oder ein anderer geeigneter sicherer Hardwareabschnitt zur Ausführung kryptographischer Operationen und zum Speichern kryptographischer Informationen einschließlich kryptographischer Schlüssel eingebettet ist, verwendet. Die Begriffe ”Client” und ”Client- Vorrichtung” werden ebenso wie die Begriffe ”Host” und ”Host-Vorrichtung” austauschbar zur Bezugnahme auf dieselbe Entität verwendet.
  • 1 ist ein Blockschaltplan einer beispielhaften Client-Vorrichtung 100, die zum Erzeugen kryptographischer Schlüssel unter Verwendung eingebetteter Hardware verwendet werden kann. Wenn die Client-Vorrichtung 100 mit einer Host-Vorrichtung gekoppelt ist, kann sie kryptographische Operationen ausführen, um die Autorisierung der Host-Vorrichtung zu verifizieren und auf der Grundlage der Verifizierung kryptographische Schlüssel zum sicheren Kommunizieren mit der Host-Vorrichtung zu erzeugen.
  • Die Client-Vorrichtung 100 enthält einen Körper 102 und eine sichere Vorrichtung 110, die innerhalb des Körpers 102 eingebettet ist. Die sichere Vorrichtung 110 weist Anschlussstifte 130 auf, die an dem Körper der sicheren Vorrichtung 110 befestigt sind. Die sichere Vorrichtung 110 enthält einen Prozessor 112 und eine sichere Zone 120, die eine persistente Ablage 122, einen ephemeren Speicher 124 und Anweisungen 126 aufweist.
  • In einigen Implementierungen kann die sichere Vorrichtung 110 eine dedizierte IC-Vorrichtung sein, die innerhalb der Client-Vorrichtung 100 eingebettet ist, während in anderen Implementierungen ein Abschnitt der Client-Vorrichtung 100 zum Implementieren der Merkmale der sicheren Vorrichtung 110 wie etwa der sicheren Zone 120 konfiguriert sein kann.
  • Der Prozessor 112 kann zum Ausführen verschiedener Operationen wie etwa Eingabe/Ausgabe-Operationen, Sicherheitsbefehlen und kryptographischen Operationen konfiguriert sein. Der Prozessor 112 kann ein digitales Verarbeitungselement enthalten oder kann ein Universalmikroprozessor sein.
  • Die sichere Zone 120 ist ein Abschnitt der sicheren Vorrichtung 110, der starke Sicherheitsmechanismen implementiert, so dass die in der sicheren Zone 120 enthaltenen Daten nicht leicht kopiert, geklont oder geändert werden und dass irgendeine nicht autorisierte Änderung der Daten durch eine Verifizierungsvorrichtung detektierbar ist. Die persistente Ablage 122 ist ein Abschnitt der sicheren Zone, der einen persistenten Speicher enthält. Die persistente Ablage 122 kann z. B. eine elektronisch löschbare Nur-Lese-Speicheranordnung (EEPROM-Anordnung) sein. Alternativ kann die persistente Ablage 122 ein Flash-Speicher oder eine Festplatte oder irgendein anderer geeigneter Ablagemechanismus, der zum Speichern von Daten auf persistente Weise konfiguriert ist, sein. Wie zuvor angegeben wurde, kann die persistente Ablage 122 zum Speichern kryptographischer Schlüssel, verschiedener Lese/Schreib-, Nur-Lese- oder geheimer Daten, der Verbrauchsprotokollierung und einer Sicherheitskonfiguration verwendet werden. Der Zugang zu den verschiedenen Abschnitten der persistenten Ablage kann auf eine Vielzahl von Arten beschränkt werden und daraufhin kann die Konfiguration verriegelt werden, um Änderungen zu verhindern.
  • Der ephemere Speicher 124 ist ein anderer Abschnitt der sicheren Zone, der für die vorübergehende Speicherung von Daten verwendet wird. Der ephemere Speicher 124 kann z. B. ein statischer Schreib-Lese-Speicher (SRAM) sein, wo die Ergebnisse der kryptographischen Operationen während sicherer Kommunikationsaustausche mit einer Verifizierungsvorrichtung gepuffert werden. In einigen Implementierungen kann der ephemere Speicher 124 zum Speichern des eingegebenen Befehls oder des auszugebenden Ergebnisses und von Zwischenrechenwerten verwendet werden. Jedes Mal, wenn der Chip in die Schlafbetriebsart geht oder die Leistung entfernt wird, kann der gesamte Inhalt des ephemeren Speichers 124 annulliert werden.
  • Das Anweisungsmodul 126 ist ein Abschnitt der sicheren Zone 110, der verschiedene durch die Vorrichtung 100 ausgeführte Anweisungen speichert. Das Anweisungsmodul 126 kann z. B. kryptographische Anweisungen enthalten, die so konfiguriert sind, dass sie veranlassen, dass der Prozessor 112 an den in der persistenten Ablage 122 und in dem ephemeren Speicher 124 gespeicherten Daten kryptographische Operationen ausführt.
  • In einigen Implementierungen kann der Prozessor 112 in der sicheren Zone 120 enthalten sein, während der Prozessor 112 in anderen Implementierungen außerhalb der sicheren Zone sein kann. In einigen Implementierungen kann die sichere Zone den gesamten Körper der Sicherheitsvorrichtung 110 umfassen.
  • Die Anschlussstifte 130 koppeln die sichere Vorrichtung 110 mit dem Körper 102 der Client-Vorrichtung 100. In einigen Implementierungen stehen die Anschlussstifte 130 von dem Körper der sicheren Vorrichtung 110 vor, während die Anschlussstifte 130 in anderen Implementierungen nicht von dem Körper der sicheren Vorrichtung 110 vorstehen können. Die Anschlussstifte 130 sind dafür konfiguriert, zwischen der Client-Vorrichtung 100 und den Daten und Anweisungen in der sicheren Vorrichtung 110 eine Schnittstelle bereitzustellen. Außerdem können die Anschlussstifte dafür konfiguriert sein, eine Leistungsquelle mit der sicheren Vorrichtung 110 zu verbinden. Die Anschlussstifte 130 können z. B. eine Ein-Anschlussstift-Hochgeschwindigkeitsschnittstelle bereitstellen. Alternativ oder zusätzlich können die Anschlussstifte 130 eine integrierte 1-Megahertz-(MHz-)Standardschaltung (I2C), die zwei Anschlussstifte verwendet, oder alternativ verschiedene einzelne Drahtschnittstellenprotokolle, die einen Anschlussstift verwenden, bereitstellen. Obwohl in 1 acht Anschlussstifte 130 gezeigt sind, kann die sichere Vorrichtung 110 eine andere Anzahl von Anschlussstiften enthalten, die kleiner oder größer als die gezeigte Anzahl sein kann.
  • Die sichere Vorrichtung 110 und insbesondere die sichere Zone 120 stellen eine weite Anordnung von Verteidigungsmechanismen bereit, die dafür konfiguriert sind, physikalische Angriffe auf die sichere Vorrichtung 110 oder logische Angriffe auf die zwischen der sicheren Vorrichtung 110 und der Client-Vorrichtung 100 und/oder zwischen der Kombination aus Client-Vorrichtung 100/sicherer Vorrichtung 110 und dem System, in dem die Client-Vorrichtung 100 verwendet wird, übertragenen Daten zu verhindern. Die sichere Zone 120 kann Hardwarebeschränkungen an die Art und Weise implementieren, in der die kryptographischen Schlüssel innerhalb der sicheren Zone erzeugt oder verwendet werden, was eine zusätzliche Sicherheit vor Angriffen sicherstellt.
  • In einigen Implementierungen ist der sicheren Vorrichtung 110 eine eindeutige laufende Nummer zugeordnet, die in der persistenten Ablage 122 gespeichert sein kann. Ein Host-System kann unter Verwendung kryptographischer Anweisungen 126, die durch die sichere Vorrichtung 110 unterstützt werden, verifizieren, dass die laufende Nummer echt ist und keine Kopie ist.
  • In einigen Implementierungen stellen die Anweisungen 126 einen flexiblen Befehlssatz bereit, der ermöglicht, dass die sichere Vorrichtung 110 in der Client-Vorrichtung 100 in einer breiten Vielfalt von Anwendungen verwendet wird. Zum Beispiel kann die sichere Vorrichtung 110 zur Bekämpfung der Produktpiraterie verwendet werden, um die Authentizität einer entnehmbaren, ersetzbaren oder verbrauchbaren Client-Vorrichtung 100 wie von Druckertintenbehältern, elektronischen Zusatzkarten oder anderen Ersatzteilen oder eines Software/Firmware-Moduls oder eines Speicherablageelements zu validieren.
  • Als eine weitere Anwendung kann die sichere Vorrichtung 110 für den Schutz von Firmware oder Medien verwendet werden. Zum Beispiel können die Anweisungen 126 Code validieren, der beim Booten im Flash-Speicher gespeichert wird, um nicht autorisierte Änderungen zu verhindern, um heruntergeladene Programmdateien als eine gemeinsame Rundsendung zu verschlüsseln oder um Codeabbilder eindeutig zu verschlüsseln, damit sie nur auf einem einzigen System verwendbar sind.
  • Eine weitere Anwendung der sicheren Vorrichtung 110 kann beim Sitzungsschlüsselaustausch liegen. Zum Beispiel kann die sichere Vorrichtung 110 von der Client-Vorrichtung 100 zum sicheren und leichten Austausch von Sitzungsverschlüsselungsschlüsseln zur Verwendung durch eine Verschlüsselungs/Entschlüsselungs-Maschine in einem Systemmikroprozessor verwendet werden, um einen vertraulichen Kommunikationskanal oder einen verschlüsselten Download zu unterstützen.
  • Eine nochmals andere Anwendung der sicheren Vorrichtung 110 kann bei der sicheren Datenspeicherung sein. Zum Beispiel können geheime Schlüssel in der persistenten Ablage 122 zur Verwendung durch kryptographische Beschleuniger in Standardmikroprozessoren gespeichert sein. Außerdem kann die persistente Ablage 122 zum Speichern von Daten für die Konfiguration, für die Kalibrierung, für den Wert einer elektronischen Geldbörse, für Verbrauchsdaten oder für andere Geheimnisse verwendet werden. Dadurch, dass die sichere Vorrichtung 110 verschlüsselte/authentifizierte Lese- und Schreibvorgänge unterstützt, kann sie einen programmierbaren Schutz bereitstellen.
  • Außerdem kann die sichere Vorrichtung 110 für die Kennwortprüfung verwendet werden. Zum Beispiel können die Anweisungen 126 veranlassen, dass der Prozessor 112 vom Nutzer eingegebene Kennwörter validiert, ohne den erwarteten Wert bekanntwerden zu lassen, einfache Kennwörter auf komplexe abbildet und Kennwortwerte mit einem entfernten System sicher austauscht. Um diese Operationen auszuführen, kann der ephemere Speicher 124 als ein ”Notizblockspeicher” zum Speichern von Sofortergebnissen kryptographischer Berechnungen verwendet werden.
  • In einigen Implementierungen kann die sichere Vorrichtung 110 eine Anzahl physikalischer Sicherheitsmerkmale enthalten, die dafür ausgelegt sind, den Inhalt der persistenten Ablage 122 vor nicht autorisierter Freilegung zu schützen. Zum Beispiel kann die sichere Vorrichtung 110 über einem Teil der Vorrichtung, der die persistente Ablage 122 aufnimmt, eine aktive Abschirmung enthalten. Alternativ oder zusätzlich kann die sichere Vorrichtung 110 eine interne Speicherverschlüsselung, Störimpulsschutz oder Spannungsmanipulationsdetektierung oder irgendeine Kombination der Obigen oder irgendeinen anderen geeigneten Mechanismus enthalten. In einigen Implementierungen können in der sicheren Vorrichtung 110 gespeicherte vorprogrammierte Transportschlüssel in der Weise verschlüsselt sein, dass die Wiedergewinnung ihrer Werte unter Verwendung einer äußeren Analyse sehr schwierig ist. In einigen Implementierungen können sowohl der Logiktakt als auch die Logikversorgungsspannung für die sichere Vorrichtung 110 intern erzeugt werden, was irgendeinen direkten Angriff auf diese zwei Signale unter Verwendung der Anschlussstifte 130 verhindert.
  • 2 ist ein Blockschaltplan von Abschnitten innerhalb einer sicheren Zone 200 einer sicheren Vorrichtung, die für kryptographische Operationen und Speicherung verwendet wird. Insbesondere veranschaulicht 2 einige der Module für kryptographische Anweisungen, die in der sicheren Zone 200 enthalten sein können, um eine starke Sicherheit bereitzustellen. Die Vorrichtung kann dieselbe wie die sichere Vorrichtung 110 sein und die sichere Zone 200 kann dieselbe wie die sichere Zone 120 sein.
  • Die sichere Zone 200 enthält einen Prozessor 205, eine persistente Ablage 210, einen ephemeren Speicher 220 und Anweisungen 230. Die Anweisungen 230 enthalten die Module RandGen 232, Nonce 234, GenKey 236, KeyConfig 238, Sense 240, GenDig 242 und Sign/Verify 244. KeyConfig 238 enthält ReqAuth 239 und AuthKey 240.
  • Der Prozessor 205 ist ähnlich dem Prozessor 112. Wie zuvor beschrieben wurde, kann der Prozessor 205 in einigen Implementierungen in der sicheren Zone 200 enthalten sein, während der Prozessor 205 in anderen Implementierungen außerhalb der sicheren Zone sein kann.
  • Die persistente Ablage 210 ist ähnlich der persistenten Ablage 122, während der ephemere Speicher 220 ähnlich dem ephemeren Speicher 124 ist. Das Anweisungsmodul 230 speichert verschiedene Anweisungen, die von der sicheren Vorrichtung, die die sichere Zone 200 enthält, wie etwa von der sicheren Vorrichtung 110 ausgeführt werden. Wie dargestellt ist, enthält das Anweisungsmodul 230 verschiedene Module, von denen jedem ein Satz von Anweisungen zugeordnet ist, die so konfiguriert sind, dass sie veranlassen, dass der Prozessor 205 an in der persistenten Ablage 210 und in dem ephemeren Speicher 220 gespeicherten Daten bestimmte Operationen ausführt.
  • Das RandGen-Modul 232 ist dem Erzeugen einer Zufallszahl zugeordnet, die als ein Startwert für kryptographische Operationen verwendet wird, die von der sicheren Vorrichtung, die die sichere Zone 200 enthält, wie etwa von der sicheren Vorrichtung 110 ausgeführt werden. Das RandGen-Modul 232 kann z. B. einen Zufallszahlgenerator enthalten, der eine bestimmte Anzahl zufälliger Bytes (z. B. 32 zufällige Bytes) an das System zurückgibt. In einigen Implementierungen kombiniert die sichere Vorrichtung diese erzeugte Zufallszahl mit einer getrennt eingegebenen Zahl, um eine ”Nonce” zu bilden, die innerhalb der sicheren Vorrichtung gespeichert wird und von nachfolgenden Befehlen verwendet werden kann.
  • In einigen Implementierungen werden Zufallszahlen aus einer Kombination der Ausgabe eines Hardware-Zufallszahlgenerators und eines internen Startwerts, auf den nicht von außen zugegriffen werden kann, erzeugt. Der interne Startwert ist in der persistenten Ablage 210 gespeichert und kann bei jedem Einschalt- oder Schlaf/Aufweck-Zyklus einmal aktualisiert werden. Nach der Aktualisierung kann dieser Startwert in Registern innerhalb der sicheren Vorrichtung gehalten werden, die annulliert werden, falls die sichere Vorrichtung in die Schlafbetriebsart eintritt oder falls die Leistung entfernt wird.
  • In einigen Implementierungen kann es für die persistente Ablage 210 eine Beständigkeitsspezifizierung geben, die die Anzahl beschränkt, in der der Startwert in der persistenten Ablage aktualisiert werden kann. In diesen Fällen kann die sichere Vorrichtung dafür konfiguriert sein, die Leistungszyklen in der Weise zu managen, dass die Anzahl der Aktualisierungen des Startwerts verringert wird. Unter bestimmten Umständen kann die sichere Vorrichtung die Startwertaktualisierung unter Verwendung von anderen Anweisungsmodulen zugeordneten Parametern unterdrücken.
  • Die sichere Vorrichtung kann das RandGen-Modul 232 verwenden, um auf einem getrennten Chip, der für kryptographische Authentifizierungsoperationen konfiguriert ist, die Eingabeauthentifizierungsabfrage für einen Nachrichtenauthentifizierungscode-Befehl (MAC-Befehl) bereitzustellen. In einigen Implementierungen kann die sichere Vorrichtung einen speziellen ”Zufalls”-Befehl für solche Fälle bereitstellen, ohne die intern gespeicherte Nonce zu beeinflussen. Als ein weiteres Beispiel kann der Zufallszahlgenerator verwendet werden, um die Eingabeauthentifizierungsabfrage für eine an eine Host-Vorrichtung gesendete Nachricht bereitzustellen, um zu verifizieren, ob die Host-Vorrichtung zum Kommunizieren mit der Client-Vorrichtung, in die die sichere Vorrichtung eingebettet ist, autorisiert ist.
  • Dem Nonce-Modul 234 sind Anweisungen zum Erzeugen einer Nonce zur Verwendung durch eine nachfolgende kryptographische Operation zugeordnet. Die Nonce kann durch Kombinieren einer intern erzeugte Zufallszahl mit einem Eingangswert von dem System erzeugt werden. Die resultierende Nonce wird intern in dem ephemeren Speicher 220 gespeichert und die erzeugte Zufallszahl wird an das System zurückgegeben.
  • Der Eingangswert kann dafür ausgelegt sein, Replay-Angriffe auf die Host-Vorrichtung in dem System zu verhindern – der Eingangswert kann durch das System extern erzeugt werden und unter Verwendung der dem Nonce-Modul 234 zugeordneten Anweisungen an die sichere Vorrichtung übergeben werden. Der Eingangswert kann irgendein Wert sein, der sich konsistent ändert, wie etwa ein nichtflüchtiger Speicher, die aktuelle Tagesechtzeit sein oder kann eine extern erzeugte Zufallszahl sein.
  • Um einen Nonce-Wert für nachfolgende kryptographische Operationen bereitzustellen, kann das Nonce-Modul 234 dafür konfiguriert sein, ein Nachrichtendigest einer Eingangszahl und einer Ausgangszufallszahl zu erzeugen. Das resultierende Nachrichtendigest ist der Nonce-Wert, der in einem Register in der sicheren Vorrichtung gespeichert werden kann. Daraufhin kann die Nonce von einer nachfolgenden kryptographischen Operation verwendet werden.
  • In einigen Implementierungen kann der tatsächliche Nonce-Wert von einem externen System verwendet werden. In solchen Implementierungen kann der Nonce-Wert extern berechnet und extern gespeichert werden, um die Ausführung von Befehlen durch das externe System abzuschließen. In einigen Implementierungen kann die Nonce ein fester Wert sein, der von dem Host-System gewählt wird.
  • In diesem Zusammenhang ist eine Nonce eine beliebige Zahl, die in einer kryptographischen Kommunikation zwischen Vorrichtungen nur einmal verwendet wird. Die Nonce kann eine Zufalls- oder Pseudozufallszahl sein, die in einem Authentifizierungsprotokoll ausgegeben wird, um sicherzustellen, dass alte Kommunikationen nicht in Replay-Angriffen wiederverwendet werden können. Eine Nonce kann ebenfalls verwendet werden, um die Sicherheit für eine Datenstromchiffre sicherzustellen. Wo derselbe kryptographische Schlüssel für mehr als eine Nachricht verwendet wird, kann eine andere Nonce verwendet werden, um sicherzustellen, dass der Schlüsseldatenstrom für verschiedene mit diesem Schlüssel verschlüsselte Nachrichten verschieden ist. Häufig wird die Nachrichtennummer verwendet.
  • Um sicherzustellen, dass eine Nonce nur einmal verwendet wird, sollte sie zeitlich veränderlich sein (einschließlich eines geeignet feinkörnigen Zeitstempels in ihrem Wert) oder mit ausreichend vielen Zufallsbits erzeugt werden, um eine probabilistisch unbedeutende Wahrscheinlichkeit der Wiederholung eines zuvor erzeugten Werts sicherzustellen.
  • Einem Nachrichtendigest ist in diesem Zusammenhang eine kryptographische Hash-Funktion zugeordnet, die einen beliebigen Datenblock nimmt und eine Bitfolge fester Größe, den (kryptographischen) Hash-Wert, zurückgibt, so dass irgendeine, entweder zufällige oder beabsichtigte, Änderung der Daten den Hash-Wert mit sehr hoher Wahrscheinlichkeit ändert. Die zu codierenden Daten werden häufig die ”Nachricht” genannt und der Hash-Wert wird gelegentlich das Nachrichtendigest oder einfach das Digest genannt.
  • Obwohl es für eine kryptographische Hash-Funktion, die eine starke Sicherheit sicherstellt, verhältnismäßig leicht sein kann, für irgendeine gegebene Nachricht das Digest zu berechnen, ist es nicht realisierbar, die Umkehrberechnung vorzunehmen, d. h. eine Nachricht zu erzeugen, die ein Digest hat. Außerdem ist es nicht realisierbar, eine Nachricht zu ändern, ohne das Digest zu ändern, oder zwei unterschiedliche Nachrichten mit demselben Digest zu ermitteln.
  • Wieder mit Bezug auf das GenKey-Modul 236 kann die Digestberechnung entweder unter Verwendung eines öffentlichen Schlüssels, der auf der Grundlage eines in der persistenten Ablage 210 gespeicherten privaten Schlüssels berechnet wird, oder unter Verwendung eines öffentlichen Schlüssels, der bereits in der persistenten Ablage gespeichert ist, ausgeführt werden. Im letzteren Fall können an dem persistenten Ablageplatz geeignete Prüfungen auf frühere Authentifizierung, beschränkte Verwendung oder andere Zugriffsbeschränkungen ausgeführt werden.
  • Dem GenKey-Modul 236 sind Anweisungen für die Schlüsselberechnung und für die Digestberechnung zugeordnet. Zum Beispiel enthält das GenKey-Modul 236 Anweisungen, die zum Erzeugen eines neuen, zufälligen privaten Schlüssels und zum Schreiben dieses Schlüssels in die persistente Ablage 210 konfiguriert sind. In einigen Implementierungen wird der Zufallszahlgenerator-Startwert vor der Ausführung dieser Anweisungen automatisch aktualisiert, falls der Zufallszahlgenerator-Startwert in dem aktuellen Leistungszyklus noch nicht aktualisiert worden ist.
  • Außerdem kann das GenKey-Modul 236 Anweisungen zum Erzeugen eines öffentlichen Schlüssels wie etwa eines öffentlichen Schlüssels einer Elliptische-Kurven-Kryptographie (ECC) auf der Grundlage eines in der persistenten Ablage gespeicherten privaten Schlüssels enthalten. Diese Anweisungen können verwendet werden, um auf Kosten der Zeit, die es dauert, ihn zu regenerieren, das Speichern des öffentlichen Schlüssels in der sicheren Vorrichtung zu vermeiden.
  • Außerdem kann das GenKey-Modul 236 Anweisungen zum Kombinieren eines öffentlichen Schlüssels mit einem in dem ephemeren Speicher 220 gespeicherten temporären Schlüsselwert, zum Berechnen eines kryptographischen Nachrichtendigests wie etwa eines Digests des sicheren 256-Bit-Hash-Standards (SHA-256) der resultierenden Nachricht und zum Zurückstellen des Digests in den ephemeren Speicher 220 enthalten. Das berechnete Digest kann als die Nachricht für eine interne Signatur oder als eine Komponente einer MAC-Berechnung verwendet werden.
  • KeyConfig 238 repräsentiert eine Anzahl von Bits (ein ”Bitfeld”), die Anweisungen zum Beschränken von Aktionen zugeordnet sind, die unter Verwendung von in der sicheren Zone 200 gespeicherten Informationen ausgeführt werden können. In einigen Implementierungen werden kryptographische Schlüssel und zugeordnete Sicherheitsparameter in spezifischen Bereichen der sicheren Zone wie etwa an vorgegebenen Orten in der persistenten Ablage, die Speicherplätze genannt werden, gespeichert. Jedem Speicherplatz kann sein eigenes KeyConfig-238-Bitfeld zugeordnet sein. Die Werte der Bits des KeyConfig 238 für jeden Speicherplatz geben die dem Speicherplatz zugeordneten Berechtigungen an.
  • ReqAuth 239 und AuthKey 240 geben Einstellungen für eines oder mehrere der Bits von KeyConfig 238 an. Zum Beispiel ist die Anzahl der Bits von KeyConfig 238 in einigen Implementierungen 16. ReqAuth 239 kann der Wert für das 8. Bit von KeyConfig 238 sein, während AuthKey 240 der Wert für die Bits 9–12 von KeyConfig 238 sein kann.
  • Wenn ReqAuth 239 1 gesetzt ist, gibt es an, dass eine Authentifizierung unter Verwendung eines Autorisierungsschlüssels erfolgreich abgeschlossen werden muss, bevor der in dem zugeordneten Speicherplatz gespeicherte kryptographische Schlüssel verwendet werden kann. Der Autorisierungsschlüssel wird durch den Wert von AuthKey 240 für dasselbe KeyConfig 238 wie das ReAuth 239 angegeben. Zum Beispiel kann der Wert von AuthKey 240 auf die Adresse eines Speicherplatzes abbilden, der den Autorisierungsschlüssel speichert.
  • Das GenDig-Modul 242 ist Anweisungen zum Erzeugen eines Digests zugeordnet. In einigen Implementierungen verwenden die dem GenDig-Modul 242 entsprechenden Anweisungen eine Hash-Funktion wie etwa SHA-256 oder den MD5-Nachrichtendigest-Algorithmus, um durch Kombinieren eines in der persistenten Ablage 210 gespeicherten Werts mit dem Inhalt eines Orts in dem ephemeren Speicher 220, der einen temporären Schlüsselwert speichert, ein Digest zu erzeugen. Der in der persistenten Ablage 210 gespeicherte Wert kann von den Datenorten oder von der Konfigurationszone in der persistenten Ablage 210 oder von Seitenorten für Einmalkennwörter (OTP), die in der persistenten Ablage 210 vorhanden sind, oder von einer Hardwaretransportschlüsselanordnung wiedergewonnen kommen. In einigen Implementierungen kann der in der persistenten Ablage 210 gespeicherte Wert ein Schlüssel oder ein anderer geheimer Wert sein. In solchen Implementierungen kann das Digest zum Verbinden der Authentifizierungsaktion mit einer Vielfalt geheimer Werte dienen.
  • Das erzeugte Digest kann in dem ephemeren Speicher 220 gespeichert werden und auf verschiedene Arten verwendet werden. Zum Beispiel kann das Digest als Teil einer Nachricht, die von kryptographischen Operationen verwendet wird, wie etwa von jenen, die dem Sign/Verify-Modul 244 zugeordnet sind, um eine Signatur zu erzeugen oder zu verifizieren, aufgenommen werden. In solchen Fällen kann das Digest zum Authentifizieren von an Datenorten oder OTP-Seitenorten in der persistenten Ablage 210 gespeicherten Daten dienen. Als ein weiteres Beispiel kann das Digest als ein Datenschutzdigest zum Bereitstellen einer Authentifizierung und/oder Vertraulichkeit für die Daten verwendet werden, wenn sie von einer Lese- oder Schreiboperation verwendet werden. In einem nochmals anderen Beispiel können die dem GenDig-Modul 242 zugeordneten Anweisungen für die sichere Personalisierung unter Verwendung eines Werts von einer Transportschlüsselanordnung verwendet werden. Das resultierende Datenschutzdigest würde dann von einer Schreiboperation verwendet.
  • Dem Sign/Verify-Modul 244 sind Anweisungen zum Erzeugen einer Signatur oder zum Verifizieren einer Signatur oder für beides zugeordnet. In einigen Implementierungen können die Anweisungen zum Erzeugen einer Signatur und die Anweisungen zum Verifizieren einer Signatur verschiedenen Modulen, z. B. einem Vorzeichenmodul bzw. einem anderen Verifizierungsmodul, zugeordnet sein. Allerdings können die Anweisungen in anderen Implementierungen wie in 2 dargestellt in demselben Modul kombiniert sein.
  • Einige der dem Sign/Verify-Modul 244 entsprechenden Anweisungen sind zum Erzeugen einer Signatur, z. B. unter Verwendung des Elliptische-Kurven-Digitalsignatur-Algorithmus (ECDSA), konfiguriert. Zum Berechnen der Signatur an einer Nachricht kann ein in der persistenten Ablage 210 gespeicherter privater Schlüssel wie etwa ein privater ECC-Schlüssel verwendet werden, der entweder intern in der sicheren Vorrichtung oder extern erzeugt werden kann. Im Fall einer externen Nachrichtenerzeugung kann das System die zu signierenden Informationen extern zusammenstellen und das Digest dieser Informationen unter Verwendung von Anweisungen für einen externen Hash-Algorithmus berechnen. Daraufhin wird das Digest z. B. unter Verwendung der dem Nonce-Modul 234 entsprechenden Anweisungen in den ephemeren Speicher 220 geladen.
  • Für die interne Nachrichtenerzeugung wird die zu signierende Nachricht intern in der sicheren Vorrichtung erzeugt. Zum Beispiel kann die Nachricht die Ausgabe von dem GenKey-Modul 236 oder dem GenDig-Modul 242 entsprechenden Anweisungen zusammen mit verschiedenen anderen Zustandsinformationen, die sich auf die sichere Vorrichtung beziehen, enthalten. Die Ausgabe der Anweisungen, die dem GenKey-Modul 236 oder dem GenDig-Modul 242 entsprechen, kann in dem ephemeren Speicher 220 angeordnet und mit Konfigurationsinformationen kombiniert werden. Auf diese Weise enthalten die Informationen, die durch die sichere Vorrichtung mit der sicheren Zone 200 authentifiziert werden, Informationen, die dem Zustand oder der Konfiguration der sicheren Vorrichtung zum Bereitstellen einer starken Sicherheit entsprechen.
  • Einige der dem Sign/Verify-Modul 244 entsprechenden Anweisungen sind dafür konfiguriert zu verifizieren, ob eine Signatur aus einer gegebenen Nachricht und einem öffentlichen Schlüssel richtig erzeugt worden ist. In einigen Implementierungen kann die Verifizierung in einer externen Betriebsart ausgeführt werden, in der der zu verwendende öffentliche Schlüssel ein Eingangsparameter für die Anweisungen ist. Vor Ausführung der Anweisungen wird die der Signatur entsprechende Nachricht, z. B. unter Verwendung der Anweisungen, die dem Nonce-Modul 234 entsprechen, in den ephemeren Speicher geschrieben. In der externen Betriebsart beschleunigt die sichere Vorrichtung die Berechnung des öffentlichen Schlüssels und gibt im Ergebnis der Verifizierung einen booleschen Wert (z. B. ”wahr” oder ”falsch”) zurück.
  • In einigen Implementierungen kann die Verifizierung in einer Gespeichert-Betriebsart ausgeführt werden, in der der zu verwendende öffentliche Schlüssel aus der persistenten Ablage 210 wiedergewonnen wird und die Nachricht zuvor in dem ephemeren Speicher 220 gespeichert wird. An dem öffentlichen Schlüssel können verschiedene Konfigurationsprüfungen ausgeführt werden. Falls die Konfigurationsprüfungen erfolgreich sind, wird die Berechnung der Verifizierung des öffentlichen Schlüssels ausgeführt und wird im Ergebnis ein boolescher Wert zurückgegeben. Andernfalls wird ein Ausführungsfehler zurückgegeben.
  • In einigen Implementierungen können die der Verifizierung entsprechenden Anweisungen in einer Validierungsbetriebsart verwendet werden. In dieser Betriebsart sind die Anweisungen zum Validieren eines in der persistenten Ablage 210 gespeicherten öffentlichen Schlüssels konfiguriert.
  • Obwohl nur einige Module in 2 gezeigt und in den vorhergehenden Abschnitten beschrieben worden sind, kann das Anweisungsmodul 230 außer den oder zusätzlich zu den zuvor beschriebenen Modulen andere kryptographische Module enthalten. Zum Beispiel kann das Anweisungsmodul 230 neben anderen Modulen ein DeriveKey-Modul, ein Lock-Modul, ein PrivWrite-Modul, ein Read-Modul und ein Write-Modul enthalten.
  • Dem DeriveKey-Modul sind Anweisungen zugeordnet, die zum Kombinieren des aktuellen Werts eines Schlüssels mit der in dem ephemeren Speicher 220 gespeicherten Nonce unter Verwendung eines Hash-Mechanismus wie etwa SHA-256 und zum Anordnen des Ergebnisses an einen Zielort in der persistenten Ablage 210 konfiguriert sind. Die DeriveKey-Modul-Anweisungen sind dafür konfiguriert, neben anderen Bedingungen einen Fehler zurückzugeben, falls der Zielplatz bereits einen privaten Schlüssel speichert oder falls der Zielplatz verriegelt ist.
  • Dem Lock-Modul sind Anweisungen zugeordnet, die zum Verhindern einer künftigen Änderung der Konfigurationszone und/oder -daten und OTP-Seitenorte in der persistenten Ablage 210 konfiguriert sind. In einigen Implementierungen können die Lock-Modul-Anweisungen verwendet werden, um einzelne Datenorte in der persistenten Ablage 210 zu verriegeln. Vor Ausführen der Verriegelungsoperationen können die Anweisungen, z. B. unter Verwendung eines zyklischen Redundanzprüfungsalgorithmus (CRC-Algorithmus), die Integrität des Inhalts der zu verriegelnden Orte verifizieren.
  • Dem PrivWrite-Modul sind Anweisungen zugeordnet, die zum Schreiben kryptographischer privater Schlüssel in die persistente Ablage 210 konfiguriert sind. Der Ort in der persistenten Ablage 210, an den ein Schlüssel geschrieben werden soll, wird für die Anweisungen als ein Eingangsparameter dargestellt.
  • Dem Read-Modul sind Anweisungen zugeordnet, die zum Lesen von Inhalt von der persistenten Ablage 210 oder von dem ephemeren Speicher 220 konfiguriert sind. Der Inhalt kann als Wörter, z. B. als ein 4-Byte-Wort oder als ein 8-Wort-Block von 32 Bytes, gelesen werden. In einigen Implementierungen können die Daten, die gelesen werden, verschlüsselt werden, bevor sie an das System zurückgegeben werden.
  • Dem Write-Modul sind Anweisungen zugeordnet, die zum Schreiben von Daten in die persistente Ablage 210 konfiguriert sind. Die Daten können als Wörter, z. B. als ein 4-Byte-Wort oder als ein 8-Wort-Block mit 32 Bytes, geschrieben werden. In einigen Implementierungen können die zu schreibenden Daten verschlüsselt werden, bevor sie zum Schreiben in die persistente Ablage 210 an die sichere Vorrichtung gesendet werden. Dies kann z. B. nützlich sein, um während der Personalisierung oder einer Systemoperation ein Abhören auf dem Bus zu verhindern. In einigen Implementierungen können die dem Write-Modul zugeordneten Anweisungen nicht zum Schreiben kryptographischer privater Schlüssel verwendet werden. Für diese Implementierungen können die kryptographischen privaten Schlüssel unter Verwendung von Anweisungen geschrieben werden, die dem wie zuvor beschriebenen PrivWrite-Modul entsprechen.
  • 3 veranschaulicht ein Beispiel eines Systems 300, das zum Erzeugen kryptographischer Schlüssel durch eine Client-Vorrichtungs-Hardware, die mit einer Host-Vorrichtung gekoppelt ist, verwendet werden kann. Das System 300 kann ebenfalls dafür verwendet werden zu verifizieren, ob die Host-Vorrichtung zum Kommunizieren mit der Client-Vorrichtung autorisiert ist. Das System 300 enthält eine Client-Vorrichtung 310, die unter Verwendung einer Verbindung 340 mit einer Host-Vorrichtung 330 gekoppelt ist. Neben anderen Komponenten enthält die Client-Vorrichtung 310 eine sichere Vorrichtung 320 und eine Client-Schnittstelle 312. Die sichere Vorrichtung 320 enthält eine sichere Zone 322, die einen oder mehrere kryptographische Schlüssel und zugeordnete Informationen wie etwa einen übergeordneten privaten Schlüssel 323, einen übergeordneten öffentlichen Schlüssel 324, ein übergeordnetes digitales Zertifikat 325, einen Autorisierungsschlüssel 326, einen untergeordneten privaten Schlüssel 327 und einen untergeordneten öffentlichen Schlüssel 328 aufnimmt. Die Host-Vorrichtung enthält neben anderen Komponenten eine Host-Schnittstelle 332 und ein kryptographisches Modul 334, das einen oder mehrere kryptographische Schlüssel und zugeordnete Informationen wie etwa einen Wurzelschlüssel 336, den Autorisierungsschlüssel 326 und den untergeordneten öffentlichen Schlüssel 328 speichert.
  • Die Client-Vorrichtung 310 ist ähnlich den zuvor beschriebenen Client-Vorrichtungen wie etwa der Client-Vorrichtung 100. Die Client-Vorrichtung 310 kann z. B. eine Zusatzkarte sein, die mit einer Hauptplatine verbunden ist. Als ein weiteres Beispiel kann die Client-Vorrichtung 310 eine in einen Computerdrucker eingeführte Druckerpatrone sein.
  • Die Client-Schnittstelle 312 ist dafür konfiguriert zu ermöglichen, dass die Client-Vorrichtung 310 mit der Host-Vorrichtung 330 kommuniziert. In einigen Implementierungen kann die Client-Schnittstelle 312 eine Netzschnittstelle sein, die die Client-Vorrichtung 310 über ein Netz mit einer fernen Host-Vorrichtung verbindet. Zum Beispiel kann die Client-Schnittstelle 312 einen Ethernet-Port, einen IEEE-802.11-Chip, eine BluetoothTM-Hardware oder ein Stück Software wie etwa Software-Radio enthalten. In einigen anderen Implementierungen kann die Client-Schnittstelle 312 eine elektrische Schnittstelle sein, die dafür konfiguriert ist, eine physikalische Kopplung zwischen der Client-Vorrichtung 310 und der Host-Vorrichtung 330 bereitzustellen. Zum Beispiel kann die Client-Schnittstelle 312 eine Universal-Serial-Bus-Schnittstelle (USB-Schnittstelle), eine externe Serial-AT-Attachment-Schnittstelle (eSATA-Schnittstelle), eine IEEE-1394-Schnittstelle (Firewire-Schnittstelle), eine Thunderbolt-Schnittstelle oder eine Lightning-Schnittstelle sein.
  • Die sichere Vorrichtung 320 ist eine Hardwareauthentifizierungsvorrichtung ähnlich der sicheren Vorrichtung 110. Die sichere Vorrichtung 320 ist dafür konfiguriert, für die Client-Vorrichtung 310 kryptographische Operationen wie etwa die sichere Speicherung, die Schlüsselerzeugung und die digitale Signatur bereitzustellen. Durch Bereitstellung von Diensten für die Client-Vorrichtung 310 kann die sichere Vorrichtung 320 eine starke Sicherheit in dem System 300 ermöglichen. In einigen Implementierungen kann die sichere Vorrichtung 320 ein Halbleiterchip wie etwa ein IC-Chip, der in die Client-Vorrichtung 310 eingebettet ist oder der extern mit der Client-Vorrichtung 310 gekoppelt ist, sein. In einigen anderen Implementierungen kann die sichere Vorrichtung 320 als Teil der Client-Vorrichtungs-Hardware wie etwa als Flash-Speicher oder als frei programmierbare logische Anordnung (FPGA) in der Client-Vorrichtung 310 implementiert sein.
  • Die sichere Zone 322 ist ähnlich der sicheren Zone 120 oder der sicheren Zone 200. Wie zuvor beschrieben wurde, kann die sichere Zone 322 enthalten: eine persistente Ablage, die ähnlich der persistenten Ablage 122 oder der persistenten Ablage 210 ist; einen ephemeren Speicher, der ähnlich dem ephemeren Speicher 124 oder dem ephemeren Speicher 220 ist; ein Anweisungsmodul, das ähnlich dem Anweisungsmodul 126 oder dem Anweisungsmodul 230 ist; und einen Prozessor oder ein digitales Verarbeitungselement wie etwa den Prozessor 112 oder den Prozessor 205.
  • In einigen Implementierungen werden einer oder mehrere kryptographische Schlüssel in der Client-Vorrichtung 310 gespeichert. Die kryptographischen Schlüssel werden in der sicheren Zone 322 entweder in der persistenten Ablage oder in dem ephemeren Speicher oder in einer geeigneten Kombination beider gespeichert. Wie zuvor beschrieben wurde, können die kryptographischen Schlüssel in Speicherplätzen in der sicheren Zone 322 gespeichert werden.
  • Die kryptographischen Schlüssel können innerhalb der sicheren Zone 322 unter Verwendung der Sicherheitsinformationen und von Sicherheitshilfsmitteln, die in der sicheren Vorrichtung 320 verfügbar sind, erzeugt werden. Alternativ können die kryptographischen Schlüssel, z. B. durch den Händler der Client-Vorrichtung 310, der die Schlüssel in der sicheren Vorrichtung 320 speichert, bevor die Client-Vorrichtung 310 zur Verwendung eingesetzt wird, extern von der sicheren Vorrichtung 320 erzeugt werden.
  • In einigen Implementierungen enthalten die in der sicheren Vorrichtung 320 gespeicherten kryptographischen Schlüssel einen übergeordneten privaten Schlüssel 323, der Teil eines asymmetrischen Paars eines privaten Schlüssels/eines öffentlichen Schlüssels ist. Der übergeordnete private Schlüssel 323 kann z. B. auf Elliptische-Kurven-Kryptographie-Hilfsmitteln (ECC-Hilfsmitteln), RSA-Algorithmen, einem ElGamal-System oder einem anderen geeigneten asymmetrischen Schlüsselsystem beruhen. Der übergeordnete private Schlüssel 323 ist nur der sicheren Vorrichtung 320 bekannt und ist für die Außenwelt wie etwa für die Host-Vorrichtung 330 nicht sichtbar. Der übergeordnete private Schlüssel 323 kann vor Verwendung der Client-Vorrichtung 310 durch den Händler in der Fabrik erzeugt werden und in seinem vorgegebenen Speicherplatz in der sicheren Zone 322 gespeichert werden.
  • Die in der sicheren Vorrichtung gespeicherten kryptographischen Schlüssel können den übergeordneten öffentlichen Schlüssel 324 enthalten, der auf der Grundlage des übergeordneten privaten Schlüssels 323 wie oben angegeben unter Verwendung eines geeigneten asymmetrischen Schlüsselsystems erzeugt wird. In einigen Implementierungen wird der übergeordnete öffentliche Schlüssel 324 vor Verwendung der Client-Vorrichtung 310 durch den Händler in der Fabrik erzeugt und in seinem vorgegebenen Speicherplatz in der sicheren Zone 322 gespeichert. In einigen anderen Implementierungen wird der übergeordnete öffentliche Schlüssel 324 nicht in einem vorgegebenen Speicherplatz in der sicheren Zone 322 gespeichert. Stattdessen wird der übergeordnete öffentliche Schlüssel 324 nach Bedarf unter Verwendung des geeigneten asymmetrischen Schlüsselsystems aus dem übergeordneten privaten Schlüssel 323 regeneriert.
  • Das übergeordnete Zertifikat 325 ist eine digitale Signatur, die an dem übergeordneten öffentlichen Schlüssel 324 berechnet wird und in ihrem eigenen vorgegebenen Speicherplatz in der sicheren Zone 322 angeordnet wird. Die digitale Signatur kann vor Verwendung der Client-Vorrichtung 310 durch den Händler erzeugt und in der sicheren Zone 322 gespeichert werden.
  • Das übergeordnete Zertifikat 325 wird unter Verwendung eines geeigneten asymmetrischen Schlüsselsystems, das dasselbe asymmetrische Schlüsselsystem sein kann, auf dessen Grundlage der übergeordnete öffentliche Schlüssel 324 aus dem übergeordneten privaten Schlüssel 323 erzeugt wird, an dem übergeordneten öffentlichen Schlüssel 324 berechnet. Alternativ kann die an dem übergeordneten öffentlichen Schlüssel 324 erzeugte digitale Signatur auf einem asymmetrischen Schlüsselsystem beruhen, das von dem zum Erzeugen des übergeordneten öffentlichen Schlüssels 324 aus dem übergeordneten privaten Schlüssel 323 verwendeten verschieden ist.
  • In einigen Implementierungen verwendet der Händler einen privaten Wurzelschlüssel, um den übergeordneten öffentlichen Schlüssel 324 zu signieren, um das übergeordnete Zertifikat 325 zu erzeugen. Der private Wurzelschlüssel ist ein vertrauenswürdiger asymmetrischer privater Schlüssel, der nur dem Händler bekannt ist und der auf einem geeigneten asymmetrischen Schlüsselsystem wie etwa auf einem der zuvor beschriebenen beruhen kann.
  • In diesen Implementierungen führt der Händler für alle Client-Vorrichtungen und Host-Vorrichtungen, die durch den Händler eingesetzt werden, die Rolle einer vertrauenswürdigen Zertifizierungsstelle (CA) aus. Durch den Händler können in einzelnen Client-Vorrichtungen 310 unterschiedliche übergeordnete private Schlüssel 323 gespeichert werden. Für jede Client-Vorrichtung 310 wird der entsprechende übergeordnete öffentliche Schlüssel 324, der ebenfalls verschieden sein kann, durch den Händler unter Verwendung des übergeordneten privaten Wurzelschlüssels signiert und wird das resultierende übergeordnete Zertifikat 325 in seinem vorgegebenen Speicherplatz in der sicheren Zone 322 der sicheren Vorrichtung 320, die in die jeweilige Client-Vorrichtung 310 eingebettet ist, gespeichert. Der Händler nutzt den dem privaten Wurzelschlüssel zugeordneten öffentlichen Wurzelschlüssel mit den Host-Vorrichtungen 330 gemeinsam, so dass eine Host-Vorrichtung das übergeordnete Zertifikat 325 einer Client-Vorrichtung 310, mit der die Host-Vorrichtung kommuniziert, verifizieren kann.
  • In einigen Implementierungen speichert die sichere Zone 322 einen Autorisierungsschlüssel 326. Der Autorisierungsschlüssel 326 kann ein symmetrischer Schlüssel sein, der mit einem symmetrischen Algorithmus wie etwa SHA-256 oder Advanced Encryption Standard (AES) verwendet wird, oder der Autorisierungsschlüssel 326 kann ein asymmetrischer Schlüssel sein. Der Autorisierungsschlüssel ist ein geheimer Schlüssel, der für die Außenwelt nicht sichtbar ist. Außer der sicheren Vorrichtung 320 ist der Autorisierungsschlüssel 326 einer oder mehreren Host-Vorrichtungen 330 bekannt, die durch den Händler zum Kommunizieren mit der Client-Vorrichtung 310, die die sichere Vorrichtung 320 einbettet, autorisiert worden sind.
  • In einigen Implementierungen ist die sichere Vorrichtung 320 so konfiguriert, dass zunächst eine Autorisierung erhalten werden muss, indem die Kenntnis des Autorisierungsschlüssels 326 nachgewiesen wird, um den übergeordneten privaten Schlüssel 323 zu verwenden. Zum Beispiel kann das dem Speicherplatz des übergeordneten privaten Schlüssels 323 entsprechende Bitfeld KeyConfig 238 mit dem Satz ReqAuth 239 und mit dem AuthKey 240, der auf denjenigen Speicherplatz weist, der die Autorisierungsschlüssel 326 speichert, konfiguriert sein.
  • In einigen Implementierungen speichert die sichere Zone einen untergeordneten privaten Schlüssel 327, der durch die Client-Vorrichtung 310 innerhalb der sicheren Zone 322 z. B. unter Verwendung des GenKey-Moduls 236 erzeugt wird. Der untergeordnete private Schlüssel 327 kann erzeugt werden, nachdem die Client-Vorrichtung 310 die Autorisierung der Host-Vorrichtung 330 unter Verwendung des Autorisierungsschlüssels 326 verifiziert hat, und beim Empfang von Anweisungen von der Host-Vorrichtung 330. Der untergeordnete private Schlüssel 327 kann auf einer geeigneten Zufallszahl beruhen, die unter Verwendung des RandGen-Moduls 232 erzeugt wird.
  • Außerdem kann die sichere Zone 322 einen untergeordneten öffentlichen Schlüssel 328 speichern, der auf der Grundlage des untergeordneten privaten Schlüssels 327 unter Verwendung eines geeigneten asymmetrischen Schlüsselsystems wie etwa eines der in den vorhergehenden Abschnitten beschriebenen erzeugt wird. Der untergeordnete öffentliche Schlüssel 328 kann durch die sichere Vorrichtung 320 unter Verwendung des GenKey-Moduls 236 erzeugt werden und in seinem vorgegebenen Speicherplatz in der sicheren Zone 322 gespeichert werden. Allerdings wird der untergeordnete öffentliche Schlüssel 328 in einigen Implementierungen nicht in einem vorgegebenen Speicherplatz in der sicheren Zone 322 gespeichert. Stattdessen wird der untergeordnete öffentliche Schlüssel 328 nach Bedarf unter Verwendung des geeigneten asymmetrischen Schlüsselsystems aus dem untergeordneten privaten Schlüssel 327 regeneriert.
  • Wie zuvor angegeben wurde und ausführlicher in den folgenden Abschnitten beschrieben ist, können die in der sicheren Zone 322 gespeicherten kryptographischen Schlüssel von der Client-Vorrichtung 310 verwendet werden, um zu verifizieren, ob die Host-Vorrichtung 330 zum Kommunizieren mit der Client-Vorrichtung autorisiert ist. Wenn eine Host-Vorrichtung 330 als autorisiert verifiziert wird, können die kryptographischen Schlüssel zum Aufbauen einer vertrauenswürdigen Beziehung zwischen der Client-Vorrichtung 310 und der Host-Vorrichtung 330 verwendet werden. Als Teil des Aufbauens der vertrauenswürdigen Beziehung kann die Host-Vorrichtung ebenfalls verifizieren, dass die Client-Vorrichtung den untergeordneten privaten Schlüssel, der zum Signieren von durch die Client-Vorrichtung gesendeten Nachrichten verwendet wird, kennt.
  • In diesem Zusammenhang gibt die Tatsache, dass eine Host-Vorrichtung 330 autorisiert worden ist, an, dass die Client-Vorrichtung 310 Nachrichten, die von der Host-Vorrichtung gesendet werden, als richtig annimmt. Die Nachrichten können Anweisungen für die Client-Vorrichtung 310 zum Ausführen einiger Operationen enthalten und die Client-Vorrichtung 310 ist zum Ausführen der Operationen auf der Grundlage von von einer autorisierten Host-Vorrichtung 330 gesendeten Anweisungen konfiguriert. Eine vertrauenswürdige Beziehung gibt an, dass eine von der Client-Vorrichtung 310 an die Host-Vorrichtung 330 gesendete Nachricht unter Verwendung eines in der sicheren Vorrichtung 320 gespeicherten kryptographischen Schlüssels wie etwa des untergeordneten privaten Schlüssels 327 durch die Client-Vorrichtung 310 signiert wird. Beim Empfang der Nachricht kann die Host-Vorrichtung 330 die Nachricht durch Prüfen der Signatur an der Nachricht unter Verwendung des untergeordneten öffentlichen Schlüssels 328, der dem untergeordneten privaten Schlüssel 327 entspricht, authentifizieren. Nachdem die Autorisierung der Host-Vorrichtung 330 verifiziert worden ist, kann der untergeordnete öffentliche Schlüssel 328 von der Client-Vorrichtung an die Host-Vorrichtung 330 gesendet werden.
  • Obwohl nur einige Komponenten für die Client-Vorrichtung 310 gezeigt sind, kann es außer oder anstelle der Client-Schnittstelle 312, der sicheren Vorrichtung 320 oder beider andere in der Client-Vorrichtung enthaltene Komponenten und Module geben.
  • Die Host-Vorrichtung 330 ist ähnlich den zuvor beschriebenen Host-Vorrichtungen. Zum Beispiel kann die Host-Vorrichtung 330 eine Hauptplatine sein, mit der eine Zusatzkarte als eine Client-Vorrichtung verbunden ist. Als ein weiteres Beispiel kann die Host-Vorrichtung ein Computerdrucker sein, der eine Druckerpatrone als die Client-Vorrichtung enthält.
  • Die Host-Schnittstelle 332 ist dafür konfiguriert zu ermöglichen, dass die Host-Vorrichtung 330 mit der Client-Vorrichtung 310 kommuniziert. In einigen Implementierungen kann die Host-Vorrichtung 332 eine Netzschnittstelle sein, die die Host-Vorrichtung 330 über ein Netz mit einer fernen Client-Vorrichtung verbindet. Die Host-Schnittstelle 332 kann z. B. einen Ethernet-Port, einen IEEE-802.11-Chip, Bluetooth-Hardware oder ein Stück Software wie etwa Software-Radio enthalten. In einigen anderen Implementierungen kann die Host-Schnittstelle 332 eine elektrische Schnittstelle sein, die zum Bereitstellen einer physikalischen Kopplung zwischen der Host-Vorrichtung 330 und der Client-Vorrichtung 310 konfiguriert ist. Zum Beispiel kann die Host-Schnittstelle 332 eine Universal-Serial-Bus-Schnittstelle (USB-Schnittstelle), eine externe serielle AT-Attachement-Schnittstelle (eSATA-Schnittstelle), eine IEEE-1394-Schnittstelle (Firewire-Schnittstelle), eine Thunderbolt-Schnittstelle oder eine Lightning-Schnittstelle sein.
  • Das Kryptomodul 334 kann ein Stück Hardware (wie etwa ein IC-Chip) oder Software (wie etwa Softwarebibliotheken), die in einen nichtflüchtigen Speicher in der Host-Vorrichtung eingebettet ist, oder eine Kombination aus Hardware und Software sein. Das Kryptomodul 334 stellt Dienstprogramme zur Ausführung kryptographischer Operationen bereit, um eine sichere Kommunikation der Host-Vorrichtung 330 mit der Client-Vorrichtung 310 zu ermöglichen.
  • In einigen Implementierungen speichert das Kryptomodul 334, z. B. in Speicherplätzen, die in der persistenten Ablage in dem Kryptomodul 334 konfiguriert sind, einen oder mehrere kryptographische Schlüssel. Die kryptographischen Schlüssel enthalten einen öffentlichen Wurzelschlüssel 336, der der öffentliche Schlüssel ist, der dem durch den Händler zum Signieren des übergeordneten Zertifikats 325 verwendeten privaten Wurzelschlüssel entspricht. Die Host-Vorrichtung 330 vertraut dem Händler als der CA, so dass der öffentliche Wurzelschlüssel 336 ein vertrauenswürdiger Schlüssel ist. Der Händler kann den öffentlichen Wurzelschlüssel 336 vor dem Einsatz der Host-Vorrichtung 330 in dem Kryptomodul 334 speichern, so dass die Host-Vorrichtung 330 nachfolgend während des Aufbaus einer Kommunikation mit einer Client-Vorrichtung 310 das übergeordnete Zertifikat 325 der Client-Vorrichtung 310 unter Verwendung des öffentlichen Wurzelschlüssels 336 verifizieren kann.
  • In einigen Implementierungen können verschiedene Händler verschiedene Paare eines privaten/eines öffentlichen Wurzelschlüssels zum Konfigurieren ihrer jeweiligen Client- und Host-Vorrichtungen verwenden. Zum Beispiel kann der Händler A den privaten Wurzelschlüssel A zum Erzeugen des übergeordneten Zertifikats 325, das den durch den Händler A eingesetzten Client-Vorrichtungen zugeordnet ist, verwenden und den entsprechenden öffentlichen Wurzelschlüssel A in den durch den Händler A eingesetzten Host-Vorrichtungen 330 speichern. Der private Wurzelschlüssel A kann nur dem Händler A bekannt sein, so dass folglich das Paar A eines privaten/eines öffentlichen Wurzelschlüssels nur durch den Händler A beim Signieren von Digests für Zertifikate verwendet werden kann. Ein anderer Händler B kann beim Konfigurieren von Client- und Host-Vorrichtungen, die dem Händler B zugeordnet sind, ein anderes Paar eines privaten/eines öffentlichen Wurzelschlüssels B verwenden. Somit kann die Host-Vorrichtung A, wenn ein Versuch unternommen wird, eine Client-Vorrichtung B, die durch den Händler B eingesetzt wird, mit einer Host-Vorrichtung A zu koppeln, die durch den Händler A eingesetzt wird, nicht in der Lage sein, das durch die Client-Vorrichtung B bereitgestellte übergeordnete Zertifikat zu authentifizieren, da das übergeordnete Zertifikat mit dem privaten Wurzelschlüssel B signiert ist, während der in der Host-Vorrichtung A gespeicherte öffentliche Wurzelschlüssel 336 der öffentliche Wurzelschlüssel A ist. Dementsprechend können verschiedene Händler unter Verwendung unterschiedlicher Paare eines privaten/eines öffentlichen Schlüssels die Host-Vorrichtungen auf das Verbinden mit ihren jeweiligen Client-Vorrichtungen und umgekehrt beschränken.
  • In einigen Implementierungen speichert das Kryptomodul 334 den Autorisierungsschlüssel 326, der durch den Händler vor dem Einsatz der Host-Vorrichtung 330 in der Host-Vorrichtung 310 vorgeladen werden kann. Wie zuvor angegeben wurde, können unterschiedliche Kategorien von Client-Vorrichtungen 310 oder Client-Vorrichtungen 310 von unterschiedlichen Händlern ihre eindeutigen Autorisierungsschlüssel aufweisen. Der Händler kann einen oder mehrere Autorisierungsschlüssel 326, die jenen Client-Vorrichtungen 310 entsprechen, mit denen zu kommunizieren die Host-Vorrichtung 330 durch den Händler autorisiert wird, in der Host-Vorrichtung 330 speichern. Zum Beispiel können alle blauen Druckerpatronen von dem Händler A einen Autorisierungsschlüssel gemeinsam nutzen, der von dem von allen roten Druckerpatronen von dem Händler A gemeinsam genutzten Autorisierungsschlüssel verschieden ist. Ein von dem Händler A eingesetzter Tintenstrahldrucker kann mit mehreren Autorisierungsschlüsseln 326 für die verschiedenen Farben eines bestimmten Modells von Tintenstrahlpatronen (wie etwa roten und blauen Patronen wie oben), die von dem Händler A hergestellt sind, die der Tintenstrahldrucker verwenden kann, vorgeladen sein. Allerdings kann der Händler A den Tintenstrahldrucker nicht mit Autorisierungsschlüsseln 326 laden, die einem anderen Modell von Druckerpatronen von dem Händler A, die für ein anderes Druckermodell bestimmt sind, entsprechen. Folglich kann der Tintenstrahldrucker seine Autorisierung nur für die roten und blauen Tintenstrahlpatronen nachweisen, mit denen der Tintenstrahldrucker Autorisierungsschlüssel gemeinsam nutzt, während der Drucker mit einem anderen Modell von Druckerpatronen, mit denen er keine Autorisierungsschlüssel gemeinsam nutzt, keine Autorisierung nachweisen kann. Somit kann der Händler A unterschiedliche Modelle von Druckern auf die Verwendung unterschiedlicher Modelle von Druckerpatronen beschränken.
  • Die Autorisierungsschlüssel, die den durch den Händler B hergestellten Tintenstrahldruckerpatronen zugeordnet sind, können von den in dem obigen Tintenstrahldrucker gespeicherten verschieden sein. Somit wird der Drucker, falls eine Tintenstrahlpatrone durch den Händler B in den Tintenstrahldrucker von dem Händler A eingeführt wird, für die Tintenstrahlpatrone des Händlers B nicht erfolgreich autorisiert und kann die Tintenstrahlpatrone von dem Händler B folglich in dem Drucker von dem Händler A nicht verwendet werden.
  • Das Kryptomodul 334 kann außerdem den übergeordneten öffentlichen Schlüssel 324 speichern. Nachdem die Autorisierung der Host-Vorrichtung durch einen Authentifizierungsabfrage-Antwort-Mechanismus unter Verwendung des Autorisierungsschlüssels 326 wie zuvor angegeben und in den folgenden Abschnitten ausführlicher diskutiert verifiziert worden ist, kann die Client-Vorrichtung 310 den übergeordneten öffentlichen Schlüssel 324 zusammen mit dem übergeordneten Zertifikat 325 an die Host-Vorrichtung 330 senden.
  • Die Host-Vorrichtung 330 verifiziert die Authentizität des übergeordneten öffentlichen Schlüssels 324 durch Verifizieren des übergeordneten Zertifikats 325 unter Verwendung des öffentlichen Wurzelschlüssels 336. In diesem Zusammenhang gibt die Verifizierung der Authentizität des übergeordneten öffentlichen Schlüssels 324 an, dass der übergeordnete öffentliche Schlüssel 324 auf der Grundlage der in dem übergeordneten Zertifikat 325 enthaltenen Informationen als eine bekannte Identität der Client-Vorrichtung 310 gebunden verifiziert worden ist. Das übergeordnete Zertifikat wird durch den privaten Wurzelschlüssel signiert. Da die Host-Vorrichtung 330 den vertrauenswürdigen öffentlichen Wurzelschlüssel 336 speichert, kann die Host-Vorrichtung 330 bestätigen, dass das übergeordnete Zertifikat 325 tatsächlich unter Verwendung des öffentlichen Wurzelschlüssels 336 durch die CA signiert worden ist.
  • Wenn der übergeordnete öffentliche Schlüssel 324 als authentisch verifiziert worden ist, kann die Host-Vorrichtung 330 den übergeordneten öffentlichen Schlüssel 324 in dem Kryptomodul 334 speichern. Wenn nachfolgend andere kryptographische Schlüssel oder Nachrichten von der Client-Vorrichtung 310 empfangen werden, die unter Verwendung des übergeordneten privaten Schlüssels 323 signiert und/oder verschlüsselt worden sind, kann die Host-Vorrichtung 330 durch Prüfen der Signatur und/oder Entschlüsseln der Nachricht unter Verwendung des übergeordneten öffentlichen Schlüssels 324 bestätigen, dass sie durch die Client-Vorrichtung 310 erzeugt worden sind.
  • Außerdem kann das Kryptomodul 334 den untergeordneten öffentlichen Schlüssel 328 speichern. Die Client-Vorrichtung 310 kann den untergeordneten öffentlichen Schlüssel 328 nach Empfang von Anweisungen von der autorisierten Host-Vorrichtung 330 zum Erzeugen eines Paars eines untergeordneten eines privaten Schlüssels/eines öffentlichen Schlüssels an die Host-Vorrichtung 330 senden. Die Client-Vorrichtung 310 erzeugt auf der Grundlage der Anweisungen den untergeordneten privaten Schlüssel 327 und den entsprechenden untergeordneten öffentlichen Schlüssel 328 und sendet den untergeordneten öffentlichen Schlüssel 328 an die Host-Vorrichtung 330.
  • In einigen Implementierungen kann die Client-Vorrichtung 310 den untergeordneten öffentlichen Schlüssel 328 zusammen mit einer Signatur an den untergeordneten öffentlichen Schlüssel 328 senden, der mit dem übergeordneten privaten Schlüssel 323 signiert worden ist, um ihre Authentizität nachzuweisen. Die Host-Vorrichtung 310 kann die Signatur an dem untergeordneten öffentlichen Schlüssel 328 unter Verwendung des übergeordneten öffentlichen Schlüssels 324 verifizieren. Falls die Signatur verifiziert wird, kann die Host-Vorrichtung 330 den untergeordneten öffentlichen Schlüssel 328 als von der Client-Vorrichtung 310 kommend annehmen. Daraufhin kann die Host-Vorrichtung 330 den untergeordneten öffentlichen Schlüssel 328 in dem Kryptomodul 334 speichern.
  • In einigen Implementierungen kann die Host-Vorrichtung verifizieren, dass die Client-Vorrichtung den untergeordneten privaten Schlüssel 327, der dem in dem Kryptomodul 334 gespeicherten untergeordneten öffentlichen Schlüssel 328 entspricht, kennt, bevor die Host-Vorrichtung nachfolgende Kommunikationen von der Client-Vorrichtung 310, die unter Verwendung des untergeordneten privaten Schlüssels 327 signiert worden sind, annimmt. Eine solche Verifizierung kann z. B. in Fällen nützlich sein, in denen nach einem Zeitintervall seit der Kommunikation, während der die Host-Vorrichtung 330 den untergeordneten öffentlichen Schlüssel 328 von der Client-Vorrichtung 310 empfangen hat, eine neue Kommunikationssitzung zwischen der Host-Vorrichtung und der Client-Vorrichtung initiiert wird. Die Verifizierung kann Replay-Angriffe, die durch nicht autorisierte Client-Vorrichtungen gestartet werden, verhindern helfen.
  • Die Verifizierung kann unter Verwendung eines Authentifizierungsabfrage-Antwort-Mechanismus ausgeführt werden, in dem die Host-Vorrichtung 330 eine Authentifizierungsabfrage erzeugt, die in einer Nachricht an die Client-Vorrichtung 310 gesendet wird. Die Client-Vorrichtung 310 antwortet mit einer signierten Version der Authentifizierungsabfrage, die mit einem der Client-Vorrichtung bekannten privaten Schlüssel signiert worden ist. Die Host-Vorrichtung prüft unter Verwendung des in dem Kryptomodul 334 gespeicherten untergeordneten öffentlichen Schlüssels 328, ob die Signatur an der Authentifizierungsabfrage unter Verwendung des untergeordneten privaten Schlüssels 327 erzeugt worden ist. Falls verifiziert wird, dass die Signatur unter Verwendung des untergeordneten privaten Schlüssels, der dem der Host-Vorrichtung 330 bekannten untergeordneten öffentlichen Schlüssel 328 entspricht, erzeugt worden ist, nimmt die Host-Vorrichtung 330 an, dass die Client-Vorrichtung 310 im Besitz des richtigen untergeordneten privaten Schlüssels 327 ist.
  • Die Verbindung 340 ist zum Koppeln der Client-Vorrichtung 310 mit der Host-Vorrichtung 320 konfiguriert. In einigen Implementierungen, in denen die Client-Vorrichtung und die Host-Vorrichtung fern voneinander sind, kann die Verbindung 340 eine Netzverbindung sein. Die Verbindung 340 kann z. B. über ein leitungsvermitteltes Datennetz, über ein paketvermitteltes Datennetz, über ein lokales Netz (LAN) oder über irgendein anderes Netz zum Übermitteln von Daten, z. B. über Internetprotokoll-gestützte (IP-gestützte) Netze oder Netze auf der Grundlage des asynchronen Übertragungsmodus (ATM) einschließlich verdrahteter oder drahtloser Netze, erfolgen. In einigen anderen Implementierungen, in denen die Client-Vorrichtung und die Host-Vorrichtung am nächsten angeordnet sind, kann die Verbindung 340 ein Datenkabel sein. In nochmals anderen Implementierungen, in denen die Client-Vorrichtung und die Host-Vorrichtung physikalisch gekoppelt sind, kann die Verbindung 340 eine Hardwareschnittstelle wie etwa eine PCI-Schnittstelle auf einer Hauptplatine sein.
  • Obwohl das System 300 eine Host-Client-Konfiguration mit der in der Client-Vorrichtung 310 enthaltenen sicheren Vorrichtung 320 zeigt, sind andere Konfigurationen ebenfalls möglich. Zum Beispiel kann die sichere Vorrichtung 320 extern von der Client-Vorrichtung 310, mit der Letzteren aber über eine geeignete Schnittstelle gekoppelt sein. Ähnlich kann das Kryptomodul 344 extern von der Host-Vorrichtung 330, mit dem Letzteren aber unter Verwendung einer geeigneten Schnittstelle gekoppelt sein. Eine solche Konfiguration kann ermöglichen, dass eine Client-Vorrichtung 310 und/oder eine Host-Vorrichtung 330, die gegebenenfalls nicht mit geeigneten Sicherheitsmerkmalen ähnlich der sicheren Vorrichtung 320 oder dem Kryptomodul 334 vorkonfiguriert sind, unter Verwendung des Vorrichtungsautorisierungs- und Schlüsselerzeugungs- und Speichermechanismus, die in den vorhergehenden Abschnitten beschrieben sind, sicher miteinander kommunizieren.
  • Obwohl das System 300 eine Host-Client-Konfiguration mit einer einzelnen Client-Vorrichtung 310 zeigt, sind andere Konfigurationen ebenfalls möglich. Zum Beispiel kann das System 300 mehrere Client-Vorrichtungen 310 enthalten, die mit einer einzelnen Host-Vorrichtung 330 verbunden sind. In einigen Implementierungen kann die Verbindung 340 unter den mehreren Client-Vorrichtungen 310 gemeinsam genutzt sein oder kann die Verbindung 340 für jede mit der Host-Vorrichtung 340 verbundene Client-Vorrichtung 310 wiederholt sein.
  • 4 ist ein Ablaufplan, der ein Beispiel eines Prozesses 400 darstellt, durch den eine Client-Vorrichtung unter Verwendung sicherer Hardware für die Kommunikation mit einer Host-Vorrichtung kryptographische Schlüssel erzeugen kann. Der Prozess 400 kann ebenfalls zum Verifizieren der Autorisierung der Host-Vorrichtung zum Kommunizieren mit der Client-Vorrichtung verwendet werden. Der Prozess 400 kann durch eine Client-Vorrichtung, die eine sichere Vorrichtung wie etwa die sichere Vorrichtung 320 zum Erzeugen kryptographischer Schlüssel in Hardware und zum Speichern der kryptographischen Schlüssel enthält, ausgeführt werden. Der Prozess 400 kann z. B. unter Verwendung der Client-Vorrichtung 310 in dem System 300 ausgeführt werden. Dementsprechend beschreibt der folgende Abschnitt den Prozess 400 in der Weise, dass er durch Komponenten des Systems 300 ausgeführt wird. Allerdings kann der Prozess 400 durch andere Schaltungen, Systeme oder Systemkonfigurationen ausgeführt werden.
  • Der Prozess 400 wird durch die Client-Vorrichtung als Teil eines sicheren Anfangsaustauschs mit der Host-Vorrichtung ausgeführt. Die Client-Vorrichtung erzeugt Z. B. auf der Grundlage von Anweisungen von der Host-Vorrichtung ein Paar eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels, die zum Authentifizieren von der Client-Vorrichtung an die Host-Vorrichtung gesendeter Nachrichten verwendet werden. Die Client-Vorrichtung authentifiziert die erzeugten kryptographischen Schlüssel unter Verwendung eines in der Client-Vorrichtung gespeicherten übergeordneten privaten Schlüssels wie etwa des übergeordneten privaten Schlüssels 323.
  • In einigen Implementierungen ist die Client-Vorrichtung in der Weise konfiguriert, dass die Host-Vorrichtung, bevor das Paar eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels erzeugt wird, nachweist, dass sie zum Senden von Anweisungen an die Client-Vorrichtung autorisiert ist. Zum Beispiel wird das dem übergeordneten privaten Schlüssel 323 entsprechende ReqAuth 239 in dem Bitfeld KeyConfig 238 eingestellt und bildet der zugeordnete AuthKey 240 auf die Adresse des Speicherplatzes in der sicheren Zone 322, der den Autorisierungsschlüssel 326 speichert, ab. Somit kann die Autorisierung der Host-Vorrichtung dadurch verifiziert werden, dass veranlasst wird, dass die Host-Vorrichtung nachweist, dass sie in Besitz des Autorisierungsschlüssels 326 ist. Die Autorisierung der Host-Vorrichtung wird durch einen Authentifizierungsabfrage-Antwort-Nachrichtenaustausch zwischen der Client-Vorrichtung und der Host-Vorrichtung ausgeführt.
  • Die Client-Vorrichtung erzeugt eine Zufallszahl (402). Zum Beispiel erzeugt die Client-Vorrichtung 310 eine Zufallszahl unter Verwendung des RandGen-Moduls 232. Die Zufallszahl kann unter Verwendung der sicheren Vorrichtung 320, z. B. in der sicheren Zone 322, erzeugt werden.
  • Die Client-Vorrichtung sendet eine Authentifizierungsabfrage mit der Zufallszahl an die Host-Vorrichtung (404). Zum Beispiel sendet die Client-Vorrichtung 310 eine Nachricht, die die neu erzeugte Zufallszahl als Teil der Nachricht enthält, an die Host-Vorrichtung 330.
  • Die Client-Vorrichtung empfängt eine Authentifizierungsabfrage-Antwort mit der signierten Zufallszahl (406). Zum Beispiel empfängt die Client-Vorrichtung 310 von der Host-Vorrichtung 330 als Antwort auf die Authentifizierungsabfragenachricht, die an die Letztere gesendet wurde, eine Nachricht. Die Nachricht von der Host-Vorrichtung 330 enthält eine Version der Zufallszahl, die mit einem kryptographischen Schlüssel signiert ist.
  • Die Client-Vorrichtung prüft, ob die Zufallszahlsignatur verifiziert wird (408). Zum Beispiel berechnet die Client-Vorrichtung 310 an der Zufallszahl, die sie unter Verwendung des Autorisierungsschlüssels 326 erzeugt hat, der in der sicheren Zone 322 gespeichert ist, einen Keyed-Hash-Wert. Die Client-Vorrichtung 310 vergleicht den berechneten Keyed-Hash-Wert mit der von der Host-Vorrichtung 330 empfangenen signierten Version der Zufallszahl und bestimmt, ob es eine Übereinstimmung gibt.
  • Falls der Keyed-Hash-Wert nicht mit der signierten Version der Zufallszahl übereinstimmt, wird die von der Host-Vorrichtung 330 empfangene signierte Zufallszahl nicht verifiziert. In diesem Fall kann die Client-Vorrichtung 310 nicht bestätigen, dass die Host-Vorrichtung 330 den Autorisierungsschlüssel 326 besitzt, und kann sie daher nicht bestätigen, dass die Host-Vorrichtung 330 zum Senden von Anweisungen an die Client-Vorrichtung autorisiert ist. Dies gibt eine Fehlerbedingung an (410). In einigen Implementierungen sendet die Client-Vorrichtung 310 eine Fehlermeldung an die Host-Vorrichtung 330 und bittet sie die Host-Vorrichtung, die Authentifizierungsabfrage-Antwort mit einer neu berechneten signierten Zufallszahl erneut zu senden oder die Transaktion abzubrechen. In einigen anderen Implementierungen beendet die Client-Vorrichtung 310 die Transaktion, ohne irgendeine Nachricht an die Host-Vorrichtung 330 zu senden.
  • Wie zuvor angegeben wurde, werden (402), (404), (406), (408) und (410) in Implementierungen verwendet, in denen die Host-Vorrichtung nachweisen muss, dass sie autorisiert ist, bevor durch die Client-Vorrichtung ein Paar eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels erzeugt wird. Somit können (402), (404), (406), (408) und (410) als optional angesehen werden, was in 4 durch die Strichlinienränder für (402), (404), (406), (408) und (410) angegeben ist.
  • Falls der Keyed-Hash-Wert wieder zurück zu (408) mit der signierten Version der Zufallszahl übereinstimmt, wird die von der Host-Vorrichtung 330 empfangene signierte Zufallszahl verifiziert. Dies gibt an, dass die Host-Vorrichtung 330 die Zufallszahl unter Verwendung desselben der Client-Vorrichtung 310 bekannten Autorisierungsschlüssels signiert hat. Folglich wird die Host-Vorrichtung 330 als zum Senden von Anweisungen an die Client-Vorrichtung 310 autorisiert verifiziert. Daraufhin kann die Client-Vorrichtung 310 die Bits in dem dem übergeordneten privaten Schlüssel 323 zugeordneten ReqAuth-Feld 239 in dem Bitfeld KeyConfig 238 setzen, was angibt, dass die Autorisierung der Host-Vorrichtung unter Verwendung des Autorisierungsschlüssels, auf den AuthKey 240 weist, nachgewiesen worden ist.
  • Der in dem vorhergehenden Abschnitt beschriebene Prozess des Nachweisens der Autorisierung des Hosts ist ein Beispiel der Verwendung einer symmetrischen Kryptographie für die Autorisierung. In einigen Implementierungen kann die Autorisierung des Hosts unter Verwendung einer asymmetrischen Kryptographie, z. B. durch einen Authentifizierungsabfrage-Antwort-Mechanismus unter Verwendung eines Paars eines privaten Schlüssels/öffentlichen Schlüssels, verifiziert werden. In solchen Implementierungen kann die Host-Vorrichtung 330 im Besitz eines privaten Schlüssels sein und ist der entsprechende öffentliche Schlüssel in einer Client-Vorrichtung 310 gespeichert, die dafür bestimmt ist, mit der Host-Vorrichtung 330 zu kommunizieren. Die Client-Vorrichtung 310 verifiziert wie in dem symmetrischen Fall durch einen Authentifizierungsabfrage-Antwort-Mechanismus, dass die Host-Vorrichtung autorisiert ist.
  • Die Client-Vorrichtung sendet eine Authentifizierungsabfrage (z. B. eine Nonce) an die Host-Vorrichtung. Nachfolgend empfängt die Client-Vorrichtung von der Host-Vorrichtung eine Antwort mit der Signatur auf die Authentifizierungsabfrage (406), die mit einem der Host-Vorrichtung bekannten privaten Schlüssel signiert ist.
  • Die Client-Vorrichtung prüft, ob die Signatur unter Verwendung des privaten Schlüssels, der dem öffentlichen Schlüssel, der bei der Client-Vorrichtung gespeichert ist, entspricht, erzeugt worden ist. Falls die Client-Vorrichtung bestimmt, dass es eine Übereinstimmung gibt, wird die Host-Vorrichtung 330 als zum Senden von Anweisungen an die Client-Vorrichtung 310 autorisiert verifiziert.
  • Wenn die Autorisierung der Host-Vorrichtung verifiziert wird, sendet die Client-Vorrichtung den übergeordneten öffentlichen Schlüssel und das zugeordnete Zertifikat an die Host-Vorrichtung (412). Zum Beispiel sendet die Client-Vorrichtung 310 den übergeordneten öffentlichen Schlüssel 324 und das übergeordnete Zertifikat 325 an die Host-Vorrichtung 330.
  • Daraufhin empfängt die Client-Vorrichtung von der Host-Vorrichtung eine Anweisung zum Erzeugen eines Paars eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels (414). Zum Beispiel empfängt die Client-Vorrichtung 310 von der Host-Vorrichtung 330 eine Nachricht, die für die Client-Vorrichtung 310 Anweisungen zum Erzeugen eines Paars eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels enthält.
  • Die Client-Vorrichtung erzeugt ein Paar eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels; speichert den untergeordneten privaten Schlüssel; und sendet den untergeordneten öffentlichen Schlüssel an die Host-Vorrichtung (416). Zum Beispiel erzeugt die Client-Vorrichtung 310 einen privaten Schlüssel 327 auf der Grundlage einer geeigneten Zufallszahl und eines entsprechenden untergeordneten öffentlichen Schlüssels 328 unter Verwendung von Anweisungen von dem GenKey-Modul 236 in der sicheren Vorrichtung 320. Die Client-Vorrichtung 310 speichert den untergeordneten privaten Schlüssel 327 in einem vorgegebenen Speicherplatz in der sicheren Zone. Der untergeordnete private Schlüssel 327 ist nur der Client-Vorrichtung 310 bekannt; er wird nicht mit irgendeiner anderen Vorrichtung gemeinsam genutzt. Die Client-Vorrichtung 310 erzeugt, z. B. unter Verwendung des GenDig-Moduls 242, ein Digest des untergeordneten öffentlichen Schlüssels 328 und speichert das Digest im temporären Speicher wie etwa in dem ephemeren Speicher in der sicheren Vorrichtung 320. Die Client-Vorrichtung 310 sendet eine Kopie des untergeordneten öffentlichen Schlüssels 328 an die Host-Vorrichtung 330.
  • Nachdem der untergeordnete öffentliche Schlüssel an die Host-Vorrichtung gesendet worden ist, empfängt die Client-Vorrichtung von der Host-Vorrichtung eine Anweisung zum Erzeugen einer Signatur an dem untergeordneten öffentlichen Schlüssel (418). Zum Beispiel empfängt die Client-Vorrichtung 310 als Antwort auf das Senden des untergeordneten öffentlichen Schlüssels 328 an die Host-Vorrichtung 330 von der Host-Vorrichtung eine Nachricht, die die Client-Vorrichtung anweist, das Digest des untergeordneten öffentlichen Schlüssels 328 unter Verwendung des übergeordneten privaten Schlüssels 323 zu signieren.
  • Die Client-Vorrichtung erzeugt an dem untergeordneten öffentlichen Schlüssel unter Verwendung des übergeordneten privaten Schlüssels eine Signatur und sendet die Signatur an die Host-Vorrichtung (420). Zum Beispiel berechnet die Client-Vorrichtung 310 unter Verwendung des übergeordneten privaten Schlüssels 323 an dem Digest des untergeordneten öffentlichen Schlüssels 328 eine digitale Signatur. Die Client-Vorrichtung 310 kann Anweisungen von dem Sign/Verify-Modul 244 zum Berechnen der digitalen Signatur verwenden. Die Client-Vorrichtung 310 sendet die berechnete digitale Signatur an die Host-Vorrichtung 330.
  • In einigen Implementierungen erzeugt die Client-Vorrichtung das Paar des untergeordneten privaten Schlüssels/öffentlichen Schlüssels und die Signatur an dem untergeordneten öffentlichen Schlüssel, ohne getrennte Anweisungen von der Host-Vorrichtung zu empfangen. Zum Beispiel kann die Client-Vorrichtung die Signatur an dem untergeordneten öffentlichen Schlüssel nach Erzeugen des untergeordneten öffentlichen Schlüssels automatisch berechnen. Nachfolgend kann die Client-Vorrichtung den untergeordneten öffentlichen Schlüssel und die zugeordnete Signatur zusammen an die Host-Vorrichtung senden. In solchen Implementierungen braucht die Client-Vorrichtung keine Anweisungen von der Host-Vorrichtung zu empfangen, um eine Signatur an dem untergeordneten öffentlichen Schlüssel zu erzeugen (418).
  • In einigen Implementierungen kann die an dem untergeordneten öffentlichen Schlüssel 328 erzeugte Signatur der sicheren Vorrichtung 320 entsprechende Zustandsinformationen enthalten. Die Zustandsinformationen können Konfigurationsinformationen, die dem für die Speicherung der untergeordneten öffentlichen oder privaten Schlüssel verwendeten Ort in der persistenten Ablage zugeordnet sind, Chipzustandsinformationen und Befehlsparameter enthalten. Die sichere Vorrichtung 320 kann einen Sensor enthalten, wobei die sichere Vorrichtung in diesem Fall als Teil des Digests, an dem die Signatur erzeugt wird, ein Sensorlesen verwenden kann.
  • In einigen Implementierungen ist der sichere Anfangsaustausch in dieser Phase abgeschlossen und kann die Client-Vorrichtung nachfolgend mit der Host-Vorrichtung Daten austauschen, die unter Verwendung des Paars des untergeordneten privaten Schlüssels/öffentlichen Schlüssels authentifiziert und/oder verschlüsselt werden. Allerdings kann die Client-Vorrichtung in anderen Implementierungen eine Authentifizierungsabfrage von der Host-Vorrichtung empfangen (422). Zum Beispiel kann die Client-Vorrichtung 310 nach Senden der Signatur an dem untergeordneten öffentlichen Schlüssel an die Host-Vorrichtung von der Host-Vorrichtung 330 eine Nachricht empfangen, die eine Authentifizierungsabfrage (z. B. eine Nonce oder eine andere Zufallszahl) enthält. Wie zuvor beschrieben wurde, kann die Host-Vorrichtung die Authentifizierungsabfrage an die Client-Vorrichtung senden, um nachzuweisen, dass die Client-Vorrichtung in Besitz des untergeordneten privaten Schlüssels ist, der dem untergeordneten öffentlichen Schlüssel entspricht. Neben anderen Verwendungen kann dies bei der Verhinderung von Replay-Angriffen nützlich sein.
  • Die Client-Vorrichtung signiert die Authentifizierungsabfrage bei Empfang der Nachricht von der Host-Vorrichtung mit dem untergeordneten privaten Schlüssel und sendet eine Antwort mit der signierten Authentifizierungsabfrage an die Host-Vorrichtung (424). Zum Beispiel kann die Client-Vorrichtung 310 die Authentifizierungsabfragenummer aus der durch die Host-Vorrichtung 330 gesendeten Nachricht extrahieren, an der Authentifizierungsabfrage ein Digest erzeugen und das Digest unter Verwendung des untergeordneten privaten Schlüssels 327 signieren. Daraufhin sendet die Client-Vorrichtung 310 an die Host-Vorrichtung 330 eine Antwort, die die mit dem untergeordneten privaten Schlüssel 327 erzeugte Signatur enthält. Nachfolgend kann die Host-Vorrichtung 330 die Signatur unter Verwendung des untergeordneten öffentlichen Schlüssels 328 verifizieren.
  • Die Client-Vorrichtung kann Zustandsinformationen oder andere Konfigurationsparameter, die der sicheren Vorrichtung 320 entsprechen, mit dem Digest kombinieren und an der Kombination des Digests und der Zustandsinformationen die Signatur erzeugen. Das Kombinieren der Zustands- oder anderen Konfigurationsinformationen kann zusätzliche Sicherheit sicherstellen, da sie verifizieren helfen, dass die Signatur durch eine Entität mit Zugang zu den physikalischen charakteristischen Informationen der sicheren Vorrichtung 320 erzeugt wurde.
  • In einigen Implementierungen kann die Verwendung des übergeordneten privaten Schlüssels und/oder des untergeordneten privaten Schlüssels zum Signieren eines beliebigen Digests beschränkt werden, um Vertrauen sicherzustellen, dass das durch den jeweiligen Schlüssel signierte Digest einem Anfangszustand, einer Konfiguration oder Geheimnissen, die in der sicheren Zone 322 gespeichert sind, entspricht. Zum Beispiel kann die sichere Vorrichtung 320 die Verwendung des Signierschlüssels auf Situationen beschränken, in denen das Digest durch die interne Schaltungsanordnung erzeugt wird. Die sichere Vorrichtung 320 kann dies dadurch erreichen, dass sie die Zustandsinformationen nachführt, die Werten zugeordnet sind, die entweder in der persistenten Ablage oder in dem ephemeren Speicher gespeichert sind.
  • In einigen Implementierungen kann die sichere Vorrichtung 320 die Art und Weise beschränken, in der eine Signatur berechnet wird, um eine Unterscheidung zwischen einer Signatur eines intern erzeugten Digests und eines extern bereitgestellten Digests sicherzustellen. Zum Beispiel kann das Format der Hash-Daten Zustandsbits enthalten, die die Einzelheiten des Digestberechnungsprozesses nachführen. Außerdem können die Befehlsinformationen für die Anweisungen, die der Signierungsoperation zugeordnet sind, in dem erzeugten Digest nachgeführt werden. Alternativ oder zusätzlich kann die Verarbeitung des Digests zum Erzeugen der tatsächlichen Eingangszahl in den asymmetrischen Algorithmus im Vergleich zu dem Fall, dass ein externes Digest signiert wird, anders sein, wenn ein internes Digest signiert wird. Zum Beispiel kann in einigen Implementierungen zum Signieren interner Digests das GenKey-Modul 236 verwendet werden, während dem Signieren extern bereitgestellter Digests das GenDig-Modul 242 zugeordnet sein kann.
  • (422) und (424) werden in Implementierungen verwendet, in denen die Host-Vorrichtung verifiziert, dass die Client-Vorrichtung im Besitz des untergeordneten privaten Schlüssels ist, der dem untergeordneten öffentlichen Schlüssel, der der Host-Vorrichtung bekannt ist, entspricht. Somit können (422) und (424) als optional angesehen werden, was in 4 durch die Strichlinienränder für (422) und (424) angegeben ist.
  • 5 ist ein Ablaufplan, der ein Beispiel eines Prozesses 500 darstellt, durch den eine Host-Vorrichtung von einer Client-Vorrichtung gesendete kryptographische Schlüssel verifiziert. Der Prozess 500 kann ebenfalls zum Autorisieren der Host-Vorrichtung für die Client-Vorrichtung verwendet werden. Der Prozess 500 kann durch eine Host-Vorrichtung ausgeführt werden, die mit einer Client-Vorrichtung kommuniziert, die eine sichere Vorrichtung wie etwa die sichere Vorrichtung 320 zur sicheren Speicherung und Signatur enthält. Zum Beispiel kann der Prozess 500 durch die Host-Vorrichtung 330 in dem System 300 ausgeführt werden. Dementsprechend ist der Prozess 500 im Folgenden in der Weise beschrieben, dass er durch Komponenten des Systems 300 ausgeführt wird. Allerdings kann der Prozess 500 durch andere Schaltungen, Systeme oder Systemkonfigurationen ausgeführt werden.
  • Der Prozess 500 kann durch die Host-Vorrichtung als Teil eines sicheren Anfangsaustauschs mit der Client-Vorrichtung ausgeführt werden. Zum Beispiel verifiziert die Host-Vorrichtung für die Client-Vorrichtung, dass die Erstere zum Senden von Anweisungen an die Letztere autorisiert ist. Bei Verifizierung sendet die Host-Vorrichtung an die Client-Vorrichtung Anweisungen zum Erzeugen eines Paars eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels zum Sichern des nachfolgenden Nachrichtenaustauschs zwischen der Client- und der Host-Vorrichtung. Die Host-Vorrichtung empfängt den erzeugten untergeordneten öffentlichen Schlüssel von der Client-Vorrichtung und authentifiziert den untergeordneten öffentlichen Schlüssel vor dem nachfolgenden Nachrichtenaustausch. In diesem Zusammenhang beschreibt der Prozess 500 Operationen der Host-Vorrichtung, die in Zusammenarbeit mit den durch den Prozess 400 beschriebenen Operationen der Client-Vorrichtung ausgeführt werden.
  • Als Teil des Prozesses 500 empfängt die Host-Vorrichtung in einigen Implementierungen von der Client-Vorrichtung eine Authentifizierungsabfrage mit einer Zufallszahl (502). Zum Beispiel empfängt die Host-Vorrichtung 330 von der Client-Vorrichtung 310 eine Nachricht, die eine durch die Client-Vorrichtung 310 erzeugte Zufallszahl enthält. Die Zufallszahl kann unter Verwendung der sicheren Vorrichtung 320 wie etwa durch das RandGen-Modul 232 erzeugt werden.
  • Die Host-Vorrichtung signiert die Zufallszahl unter Verwendung des gespeicherten Autorisierungsschlüssels (504). Zum Beispiel signiert die Host-Vorrichtung 330 die von der Client-Vorrichtung 310 empfangene Zufallszahl unter Verwendung des Autorisierungsschlüssels 326, der in dem Kryptomodul 334 gespeichert ist.
  • Die Host-Vorrichtung sendet an die Client-Vorrichtung eine Authentifizierungsabfrage-Antwort mit der Zufallszahlsignatur (506). Zum Beispiel sendet die Host-Vorrichtung 330 an die Client-Vorrichtung 310 eine Antwort, die eine von der Client-Vorrichtung 310 empfangene Version der Zufallszahl enthält. Die in der Antwort enthaltene Version der Zufallszahl wird mit dem Autorisierungsschlüssel 326 signiert.
  • Wie zuvor angegeben wurde, werden (502), (504) und (506) in Implementierungen verwendet, in denen die Host-Vorrichtung nachweisen muss, dass sie autorisiert ist, bevor durch die Client-Vorrichtung ein Paar eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels erzeugt wird. Somit können (502), (504) und (506) in einigen Implementierungen als optional angesehen werden, was in 5 durch die Strichlinienränder für (502), (504) und (506) angegeben ist.
  • Die Host-Vorrichtung empfängt von der Client-Vorrichtung einen übergeordneten öffentlichen Schlüssel und ein zugeordnetes Zertifikat (508). Zum Beispiel empfängt die Host-Vorrichtung 330 von der Client-Vorrichtung 310 den übergeordneten öffentlichen Schlüssel 524 und das übergeordnete Zertifikat 525, wobei der entsprechende übergeordnete private Schlüssel 323 in der sicheren Zone 322 der sicheren Vorrichtung 320 gespeichert wird.
  • In einigen Implementierungen sendet die Host-Vorrichtung an die Client-Vorrichtung eine Anweisung, die die Client-Vorrichtung anweist, aus dem übergeordneten privaten Schlüssel den übergeordneten öffentlichen Schlüssel zu erzeugen und den übergeordneten öffentlichen Schlüssel an die Host-Vorrichtung zu senden. Dies kann z. B. der Fall sein, wenn in der Client-Vorrichtung keine Kopie des übergeordneten öffentlichen Schlüssels gespeichert ist.
  • In einigen Implementierungen kann die Host-Vorrichtung von der Client-Vorrichtung nur den übergeordneten öffentlichen Schlüssel und kein begleitendes Zertifikat empfangen. In solchen Implementierungen liest die Host-Vorrichtung beim Empfang des übergeordneten öffentlichen Schlüssels das zugeordnete Zertifikat, das in der in die Client-Vorrichtung eingebetteten sicheren Vorrichtung gespeichert ist. Zum Beispiel kann die Host-Vorrichtung 330 an die Client-Vorrichtung 310 eine Anweisung senden, die um eine Kopie des gespeicherten übergeordneten Zertifikats 325, das in der sicheren Zone 322 der sicheren Vorrichtung 320 gespeichert ist, bittet.
  • Nach Empfang des übergeordneten öffentlichen Schlüssels verifiziert die Host-Vorrichtung, ob der übergeordnete Schlüssel gültig ist (510). Zum Beispiel prüft die Host-Vorrichtung 330, ob das empfangene Zertifikat 325 durch die vertrauenswürdige CA erzeugt worden ist. Da die vertrauenswürdige CA (d. h. der der Host-Vorrichtung 330 zugeordnete Händler) den entsprechenden privaten Wurzelschlüssel zum Signieren des Zertifikats verwenden würde, verwendet die Host-Vorrichtung 330 den öffentlichen Wurzelschlüssel 336, um die Authentizität des Zertifikats zu verifizieren. Das Zertifikat 325 bindet den empfangenen übergeordneten öffentlichen Schlüssel 324 an die Client-Vorrichtung 310. Somit kann die Host-Vorrichtung 330 annehmen, dass der öffentliche Wurzelschlüssel 324 gültig ist, falls die Authentizität des Zertifikats 325 verifiziert wird.
  • Falls das Zertifikat nicht als authentisch verifiziert werden kann, nimmt die Host-Vorrichtung den übergeordneten öffentlichen Schlüssel nicht als gültig an. Dies gibt eine Fehlerbedingung an (512). In einigen Implementierungen kann die Host-Vorrichtung 330 an die Client-Vorrichtung 310 eine Fehlermeldung senden, die die Client-Vorrichtung bittet, den übergeordneten öffentlichen Schlüssel 324 und das übergeordnete Zertifikat 325 erneut zu senden, oder die Transaktion abbrechen. In einigen anderen Implementierungen kann die Host-Vorrichtung 330 die Transaktion abbrechen, ohne irgendeine Nachricht an die Client-Vorrichtung 310 zu senden.
  • Falls das Zertifikat andererseits erfolgreich verifiziert wird, nimmt die Host-Vorrichtung den empfangenen übergeordneten öffentlichen Schlüssel als gültig an. Die Host-Vorrichtung speichert den übergeordneten öffentlichen Schlüssel als einen vertrauenswürdigen Schlüssel (514). Zum Beispiel speichert die Host-Vorrichtung 330 den übergeordneten öffentlichen Schlüssel 324 in dem Kryptomodul 334.
  • Daraufhin sendet die Host-Vorrichtung an die Client-Vorrichtung eine Anweisung, ein Paar eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels zu erzeugen (516). Zum Beispiel sendet die Host-Vorrichtung 330 an die Client-Vorrichtung 310 eine Anweisung, die die Client-Vorrichtung anweist, ein Paar eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels zu erzeugen, das für die Sicherung der künftigen Kommunikation von der Client-Vorrichtung 310 zu der Host-Vorrichtung 330 verwendet werden kann, wenn der übergeordnete öffentliche Schlüssel 324 als gültig verifiziert wird.
  • Die Host-Vorrichtung empfängt von der Client-Vorrichtung einen untergeordneten öffentlichen Schlüssel (518). Der untergeordnete öffentliche Schlüssel kann Teil des Paars eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels sein, das durch die Client-Vorrichtung auf die von der Host-Vorrichtung empfangene Anweisung folgend erzeugt wird. Zum Beispiel empfängt die Host-Vorrichtung 330 von der Client-Vorrichtung 310 den untergeordneten öffentlichen Schlüssel 328. Die Host-Vorrichtung 330 cacht den untergeordneten öffentlichen Schlüssel 328 lokal, bis der Schlüssel verifiziert werden kann.
  • Der Host sendet an die Client-Vorrichtung eine Anweisung zum Erzeugen einer Signatur an dem untergeordneten öffentlichen Schlüssel (520). Zum Beispiel sendet die Host-Vorrichtung 330 an die Client-Vorrichtung 310 eine Nachricht, die die Client-Vorrichtung anweist, ein Digest des untergeordneten öffentlichen Schlüssels 328, der in der Client-Vorrichtung, z. B. in dem ephemeren Speicher in der sicheren Vorrichtung 320, gespeichert ist, zu signieren.
  • Die Host-Vorrichtung empfängt von der Client-Vorrichtung eine Signatur eines untergeordneten öffentlichen Schlüssels (522). Zum Beispiel empfängt die Host-Vorrichtung 330 nach dem Senden der Nachricht, die die Client-Vorrichtung anweist, ein Digest des untergeordneten öffentlichen Schlüssels 328 zu signieren, an die Client-Vorrichtung 310 von der Client-Vorrichtung 310 eine Nachricht, die eine Signatur an dem untergeordneten öffentlichen Schlüssel 328 enthält. Die Signatur kann durch die Client-Vorrichtung 310, die das Digest des in dem ephemeren Speicher in der Client-Vorrichtung gespeicherten untergeordneten öffentlichen Schlüssels 328 signiert, erzeugt worden sein.
  • In einigen Implementierungen empfängt die Host-Vorrichtung von der Client-Vorrichtung den untergeordneten öffentlichen Schlüssel und die zugeordnete Signatur gleichzeitig. Dies kann z. B. der Fall sein, wenn die Client-Vorrichtung das Paar des untergeordneten privaten Schlüssels/öffentlichen Schlüssels und die Signatur an dem untergeordneten öffentlichen Schlüssel automatisch, ohne getrennte Anweisungen von der Host-Vorrichtung zu empfangen, erzeugt. In solchen Implementierungen braucht die Host-Vorrichtung an die Host-Vorrichtung keine getrennten Anweisungen zum Erzeugen einer Signatur an dem untergeordneten öffentlichen Schlüssel (520) zu senden.
  • Die Host-Vorrichtung prüft, ob die Signatur des untergeordneten öffentlichen Schlüssels gültig ist (524). Der untergeordnete öffentliche Schlüssel kann durch die Client-Vorrichtung unter Verwendung des untergeordneten privaten Schlüssels signiert werden und die Host-Vorrichtung kann die Signatur unter Verwendung des übergeordneten öffentlichen Schlüssels, der bei der Host-Vorrichtung gespeichert ist, verifizieren. Zum Beispiel kann die Host-Vorrichtung 330 die Signatur an dem untergeordneten öffentlichen Schlüssel 328 unter Verwendung des übergeordneten öffentlichen Schlüssels 324 verifizieren und folglich den untergeordneten öffentlichen Schlüssel verifizieren. In einigen Implementierungen entschlüsselt die Host-Vorrichtung 330 die von der Client-Vorrichtung 310 empfangene Signatur des untergeordneten öffentlichen Schlüssels unter Verwendung der lokal gespeicherten Kopie des übergeordneten öffentlichen Schlüssels 324 und erhält das Digest. Die Host-Vorrichtung 330 berechnet auf der Grundlage der gecachten Kopie des untergeordneten öffentlichen Schlüssels 328 zusammen mit Zustands- und/oder Konfigurationsinformationen, die der sicheren Vorrichtung 320 zugeordnet sind, die von der Client-Vorrichtung 310 empfangen worden sein können, lokal ein neues Digest.
  • Falls die Signatur des untergeordneten öffentlichen Schlüssels nicht gültig ist, wird eine Fehlerbedingung angegeben (512). Falls z. B. die unter Verwendung des lokal gespeicherten übergeordneten öffentlichen Schlüssels durch die Host-Vorrichtung 330 berechnete Signatur nicht mit der von der Client-Vorrichtung 310 empfangenen Signatur übereinstimmt, kann der von der Client-Vorrichtung empfangene untergeordnete öffentliche Schlüssel nicht als gültig verifiziert werden. In diesem Fall wirkt die Host-Vorrichtung 330 auf ähnliche Weise wie zuvor in Bezug auf die Angabe der Fehlerbedingung beschrieben worden ist (512).
  • Falls die von der Client-Vorrichtung empfangene Signatur an dem untergeordneten öffentlichen Schlüssel andererseits als gültig verifiziert wird, kann die Host-Vorrichtung den untergeordneten öffentlichen Schlüssel als einen gültigen Schlüssel speichern. Zum Beispiel verifiziert die Host-Vorrichtung den empfangenen untergeordneten öffentlichen Schlüssel 328 erfolgreich als gültig, falls das neue Digest mit dem Digest, das wie oben beschrieben durch Entschlüsseln der empfangenen Signatur erhalten wird, übereinstimmt. Somit kann die Host-Vorrichtung 330 den von der Client-Vorrichtung 310 empfangenen untergeordneten öffentlichen Schlüssel 328 verifizieren.
  • In einigen Implementierungen kann die Host-Vorrichtung eine weitere Authentifizierungsabfrage-Antwort ausführen, um zu verifizieren, dass die Client-Vorrichtung, mit der sie aktuell kommuniziert, im Besitz des untergeordneten privaten Schlüssels ist, der dem kürzlich validierten untergeordneten öffentlichen Schlüssel entspricht. Die Host-Vorrichtung sendet eine Authentifizierungsabfrage an die Client-Vorrichtung (526). Zum Beispiel erzeugt die Host-Vorrichtung 330 eine Zufallszahl und sendet sie an die Client-Vorrichtung 310 eine Nachricht, die die Zufallszahl enthält.
  • Die Host-Vorrichtung empfängt von der Client-Vorrichtung eine Antwort mit einer signierten Authentifizierungsabfrage (528). Zum Beispiel empfängt die Host-Vorrichtung 330 eine Antwort auf die Authentifizierungsabfragenachricht, die an die Client-Vorrichtung 310 gesendet wird. Die Antwortnachricht enthält eine Signatur an der Zufallszahl, die durch die Host-Vorrichtung erzeugt wurde.
  • Die Host-Vorrichtung bestimmt, ob die Authentifizierungsabfragesignatur mit dem untergeordneten öffentlichen Schlüssel verifiziert werden kann (530). Zum Beispiel prüft die Host-Vorrichtung 330, ob die Signatur an der Zufallszahl, die von der Client-Vorrichtung empfangen wird, mit dem untergeordneten öffentlichen Schlüssel 328 verifiziert werden kann. Falls der untergeordnete öffentliche Schlüssel die Signatur nicht verifizieren kann, wird eine Fehlerbedingung angegeben (512).
  • Andererseits speichert die Host-Vorrichtung den untergeordneten öffentlichen Schlüssel als einen vertrauenswürdigen Schlüssel, falls die von der Client-Vorrichtung empfangene Authentifizierungsabfragesignatur unter Verwendung des untergeordneten öffentlichen Schlüssels verifiziert wird (532). Zum Beispiel kann die Host-Vorrichtung bestätigen, dass die Client-Vorrichtung, mit der sie aktuell kommuniziert, in Besitz des untergeordneten privaten Schlüssels ist, der dem untergeordneten öffentlichen Schlüssel 328 entspricht, falls die Host-Vorrichtung 330 die Zufallszahlsignatur unter Verwendung des untergeordneten öffentlichen Schlüssels 328 erfolgreich verifizieren kann. Folglich speichert die Host-Vorrichtung 330 den untergeordneten öffentlichen Schlüssel 328 als einen vertrauenswürdigen Schlüssel, d. h., der untergeordnete öffentliche Schlüssel 328 ist durch die sichere Vorrichtung 320 erzeugt worden, die bei der Client-Vorrichtung 310 eingebettet ist und der das auf der Grundlage des öffentlichen Wurzelschlüssels 336 authentifizierte Paar eines übergeordneten öffentlichen Schlüssels/privaten Schlüssels zugeordnet ist. In diesem Fall speichert die Host-Vorrichtung 330 den untergeordneten öffentlichen Schlüssel 328 als einen vertrauenswürdigen Schlüssel z. B. in dem Kryptomodul 334.
  • (526), (528) und (530) werden in Implementierungen verwendet, in denen die Host-Vorrichtung einen Authentifizierungsabfrage-Antwort-Mechanismus verwendet, um zu verifizieren, dass die Client-Vorrichtung tatsächlich in Besitz des untergeordneten privaten Schlüssels ist, der dem untergeordneten öffentlichen Schlüssel, der der Host-Vorrichtung bekannt ist, entspricht. Somit können (526), (528) und (530) in einigen Implementierungen als optional angesehen werden, was in 5 durch die Strichlinienränder für (526), (528) und (530) angegeben ist.
  • In dieser Phase ist der sichere Anfangsaustausch abgeschlossen. Nachfolgend kann die Host-Vorrichtung 330 von der Client-Vorrichtung 310 gesendete Nachrichten, die durch den untergeordneten öffentlichen Schlüssel 328 signiert worden sind, authentifizieren, d. h. annehmen, dass die Informationen in der Nachricht durch die Client-Vorrichtung 310 erzeugt worden sind. Außerdem kann die Host-Vorrichtung 330 den untergeordneten öffentlichen Schlüssel 328 zum Entschlüsseln und Lesen einer Kommunikation verwenden, die durch die Client-Vorrichtung 310 unter Verwendung des untergeordneten privaten Schlüssels 327 verschlüsselt worden ist.
  • Wie in den vorhergehenden Abschnitten beschrieben worden ist, kann eine Client-Vorrichtung eingebettete sichere Hardware verwenden, um die Autorisierung einer Host-Vorrichtung, mit der die Client-Vorrichtung verbunden ist, zu prüfen und um dementsprechend kryptographische Schlüssel für die sichere Kommunikation zwischen den zwei Vorrichtungen zu erzeugen. Die Client-Vorrichtung kann Informationen über den Zustand oder über die Konfiguration der sicheren Vorrichtung beim Erzeugen der kryptographischen Schlüssel und/oder beim Berechnen von Signaturen an den erzeugten Schlüsseln und Nachrichten enthalten. Somit kann die sichere Vorrichtung eine robuste Sicherheit bereitstellen, die an die Eigenschaften der signierenden Entität gebunden ist. Die ECC kann als die Grundlage des asymmetrischen kryptographischen Schemas zum Erzeugen der kryptographischen Schlüssel und der Signaturen verwendet werden. Allerdings können andere asymmetrische kryptographische Mechanismen, z. B. der RSA-Algorithmus mit öffentlichen Schlüsseln, ebenfalls verwendet werden. Außerdem können mit der ECC andere Kurven verwendet werden und können von ECEDSA verschiedene Signaturschemata wie etwa der Digital Signature Algorithm (DSA) oder die Schnorr-Signatur oder ein anderer geeigneter Mechanismus verwendet werden.
  • In einigen Implementierungen kann die durch die sichere Vorrichtung bereitgestellte Sicherheit durch das Implementieren von Richtlinienbeschränkungen an die Verwendung des Signierungsschlüssels, z. B. durch die Aufnahme von Identitätsinformationen wie etwa Biometrie, variiert werden. Die Digests, die durch die sichere Vorrichtung erzeugt werden, können unter Verwendung programmierbarer Erzeugungsschemata anstelle fester Berechnung implementiert werden. Außerdem können die Berechnungen der kryptographischen Schlüssel als Alternative oder zusätzlich zur Verwendung der Stelle in der persistenten Ablage, an der die Schlüssel gespeichert sind, die Nutzung von Eigenschaften der Schlüssel enthalten. In einigen Implementierungen kann das Paar eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels nach einer bestimmten Zeitdauer auf der Grundlage der anwendbaren Sicherheitsrichtlinie regeneriert werden.
  • Durch Verwendung einer sicheren Vorrichtung zum Erzeugen kryptographischer Schlüssel wie in den vorhergehenden Abschnitten beschrieben können Herstellungskosten gesenkt werden, da einige Schlüssel wie etwas das Paar des untergeordneten privaten Schlüssels/öffentlichen Schlüssels nach der Herstellung erzeugt werden können. In einigen Implementierungen können einige Zertifikate/Signaturen und der Vorrichtungsautorisierungsschlüssel zu einer Zeit nach der Vorrichtungspersonalisierung am Herstellungsstandort erzeugt werden. In solchen Implementierungen kann es keine Anforderung, den privaten Wurzelschlüssel sicher am Herstellungsstandort zu speichern, geben, was die Herstellungskomplexität verringern kann. Da die kryptographischen Schlüssel durch die Client-Vorrichtung erzeugt werden können, nachdem sie den Herstellungsstandort verlassen hat, kann der private Wurzelschlüssel an anderer Stelle (z. B. auf einem Internet-Server) gespeichert werden. Da der untergeordnete öffentliche Schlüssel durch die Client-Vorrichtung an dem Endverwendungsstandort erzeugt werden kann, können Bedenken über die Privatsphäre oder über die Sicherheit in der Fabrik erzeugter kryptographischer Schlüssel zerstreut werden.
  • Unter Verwendung einer Hierarchie vertrauenswürdiger Schlüssel wie etwa des Paars eines privaten/eines öffentlichen Wurzelschlüssels, des Paars eines übergeordneten privaten Schlüssels/öffentlichen Schlüssels und des Paars eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels können für einzelne Entitäten Schlüssel bereitgestellt werden, die nur sie verwenden können. Dies ordnet nur diesen Schlüssel der bestimmten Entität zu.
  • In einigen Implementierungen kann die Client-Vorrichtung darauf beschränkt werden, immer nur mit einer einzelnen Host-Vorrichtung zu arbeiten. Dies kann dadurch erreicht werden, dass der untergeordnete öffentliche Schlüssel der Vorrichtung in dem Host-Speicher gespeichert wird. Falls die Client-Vorrichtung zu einer neuen Host-Vorrichtung umgesetzt wird, wird die Beziehung zu der alten Host-Vorrichtung beseitigt, was die gleichzeitige Verwendung mit zwei Host-Vorrichtungen verhindert. Die neue Host-Vorrichtung müsste die Client-Vorrichtung anweisen, neue untergeordnete private Schlüssel/öffentliche Schlüssel, die der alten Host-Vorrichtung nicht bekannt wären, zu erzeugen. Außerdem würde der Schlüssel von einer anderen Host-Vorrichtung nicht angenommen, falls ein untergeordneter öffentlicher Schlüssel auf irgendeine Weise bloßgestellt würde, da die neue Host-Vorrichtung fordern würde, dass die Client-Vorrichtung ein neues Paar eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels erzeugt.
  • In einigen Implementierungen kann die Client-Vorrichtung darauf beschränkt werden, nur mit einer Host-Vorrichtung zu arbeiten, und kann verhindert werden, dass sie mit irgendeiner anderen Host-Vorrichtung arbeitet. Dies kann dadurch erzielt werden, dass die Client-Vorrichtung in der Weise konfiguriert wird, dass der untergeordnete öffentliche Schlüssel über einen Zählermechanismus darauf beschränkt wird, einmal erzeugt zu werden.
  • In einigen Implementierungen ermöglicht die Verwendung des Autorisierungsschlüssels die Beschränkung der Erzeugung des Paars eines untergeordneten privaten Schlüssels/öffentlichen Schlüssels auf eine bestimmte Anzahl. Falls der Autorisierungsschlüssel nicht erforderlich wäre, könnte eine gegnerische Host-Vorrichtung die Client-Vorrichtung anweisen, ein Paar des untergeordneten privaten Schlüssels/öffentlichen Schlüssels oftmals zu erzeugen, bis der Schlüsselverwendungszähler erschöpft ist, wodurch die weitere Verwendung dieses untergeordneten Schlüssels verweigert wird. Mit dem Autorisierungsmechanismus könnte ein nicht autorisierter Angreifer diesen Angriff nicht führen, da der Angreifer den Autorisierungsschlüssel zum Verifizieren bei der Client-Vorrichtung nicht besitzen würde.
  • In einigen Implementierungen hängt die Sicherheit eines kryptographischen Schlüssels mit der Anzahl zusammen, in der der Schlüssel verwendet wird. In solchen Implementierungen verbessert die Beschränkung der Verwendung eines kryptographischen Schlüssels, indem gefordert wird, dass die Host-Vorrichtung autorisiert wird, die Sicherheit des Schlüssels. Ein Angreifer kann die Client-Vorrichtung überhaupt nicht anweisen, das Paar des untergeordneten privaten Schlüssels/öffentlichen Schlüssels zu erzeugen, falls der Angreifer die geforderte Autorisierung nicht erhalten kann.
  • Obwohl dieses Dokument viele spezifische Implementierungseinzelheiten enthält, sind diese nicht als Beschränkungen des Schutzumfangs der Ansprüche, sondern als Beschreibungen von Merkmalen, die spezifisch für bestimmte Ausführungsformen sein können, zu verstehen. Bestimmte Merkmale, die in dieser Beschreibung im Kontext getrennter Ausführungsformen beschrieben sind, können ebenfalls zusammen in einer einzelnen Ausführungsform implementiert werden. Umgekehrt können verschiedene Merkmale, die im Kontext einer einzelnen Ausführungsform beschrieben sind, in mehreren Ausführungsformen getrennt oder in irgendeiner geeigneten Unterkombination implementiert werden. Obwohl Merkmale oben in der Weise beschrieben und anfangs sogar in der Weise beansprucht worden sein können, dass sie in bestimmten Kombinationen wirken können, können darüber hinaus in einigen Fällen eines oder mehrere Merkmale aus einer beanspruchten Kombination aus der Kombination entfernt werden und kann die beanspruchte Kombination auf eine Teilkombination oder Änderung einer Teilkombination gerichtet sein.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • IEEE-802.11-Chip [0096]
    • IEEE-1394-Schnittstelle [0096]
    • IEEE-802.11-Chip, [0115]
    • IEEE-1394-Schnittstelle [0115]

Claims (26)

  1. Verfahren, das umfasst: Senden eines übergeordneten öffentlichen Schlüssels und eines zugeordneten Zertifikats an eine Host-Vorrichtung durch eine Client-Vorrichtung, die mit der Host-Vorrichtung gekoppelt ist, wobei der übergeordnete öffentliche Schlüssel, das Zertifikat und ein entsprechender übergeordneter privater Schlüssel in einer sicheren persistenten Ablage gespeichert sind, die in einer der Client-Vorrichtung zugeordneten sicheren Vorrichtung enthalten ist, und wobei der übergeordnete öffentliche und private Schlüssel kryptographische Schlüssel sind und wobei das Zertifikat ein kryptographisches Zertifikat ist; Empfangen von Anweisungen zum Erzeugen eines Paars eines untergeordneten privaten und öffentlichen Schlüssels von der Host-Vorrichtung bei der Client-Vorrichtung; Erzeugen eines untergeordneten privaten Schlüssels auf der Grundlage einer innerhalb der sicheren Vorrichtung erzeugten ersten Zufallszahl und eines dem untergeordneten privaten Schlüssel zugeordneten untergeordneten öffentlichen Schlüssels durch die Client-Vorrichtung als Antwort auf den Empfang der Anweisungen, wobei der untergeordnete private und öffentliche Schlüssel kryptographische Schlüssel sind; Berechnen einer ersten Signatur an dem untergeordneten öffentlichen Schlüssel unter Verwendung des übergeordneten privaten Schlüssels durch die Client-Vorrichtung, wobei die erste Signatur eine kryptographische Signatur ist; und Senden des untergeordneten öffentlichen Schlüssels und der ersten Signatur an die Host-Vorrichtung durch die Client-Vorrichtung.
  2. Verfahren nach Anspruch 1, wobei das Paar des untergeordneten privaten und öffentlichen Schlüssels innerhalb der sicheren Vorrichtung erzeugt wird und wobei das Berechnen der ersten Signatur an dem untergeordneten öffentlichen Schlüssel unter Verwendung des übergeordneten privaten Schlüssels umfasst: Kombinieren einer Nonce mit dem untergeordneten öffentlichen Schlüssel, um ein Digest zu erzeugen, unter Verwendung der sicheren Vorrichtung; Kombinieren des Digests mit der sicheren Vorrichtung zugeordneten Informationen; und Erzeugen der ersten Signatur durch Ausführen einer Berechnung einer asymmetrischen kryptographischen Signatur unter Verwendung des übergeordneten privaten Schlüssels an der Kombination des Digests und der der sicheren Vorrichtung zugeordneten Informationen durch die sichere Vorrichtung.
  3. Verfahren nach Anspruch 2, wobei die der sicheren Vorrichtung zugeordneten Informationen Zustandsinformationen der sicheren Vorrichtung und/oder Schlüsselablage-Konfigurationsinformationen und/oder Schlüsselablage-Zustandsinformationen und/oder Befehlsparameter enthalten.
  4. Verfahren nach Anspruch 1, wobei das Authentifizieren der Host-Vorrichtung durch die Client-Vorrichtung umfasst: Setzen eines in der sicheren Vorrichtung enthaltenen Bits, das dem übergeordneten privaten Schlüssel zugeordnet ist, das angibt, dass die Host-Vorrichtung authentifiziert worden ist.
  5. Verfahren nach Anspruch 4, wobei das Senden des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats an die Host-Vorrichtung und das Erzeugen des untergeordneten privaten Schlüssels umfassen: Senden des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats an die Host-Vorrichtung und Erzeugen des untergeordneten privaten Schlüssels auf der Grundlage des Bits, das in der sicheren Vorrichtung gesetzt ist.
  6. Verfahren nach Anspruch 1, das umfasst: Empfangen des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats von der Client-Vorrichtung bei der Host-Vorrichtung; Verifizieren der Gültigkeit des übergeordneten öffentlichen Schlüssels durch Prüfen der Signatur an dem zugeordneten Zertifikat unter Verwendung eines öffentlichen Wurzelschlüssels, der einer Zertifizierungsstelle entspricht, der die Host-Vorrichtung und die Client-Vorrichtung vertrauen, durch die Host-Vorrichtung; Senden von Anweisungen von der Host-Vorrichtung an die Client-Vorrichtung auf der Grundlage der Verifizierung des übergeordneten öffentlichen Schlüssels als gültig, wobei die Anweisungen die Client-Vorrichtung anweisen, das Paar des untergeordneten privaten und öffentlichen Schlüssels zu erzeugen; Empfangen des untergeordneten öffentlichen Schlüssels und der ersten Signatur bei der Host-Vorrichtung als Antwort auf das Senden der Anweisungen; und Verifizieren der Gültigkeit des untergeordneten öffentlichen Schlüssels durch Verifizieren der Richtigkeit der ersten Signatur unter Verwendung des verifizierten übergeordneten öffentlichen Schlüssels durch die Host-Vorrichtung.
  7. Verfahren nach Anspruch 1, wobei das Senden des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats an die Host-Vorrichtung auf der Authentifizierung der Host-Vorrichtung durch die Client-Vorrichtung beruht, wobei das Verfahren umfasst: Senden einer ersten kryptographischen Authentifizierungsabfrage an die Host-Vorrichtung durch die Client-Vorrichtung, wobei die erste kryptographische Authentifizierungsabfrage zur Authentifizierung der Host-Vorrichtung gesendet wird; Empfangen einer Antwort auf die erste kryptographische Authentifizierungsabfrage bei der Client-Vorrichtung, wobei die Antwort eine der ersten kryptographischen Authentifizierungsabfrage zugeordnete Anfangssignatur enthält, die mit einem für die Host-Vorrichtung verfügbaren Authentifizierungsschlüssel signiert ist, wobei eine Kopie des Authentifizierungsschlüssels in einer in der sicheren Vorrichtung enthaltenen sicheren persistenten Ablage gespeichert wird; Verifizieren der Richtigkeit der Anfangssignatur unter Verwendung der in der sicheren persistenten Ablage gespeicherten Kopie des Authentifizierungsschlüssels durch die Client-Vorrichtung; und Authentifizieren der Host-Vorrichtung auf der Grundlage der Verifizierung der Richtigkeit der Anfangssignatur durch die Client-Vorrichtung.
  8. Verfahren nach Anspruch 7, das umfasst: Empfangen der ersten kryptographischen Authentifizierungsabfrage von der Client-Vorrichtung bei der Host-Vorrichtung; Zugreifen auf den Authentifizierungsschlüssel, der für die Host-Vorrichtung verfügbar ist, durch die Host-Vorrichtung; Berechnen der Anfangssignatur an der ersten kryptographischen Authentifizierungsabfrage unter Verwendung des Authentifizierungsschlüssels durch die Host-Vorrichtung; und Senden der Anfangssignatur an die Client-Vorrichtung durch die Host-Vorrichtung.
  9. Verfahren nach Anspruch 1, das umfasst: Empfangen einer Nachricht, die eine zweite kryptographische Authentifizierungsabfrage enthält, bei der Client-Vorrichtung und von der Host-Vorrichtung; Berechnen einer zweiten Signatur an der zweiten kryptographischen Authentifizierungsabfrage unter Verwendung des durch die Client-Vorrichtung erzeugten untergeordneten privaten Schlüssels durch die Client-Vorrichtung; und Senden einer Antwort auf die kryptographische Authentifizierungsabfrage durch die Client-Vorrichtung und an die Host-Vorrichtung, wobei die Antwort die zweite Signatur enthält.
  10. Verfahren nach Anspruch 9, das umfasst: Senden der zweiten kryptographischen Authentifizierungsabfrage an die Client-Vorrichtung durch die Host-Vorrichtung; Empfangen einer Antwort auf die zweite kryptographische Authentifizierungsabfrage, die die zweite Signatur enthält, bei der Host-Vorrichtung; Verifizieren der Richtigkeit der zweiten Signatur unter Verwendung des untergeordneten öffentlichen Schlüssels, der von der Client-Vorrichtung empfangen wird, durch die Host-Vorrichtung; und Speichern des untergeordneten öffentlichen Schlüssels als einen vertrauenswürdigen Schlüssel durch die Host-Vorrichtung auf der Grundlage der Verifizierung der Richtigkeit der zweiten Signatur.
  11. System, das umfasst: einen ersten Prozessor; und erste Anweisungen, die in einem nichtflüchtigen maschinenlesbaren ersten Medium zur Ausführung durch den ersten Prozessor codiert sind und die, wenn sie ausgeführt werden, so konfiguriert sind, dass sie veranlassen, dass der erste Prozessor Operationen ausführt, die umfassen: Senden eines übergeordneten öffentlichen Schlüssels und eines zugeordneten Zertifikats an eine Host-Vorrichtung durch eine Client-Vorrichtung, die mit der Host-Vorrichtung gekoppelt ist, wobei der übergeordnete öffentliche Schlüssel, das Zertifikat und ein entsprechender übergeordneter privater Schlüssel in einer sicheren persistenten Ablage gespeichert sind, die in einer der Client-Vorrichtung zugeordneten sicheren Vorrichtung enthalten ist, und wobei der übergeordnete öffentliche und private Schlüssel kryptographische Schlüssel sind und wobei das Zertifikat ein kryptographisches Zertifikat ist; Empfangen von Anweisungen zum Erzeugen eines Paars eines untergeordneten privaten und öffentlichen Schlüssels von der Host-Vorrichtung bei der Client-Vorrichtung; Erzeugen eines untergeordneten privaten Schlüssels auf der Grundlage einer innerhalb der sicheren Vorrichtung erzeugten ersten Zufallszahl und eines dem untergeordneten privaten Schlüssel zugeordneten untergeordneten öffentlichen Schlüssels durch die Client-Vorrichtung als Antwort auf den Empfang der Anweisungen, wobei der untergeordnete private und öffentliche Schlüssel kryptographische Schlüssel sind; Berechnen einer ersten Signatur an dem untergeordneten öffentlichen Schlüssel unter Verwendung des übergeordneten privaten Schlüssels durch die Client-Vorrichtung, wobei die erste Signatur eine kryptographische Signatur ist; und Senden des untergeordneten öffentlichen Schlüssels und der ersten Signatur an die Host-Vorrichtung durch die Client-Vorrichtung.
  12. System nach Anspruch 11, wobei das Paar des untergeordneten privaten und öffentlichen Schlüssels innerhalb der sicheren Vorrichtung erzeugt wird und wobei die ersten Anweisungen, die so konfiguriert sind, dass sie veranlassen, dass der erste Prozessor Operationen ausführt, die das Berechnen der ersten Signatur an dem untergeordneten öffentlichen Schlüssel unter Verwendung des übergeordneten privaten Schlüssels umfassen, erste Anweisungen enthalten, die so konfiguriert sind, dass sie veranlassen, dass der erste Prozessor Operationen ausführt, die umfassen: Kombinieren einer Nonce mit dem untergeordneten öffentlichen Schlüssel, um ein Digest zu erzeugen, unter Verwendung der sicheren Vorrichtung; Kombinieren des Digests mit der sicheren Vorrichtung zugeordneten Informationen; und Erzeugen der ersten Signatur durch Ausführen einer Berechnung einer asymmetrischen kryptographischen Signatur unter Verwendung des übergeordneten privaten Schlüssels an der Kombination des Digests und der der sicheren Vorrichtung zugeordneten Informationen unter Verwendung der sicheren Vorrichtung.
  13. System nach Anspruch 12, wobei die der sicheren Vorrichtung zugeordneten Informationen Zustandsinformationen der sicheren Vorrichtung und/oder Schlüsselablage-Konfigurationsinformationen und/oder Schlüsselablage-Zustandsinformationen und/oder Befehlsparameter enthalten.
  14. System nach Anspruch 11, wobei die ersten Anweisungen, die so konfiguriert sind, dass sie veranlassen, dass der erste Prozessor Operationen ausführt, die das Authentifizieren der Host-Vorrichtung durch die Client-Vorrichtung umfassen, erste Anweisungen enthalten, die so konfiguriert sind, dass sie veranlassen, dass der erste Prozessor Operationen ausführt, die umfassen: Setzen eines in der sicheren Vorrichtung enthaltenen Bits, das dem übergeordneten privaten Schlüssel zugeordnet ist, das angibt, dass die Host-Vorrichtung authentifiziert worden ist.
  15. System nach Anspruch 14, wobei die ersten Anweisungen, die so konfiguriert sind, dass sie veranlassen, dass der erste Prozessor Operationen ausführt, die das Senden des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats an die Host-Vorrichtung und das Erzeugen des untergeordneten privaten Schlüssels umfassen, erste Anweisungen enthalten, die so konfiguriert sind, dass sie veranlassen, dass der erste Prozessor Operationen ausführt, die umfassen: Senden des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats an die Host-Vorrichtung und Erzeugen des untergeordneten privaten Schlüssels auf der Grundlage des Bits, das in der sicheren Vorrichtung gesetzt ist.
  16. System nach Anspruch 15, wobei das zugeordnete Zertifikat durch eine Zertifizierungsstelle vor dem Einsatz der Client-Vorrichtung erzeugt wird und wobei das Paar des übergeordneten privaten und öffentlichen Schlüssels und das zugeordnete Zertifikat vor dem Einsatz der Client-Vorrichtung in der persistenten Ablage in der sicheren Vorrichtung gespeichert werden.
  17. System nach Anspruch 11, das umfasst: einen zweiten Prozessor; und zweite Anweisungen, die in einem nichtflüchtigen maschinenlesbaren zweiten Medium zur Ausführung durch den zweiten Prozessor codiert sind und die, wenn sie ausgeführt werden, dafür konfiguriert sind zu veranlassen, dass der zweite Prozessor Operationen ausführt, die umfassen: Empfangen des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats von der Client-Vorrichtung bei der Host-Vorrichtung; Verifizieren der Gültigkeit des übergeordneten öffentlichen Schlüssels durch Prüfen der Signatur an dem zugeordneten Zertifikat unter Verwendung eines öffentlichen Wurzelschlüssels, der einer Zertifizierungsstelle entspricht, der die Host-Vorrichtung und die Client-Vorrichtung vertrauen, durch die Host-Vorrichtung; Senden von Anweisungen von der Host-Vorrichtung an die Client-Vorrichtung bei der Verifizierung des übergeordneten öffentlichen Schlüssels als gültig, wobei die Anweisungen die Client-Vorrichtung anweisen, das Paar des untergeordneten privaten und öffentlichen Schlüssels zu erzeugen; Empfangen des untergeordneten öffentlichen Schlüssels und der ersten Signatur bei der Host-Vorrichtung als Antwort auf das Senden der Anweisungen; und Verifizieren der Gültigkeit des untergeordneten öffentlichen Schlüssels durch Verifizieren der Richtigkeit der ersten Signatur unter Verwendung des verifizierten übergeordneten öffentlichen Schlüssels durch die Host-Vorrichtung.
  18. System nach Anspruch 17, wobei der öffentliche Wurzelschlüssel vor dem Einsatz der Host-Vorrichtung in der Host-Vorrichtung gespeichert wird.
  19. System nach Anspruch 11, wobei das Senden des übergeordneten öffentlichen Schlüssels und des zugeordneten Zertifikats an die Host-Vorrichtung auf der Authentifizierung der Host-Vorrichtung durch die Client-Vorrichtung beruht und wobei die ersten Anweisungen so konfiguriert sind, dass sie veranlassen, dass der erste Prozessor Operationen ausführt, die umfassen: Senden einer ersten kryptographischen Authentifizierungsabfrage an die Host-Vorrichtung durch die Client-Vorrichtung, wobei die erste kryptographische Authentifizierungsabfrage zur Authentifizierung der Host-Vorrichtung gesendet wird; Empfangen einer Antwort auf die erste kryptographische Authentifizierungsabfrage bei der Client-Vorrichtung, wobei die Antwort eine der ersten kryptographischen Authentifizierungsabfrage zugeordnete Anfangssignatur enthält, die mit einem für die Host-Vorrichtung verfügbaren Authentifizierungsschlüssel signiert ist, wobei eine Kopie des Authentifizierungsschlüssels in einer in der sicheren Vorrichtung enthaltenen sicheren persistenten Ablage gespeichert wird; Verifizieren der Richtigkeit der Anfangssignatur unter Verwendung der in der sicheren persistenten Ablage gespeicherten Kopie des Authentifizierungsschlüssels durch die Client-Vorrichtung; und Authentifizieren der Host-Vorrichtung auf der Grundlage der Verifizierung der Richtigkeit der Anfangssignatur durch die Client-Vorrichtung.
  20. System nach Anspruch 19, das umfasst: einen zweiten Prozessor; und zweite Anweisungen, die in einem nichtflüchtigen maschinenlesbaren zweiten Medium zur Ausführung durch den zweiten Prozessor codiert sind und die, wenn sie ausgeführt werden, dafür konfiguriert sind zu veranlassen, dass der zweite Prozessor Operationen ausführt, die umfassen: Empfangen der ersten kryptographischen Authentifizierungsabfrage von der Client-Vorrichtung bei der Host-Vorrichtung; Zugreifen auf den Authentifizierungsschlüssel, der für die Host-Vorrichtung verfügbar ist, durch die Host-Vorrichtung; Berechnen der Anfangssignatur an der ersten kryptographischen Authentifizierungsabfrage unter Verwendung des Authentifizierungsschlüssels durch die Host-Vorrichtung; und Senden der Anfangssignatur an die Client-Vorrichtung durch die Host-Vorrichtung.
  21. System nach Anspruch 19, wobei der Authentifizierungsschlüssel vor dem Einsatz der Client-Vorrichtung bzw. der Host-Vorrichtung in der persistenten Ablage in der sicheren Vorrichtung und in der Host-Vorrichtung gespeichert wird.
  22. System nach Anspruch 19, wobei der Authentifizierungsschlüssel einen Hash-basierten 256-Bit-Secure-Hash-Standard-Nachrichtenauthentifizierungscode-Schlüssel (SHA-256-HMAC-Schlüssel) enthält.
  23. System nach Anspruch 11, wobei die ersten Anweisungen dafür konfiguriert sind zu veranlassen, dass der erste Prozessor Operationen ausführt, die umfassen: Empfangen einer zweiten kryptographischen Authentifizierungsabfrage, die eine zweite Zufallszahl enthält, bei der Client-Vorrichtung und von der Host-Vorrichtung; Berechnen einer zweiten Signatur an der zweiten kryptographischen Authentifizierungsabfrage unter Verwendung des durch die Client-Vorrichtung erzeugten untergeordneten privaten Schlüssels durch die Client-Vorrichtung; und Senden einer Antwort auf die zweite kryptographische Authentifizierungsabfrage durch die Client-Vorrichtung und an die Host-Vorrichtung, wobei die Antwort die zweite Signatur enthält.
  24. System nach Anspruch 23, das umfasst: einen zweiten Prozessor; und zweite Anweisungen, die in einem nichtflüchtigen maschinenlesbaren zweiten Medium zur Ausführung durch den zweiten Prozessor codiert sind und die, wenn sie ausgeführt werden, dafür konfiguriert sind zu veranlassen, dass der zweite Prozessor Operationen ausführt, die umfassen: Senden der zweiten kryptographischen Authentifizierungsabfrage an die Client-Vorrichtung durch die Host-Vorrichtung; Empfangen einer Antwort auf die zweite kryptographische Authentifizierungsabfrage, die die zweite Signatur enthält, bei der Host-Vorrichtung; Verifizieren der Richtigkeit der zweiten Signatur unter Verwendung des untergeordneten öffentlichen Schlüssels, der von der Client-Vorrichtung empfangen wird, durch die Host-Vorrichtung; und Speichern des untergeordneten öffentlichen Schlüssels als einen vertrauenswürdigen Schlüssel durch die Host-Vorrichtung auf der Grundlage der Verifizierung der Richtigkeit der zweiten Signatur.
  25. System nach Anspruch 11, wobei die sichere Vorrichtung einen Mikroprozessor mit einer integrierten Schaltung enthält.
  26. System nach Anspruch 11, wobei das Paar des übergeordneten privaten Schlüssels und öffentlichen Schlüssels und/oder das Paar des untergeordneten privaten Schlüssels und öffentlichen Schlüssels unter Verwendung einer Elliptische-Kurven-Kryptographie erzeugt werden.
DE201410204713 2013-03-13 2014-03-13 Erzeugung von Schlüsseln unter Verwendung sicherer Hardware Pending DE102014204713A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/800,422 US9118467B2 (en) 2013-03-13 2013-03-13 Generating keys using secure hardware
US13/800,422 2013-03-13

Publications (1)

Publication Number Publication Date
DE102014204713A1 true DE102014204713A1 (de) 2014-09-18

Family

ID=51419320

Family Applications (1)

Application Number Title Priority Date Filing Date
DE201410204713 Pending DE102014204713A1 (de) 2013-03-13 2014-03-13 Erzeugung von Schlüsseln unter Verwendung sicherer Hardware

Country Status (2)

Country Link
US (1) US9118467B2 (de)
DE (1) DE102014204713A1 (de)

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9323950B2 (en) 2012-07-19 2016-04-26 Atmel Corporation Generating signatures using a secure device
KR101906089B1 (ko) 2013-07-31 2018-10-08 휴렛-팩커드 디벨롭먼트 컴퍼니, 엘.피. 소모성 제품의 메모리 내 데이터의 보호
US10452869B2 (en) * 2014-05-07 2019-10-22 Infineon Technologies Ag Systems and methods for processing and verifying data using signatures
US9870462B2 (en) * 2014-09-22 2018-01-16 Intel Corporation Prevention of cable-swap security attack on storage devices
US9705857B1 (en) * 2014-10-10 2017-07-11 Sprint Spectrum L.P. Securely outputting a security key stored in a UE
DE102015215569A1 (de) * 2015-08-14 2017-02-16 Robert Bosch Gmbh Verfahren zur Generierung eines Geheimnisses zwischen Teilnehmern eines Netzwerkes sowie dazu eingerichtete Teilnehmer des Netzwerks
DE102015216082A1 (de) * 2015-08-24 2017-03-02 Siemens Aktiengesellschaft Verfahren und Speichermodul für sicherheitsgeschützte Schreibvorgänge und/oder Lesevorgänge auf dem Speichermodul
US10482255B2 (en) 2016-02-16 2019-11-19 Atmel Corporation Controlled secure code authentication
US10474823B2 (en) 2016-02-16 2019-11-12 Atmel Corporation Controlled secure code authentication
US10616197B2 (en) 2016-04-18 2020-04-07 Atmel Corporation Message authentication with secure code verification
ES2886773T3 (es) * 2016-06-17 2021-12-20 Hewlett Packard Development Co Autenticación de elemento reemplazable
WO2018022993A1 (en) * 2016-07-29 2018-02-01 Trusona, Inc. Anti-replay authentication systems and methods
CN117196655A (zh) * 2016-08-03 2023-12-08 惠普发展公司，有限责任合伙企业 数字签名数据
EP3291504B1 (de) * 2016-08-30 2020-03-11 Wacom Co., Ltd. Authentifizierung und sichere übertragung von daten zwischen unterschriften- und host-computern mit transport-schicht-sicherheit
US11463267B2 (en) * 2016-09-08 2022-10-04 Nec Corporation Network function virtualization system and verifying method
US10540652B2 (en) * 2016-11-18 2020-01-21 Intel Corporation Technology for secure partitioning and updating of a distributed digital ledger
US10872161B2 (en) * 2016-11-23 2020-12-22 Entrust Corporation Printer identity and security
US10372945B2 (en) * 2017-01-24 2019-08-06 Microsoft Technology Licensing, Llc Cross-platform enclave identity
US11538031B2 (en) * 2017-03-31 2022-12-27 Vijay Madisetti Method and system for identity and access management for blockchain interoperability
CN110770846B (zh) * 2017-06-15 2024-04-02 巴克斯特国际公司 透析机、外部医疗设备以及在透析机和外部医疗设备之间建立安全通信的方法
US11836717B2 (en) 2017-12-04 2023-12-05 Vijay Madisetti System and method for processing payments in fiat currency using blockchain and tethered tokens
US10892903B2 (en) * 2018-05-29 2021-01-12 Ememory Technology Inc. Communication system capable of preserving a chip-to-chip integrity
CN109067526A (zh) * 2018-08-15 2018-12-21 数字钱包（北京）科技有限公司 层次公私钥对生成方法和装置
US11210238B2 (en) 2018-10-30 2021-12-28 Cypress Semiconductor Corporation Securing data logs in memory devices
US11151007B2 (en) * 2018-11-26 2021-10-19 Intel Corporation Technology to provide fault tolerance for elliptic curve digital signature algorithm engines
CN110046996B (zh) * 2019-01-18 2020-09-15 阿里巴巴集团控股有限公司 数据处理方法和装置
US20200259663A1 (en) * 2019-02-07 2020-08-13 Guardtime Sa One-Time Data Signature System and Method with Untrusted Server Assistance
WO2020237093A1 (en) * 2019-05-23 2020-11-26 Crytography Research, Inc. Anti-counterfeiting applications for advanced memories
US10797887B2 (en) 2019-06-26 2020-10-06 Alibaba Group Holding Limited Confidential blockchain transactions
US11296872B2 (en) 2019-11-07 2022-04-05 Micron Technology, Inc. Delegation of cryptographic key to a memory sub-system
WO2021206933A1 (en) * 2020-04-07 2021-10-14 Cryptography Research, Inc. Authentication using an ephemeral asymmetric keypair
US12052370B2 (en) * 2020-05-04 2024-07-30 Intel Corporation Managing state in accelerators
JP2021190839A (ja) * 2020-05-29 2021-12-13 日立Astemo株式会社 電子制御装置
US11310059B2 (en) 2020-06-02 2022-04-19 Microsoft Technology Licensing, Llc Ephemeral cryptography keys for authenticating computing services
US11909874B2 (en) * 2020-11-09 2024-02-20 Hub data security Ltd. Secure confidential use of communication session keys
CN112491843B (zh) 2020-11-17 2022-06-21 苏州浪潮智能科技有限公司 一种数据库多重认证方法、系统、终端及存储介质
CN114553426B (zh) * 2020-11-26 2023-08-15 中移物联网有限公司 签名验证方法、密钥管理平台、安全终端及电子设备
CN112968774B (zh) * 2021-02-01 2023-04-07 中国海洋石油集团有限公司 一种组态存档加密及解密方法、装置存储介质及设备
CN113591109B (zh) * 2021-07-23 2023-05-02 上海瓶钵信息科技有限公司 可信执行环境与云端通信的方法及系统
GB2610559A (en) * 2021-09-07 2023-03-15 Licensing Ag Nchain Generating shared cryptographic keys
WO2023059329A1 (en) * 2021-10-07 2023-04-13 Hewlett-Packard Development Company, L.P. Certificate schemas for public key certificates
CN114301597B (zh) * 2021-12-13 2024-02-09 零信技术(深圳)有限公司 密钥验证方法、设备及可读存储介质
CN115208685B (zh) * 2022-07-27 2023-05-23 公安部交通管理科学研究所 一种终端设备数字身份管理方法
CN118413392B (zh) * 2024-06-28 2024-09-06 中国兵器装备集团兵器装备研究所 一种可信的指令传输系统

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212635B1 (en) 1997-07-18 2001-04-03 David C. Reardon Network security system allowing access and modification to a security subsystem after initial installation when a master token is in place
US6708273B1 (en) * 1997-09-16 2004-03-16 Safenet, Inc. Apparatus and method for implementing IPSEC transforms within an integrated circuit
US6704871B1 (en) * 1997-09-16 2004-03-09 Safenet, Inc. Cryptographic co-processor
US6601172B1 (en) 1997-12-31 2003-07-29 Philips Electronics North America Corp. Transmitting revisions with digital signatures
WO2000048061A1 (en) 1999-02-15 2000-08-17 Hewlett-Packard Company Protection of the configuration of modules in computing apparatus
EP1076279A1 (de) 1999-08-13 2001-02-14 Hewlett-Packard Company Computerplattformen und deren Betriebsverfahren
US6708049B1 (en) 1999-09-28 2004-03-16 Nellcor Puritan Bennett Incorporated Sensor with signature of data relating to sensor
US6826690B1 (en) 1999-11-08 2004-11-30 International Business Machines Corporation Using device certificates for automated authentication of communicating devices
DE69941335D1 (de) 1999-12-02 2009-10-08 Sony Deutschland Gmbh Nachrichtenauthentisierung
US6996710B1 (en) 2000-03-31 2006-02-07 Intel Corporation Platform and method for issuing and certifying a hardware-protected attestation key
US6961858B2 (en) 2000-06-16 2005-11-01 Entriq, Inc. Method and system to secure content for distribution via a network
US20020026578A1 (en) * 2000-08-22 2002-02-28 International Business Machines Corporation Secure usage of digital certificates and related keys on a security token
US7779267B2 (en) * 2001-09-04 2010-08-17 Hewlett-Packard Development Company, L.P. Method and apparatus for using a secret in a distributed computing system
US20030093663A1 (en) 2001-11-09 2003-05-15 Walker Jesse R. Technique to bootstrap cryptographic keys between devices
US20030138105A1 (en) * 2002-01-18 2003-07-24 International Business Machines Corporation Storing keys in a cryptology device
US7142674B2 (en) 2002-06-18 2006-11-28 Intel Corporation Method of confirming a secure key exchange
US20040101141A1 (en) 2002-11-27 2004-05-27 Jukka Alve System and method for securely installing a cryptographic system on a secure device
US7165181B2 (en) 2002-11-27 2007-01-16 Intel Corporation System and method for establishing trust without revealing identity
US7584359B2 (en) 2002-12-11 2009-09-01 Broadcom Corporation Secure media peripheral association in a media exchange network
US7802087B2 (en) * 2003-03-10 2010-09-21 Igt Universal method for submitting gaming machine source code software to a game certification laboratory
CA2584525C (en) 2004-10-25 2012-09-25 Rick L. Orsini Secure data parser method and system
GB2419787B (en) * 2004-10-28 2007-07-04 Hewlett Packard Development Co Method and apparatus for providing short-term private keys in public-key cryptographic systems
US7369856B2 (en) 2004-11-24 2008-05-06 Intel Corporation Method and system to support fast hand-over of mobile subscriber stations in broadband wireless networks
US20060218649A1 (en) 2005-03-22 2006-09-28 Brickell Ernie F Method for conditional disclosure of identity information
US20060236098A1 (en) * 2005-03-31 2006-10-19 Alexander Gantman Multisigning - a protocol for robust multiple party digital signatures
US7716497B1 (en) 2005-06-14 2010-05-11 Xilinx, Inc. Bitstream protection without key storage
US7596812B2 (en) 2005-06-14 2009-09-29 Motorola, Inc. System and method for protected data transfer
JP4912772B2 (ja) 2005-09-22 2012-04-11 富士通株式会社 暗号化方法，暗号復号化方法，暗号化装置，暗号復号化装置，送受信システムおよび通信システム
US20070237366A1 (en) * 2006-03-24 2007-10-11 Atmel Corporation Secure biometric processing system and method of use
US8165301B1 (en) 2006-04-04 2012-04-24 Bitmicro Networks, Inc. Input-output device and storage controller handshake protocol using key exchange for data security
JP2010503252A (ja) 2006-08-31 2010-01-28 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピューティング・プラットフォームの証明
WO2008066671A2 (en) * 2006-11-08 2008-06-05 Voltage Security, Inc. Indentity-based-encryption extensions formed using multiple instances of an identity based encryption scheme
US7685263B2 (en) 2006-12-19 2010-03-23 Blue Coat Systems, Inc. Method and system for configuring a device with a wireless mobile configurator
US8356181B2 (en) 2007-11-15 2013-01-15 Intel Corporation Apparatus and method for a direct anonymous attestation scheme from short-group signatures
US20110099362A1 (en) * 2008-06-23 2011-04-28 Tomoyuki Haga Information processing device, encryption key management method, computer program and integrated circuit
US8161285B2 (en) 2008-09-26 2012-04-17 Microsoft Corporation Protocol-Independent remote attestation and sealing
US9230109B2 (en) * 2008-10-07 2016-01-05 Microsoft Technology Licensing, Llc Trusted platform module security
WO2011091313A1 (en) 2010-01-22 2011-07-28 Interdigital Patent Holdings, Inc. Method and apparatus for trusted federated identity management and data access authorization
US20110219427A1 (en) 2010-03-04 2011-09-08 RSSBus, Inc. Smart Device User Authentication
US9418205B2 (en) 2010-03-15 2016-08-16 Proxense, Llc Proximity-based system for automatic application or data access and item tracking
US9104985B2 (en) 2011-08-17 2015-08-11 International Business Machines Corporation Processing system using metadata for administering a business transaction
US8843740B2 (en) 2011-12-02 2014-09-23 Blackberry Limited Derived certificate based on changing identity
US9323950B2 (en) 2012-07-19 2016-04-26 Atmel Corporation Generating signatures using a secure device
US20140089670A1 (en) 2012-09-27 2014-03-27 Atmel Corporation Unique code in message for signature generation in asymmetric cryptographic device

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
IEEE-1394-Schnittstelle
IEEE-802.11-Chip
IEEE-802.11-Chip,

Also Published As

Publication number Publication date
US20140281554A1 (en) 2014-09-18
US9118467B2 (en) 2015-08-25

Similar Documents

Publication Publication Date Title
DE102014204713A1 (de) Erzeugung von Schlüsseln unter Verwendung sicherer Hardware
DE112020000269T5 (de) Ferngewährung des zugangs zu einer gesperrten datenspeichervorrichtung
DE102013213568A1 (de) Sicheres Speichern und Signatur
US8724819B2 (en) Credential provisioning
DE102017205948A1 (de) Nachrichtenauthentifizierung mit sicherer Codeverifikation
EP2765752B1 (de) Verfahren zum versehen eines mobilen endgeräts mit einem authentisierungszertifikat
DE112008001436T5 (de) Sichere Kommunikation
DE102018216915A1 (de) System und Verfahren für sichere Kommunikationen zwischen Steuereinrichtungen in einem Fahrzeugnetzwerk
CN109728903B (zh) 一种使用属性密码的区块链弱中心密码授权方法
DE102015209116A1 (de) Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
EP3474172A1 (de) Zugangskontrolle unter verwendung einer blockchain
EP2918040A1 (de) Erstellen eines abgeleiteten schlüssels aus einem kryptographischen schlüssel mittels einer physikalisch nicht klonbaren funktion
DE102013215970A1 (de) Einzigartiger Code in einer Nachricht für eine Signaturerzeugung in einem asymetrischen Kryptographiegerät
DE112006001151T5 (de) Computersicherheitssystem und -Verfahren
BRPI0315450B1 (pt) circuito eletrônico à prova de violação para implementação em um dispositivo, dispositivo implementado com um circuito eletrônico à prova de violação, e, método de gerenciamento de dados de segurança para um dispositivo
DE112020000238T5 (de) Wiederherstellungsschlüssel zum entriegeln einer datenspeicherungsvorrichtung
DE102015209108A1 (de) Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
EP3246839B1 (de) Zugangskontrolle mit einem mobilfunkgerät
DE112020000244T5 (de) Initialisierung einer Datenspeicherungsvorrichtung mit einer Managervorrichtung
DE112020000236T5 (de) Mehrrollenentsperrung einer datenspeicherungsvorrichtung
DE112020000180T5 (de) Mehrvorrichtungsentsperrung einer datenspeichervorrichtung
DE112020000179T5 (de) Entsperren einer datenspeicherungsvorrichtung
DE112020000234T5 (de) Drahtlos-sicherheitsprotokoll
DE112020000235T5 (de) Anmeldung einer vorautorisierten vorrichtung
DE102020205993B3 (de) Konzept zum Austausch von kryptographischen Schlüsselinformationen

Legal Events

Date Code Title Description
R012 Request for examination validly filed