DE112017001853T5 - Flexible Bereitstellung von Bestätigungsschlüsseln in sicheren Enklaven - Google Patents

Flexible Bereitstellung von Bestätigungsschlüsseln in sicheren Enklaven Download PDF

Info

Publication number
DE112017001853T5
DE112017001853T5 DE112017001853.6T DE112017001853T DE112017001853T5 DE 112017001853 T5 DE112017001853 T5 DE 112017001853T5 DE 112017001853 T DE112017001853 T DE 112017001853T DE 112017001853 T5 DE112017001853 T5 DE 112017001853T5
Authority
DE
Germany
Prior art keywords
provisioning
key
enclave
confirmation
slave
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
DE112017001853.6T
Other languages
English (en)
Inventor
Vincent R. Scarlata
Francis X. McKeen
Carlos V. Rozas
Simon P. Johnson
Bo Zhang
James D. Beaney Jr.
Piotr Zmijewski
Wesley Hamilton Smith
Eduardo Cabre
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.)
Intel Corp
Original Assignee
Intel 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 Intel Corp filed Critical Intel Corp
Publication of DE112017001853T5 publication Critical patent/DE112017001853T5/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/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/3247—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 digital signatures
    • H04L9/3252—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 digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
    • H04L9/302—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the integer factorization problem, e.g. RSA or quadratic sieve [QS] schemes
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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/3247—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 digital signatures
    • 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/3247—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 digital signatures
    • H04L9/3249—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 digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127—Trusted platform modules [TPM]
    • 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
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Algebra (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Eine Computerplattform implementiert eine oder mehrere sichere Enklaven, die eine erste Bereitstellungsenklave, um sich mit einem ersten Bereitstellungsdienst zum Erhalten eines ersten Bestätigungsschlüssels von dem ersten Bereitstellungsdienst zu verbinden, eine zweite Bereitstellungsenklave, um sich mit einem anderen zweiten Bereitstellungsdienst zum Erhalten eines zweiten Bestätigungsschlüssels von dem zweiten Bereitstellungsdienst zu verbinden, und eine Bereitstellungszertifizierungsenklave enthält, um erste Daten von der ersten Bereitstellungsenklave und zweite Daten von der zweiten Bereitstellungsenklave unter Verwendung eines hardwarebasierten Bereitstellungsbestätigungsschlüssels zu signieren. Die signierten ersten Daten werden von der ersten Bereitstellungsenklave verwendet, um sich bei dem ersten Bereitstellungsdienst zu authentifizieren, um den ersten Bestätigungsschlüssel zu erhalten, und die signierten zweiten Daten werden von der zweiten Bereitstellungsenklave verwendet, um sich bei dem zweiten Bereitstellungsdienst zu authentifizieren, um den zweiten Bestätigungsschlüssel zu erhalten.

Description

  • QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
  • Diese Anmeldung beansprucht Priorität gegenüber der US-Patentanmeldung mit der fortlaufenden Nr. 15/279,527 , die am 29. September 2016 eingereicht wurde, wobei die Anmeldung den Vorteil gegenüber der vorläufigen US-Patentanmeldung mit der fortlaufenden Nr. 62/345,325 , die am 3. Juni 2016 eingereicht wurde, beansprucht. Die vorstehenden Anmeldungen sind durch Bezugnahme hierin in ihrer Gesamtheit aufgenommen.
  • TECHNISCHES GEBIET
  • Diese Offenbarung betrifft im Allgemeinen das Gebiet von Computersicherheit und insbesondere das Sichern von Enklaven innerhalb eines Datenverarbeitungssystems.
  • HINTERGRUND
  • Software und Dienste können über das Internet genutzt werden. Einige Dienste können auf virtuellen Maschinen gehostet werden, um eine flexible Nutzung eines Dienstes zu ermöglichen. Eine virtuelle Maschine ist eine Emulation eines Datenverarbeitungssystems und kann ermöglichen, dass der Dienst zwischen mehreren physischen Serversystemen gleichzeitig migriert oder gestartet wird. Softwaredienste können Daten über ein drahtgebundenes oder drahtloses Netzwerk mit anderen Systemen austauschen. Einige dieser Daten können vertrauliche Inhalte enthalten. Während Verschlüsselung und Authentifizierung verwendet werden können, um die Kommunikation zwischen Systemen zu sichern, kann Vertrauen zwischen den Systemen erforderlich sein, um solche Transaktionen zu erleichtern. Böswillige Handelnde haben Techniken wie Spoofing, Man-in-the-Middle-Angriffe und andere Aktionen mit dem Versuch eingesetzt, Sicherheitsmaßnahmen in Systemen zur Sicherung der Kommunikation zu umgehen. Wenn keine vertrauenswürdige Beziehung hergestellt wird, können herkömmliche Sicherheitsaufgaben für die Kommunikation unwirksam werden.
  • Figurenliste
    • 1 ist ein vereinfachtes Diagramm eines beispielhaften Systems, das ein Bestätigungssystem gemäß einer Ausführungsform enthält;
    • 2 ist ein vereinfachtes Blockdiagramm eines beispielhaften Systems, das eine beispielhafte Plattform enthält, die sichere Enklaven gemäß einer Ausführungsform unterstützt;
    • 3 ist ein vereinfachtes Blockdiagramm, das eine Anwendungsbestätigung gemäß einer Ausführungsform darstellt;
    • 4 ist ein vereinfachtes Blockdiagramm, das eine erste Implementierung eines Systems darstellt, das Bestätigung gemäß einer Ausführungsform unterstützt;
    • 5 ist ein vereinfachtes Blockdiagramm, das eine zweite Implementierung eines Systems darstellt, das Bestätigung gemäß einer Ausführungsform unterstützt;
    • 6 ist ein vereinfachtes Blockdiagramm, das eine dritte Implementierung eines Systems darstellt, das Bestätigung gemäß einer Ausführungsform unterstützt;
    • 7 ist ein vereinfachtes Ablaufdiagramm, das eine beispielhafte Technik darstellt, die eine Bereitstellungszertifizierungsenklave verwendet, die auf einer bestimmten Plattform gehostet ist;
    • 8 ist ein Block ist ein Blockdiagramm eines beispielhaften Prozessors gemäß einer Ausführungsform;
    • 9 ist ein Blockdiagramm eines beispielhaften Mobilgerätesystems gemäß einer Ausführungsform; und
    • 10 ist ein Blockdiagramm eines beispielhaften Computersystems gemäß einer Ausführungsform.
  • Gleiche Bezugszeichen und Bezeichnungen in den verschiedenen Zeichnungen bezeichnen gleiche Elemente.
  • DETAILLIERTE BESCHREIBUNG VON BEISPIELHAFTEN AUSFÜHRUNGSFORMEN
  • 1 ist ein vereinfachtes Blockdiagramm, das eine beispielhafte Ausführungsform einer Datenverarbeitungsumgebung 100 mit einem beispielhaften Bestätigungssystem 105 darstellt. Das Bestätigungssystem 105 kann Daten oder „Anfragen“ empfangen, die von gesicherten logischen Komponenten oder Enklaven erzeugt werden, die auf Host-Systemen (z. B. 110, 115, 120, 125) laufen, um die Authentizität und Sicherheit (und andere Eigenschaften) einer anderen Anwendung oder Enklave des Hosts zu bestätigen und die Bestätigung basierend auf der empfangenen Anfrage zu bestätigen. Die Anfrage kann signiert sein oder Daten einschließen, die durch einen kryptografischen Schlüssel, Chiffre oder ein anderes Element (hierin gemeinsam als „Schlüssel“ bezeichnet) signiert wurden, aus dem das Bestätigungssystem die Vertrauenswürdigkeit der Anfrage authentifizieren oder bestätigen kann (und dadurch auch die Anwendung oder Enklave, die durch die Anfrage bestätigt wird). Derartige Schlüssel können als Bestätigungsschlüssel bezeichnet werden. Ein Bereitstellungssystem 130 kann verwendet werden, um solche Bestätigungsschlüssel auf den verschiedenen Hostvorrichtungen 110, 115, 120, 125 sicher bereitzustellen.
  • In einigen Fällen kann die Bestätigung in Verbindung mit einer Client-Server- oder Front-End-Back-End-Interaktion (z. B. über ein oder mehrere Netzwerke 135) zwischen einer Anwendung, die auf einem Host-System gehostet wird (z. B. 110, 115, 120, 125), und einem Back-End-Dienst, der von einem entfernten Back-End-System (z. B. 140, 145) gehostet wird, ausgeführt werden. Bei solchen Interaktionen können sensible Daten und Transaktionen stattfinden, und die Anwendung kann ihre Vertrauenswürdigkeit und Sicherheit gegenüber dem Back-End-System (und umgekehrt) unter Verwendung eines Bestätigungssystems (z. B. 105) bestätigen. In einigen Implementierungen kann das Bestätigungssystem selbst auf dem Back-End-System gehostet werden. In anderen Fällen kann ein Back-End-System (z. B. 140) (oder sogar ein anderes Host-Gerät in einer Peer-to-Peer-Bestätigung) die Bestätigungsdienste eines separaten Bestätigungssystems (z. B. 105) nutzen.
  • Ein Bereitstellungssystem kann eine Datenbank von Zertifikaten verwalten, die verschiedenen Host-Vorrichtungen (z. B. 110, 115, 120, 125) zugeordnet sind, die mit Hardware und Software ausgestattet sind, um vertrauenswürdige Ausführungsumgebungen oder sichere Enklaven zu implementieren. Jedes der Zertifikate kann von Schlüsseln abgeleitet werden, die selbst auf dauerhaft gepflegten, sicheren Geheimnissen basieren, die während der Herstellung auf den Host-Vorrichtungen (z. B. 110, 115, 120, 125) bereitgestellt werden. Die Geheimnisse bleiben für das Host-Gerät geheim und können unter anderen Implementierungen als Sicherungen, als Code im sicheren dauerhaften Speicher implementiert werden. Der Schlüssel kann das Geheimnis selbst oder ein vom Geheimnis abgeleiteter Schlüssel sein. Das Zertifikat kann den Schlüssel möglicherweise nicht identifizieren und der Schlüssel kann möglicherweise nicht von dem Zertifikat abgeleitet werden, jedoch können Signaturen, die durch den Schlüssel erzeugt werden, als von einer bestimmten der Host-Vorrichtungen stammend identifiziert werden, für die ein Zertifikat basierend auf dem entsprechenden Zertifikat aufrechterhalten wird. Auf diese Weise kann sich eine Host-Vorrichtung (z. B. 110, 115, 120, 125) gegenüber dem Bereitstellungssystem 130 authentifizieren und (durch das Bereitstellungssystem 130) mit einem Bestätigungsschlüssel versehen werden, der der Host-Vorrichtung sicher zugeordnet ist. Diese Bestätigungsschlüssel können dann von sicheren Enklaven auf der entsprechenden Host-Vorrichtung (z. B. 110, 115, 120, 125) verwendet werden, um eine oder mehrere auf der Host-Vorrichtung vorhandene Anwendungen oder Enklaven zu bestätigen.
  • Wie angemerkt, können Client-Systeme, Host-Vorrichtungen (z. B. 110, 115, 120, 125) sich mit anderen Systemen einschließlich Back-End-Systemen (z. B. 140, 145) und Bestätigungssystemen (z. B. 105) und Schlüsselbereitstellungssystemen 130 über einen oder mehrere Netzwerkkanäle (des Netzwerks 135) verbinden oder mit diesen kommunizieren. Kryptografie kann eingesetzt werden, um die Kommunikation über diese Netzwerkkanäle zu sichern. Die Netzwerke 135 können in einigen Implementierungen lokale und Weitbereichsnetzwerke, drahtlose und drahtgebundene Netzwerke, öffentliche und private Netzwerke und jedes andere Kommunikationsnetzwerk umfassen, das die Kommunikation zwischen den Systemen ermöglicht.
  • Im Allgemeinen können „Server“, „Vorrichtungen“, „Rechenvorrichtungen“, „Host-Vorrichtungen“, „Benutzervorrichtungen“, „Clients“, „Server“, „Computer“, „Plattform“, „Umgebung“, „Systeme“ usw. (z. B. 105, 110, 115, 120, 125, 130, 140, 145 usw.) elektronische Rechenvorrichtungen enthalten, die zum Empfangen, Übertragen, Verarbeiten, Speichern oder Verwalten von Daten und Informationen, die der Datenverarbeitungsumgebung 100 zugeordnet sind, betreibbar sind. Wie in diesem Dokument verwendet, soll der Ausdruck „Computer“, „Rechenvorrichtung“, „Prozessor“ oder „Verarbeitungsvorrichtung“ jede geeignete Verarbeitungsvorrichtung umfassen, die angelegt ist, um Computeraufgaben durchzuführen, die mit der Ausführung von computerlesbaren Anweisungen übereinstimmen. Ferner können beliebige, alle oder einige der Rechenvorrichtungen so ausgelegt werden, dass sie jedes Betriebssystem ausführen, einschließlich Linux, UNIX, Windows Server usw., sowie virtuelle Maschinen, die ausgelegt sind, um die Ausführung eines bestimmten Betriebssystems einschließlich kundenspezifischer und geschützter Betriebssysteme zu virtualisieren. Rechenvorrichtungen können ferner mit Kommunikationsmodulen ausgestattet werden, um die Kommunikation mit anderen Rechenvorrichtungen über ein oder mehrere Netzwerke (z. B. 135) zu ermöglichen. Solche Netzwerke 135 können lokale und Weitbereichsnetzwerke, drahtlose und drahtgebundene Netzwerke, öffentliche und private Netzwerke und jedes andere Kommunikationsnetzwerk, das die Kommunikation zwischen Systemen ermöglicht, umfassen.
  • Host-Vorrichtungen (z. B. 110, 115, 120, 125) können ferner Rechenvorrichtungen umfassen, die als ein oder mehrere lokale und/oder entfernte Client- oder Endbenutzervorrichtungen wie Anwendungsserver, persönliche Computer, Laptops, Smartphones, Tablet-Computer, persönliche digitale Assistenten, Medienclients, internetfähige Fernsehgeräte, Telepräsenzsysteme, Spielsysteme, Multimediaserver, Set-Top-Boxen, intelligente Geräte, fahrzeuginterne Rechensysteme und andere Vorrichtungen implementiert sind, die ausgelegt sind zum Empfangen, Anzeigen, Verfassen, Senden oder sonstigen Interagieren mit, Zugreifen, Manipulieren, Konsumieren oder sonstigen Verwenden von Anwendungen, Programmen und Diensten, die durch Server innerhalb oder außerhalb der jeweiligen Vorrichtung (oder der Umgebung 100) bedient oder bereitgestellt werden. Eine Host-Vorrichtung kann eine beliebige Rechenvorrichtung umfassen, die betreibbar ist, um zumindest mit Servern, anderen Host-Vorrichtungen, Netzwerken und/oder anderen Vorrichtungen unter Verwendung einer drahtgebundenen oder drahtlosen Verbindung zu verbinden oder zu kommunizieren. Eine Host-Vorrichtung kann in einigen Fällen ferner mindestens eine grafische Anzeigevorrichtung und Benutzerschnittstellen, einschließlich Touchscreen-Anzeigen, enthalten, die es einem Benutzer ermöglichen, grafische Benutzerschnittstellen von Anwendungen, Tools, Diensten und anderer Software, vorgesehen in einer Umgebung 100, zu betrachten und mit diesen zu interagieren. Es versteht sich, dass es eine beliebige Anzahl von Host-Vorrichtungen geben kann, die der Umgebung 100 zugeordnet sind, ebenso wie eine beliebige Anzahl von Host-Vorrichtungen, die sich außerhalb der Umgebung 100 befinden. Weiterhin können der Begriff „Host-Vorrichtung“, „Client“, „Endbenutzervorrichtung“, „Endpunktvorrichtung“ und „Benutzer“ entsprechend austauschbar verwendet werden, ohne vom Schutzumfang dieser Offenbarung abzuweichen. Während jede Endbenutzervorrichtung im Hinblick darauf beschrieben werden kann, dass sie von einem Benutzer verwendet wird, zieht diese Offenbarung darüber hinaus in Betracht, dass viele Benutzer einen Computer verwenden können oder dass ein Benutzer, unter anderen Beispielen, mehrere Computer verwenden kann.
  • Während 1 so beschrieben wird, dass sie eine Vielzahl von Elementen enthält oder ihnen zugeordnet ist, kann es sein, dass nicht alle Elemente, die in dem System 100 von 1 dargestellt sind, in jeder alternativen Implementierung der vorliegenden Offenbarung verwendet werden. Zusätzlich können ein oder mehrere der hierin beschriebenen Elemente außerhalb des Systems 100 angeordnet sein, während in anderen Fällen bestimmte Elemente in oder als Teil von einem oder mehreren der anderen beschriebenen Elemente sowie anderen Elementen, die nicht in der dargestellten Implementierung beschrieben sind, enthalten sein können. Ferner können bestimmte Elemente, die in 1 dargestellt sind, mit anderen Komponenten kombiniert werden sowie für alternative oder zusätzliche Zwecke zusätzlich zu den hierin beschriebenen Zwecken verwendet werden.
  • Unter Bezugnahme auf das Beispiel von 2 ist ein vereinfachtes Blockdiagramm 200 gezeigt, das ein System oder eine Datenverarbeitungsumgebung darstellt, das bzw. die ein Host-System 110 enthält, das zum Unterstützen einer oder mehrerer sicherer Enklaven (z. B. 235, 250, 255, 260, 265) ausgestattet ist. Ein Host-System 110 kann eine oder mehrere Prozessorvorrichtungen 205, ein oder mehrere Speicherelemente 210 und andere Komponenten umfassen, die in Hardware und/oder Software implementiert sind, einschließlich eines Betriebssystems 215 und eines Satzes von Anwendungen (z. B. 220, 225, 230). Eine oder mehrere der Anwendungen können unter Verwendung einer sicheren Enklave 235 oder Anwendungsenklave gesichert werden. Sichere Enklaven können in einem sicheren Speicher 240 (im Gegensatz zu einem allgemeinen Speicher 245) implementiert werden und eine gesicherte Verarbeitungsfunktionalität von mindestens einem der Prozessoren (z. B. 205) des Host-Systems verwenden, um private Code- und Datenbereiche zu implementieren, um bestimmte gesicherte oder geschützte Funktionalität der Anwendung bereitzustellen. Logik, die in Firmware und/oder Software des Host-Systems (wie zum Beispiel Code der CPU des Hosts) implementiert ist, kann auf dem Host-System 110 bereitgestellt werden, das durch Anwendungen oder einen anderen lokalen Code für das Host-System verwendet werden kann, um private Code- und Datenbereiche abzulegen, die einer garantierten erhöhten Sicherheit unterliegen, um eine oder mehrere sichere Enklaven auf dem System zu implementieren. Zum Beispiel kann eine sichere Enklave verwendet werden, um sensible Daten vor unberechtigtem Zugriff oder Modifikation durch schädliche Software auf höheren Berechtigungsstufen zu schützen und die Vertraulichkeit und Integrität sensibler Codes und Daten zu bewahren, ohne die Fähigkeit legitimer Systemsoftware zu stören, die Nutzung von Plattformressourcen zu planen und zu verwalten. Sichere Enklaven können es Anwendungen ermöglichen, sichere Code- und Datenbereiche zu definieren, die die Vertraulichkeit auch dann gewährleisten, wenn ein Angreifer die Plattform physisch steuert und direkte Angriffe auf den Speicher ausführen kann. Sichere Enklaven können den Verbrauchern der Host-Vorrichtungen (z. B. 110) weiterhin erlauben, die Steuerung über ihre Plattformen zu behalten, einschließlich der Freiheit, Anwendungen und Dienste nach Belieben zu installieren und zu deinstallieren. Sichere Enklaven können es auch einer Host-Systemplattform ermöglichen, den vertrauenswürdigen Code einer entsprechenden Anwendung zu messen und eine im Prozessor verwurzelte signierte Bestätigung zu erzeugen, die diese Messung und andere Zertifizierung beinhaltet, dass der Code in einer vertrauenswürdigen Umgebung korrekt initialisiert ist (und in der Lage ist, die Sicherheitsmerkmale einer sicheren Enklave, wie in den obigen Beispielen umrissen, bereitzustellen). Im Allgemeinen können sichere Enklaven (und andere gesicherte Enklaven, die hierin beschrieben sind) Prinzipien übernehmen oder auf diesen aufgebaut sein, die zum Beispiel in der Programmierungsreferenz Intel® Software Guard Extensions (SGX) unter anderen beispielhaften Plattformen beschrieben sind.
  • Nun kurz unter Bezug auf 3 ist ein vereinfachtes Blockdiagramm 300 gezeigt, das den durch eine sichere Enklave gebotenen Schutz darstellt. Zum Beispiel kann in diesem Beispiel eine Anwendungsenklave (z. B. 235) alle oder einen Teil einer gegebenen Anwendung schützen und ermöglichen, dass die Anwendung (und ihre Sicherheitsmerkmale) bestätigt werden. Zum Beispiel kann ein Dienstanbieter 140, wie etwa ein Back-End-Dienst oder ein Web-Dienst, bevorzugen oder erfordern, dass Clients, mit denen er interagiert, bestimmte Sicherheitsmerkmale oder Garantien besitzen, so dass der Dienst 140 verifizieren kann, dass er mit dem sich als dieser ausweisenden Client ein Geschäft abwickelt. Zum Beispiel kann manchmal Malware (z. B. 305) konstruiert werden, um die Identität eines Benutzers oder einer Anwendung mit der Absicht zu fälschen, sensible Daten aus einer Transaktion mit dem Dienst 140 zu extrahieren, zu infizieren oder sich anderweitig in böswilliger Weise zu verhalten. Signierte Bestätigung (oder einfach „Bestätigung“) kann einer Anwendung (z. B. 230) erlauben, zu verifizieren, dass es sich um eine legitime Instanz der Anwendung (d. h. keine Malware) handelt. Andere Anwendungen (z. B. 220), die mit keiner sicheren Anwendungsenklave ausgestattet sind, können legitim sein, aber sie können dem Dienstanbieter 140 keine Bestätigung ausstellen, was den Dienstanbieter in gewissem Maße an der Authentizität und Vertrauenswürdigkeit der Anwendung zweifeln lässt. Ferner können Host-Systemplattformen (z. B. 210) emuliert werden (z. B. durch Emulator 310), um zu versuchen, fälschlicherweise eine Transaktion mit dem Dienst 140 durchzuführen. Eine Bestätigung durch eine sichere Enklave kann vor solchen unsicheren, schädlichen und fehlerhaften Transaktionen schützen.
  • Zurück zu 2 kann eine Bestätigung auf der Basis eines signierten Datenstücks oder einer „Anfrage“ bereitgestellt werden, das bzw. die unter Verwendung eines Bestätigungsschlüssels signiert wird, der sicher auf der Plattform bereitgestellt wird. Zusätzliche gesicherte Enklaven können bereitgestellt werden (d. h. getrennt von der sicheren Anwendungsenklave 235), um die Anwendung und ihre Enklave 235 zu messen oder zu bewerten, die Messung (die in der Anfrage enthalten ist) zu signieren und bei der Bereitstellung für eine oder mehrere der Enklaven von Schlüsseln zur Verwendung beim Signieren der Anfrage und Herstellen von gesicherten Kommunikationskanälen zwischen Enklaven oder zwischen einer Enklave und einem Außendienst (z. B. 105, 130, 140) behilflich zu sein. Zum Beispiel können eine oder mehrere Bereitstellungsenklaven 250 bereitgestellt werden, um sich mit einem entsprechenden Bereitstellungssystem zu verbinden, um Bestätigungsschlüssel zur Verwendung durch eine anfragende Enklave 255 und/oder Anwendungsenklave zu erhalten. Eine oder mehrere anfragende Enklaven 255 können bereitgestellt werden, um eine Anwendung 230 und/oder die entsprechende Anwendungsenklave 235 zuverlässig zu messen oder zu bewerten und die Messung mit dem durch die entsprechende Bereitstellungsenklave 250 erhaltenen Bestätigungsschlüssel zu signieren. Eine Bereitstellungszertifizierungsenklave 260 kann ebenfalls bereitgestellt werden, um eine Bereitstellungsenklave (z. B. 250) gegenüber ihrem entsprechenden Bereitstellungssystem (z. B. 130) zu authentifizieren. Die Bereitstellungszertifizierungsenklave 260 kann einen Bereitstellungsbestätigungsschlüssel aufrechterhalten, der auf einem dauerhaft aufrechterhaltenen, sicheren, hardwarebasierten Geheimnis auf der Host-Plattform 110 basiert, wie etwa einem Geheimnis, das in Sicherungen 265 der Plattform während der Herstellung eingestellt wurde, um die Bestätigung der Vertrauenswürdigkeit der Bereitstellungsenklave 250 an das Bereitstellungssystem 130 zu unterstützen, so dass die Bereitstellungsenklave 250 authentifiziert wird, bevor das Bereitstellungssystem 130 der Bereitstellungsenklave 250 einen Bestätigungsschlüssel anvertraut. In einigen Implementierungen kann die Bereitstellungszertifizierungsenklave 260 die Authentizität und Sicherheit einer beliebigen der potenziell mehreren Bereitstellungsenklaven 250, die auf der Plattform 110 bereitgestellt sind, bestätigen. Zum Beispiel können mehrere unterschiedliche Bereitstellungsenklaven 250 bereitgestellt werden, die sich jeweils mit ihrem eigenen jeweiligen Bereitstellungssystem verbinden, wodurch sie ihre eigenen jeweiligen Bestätigungsschlüssel für eine von potenziell mehreren anfragenden Enklaven (z. B. 255), die auf der Plattform vorgesehen sind, bereitstellen. Zum Beispiel können verschiedene Anwendungsenklaven verschiedene anfragende Enklaven während der Bestätigung der entsprechenden Anwendung verwenden, und jede anfragende Enklave kann einen unterschiedlichen Bestätigungsschlüssel verwenden, um die Bestätigung zu unterstützen. Ferner können durch die Verwendung von mehreren Bereitstellungsenklaven und Bereitstellungsdiensten verschiedene Schlüsseltypen und Verschlüsselungstechnologien in Verbindung mit der Bestätigung verschiedener Anwendungen und Dienste verwendet werden (z. B. gehostet von Back-End-Systemen 140) .
  • In einigen Implementierungen können, anstatt einen Bestätigungsschlüssel von einem entfernten Dienst (z. B. dem Bereitstellungssystem 130) zu erhalten, eine oder mehrere Anwendungen und anfragende Enklaven Schlüssel verwenden, die von einer Schlüsselerzeugungsenklave 270 auf der Plattform erzeugt werden. Um die Zuverlässigkeit des von der Schlüsselerzeugungsenklave bereitgestellten Schlüssels zu bestätigen, kann die Bereitstellungszertifizierungsenklave den Schlüssel signieren (z. B. den öffentlichen Schlüssel eines Schlüsselpaars, das zufällig durch die Schlüsselerzeugungsenklave erzeugt wird), so dass Angebote, die durch den Schlüssel signiert werden, als legitim signierte Anfragen identifiziert werden können. In einigen Fällen können Schlüsselerzeugungsenklaven (z. B. 270) und Bereitstellungsenklaven (z. B. 250) auf derselben Plattform bereitgestellt werden, während in anderen Fällen Schlüsselerzeugungsenklaven (z. B. 270) und Bereitstellungsenklaven (z. B. 250) als Alternativen für den anderen (z. B. mit nur einer Schlüsselerzeugungsenklave oder Bereitstellungsenklaven auf einer gegebenen Plattform), unter anderen Beispielen und Implementierungen, bereitgestellt werden können.
  • Unter Bezugnahme auf das vereinfachte Blockdiagramm 400 von 4 ist in einigen Plattformen (z. B. 405) eine einzelne anfragende Enklave 410 vorgesehen und steht direkt mit einem Bereitstellungsenklavenpaket 415 in Verbindung. Die gleiche anfragende Enklave wird hier für jede Anwendungsenklave 235, die in dem System vorgesehen ist, verwendet. Ein Bereitstellungsschlüssel ist in dem Bereitstellungsenklavenpaket 415 gehostet und wird verwendet, um das Bereitstellungspaket 415 gegenüber einem Bestätigungsschlüssel-Bereitstellungsdienst 130 zu authentifizieren. Der Bestätigungsschlüssel-Bereitstellungsdienst kann Vorrichtungszertifikate 425 halten, die Vorrichtungen (z. B. Seriennummern von Vorrichtungen) entsprechenden Zertifikaten zuordnen, wobei jedes Zertifikat basierend auf einem Root-Schlüsselsatz in der Hardware der Vorrichtungsplattform 405 (z. B. durch einen Root-Schlüsselgenerator 430, wie dem Hersteller der Plattform 405) erzeugt wird (und geheim gehalten wird). Auf diese Weise können Zertifikate 425 bereitgestellt werden, die das hardwarebasierte Geheimnis, das in der Vorrichtung 405 verwaltet wird, nicht offen legen, aber das Vorhandensein des Geheimnisses durch den Zertifikatsinhaber verifizieren lassen (z. B. basierend auf einer aus dem Geheimnis oder einem Schlüssel basierend auf dem Geheimnis erzeugten Signatur). Dementsprechend kann das Bereitstellungsenklavenpaket 415 dem Bestätigungsschlüssel-Bereitstellungsdienst 130 signierte Daten bereitstellen, um deren Authentizität zu bestätigen, und dass sie auf einer Vorrichtungsplattform (z. B. 405) implementiert sind, von der bekannt ist, dass sie die Funktionalität der Instanziierung und des Hostings einer sicheren, vertrauenswürdige Enklave besitzt. Basierend auf dieser Bestätigung kann der Bestätigungsschlüssel-Bereitstellungsdienst 130 einen sicheren Kanal zwischen dem Bestätigungsschlüssel-Bereitstellungsdienst 130 und dem Bereitstellungsenklavenpaket 415 aushandeln und als Antwort darauf einen Bestätigungsschlüssel für das Bereitstellungsenklavenpaket 415 bereitstellen. Tatsächlich können die Daten, die von dem Bereitstellungsenklavenpaket 415 signiert werden, Informationen (z. B. signierte öffentliche Schlüssel, Protokollidentifizierer usw.) enthalten, die zum Einrichten des sicheren Kanals verwendet werden. Das Bereitstellungsenklavenpaket 415 kann dann die anfragende Enklave mit dem empfangenen Bestätigungsschlüssel versorgen.
  • Eine anfragende Enklave (z. B. 410) kann Attribute der Anwendung (z. B. 230) und/oder Anwendungsenklave (z. B. 235) sowie die Hosting-Plattform messen oder identifizieren und kann diese Information in einer Anfrage 445 bereitstellen, die Daten enthält, von denen mindestens ein Teil unter Verwendung des Bestätigungsschlüssels an der anfragenden Enklave signiert wird. Zum Beispiel kann eine Anfrage (z. B. 445) Daten einschließlich Informationen und Authentifizierungsdaten (z. B. Signaturen) sein, aus denen ein Bestätigungsdienst die Vertrauenswürdigkeit der Komponente, der Plattform oder der Enklave, die durch die Anfrage bestätigt wird, verifizieren kann. Eine Anfrage (z. B. 445) kann derartige Eigenschaften wie den Typ und die Kennung des Plattformprozessors (z. B. CPU, Chipsatz usw.), die von dem bzw. den Prozessoren verwendete Firmwareversion, die Identifikation und den Status von authentifizierten Codemodulen (ACMs) des bzw. der Prozessoren, das Vorhandensein einer vertrauenswürdigen Boot-Funktionalität, die Firmware aller vertrauenswürdigen Vorrichtungen, Softwareversionen für jede Enklave, die sichere Dienste bereitstellen, unter anderen Beispielen identifizieren. Die anfragende Enklave 410 kann mindestens einen Teil der Anfragedaten (z. B. 445) mit dem Bestätigungsschlüssel signieren und die signierte Anfrage an die Anwendungsenklave 235 weiterleiten, die die Anfrage an einen Back-End-Dienst (wie etwa einen geheimen Eigentümer 450 (der z. B. Geheimnisse hostet, die von der Anwendung zum Entschlüsseln von Daten oder zum Zugreifen auf Inhalte usw. verwendet werden können) übermitteln können, um die Authentizität der Anwendung zu bestätigen. In diesem Beispiel kann der Back-End-Dienst (z. B. „geheimer Eigentümer“) 450 die Dienste eines Bestätigungsdienstes 105 benutzen, der Bestätigungsschlüsselzertifikate 460 und Sperrlisten empfangen kann, die durch den Bestätigungsschlüssel-Bereitstellungsdienst 130 erzeugt werden, der den von der anfragenden Enklave 410 der Plattform 405 verwendeten Bestätigungsschlüssel erzeugt hat. Durch diese Zertifikate kann der Bestätigungsdienst 105 die Authentizität der Anfrage 445 basierend auf der in der Anfrage enthaltenen Signatur (signiert durch den Bestätigungsschlüssel, der von dem Bestätigungsschlüssel-Bereitstellungsdienst bereitgestellt wird) verifizieren. Nach dem Verifizieren der Authentizität der Anfrage 445 und dem weiteren Verifizieren, aus der Beschreibung der Anwendungsenklave 235, die in der Anfrage 445 enthalten ist, der Eigenschaften der Anwendungsenklave 235 (z. B. dass es eine zuverlässig implementierte Enklave auf einer fähigen Plattform ist), kann der Bestätigungsdienst die Ergebnisse der Bestätigung an den Back-End-Dienst übermitteln. Aus diesen Ergebnissen kann der Back-End-Dienst basierend darauf, ob die Anwendung durch eine vertrauenswürdige Anwendungsenklave geschützt ist oder nicht, eine Dienstebene bereitstellen (oder den Dienst vollständig gewähren/verweigern).
  • Unter Bezugnahme auf das Beispiel von 5 ist ein vereinfachtes Blockdiagramm 500 gezeigt, das eine verbesserte Version einer Bestätigungsplattform zeigt, die auf einer Vorrichtungsplattform bereitgestellt wird. In diesem Beispiel werden mehrere potentielle Bereitstellungsenklaven (z. B. 505, 515) und anfragende Enklaven (z. B. 515, 520) unterstützt. Zum Beispiel kann eine EPID(Enhanced Privacy Identifier)-basierte Bereitstellungsenklave 505 (entsprechend oder in Verbindung mit einem Hersteller der Vorrichtungsplattform bereitgestellt) instanziiert werden, um eine erste anfragende Enklave 515 bereitzustellen, die einen ersten Typ von Bestätigungsschlüssel (z. B. einen EPID-Schlüssel) verwendet, und eine zweite Bereitstellungsenklave 510 (die einer Drittpartei (d. h. einem anderen als dem Anbieter oder Hersteller der Plattform) entspricht) kann eine zweite anfragende Enklave 520 bereitstellen, die möglicherweise einen anderen, zweiten Typ eines Bestätigungsschlüssels verwendet (z. B. einen RSA-Schlüssel), unter anderen Beispielen. Tatsächlich können zwei oder mehr unterschiedliche Bereitstellungsenklaven (z. B. 505, 510) bereitgestellt werden, um Bestätigungsschlüssel auf zwei oder mehr verschiedenen anfragenden Enklaven (z. B. 515, 520) bereitzustellen. Im Gegenzug kann jede dieser anfragenden Enklaven 515, 520 Bestätigungsunterstützung für eine oder mehrere Anwendungen (z. B. 230, 540) bereitstellen, die mit Anwendungsenklaven (z. B. 235, 525) versehen sind. Zum Beispiel kann eine anfragende Enklave eine, zwei oder mehr Anwendungsenklaven unterstützen, eine andere anfragende Enklave kann eine andere Anwendungsenklave usw. unterstützen. Diese mehreren Bereitstellungsenklaven 505, 510 können durch eine einzige Bereitstellungszertifizierungsenklave 550 unterstützt werden, die einen Bereitstellungsbestätigungsschlüssel verwaltet, der aus einem dauerhaft und sicher aufrechterhaltenen Geheimnis der Vorrichtung (z. B. einem Root-Schlüssel) erzeugt wird, das während der Herstellung der Vorrichtung eingestellt wird.
  • In dem Beispiel von 5 kann jede der verschiedenen Bereitstellungsenklaven (z. B. 505, 510) einem entsprechenden Bereitstellungsdienst (z. B. 530, 535) zugeordnet sein, von dem jeweilige Bestätigungsschlüssel erhalten werden sollen. Die Bereitstellungszertifizierungsenklave kann effektiv dazu dienen, die Bestätigung der Bereitstellungsenklave für ihren entsprechenden Bereitstellungsdienst zu unterstützen. Zum Beispiel kann eine EPID-Bereitstellungsenklave, um eine entsprechende anfragende Enklave (z. B. 505) mit einem EPID-basierten Bestätigungsschlüssel bereitzustellen, eine Bestätigungsanfrage von der Bereitstellungszertifizierungsenklave 550 anfordern, die unter Verwendung des Bereitstellungsbestätigungsschlüssels signiert ist. Die Bereitstellungszertifizierungsenklave 550 kann die Signatur unter Verwendung des Bereitstellungsbestätigungsschlüssels erzeugen und die Signatur (oder die signierte Bestätigungsanfrage) der EPID-Bereitstellungsenklave 505 bereitstellen. Die signierte Anfrage kann mit dem entsprechenden Bereitstellungsdienst (z. B. 530) geteilt werden, um sich beim Bereitstellungsdienst 530 zu authentifizieren und einen sicheren Kanal zwischen dem Bereitstellungsdienst 530 und der Bereitstellungsenklave 505 einzurichten. Die Bestätigungsanfrage kann Informationen enthalten (z. B. signierte öffentliche Schlüssel, Protokollkennungen usw.), die zum Einrichten des sicheren Kanals verwendet werden. Wie im Beispiel von 4 gezeigt, kann jeder der (möglicherweise mehreren verschiedenen) Bereitstellungsdienste (z. B. 530, 535) eine Kopie der Zertifikate 425 aufweisen, die für jede von einer Sammlung von Plattformen (z. B. 110) (durch einen Schlüsselgenerator 430) ausgegeben wurde, welche konfiguriert sind, um sichere Enklaven und Bestätigungen zu unterstützen und die auf den Root-Schlüsseln (oder anderen Geheimnissen) basieren, die auf jeder der jeweiligen Vorrichtungsplattformen bei der (oder nach der) Herstellung eingestellt werden. Diese Zertifikate verdecken das Geheimnis, auf dem der vorläufige Bestätigungsschlüssel basiert, können jedoch dazu verwendet werden, Informationen zu entschlüsseln und Signaturen zu verifizieren, die unter Verwendung eines entsprechenden dieser vorläufigen Bestätigungsschlüssel (auf dem auch die Zertifikate basieren) erzeugt werden.
  • Dementsprechend kann eine Bereitstellungsenklave (z. B. 505, 510) eine Anfrage bereitstellen, die mit dem vorläufigen Bestätigungsschlüssel signiert ist, der bei einem beliebigen der Bereitstellungsdienste, die Zugriff auf die Prozessorzertifikate haben, verifizierbar ist. Ein sicherer Kanal kann basierend auf der Bestätigung der Bereitstellungsenklave (z. B. unter Verwendung eines öffentlichen Schlüsselaustauschs oder einer anderen Technologie) eingerichtet werden. Der Bereitstellungsdienst kann einen Bestätigungsschlüssel erhalten, und der Bereitstellungsdienst kann ein entsprechendes Zertifikat auf der Grundlage von Kommunikationen zwischen der Bereitstellungsenklave und dem Bereitstellungsdienst über den sicheren Kanal erzeugen. In einem Beispiel kann der Bereitstellungsdienst den Bestätigungsschlüssel erzeugen, ein entsprechendes Zertifikat erzeugen und den Bestätigungsschlüssel an die entsprechende Bereitstellungsenklave übertragen. In einem anderen Beispiel kann die Bereitstellungsenklave den Bestätigungsschlüssel (z. B. zufällig) erzeugen und eine Verhandlung über den sicheren Kanal durchführen, um dem Bereitstellungsdienst zu ermöglichen, ein Zertifikat zu erzeugen, das dem Bestätigungsschlüssel entspricht (z. B. für den öffentlichen Schlüssel eines Bestätigungsschlüsselpaars (z. B. unter Verwendung des EPID-Join-Protokolls)). Die Bereitstellungsenklave kann dann den Bestätigungsschlüssel an eine entsprechende anfragende Enklave bereitstellen. In ähnlicher Weise können andere Bereitstellungsenklaven (z. B. 510) auch eine signierte Anfrage von der Bereitstellungs-zertifizierungsenklave 550 anfordern, die die Bereitstellungsenklave 510 als die Basis zum Aushandeln ihres eigenen sicheren Kanals mit einem entsprechenden Bereitstellungsdienst (z. B. 535) verwenden und bezüglich ihrer Vertrauenswürdigkeit als eine Bereitstellungs-enklave bestätigen kann. Genauso kann ein entsprechender Bestätigungsschlüssel mit der Bereitstellungsenklave erhalten werden, der zu seiner entsprechenden anfragenden Enklave (z. B. 520) zur Verwendung bei der Bestätigung einer oder mehrerer entsprechender Anwendungsenklaven weitergeleitet werden kann. Wie im Beispiel von 4 gezeigt, können die Anwendungsenklaven (z. B. 235, 525) Anfragen empfangen, die von ihren jeweiligen anfragenden Enklaven (z. B. 515, 520, unter Verwendung ihrer entsprechenden Bestätigungsschlüssel) signiert sind, um verschiedene Back-End-Systeme (z. B. 555, 560) zu bestätigen und erhöhten Zugriff und Funktionalität auf der Basis der Anwendung, die durch eine vertrauenswürdige Anwendungsenklave geschützt wird, zu genießen. Solche Bestätigungen können eine Vielfalt an Privilegien und erweiterten Diensten und Merkmalen bereitstellen, wie zum Beispiel die Autorisierung eines Dienstes, die Autorisierung zusätzlicher Dienste (vorausgesetzt, dass eine Anwendungsenklave auf dem Client vorhanden ist), die Ausstellung von Zertifikaten von einer Zertifizierungsautorität, das Ermöglichen, dass sich sensorartige Plattformen mit einem Koordinationspunkt paaren, und/oder das Ermöglichen, dass Daten von Sensoren (z. B. in einem Internet-der-Dinge-System) akzeptiert werden, unter potenziell unbegrenzten anderen Beispielen.
  • Wie oben erwähnt, kann in einigen Implementierungen eine Schlüsselgeneratorenklave 270 im Gegensatz zu (oder zusätzlich zu) einer oder mehreren Bereitstellungsenklaven (z. B. 505, 510) bereitgestellt werden, die letztendlich auf externe Bereitstellungsdienste (z. B. 530, 535) als eine jeweilige Quelle von Bestätigungsschlüsseln, die an entsprechende anfragende Enklaven (z. B. 515, 520) weitergeleitet werden sollen, vertrauen. Zum Beispiel wird in dem Beispiel, das durch das in 6 gezeigte vereinfachte Blockdiagramm 600 dargestellt ist, eine Schlüsselgeneratorenklave 270 bereitgestellt, die zufällige öffentliche/private Bestätigungsschlüsselpaare zur Verwendung bei der Bereitstellung einer oder mehrerer anfragenden Enklaven (z. B. 605, 610) mit Bestätigungsschlüsseln erzeugt. Zum Beispiel kann die Schlüsselgeneratorenklave 270 (zufällig) ein erstes Bestätigungsschlüsselpaar (z. B. ein RSDA-, EPID- oder Elliptische-Kurven-Digitalsignaturalgorithmus(ECDSA)-Schlüsselpaar) für eine erste anfragende Enklave 605 erzeugen und separat ein anderes, zweites Bestätigungsschlüsselpaar für eine andere anfragende Enklave 610 (unter Verwendung des/der gleichen oder eines/einer anderen Schlüsselpaar-Algorithmus oder -Technologie). Der private Schlüssel des Bestätigungsschlüsselpaars wird an die anfragende Enklave 605 zur Verwendung als Bestätigungsschlüssel der anfragenden Enklave übergeben.
  • Nach Erzeugen eines Bestätigungsschlüsselpaars kann die Schlüsselgeneratorenklave 270 anfordern, dass die Bereitstellungszertifizierungsenklave 550 den öffentlichen Schlüssel in dem Paar als eine Form einer Anfrage signiert, um die Sicherheit und Authentizität der Schlüsselgeneratorenklave 270 zu bestätigen. In einer Implementierung signiert die Bereitstellungszertifizierungsenklave den öffentlichen Schlüssel des Bestätigungsschlüsselpaars mit dem hardwarebasierten Bereitstellungsbestätigungsschlüssel. Der signierte öffentliche Schlüssel kann als eine Zertifizierung dienen, die unter Verwendung des Bereitstellungsbestätigungsschlüssels (der auf einem hardwareverwurzelten Geheimnis der Host-Plattform 110 basiert) ausgestellt/signiert wird. Prozessorzertifikate 425, die von den Root-Schlüsseln der Hostplattformen (z. B. 110) erzeugt werden und von einem entsprechenden Bestätigungsdienst 105 besessen werden, können die von der Bereitstellungszertifizierungsenklave 550 erzeugte Signatur auf der Grundlage des Bereitstellungsbestätigungsschlüssels wie in anderen Beispielen dadurch verifizieren, dass die Prozessorzertifikate bei Herstellungszeit in Verbindung mit der Bereitstellung des hardwarebasierten Geheimnisses, auf dem der Bereitstellungsbestätigungsschlüssel basiert, erzeugt werden können. In einem Beispiel kann der signierte öffentliche Schlüssel (z. B. durch die Bereitstellungszertifizierungsenklave 550 oder eine andere Enklave (nicht gezeigt)) an eine externe Entität zur direkten Übermittlung an den Bestätigungsdienst 105 gesendet werden. In anderen Beispielen kann der signierte öffentliche Schlüssel an die anfragende Enklave 605 geliefert werden, um an Anfragen (z. B. 630) angehängt zu werden, die von der anfragenden Enklave 605 erzeugt und signiert werden, um sie schließlich an den Bestätigungsdienst 105 zu liefern. Der Bestätigungsdienst 105 kann von der Anwendungsenklave 235 Anfragen (zum Beispiel wie von einem entsprechenden Back-End-Dienst oder einem anderen geheimen Eigentümer 450 weitergeleitet) einer bestimmten Anwendung 230 (wie durch die anfragende Enklave 605 erzeugt) empfangen und den entsprechenden signierten öffentlichen Schlüssel (z. B. in der Anfrage selbst) identifizieren. Der Bestätigungsdienst 105 kann seine Sammlung von Prozessorzertifikaten 425 abfragen, um zu verifizieren, dass der öffentliche Schlüssel von (dem Bereitstellungsbestätigungsschlüssel) einer seriösen Plattform (z. B. 110) signiert wurde, um daraus zu schließen, dass Daten (z. B. Anfragen 630), die durch die anfragende Enklave 605 (z. B. unter Verwendung des privaten Schlüssels des Bestätigungsschlüsselpaars) signiert sind, ebenfalls vertrauenswürdig sind. Der Bestätigungsdienst 105 kann dann ferner verifizieren, dass die Anfrage 630 von dem privaten Schlüssel des Bestätigungsschlüsselpaars signiert wurde und die Daten, die die in der Anfrage enthaltene Anwendung beschreiben, benutzen, um die Bestätigung zu vervollständigen.
  • Bezugnehmend auf 7 ist ein vereinfachtes Blockdiagramm 700 gezeigt, das eine beispielhafte Technik darstellt, die eine Bereitstellungszertifizierungsenklave verwendet, die auf einer bestimmten Plattform gehostet wird. Im Beispiel von 7 können mehrere Schlüsselbereitstellungsenklaven (z. B. 505, 510) Anforderungen (bei 705a, b) für eine Bereitstellungszertifizierungsenklave 550 senden, um entsprechende Schlüsselbereitstellungsanforderungen zu signieren, die an verschiedene Schlüsselbereitstellungsdienste zu senden sind. Die Bereitstellungszertifizierungsenklave 550 kann die Anforderungen empfangen 710 und jede der Anforderungen mit einem hardwarebasierten Bereitstellungsbestätigungsschlüssel signieren 715 (z. B. abgeleitet von einem hardwareverwurzelten Schlüssel der Hostplattform). Die Bereitstellungszertifizierungsenklave kann die signierten Anforderungen an jede der anfordernden Bereitstellungsenklaven 505, 510 zurücksenden 720. Eine erste Bereitstellungsenklave 505 kann einer ersten anfragenden Enklave entsprechen, die einen Bestätigungsschlüssel verwendet, der von einem ersten Bereitstellungsdienst bereitgestellt wird. Die erste Bereitstellungsenklave 505 kann die signierte Schlüsselanforderung von der Bereitstellungszertifizierungsenklave 550 empfangen 725a und die signierte Schlüsselanforderung an den ersten Bereitstellungsdienst senden 730a. Der erste Bereitstellungsdienst kann die Authentizität der Anfrage basierend darauf, dass er durch den Bereitstellungsbestätigungsschlüssel signiert ist, verifizieren und kann (bei 735a) einen ersten Bestätigungsschlüssel für die erste Schlüsselbereitstellungsenklave 505 bereitstellen. Die erste Bereitstellungsenklave 505 kann dann den empfangenen ersten Bestätigungsschlüssel in der ersten anfragenden Enklave bereitstellen.
  • In ähnlicher Weise kann eine zweite Bereitstellungsenklave 510 bereitgestellt werden, die einen Bestätigungsschlüssel (z. B. eine andere Art oder Form eines Bestätigungsschlüssels als von der ersten anfragenden Enklave verwendet) für eine zweite anfragende Enklave, ebenfalls auf der Plattform gehostet, erhalten soll. Die zweite Bereitstellungsenklave 510 kann ihre signierte Schlüsselanforderung von der Bereitstellungszertifizierungsenklave 550 zurück empfangen 725b und ihre signierte Schlüsselanforderung an einen anderen zweiten Bereitstellungsdienst senden 725b und als Antwort einen zweiten Bestätigungsschlüssel empfangen 730b. Die zweite Bereitstellungsenklave 510 kann dann den empfangenen zweiten Bestätigungsschlüssel in der zweiten anfragenden Enklave bereitstellen.
  • 8 - 10 sind Blockdiagramme von beispielhaften Computerarchitekturen, die gemäß hierin offenbarten Ausführungsformen verwendet werden können. Andere Computerarchitekturausgestaltungen, die in der Technik für Prozessoren, mobile Geräte und Datenverarbeitungssysteme bekannt sind, können ebenfalls verwendet werden. Im Allgemeinen können geeignete Computerarchitekturen für Ausführungsformen, die hierin offenbart sind, die Konfigurationen umfassen, die in den 8 - 10 dargestellt sind, sind aber nicht darauf beschränkt.
  • 8 ist eine beispielhafte Darstellung eines Prozessors gemäß einer Ausführungsform. Der Prozessor 800 ist ein Beispiel für eine Art von Hardwarevorrichtung, die in Verbindung mit den obigen Implementierungen verwendet werden kann.
  • Der Prozessor 800 kann ein beliebiger Typ von Prozessor sein, beispielsweise ein Mikroprozessor, ein eingebetteter Prozessor, ein digitaler Signalprozessor (DSP), ein Netzwerkprozessor, ein Mehrkernprozessor, ein Einzelkernprozessor oder eine andere Vorrichtung zum Ausführen von Code. Obwohl nur ein Prozessor 800 in 8 dargestellt ist, kann ein Verarbeitungselement alternativ mehr als einen des in 8 dargestellten Prozessors 800 enthalten. Der Prozessor 800 kann ein Single-Threaded-Kern sein, oder der Prozessor 800 kann bei mindestens einer Ausführungsform mehrere Threads aufweisen, indem er mehr als einen Hardware-Thread-Kontext (oder „logischen Prozessor“) pro Kern enthält.
  • 8 zeigt auch einen Speicher 802, der mit dem Prozessor 800 gemäß einer Ausführungsform gekoppelt ist. Der Speicher 802 kann ein beliebiger aus einer großen Vielfalt von Speichern sein (einschließlich verschiedener Schichten der Speicherhierarchie), wie sie dem Fachmann bekannt sind oder anderweitig verfügbar sind. Solche Speicherelemente können einen Direktzugriffsspeicher (RAM), einen Nur-Lese-Speicher (ROM), Logikblöcke eines feldprogrammierbaren Gate-Arrays (FPGA), löschbaren programmierbaren Nur-Lese-Speicher (EPROM) und elektrisch löschbaren programmierbaren ROM (EEPROM) umfassen, sind aber nicht darauf beschränkt.
  • Der Prozessor 800 kann jede Art von Anweisungen ausführen, die mit den hierin detailliert beschriebenen Algorithmen, Prozessen oder Operationen verbunden sind. Im Allgemeinen kann der Prozessor 800 ein Element oder einen Artikel (z. B. Daten) von einem Zustand oder einem Gegenstand in einen anderen Zustand oder einen anderen Gegenstand umwandeln.
  • Der Code 804, bei dem es sich um eine oder mehrere Anweisungen handeln kann, die vom Prozessor 800 auszuführen sind, kann im Speicher 802 gespeichert sein oder kann in Software, Hardware, Firmware oder einer beliebigen geeigneten Kombination davon oder in einer/einem anderen internen oder externen Komponente, Vorrichtung, Element oder Objekt, wo angemessen, und basierend auf bestimmten Bedarf gespeichert sein. In einem Beispiel kann der Prozessor 800 einer Programmsequenz von Anweisungen folgen, die durch den Code 804 angezeigt wird. Jede Anweisung tritt in eine Front-End-Logik 806 ein und wird durch einen oder mehrere Decodierer 808 verarbeitet. Der Decodierer kann als seine Ausgabe eine Mikrooperation, wie z B. eine Mikrooperation mit fester Breite in einem vordefinierten Format, erzeugen oder kann andere Anweisungen, Mikroanweisungen oder Steuersignale erzeugen, die die ursprüngliche Codeanweisung wiedergeben. Die Front-End-Logik 806 umfasst auch eine Registerumbenennungslogik 810 und eine Planungslogik 812, die im Allgemeinen Ressourcen zuweisen und die Operation, die der Anweisung zur Ausführung entspricht, in eine Warteschlange stellen.
  • Der Prozessor 800 kann auch eine Ausführungslogik 814 mit einem Satz von Ausführungseinheiten 816a, 816b, 816n usw. enthalten. Einige Ausführungsformen können eine Anzahl von Ausführungseinheiten enthalten, die bestimmten Funktionen oder Gruppen von Funktionen zugeordnet sind. Andere Ausführungsformen können nur eine Ausführungseinheit oder eine Ausführungseinheit, die eine bestimmte Funktion ausführen kann, enthalten. Die Ausführungslogik 814 führt die durch die Codeanweisungen spezifizierten Operationen aus.
  • Nach Abschluss der Ausführung der Operationen, die durch die Codeanweisungen spezifiziert sind, kann die Back-End-Logik 818 die Anweisungen des Codes 804 zurücknehmen. In einer Ausführungsform erlaubt der Prozessor 800 eine Ausführung außerhalb der Reihenfolge, erfordert aber eine Rücknahme von Anweisungen in Reihenfolge. Die Rücknahmelogik 820 kann eine Vielzahl bekannter Formen annehmen (z. B. Re-Order-Puffer oder dergleichen). Auf diese Weise wird der Prozessor 800 während der Ausführung des Codes 804 zumindest hinsichtlich der von dem Decodierer erzeugten Ausgabe, von der Registerumbenennungslogik 810 verwendeten Hardware-Registern und -Tabellen und von jeglichen durch die Ausführungslogik 814 modifizierten Registern (nicht gezeigt) transformiert.
  • Obwohl in 8 nicht gezeigt, kann ein Verarbeitungselement andere Elemente auf einem Chip mit dem Prozessor 800 enthalten. Beispielsweise kann ein Verarbeitungselement eine Speichersteuerlogik zusammen mit dem Prozessor 800 enthalten. Das Verarbeitungselement kann eine E/A-Steuerlogik enthalten und/oder kann eine E/A-Steuerlogik integriert mit Speichersteuerlogik enthalten. Das Verarbeitungselement kann auch einen oder mehrere Caches enthalten. In einigen Ausführungsformen kann ein nichtflüchtiger Speicher (wie zum Beispiel ein Flash-Speicher oder Sicherungen) ebenfalls auf dem Chip mit dem Prozessor 800 enthalten sein.
  • Bezugnehmend auf 9 ist ein Blockdiagramm einer beispielhaften mobilen Vorrichtung 900 dargestellt. Die mobile Vorrichtung 900 ist ein Beispiel eines möglichen Datenverarbeitungssystems (z. B. eines Hosts oder einer Endpunktvorrichtung) der hier beschriebenen Beispiele und Implementierungen. In einer Ausführungsform arbeitet die mobile Vorrichtung 900 als ein Sender und ein Empfänger von drahtlosen Kommunikationssignalen. Insbesondere kann die mobile Vorrichtung 900 in einem Beispiel in der Lage sein, mobile Sprach- und Datenmobilfunkdienste sowohl zu übertragen als auch zu empfangen. Zu den mobilen Diensten gehören derartige Funktionen wie vollständiger Internetzugang, herunterladbare und gestreamte Videoinhalte sowie telefonische Sprachkommunikation.
  • Die mobile Vorrichtung 900 kann einem herkömmlichen drahtlosen oder zellularen tragbaren Telefon entsprechen, wie beispielsweise einem Handgerät, das in der Lage ist, „3G“- oder „dritte Generation“-Zellulardienste zu empfangen. In einem anderen Beispiel kann die mobile Vorrichtung 900 in der Lage sein, auch „4G“-Mobilfunkdienste oder irgendeinen anderen mobilen Dienst zu senden und zu empfangen.
  • Beispiele von Vorrichtungen, die der mobilen Vorrichtung 900 entsprechen können, umfassen Mobiltelefonhandgeräte und Smartphones, wie zum Beispiel solche, die Internetzugang, E-Mail- und Instant-Messaging-Kommunikation ermöglichen, und tragbare Video-Empfangs- und Anzeigegeräte, zusammen mit der Fähigkeit, Telefondienste zu unterstützen. Es wird in Betracht gezogen, dass der Fachmann unter Bezugnahme auf diese Beschreibung leicht die Beschaffenheit von modernen Smartphones und Telefonhandapparatvorrichtungen und - systemen verstehen wird, welche zur Implementierung der verschiedenen Aspekte dieser Offenbarung, wie hierin beschrieben, geeignet sind. Somit ist die Architektur der mobilen Vorrichtung 900, die in 9 dargestellt ist, auf einem relativ hohen Niveau dargestellt. Nichtsdestotrotz wird in Erwägung gezogen, dass Modifikationen und Alternativen zu dieser Architektur vorgenommen werden können und für den Leser ersichtlich sind, wobei solche Modifikationen und Alternativen als in den Umfang dieser Beschreibung fallend betrachtet werden.
  • In einem Aspekt dieser Offenbarung enthält die mobile Vorrichtung 900 einen Sendeempfänger 902, der mit einer Antenne verbunden ist und mit dieser kommuniziert. Der Sendeempfänger 902 kann ein Hochfrequenz-Sendeempfänger sein. Außerdem können drahtlose Signale über den Sendeempfänger 902 gesendet und empfangen werden. Der Sendeempfänger 902 kann beispielsweise so aufgebaut sein, dass er eine analoge und digitale Hochfrequenz(HF)-„Front-End“-Funktionalität, eine Schaltung zum Umwandeln von HF-Signalen in eine Basisbandfrequenz über eine Zwischenfrequenz (ZF), falls gewünscht, analoges und digitales Filtern und andere herkömmliche Schaltungen, die zum Ausführen von drahtloser Kommunikation über moderne zellulare Frequenzen, beispielsweise solche, die für 3G- oder 4G-Kommunikationen geeignet sind, enthält. Der Sendeempfänger 902 ist mit einem Prozessor 904 verbunden, der den Hauptteil der digitalen Signalverarbeitung von zu kommunizierenden Signalen und empfangenen Signalen bei der Basisbandfrequenz durchführen kann. Der Prozessor 904 kann eine Grafikschnittstelle an ein Anzeigeelement 908 für die Anzeige von Text, Grafiken und Video für einen Benutzer bereitstellen, sowie ein Eingabeelement 910 zum Akzeptieren von Eingaben von Benutzern, wie etwa ein Touchpad, eine Tastatur, eine Rollenmaus und andere Beispiele. Der Prozessor 904 kann eine Ausführungsform umfassen, wie sie unter Bezugnahme auf den Prozessor 800 von 8 gezeigt und beschrieben ist.
  • In einem Aspekt dieser Offenbarung kann der Prozessor 904 ein Prozessor sein, der irgendeine Art von Anweisungen ausführen kann, um die Funktionalität und die Operationen zu erreichen, wie sie hierin detailliert beschrieben sind. Der Prozessor 904 kann ebenfalls mit einem Speicherelement 906 gekoppelt sein, um Informationen und Daten zu speichern, die bei Operationen verwendet werden, die unter Verwendung des Prozessors 904 ausgeführt werden. Zusätzliche Details eines beispielhaften Prozessors 904 und des Speicherelements 906 werden nachfolgend hierin beschrieben. In einer beispielhaften Ausführungsform kann die mobile Vorrichtung 900 mit einer System-auf-einem-Chip(SoC)-Architektur entworfen sein, die viele oder alle Komponenten der mobilen Vorrichtung in zumindest einem einzigen Chip in zumindest einigen Ausführungsformen integriert.
  • 10 veranschaulicht ein Computersystem 1000, das in einer Punkt-zu-Punkt(PtP)-Konfiguration gemäß einer Ausführungsform angeordnet ist. Insbesondere zeigt 10 ein System, bei dem Prozessoren, Speicher und Eingabe/Ausgabe-Vorrichtungen durch eine Anzahl von Punkt-zu-Punkt-Schnittstellen miteinander verbunden sind. Im Allgemeinen können ein oder mehrere der hierin beschriebenen Computersysteme auf die gleiche oder ähnliche Weise wie das Computersystem 1000 konfiguriert sein.
  • Die Prozessoren 1070 und 1080 können auch jeweils eine integrierte Speichersteuerlogik (MC) 1072 und 1082 zur Kommunikation mit den Speicherelementen 1032 und 1034 enthalten. In alternativen Ausführungsformen können die Speichersteuerlogik 1072 und 1082 von den Prozessoren 1070 und 1080 getrennte diskrete Logik sein. Die Speicherelemente 1032 und/oder 1034 können verschiedene Daten speichern, die von den Prozessoren 1070 und 1080 beim Erzielen von Operationen und Funktionen, die hierin umrissen sind, verwendet werden.
  • Die Prozessoren 1070 und 1080 können eine beliebige Art von Prozessor sein, wie beispielsweise diejenigen, die in Verbindung mit anderen Figuren diskutiert wurden. Die Prozessoren 1070 und 1080 können Daten über eine Punkt-zu-Punkt(PtP)-Schnittstelle 1050 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1078 bzw. 1088 austauschen. Die Prozessoren 1070 und 1080 können jeweils Daten mit einem Chipsatz 1090 über einzelne Punkt-zu-Punkt-Schnittstellen 1052 und 1054 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1076, 1086, 1094 und 1098 austauschen. Der Chipsatz 1090 kann auch Daten mit einer Hochleistungsgrafikschaltung 1038 über eine Hochleistungsgrafikschnittstelle 1039 unter Verwendung einer Schnittstellenschaltung 1092, die eine PtP-Schnittstellenschaltung sein könnte, austauschen. In alternativen Ausführungsformen können einige oder alle PtP-Verbindungen, die in 10 dargestellt sind, als ein Multi-Drop-Bus anstelle einer PtP-Verbindung implementiert werden.
  • Der Chipsatz 1090 kann über eine Schnittstellenschaltung 1096 mit einem Bus 1020 kommunizieren. Der Bus 1020 kann eine oder mehrere Vorrichtungen aufweisen, die darüber kommunizieren, wie eine Busbrücke 1018 und E/A-Vorrichtungen 1016. Über einen Bus 1010 kann die Busbrücke 1018 mit anderen Vorrichtungen, wie einer Tastatur/Maus 1012 (oder anderen Eingabevorrichtungen wie einem Touchscreen, Trackball usw.), Kommunikationsvorrichtungen 1026 (wie Modems, Netzwerkschnittstellenvorrichtungen oder anderen Arten von Kommunikationsvorrichtungen, die über ein Computernetz 1060 kommunizieren können), Audio-E/A-Vorrichtungen 1014 und/oder eine Datenspeichervorrichtung 1028, in Kommunikation stehen. Die Datenspeichervorrichtung 1028 kann Code 1030 speichern, der von den Prozessoren 1070 und/oder 1080 ausgeführt werden kann. Bei alternativen Ausführungsformen könnten beliebige Teile der Busarchitekturen mit einer oder mehreren PtP-Verbindungen implementiert werden.
  • Das Computersystem, das in 10 dargestellt ist, ist eine schematische Darstellung einer Ausführungsform eines Computersystems, das verwendet werden kann, um verschiedene hierin erörterte Ausführungsformen zu implementieren. Es versteht sich, dass verschiedene Komponenten des in 10 dargestellten Systems in einer System-auf-einem-Chip(SoC)-Architektur oder in irgendeiner anderen geeigneten Konfiguration kombiniert werden können, die in der Lage ist, die Funktionalität und Merkmale der hierin bereitgestellten Beispiele und Implementierungen zu erreichen.
  • Obwohl diese Offenbarung hinsichtlich bestimmter Implementierungen und allgemein zugehöriger Verfahren beschrieben wurde, werden Änderungen und Permutationen dieser Implementierungen und Verfahren für den Fachmann offensichtlich sein. Zum Beispiel können die hierin beschriebenen Aktionen in einer anderen Reihenfolge als der beschriebenen durchgeführt werden und dennoch die gewünschten Ergebnisse erzielen. Als ein Beispiel erfordern die in den begleitenden Figuren dargestellten Prozesse nicht notwendigerweise die gezeigte bestimmte Reihenfolge oder die sequentielle Reihenfolge, um die gewünschten Ergebnisse zu erzielen. In bestimmten Implementierungen können Multitasking und parallele Verarbeitung vorteilhaft sein. Darüber hinaus können andere Benutzeroberflächenausgestaltungen und Funktionalität unterstützt werden. Andere Variationen fallen in den Schutzumfang der folgenden Ansprüche.
  • Während die vorliegende Erfindung in Bezug auf eine begrenzte Anzahl von Ausführungsformen beschrieben wurde, werden Fachleute auf dem Gebiet zahlreiche Modifikationen und Variationen davon erkennen. Es ist beabsichtigt, dass die angefügten Ansprüche alle derartigen Modifikationen und Variationen abdecken, die in den wahren Geist und Schutzumfang der vorliegenden Erfindung fallen.
  • Aspekte der Ausführungsformen können eines oder eine Kombination der folgenden Beispiele umfassen:
  • Beispiel 1 ist eine Vorrichtung, ein System, ein Verfahren oder ein computerlesbares Medium mit ausführbaren Anweisungen zum Empfangen einer ersten Anforderung von einer ersten Bereitstellungsenklave, die auf einer Datenverarbeitungsplattform implementiert ist, um unter Verwendung eines hardwarebasierten Bereitstellungsbestätigungsschlüssels erste Daten zu signieren, erste Daten unter Verwendung des Bereitstellungsbestätigungsschlüssels zu signieren, die signierten ersten Daten an die erste Bereitstellungsenklave zurücksenden, wobei die signierten ersten Daten die erste Bereitstellungsenklave an einen ersten Bereitstellungsdienst in Verbindung mit der Erzeugung eines ersten Bestätigungsschlüssels authentifizieren sollen, um Merkmale einer ersten Anwendung auf der Datenverarbeitungsplattform zu bestätigen, eine zweite Anforderung von einer zweiten Bereitstellungsenklave, die auf der Datenverarbeitungsplattform implementiert ist, um zweite Daten unter Verwendung des Bereitstellungsbestätigungsschlüssels zu signieren, zu empfangen, die zweiten Daten unter Verwendung des Bereitstellungsbestätigungsschlüssels zu signieren und die signierten ersten Daten an die zweite Bereitstellungsenklave zurückzusenden, wobei die signierten zweiten Daten die zweite Bereitstellungsenklave zu einem zweiten Bereitstellungsdienst in Verbindung mit der Erzeugung eines zweiten Bestätigungsschlüssels authentifizieren sollen, um Merkmale einer zweiten Anwendung auf der Datenverarbeitungsplattform zu bestätigen.
  • Beispiel 2 kann den Gegenstand von Beispiel 1 umfassen, wobei der Bereitstellungsbestätigungsschlüssel auf einem Geheimnis basiert, das dauerhaft auf der Datenverarbeitungsplattform gespeichert ist.
  • Beispiel 3 kann den Gegenstand des beispielhaften Anspruchs 2 umfassen, wobei der Bereitstellungsbestätigungsschlüssel von Sicherungen abgeleitet wird, die in der Datenverarbeitungsplattform gesetzt sind.
  • Beispiel 4 kann den Gegenstand eines der Beispiele 1 - 3 umfassen, wobei der Bereitstellungsbestätigungsschlüssel einem Zertifikat entspricht, das sowohl von dem ersten als auch dem zweiten Bereitstellungsdienst gehalten wird.
  • Beispiel 5 kann den Gegenstand von Beispiel 4 umfassen, wobei das Zertifikat einem Root-Schlüssel der Datenverarbeitungsplattform entspricht.
  • Beispiel 6 kann den Gegenstand eines der Beispiele 1 - 5 enthalten, wobei der erste Bestätigungsschlüssel ein kryptografischer Schlüssel eines ersten Typs ist und der zweite Bestätigungsschlüssel ein kryptografischer Schlüssel eines anderen zweiten Typs ist.
  • Beispiel 7 kann den Gegenstand von Beispiel 6 umfassen, wobei der erste Bestätigungsschlüssel einen Enhanced Privacy Identifier(EPID)-Schlüssel enthält und der zweite Bestätigungsschlüssel einen Rivest-Shamir-Adleman(RSA)-Schlüssel enthält.
  • Beispiel 8 kann den Gegenstand eines der Beispiele 1 - 7 enthalten, wobei die Anweisungen ferner dazu geeignet sind, eine Bereitstellungszertifizierungsenklave auf der Datenverarbeitungsplattform zu instanziieren, und die Bereitstellungszertifizierungsenklave den Bereitstellungsbestätigungsschlüssel aufrechterhalten und die ersten und zweiten Daten unter Verwendung des Bereitstellungsbestätigungsschlüssels signieren soll.
  • Beispiel 9 ist ein System mit einer Datenverarbeitungsplattform mit einem oder mehreren sicheren Speicherblöcken, einer ersten Anwendung, einer zweiten Anwendung und einer Softwarelogik zum Implementieren einer oder mehrerer sicherer Enklaven unter Verwendung der sicheren Speicherblöcke. Die eine oder die mehreren sicheren Enklaven umfassen: eine erste Bereitstellungsenklave, die mit einem ersten Bereitstellungsdienst verbunden ist, um einen ersten Bestätigungsschlüssel von dem ersten Bereitstellungsdienst zu erhalten, wobei der erste Bestätigungsschlüssel mit der Bestätigung der ersten Anwendung assoziiert ist; eine zweite Bereitstellungsenklave, die mit einem anderen zweiten Bereitstellungsdienst verbunden ist, um einen zweiten Bestätigungsschlüssel von dem zweiten Bereitstellungsdienst zu erhalten, wobei der zweite Bestätigungsschlüssel der Bestätigung der zweiten Anwendung zugeordnet ist; und eine Bereitstellungszertifizierungsenklave, um erste Daten unter Verwendung eines hardwarebasierten Bereitstellungsbestätigungsschlüssels zu signieren, wobei die signierten ersten Daten von der ersten Bereitstellungsenklave verwendet werden, um sich bei dem ersten Bereitstellungsdienst zu authentifizieren, und die Bereitstellungszertifizierungsenklave ferner zweite Daten unter Verwendung des hardwarebasierten Bereitstellungsbestätigungsschlüssels signieren soll, wobei die signierten zweiten Daten von der zweiten Bereitstellungsenklave verwendet werden, um sich bei dem zweiten Bereitstellungsdienst zu authentifizieren.
  • Beispiel 10 kann den Gegenstand von Beispiel 9 umfassen, wobei die eine oder mehreren sicheren Enklaven ferner eine erste anfragende Enklave umfassen, um eine Anforderung nach einem Bestätigungsschlüssel an die erste Bereitstellungsenklave zu senden, um den ersten Bestätigungsschlüssel von der ersten Bereitstellungsenklave als Reaktion auf die Anforderung zu empfangen, erste Anfragedaten zu erzeugen, die Eigenschaften der ersten Anwendung beschreiben und eine Signatur unter Verwendung des ersten Bestätigungsschlüssels enthalten; und eine zweite anfragende Enklave, um eine Anforderung für einen Bestätigungsschlüssel an die zweite Bereitstellungsenklave zu senden, den zweiten Bestätigungsschlüssel von der zweiten Bereitstellungsenklave als Reaktion auf die Anforderung zu empfangen, zweite Anfragedaten zu erzeugen, die Eigenschaften der zweiten Anwendung beschreiben und eine Signatur unter Verwendung des zweiten Bestätigungsschlüssels enthalten.
  • Beispiel 11 kann den Gegenstand von Beispiel 10 umfassen, ferner umfassend eine erste Anwendungsenklave, die zumindest einen Teil der ersten Anwendung sichert, und eine zweite Anwendungsenklave, die zumindest einen Teil der zweiten Anwendung sichert, wobei die ersten Anfragedaten Eigenschaften der ersten Anwendungsenklave beschreiben und die zweiten Anfragedaten Eigenschaften der zweiten Anwendungsenklave beschreiben.
  • Beispiel 12 kann den Gegenstand eines der Beispiele 9 - 11 umfassen, wobei der erste Bereitstellungsdienst eine erste kryptografische Technologie verwendet und der zweite Bereitstellungsdienst eine zweite verwendet.
  • Beispiel 13 kann den Gegenstand von Beispiel 12 umfassen, wobei der erste Bestätigungsschlüssel ein erster Typ eines kryptografischen Schlüssels ist und der zweite Bestätigungsschlüssel ein zweiter Typ eines kryptografischen Schlüssels ist.
  • Beispiel 14 kann den Gegenstand eines der Beispiele 9 - 13 umfassen, wobei die eine oder mehreren sicheren Enklaven ferner eine Schlüsselgeneratorenklave umfassen, um einen dritten Bestätigungsschlüssel zu erzeugen, der ein öffentliches und privates Schlüsselpaar enthält, wobei die Bereitstellungszertifizierungsenklave den öffentlichen Schlüssel des dritten Bestätigungsschlüssels signieren soll und der dritte Bestätigungsschlüssel zur Bestätigung einer dritten Anwendung der Datenverarbeitungsplattform verwendet werden soll.
  • Beispiel 15 ist eine Vorrichtung, ein System, ein Verfahren oder ein computerlesbares Medium mit ausführbaren Anweisungen zum Implementieren einer Enklave zur Erzeugung eines sicheren Schlüssels auf einer Datenverarbeitungsplattform, wobei die Enklave zur Erzeugung eines sicheren Schlüssels einen Bestätigungsschlüssel mit einem öffentlichen Schlüssel und einem privaten Schlüssel erzeugen soll, wobei der Bestätigungsschlüssel zur Bestätigung von mindestens einer Anwendung der Datenverarbeitungsplattform verwendet wird, und ferner eine sichere Bereitstellungszertifizierungsenklave auf einer Datenverarbeitungsplattform implementieren soll. Die Bereitstellungszertifizierungsenklave soll eine Anforderung von der Schlüsselerzeugungsenklave empfangen, um den öffentlichen Schlüssel unter Verwendung eines hardwarebasierten Bereitstellungsbestätigungsschlüssels zu signieren, unter Verwendung des Bereitstellungsbestätigungsschlüssels den öffentlichen Schlüssel zu signieren und den signierten öffentlichen Schlüssel an die Schlüsselerzeugungsenklave zurückzusenden, wobei der signierte öffentliche Schlüssel die Schlüsselerzeugungsenklave an einen Bereitstellungsdienst in Verbindung mit der Bestätigung der mindestens einen Anwendung authentifizieren soll.
  • Beispiel 16 kann den Gegenstand von Beispiel 15 umfassen, wobei der Bestätigungsschlüssel zufällig erzeugt wird.
  • Beispiel 17 kann den Gegenstand eines der Beispiele 15 - 16 enthalten, wobei der Bestätigungsschlüssel ein RSA-Schlüsselpaar enthält.
  • Beispiel 18 kann den Gegenstand eines der Beispiele 15 - 17 umfassen, wobei der Bestätigungsschlüssel einen ersten Bestätigungsschlüssel enthält und die Anwendung eine erste Anwendung umfasst, wobei die Schlüsselerzeugungsenklave den signierten öffentlichen Schlüssel und den privaten Schlüssel zu einer ersten anfragenden Enklave, die der ersten Anwendung zugeordnet ist, bereitstellen soll und die Schlüsselerzeugungsenklave ferner einen zweiten Bestätigungsschlüssel zur Verwendung beim Bestätigen einer zweiten Anwendung unter Verwendung einer zweiten anfragenden Enklave erzeugen soll, und die Bereitstellungszertifizierungsenklave einen öffentlichen Schlüssel des zweiten Bestätigungsschlüssels unter Verwendung des Bereitstellungsbestätigungsschlüssels signieren soll.
  • Beispiel 19 kann den Gegenstand eines des Beispiels 15 enthalten, wobei der Bestätigungsschlüssel aus einem hardwareverwurzelten Geheimnis erzeugt wird.
  • Beispiel 20 kann den Gegenstand eines der Beispiele 15 - 18 umfassen, wobei der Bereitstellungsbestätigungsschlüssel von hardwareverwurzelten geheimen Daten auf der Datenverarbeitungsplattform abgeleitet ist.
  • Beispiel 21 kann den Gegenstand von Beispiel 19 umfassen, wobei die hardwareverwurzelten geheimen Daten einen Root-Schlüssel enthalten.
  • Während diese Beschreibung viele spezifische Implementierungsdetails enthält, sollten diese nicht als Beschränkungen des Schutzumfangs jeglicher Erfindungen oder von dem, was beansprucht wird, verstanden werden, sondern vielmehr als Beschreibungen von Merkmalen, die für bestimmte Ausführungsformen bestimmter Erfindungen spezifisch sind. Bestimmte Merkmale, die in dieser Beschreibung im Zusammenhang mit getrennten Ausführungsformen beschrieben sind, können auch in Kombination in einer einzigen Ausführungsform implementiert werden. Umgekehrt können verschiedene Merkmale, die im Zusammenhang mit einer einzelnen Ausführungsform beschrieben sind, auch in mehreren Ausführungsformen getrennt oder in irgendeiner geeigneten Unterkombination implementiert werden. Obwohl Merkmale oben als in bestimmten Kombinationen wirkend beschrieben sein können und sogar anfänglich als solche beansprucht werden, können darüber hinaus ein oder mehrere Merkmale aus einer beanspruchten Kombination in einigen Fällen aus der Kombination entfernt werden, und die beanspruchte Kombination kann auf eine Unterkombination oder Variation einer Unterkombination gerichtet sein.
  • Während Operationen in den Zeichnungen in einer bestimmten Reihenfolge dargestellt sind, sollte dies in ähnlicher Weise nicht so verstanden werden, dass solche Operationen in der bestimmten gezeigten Reihenfolge oder in sequentieller Reihenfolge durchgeführt werden sollen oder dass alle dargestellten Operationen durchgeführt werden, um die gewünschten Ergebnisse zu erzielen. Unter bestimmten Umständen können Multitasking und parallele Verarbeitung vorteilhaft sein. Darüber hinaus sollte die Trennung verschiedener Systemkomponenten in den oben beschriebenen Ausführungsformen nicht so verstanden werden, dass eine solche Trennung in allen Ausführungsformen erforderlich ist, und es sollte verstanden werden, dass die beschriebenen Programmkomponenten und Systeme im Allgemeinen in einem einzigen Softwareprodukt zusammen integriert sein können oder in mehrere Softwareprodukte gepackt sind.
  • Demzufolge sind besondere Ausführungsformen der Thematik beschrieben worden. Andere Ausführungsformen fallen in den Schutzumfang der folgenden Ansprüche. In einigen Fällen können die zitierten Vorgänge in einer unterschiedlichen Reihenfolge durchgeführt werden und immer noch die gewünschten Ergebnisse erzielen. Darüber hinaus verlangen die Vorgänge, die in den beiliegenden Figuren dargestellt sind, nicht unbedingt die gezeigte bestimmte Reihenfolge oder sequentielle Reihenfolge, um die gewünschten Ergebnisse zu erreichen.
  • 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 Patentliteratur
    • US 15/279527 [0001]
    • US 62/345325 [0001]

Claims (26)

  1. Maschinenzugreifbares Speichermedium oder mehrere maschinenzugreifbare Speichermedien, die darauf gespeicherte Anweisungen aufweisen, wobei die Anweisungen, wenn sie auf einer Maschine ausgeführt werden, die Maschine zu Folgendem veranlassen: Empfangen einer ersten Anfrage von einer ersten Bereitstellungsenklave, die auf einer Computerplattform implementiert ist, um erste Daten unter Verwendung eines hardwarebasierten Bereitstellungsbestätigungsschlüssels zu signieren; Signieren der ersten Daten unter Verwendung des Bereitstellungsbestätigungsschlüssels; Rücksenden der signierten ersten Daten an die erste Bereitstellungsenklave, wobei die signierten ersten Daten die erste Bereitstellungsenklave an einen ersten Bereitstellungsdienst in Verbindung mit der Erzeugung eines ersten Bestätigungsschlüssels authentifizieren sollen, um Merkmale einer ersten Anwendung auf der Computerplattform zu bestätigen; Empfangen einer zweiten Anfrage von einer zweiten Bereitstellungsenklave, die auf der Computerplattform implementiert ist, um zweite Daten unter Verwendung des Bereitstellungsbestätigungsschlüssels zu signieren; Signieren der zweiten Daten unter Verwendung des Bereitstellungsbestätigungsschlüssels; und Rücksenden der signierten ersten Daten an die zweite Bereitstellungsenklave, wobei die signierten zweiten Daten die zweite Bereitstellungsenklave an einen zweiten Bereitstellungsdienst in Verbindung mit der Erzeugung eines zweiten Bestätigungsschlüssels authentifizieren sollen, um Merkmale einer zweiten Anwendung auf der Computerplattform zu bestätigen.
  2. Speichermedium nach Anspruch 1, wobei der Bereitstellungsbestätigungsschlüssel auf einem Geheimnis basiert, das dauerhaft auf der Computerplattform gespeichert ist.
  3. Speichermedium nach Anspruch 2, wobei der Bereitstellungsbestätigungsschlüssel von Sicherungen abgeleitet ist, die in der Computerplattform eingestellt sind.
  4. Speichermedium nach einem der Ansprüche 1-3, wobei der Bereitstellungsbestätigungsschlüssel einem Zertifikat entspricht, das sowohl von dem ersten als auch von dem zweiten Bereitstellungsdienst gehalten wird.
  5. Speichermedium nach Anspruch 4, wobei das Zertifikat einem Root-Schlüssel der Computerplattform entspricht.
  6. Speichermedium nach einem der Ansprüche 1-5, wobei der erste Bestätigungsschlüssel ein kryptografischer Schlüssel eines ersten Typs ist und der zweite Bestätigungsschlüssel ein kryptografischer Schlüssel eines unterschiedlichen, zweiten Typs ist.
  7. Speichermedium nach Anspruch 6, wobei der erste Bestätigungsschlüssel einen Enhanced Privacy Identifier (EPID)-Schlüssel und der zweite Bestätigungsschlüssel einen Rivest-Shamir-Adleman (RSA)-Schlüssel umfasst.
  8. Speichermedium nach einem der Ansprüche 1-7, wobei die Anweisungen weiterhin betreibbar sind, um eine Bereitstellungszertifizierungsenklave auf der Computerplattform zu instanziieren, und die Bereitstellungszertifizierungsenklave den Bereitstellungsbestätigungsschlüssel beibehalten und die ersten und zweiten Daten unter Verwendung des Bereitstellungsbestätigungsschlüssels signieren soll.
  9. System, umfassend: eine Computerplattform, umfassend: einen Prozessor; einen oder mehrere sichere Speicherblöcke; eine erste Anwendung; eine zweite Anwendung; und computerausführbare Anweisungen, die durch den Prozessor ausführbar sind, um eine oder mehrere sichere Enklaven unter Verwendung der sicheren Speicherblöcke zu implementieren, wobei die eine oder die mehreren sicheren Enklaven umfassen: eine erste Bereitstellungsenklave, um sich mit einem ersten Bereitstellungsdienst zu verbinden, um einen ersten Bestätigungsschlüssel von dem ersten Bereitstellungsdienst zu erhalten, wobei der erste Bestätigungsschlüssel der Bestätigung der ersten Anwendung zugeordnet ist; eine zweite Bereitstellungsenklave, um sich mit einem unterschiedlichen, zweiten Bereitstellungsdienst zu verbinden, um einen zweiten Bestätigungsschlüssel von dem zweiten Bereitstellungsdienst zu erhalten, wobei der zweite Bestätigungsschlüssel der Bestätigung der zweiten Anwendung zugeordnet ist; und eine Bereitstellungszertifizierungsenklave, um erste Daten unter Verwendung eines hardwarebasierten Bereitstellungsbestätigungsschlüssels zu signieren, wobei die signierten ersten Daten von der ersten Bereitstellungsenklave verwendet werden, um an den ersten Bereitstellungsdienst zu authentifizieren, und die Bereitstellungszertifizierungsenklave ferner zweite Daten unter Verwendung des hardwarebasierten Bereitstellungsbestätigungsschlüssels signieren soll, wobei die signierten zweiten Daten von der zweiten Bereitstellungsenklave verwendet werden, um an den zweiten Bereitstellungsdienst zu authentifizieren.
  10. System nach Anspruch 9, wobei die eine oder die mehreren sicheren Enklaven ferner umfassen: eine erste anfragende Enklave zum: Senden einer Anfrage nach einem Bestätigungsschlüssel an die erste Bereitstellungsenklave; Empfangen des ersten Bestätigungsschlüssels von der ersten Bereitstellungsenklave als Reaktion auf die Anfrage; Erzeugen von ersten Anfragedaten, die Merkmale der ersten Anwendung beschreiben und eine Signatur unter Verwendung des ersten Bestätigungsschlüssels umfassen; und eine zweite anfragende Enklave zum: Senden einer Anfrage nach einem Bestätigungsschlüssel an die zweite Bereitstellungsenklave; Empfangen des zweiten Bestätigungsschlüssels von der zweiten Bereitstellungsenklave als Reaktion auf die Anforderung; Erzeugen von zweiten Anfragedaten, die Merkmale der zweiten Anwendung beschreiben und eine Signatur unter Verwendung des zweiten Bestätigungsschlüssels umfassen.
  11. System nach Anspruch 10, ferner umfassend eine erste Anwendungsenklave, die mindestens einen Teil der ersten Anwendung sichert, und eine zweite Anwendungsenklave, die mindestens einen Teil der zweiten Anwendung sichert, wobei die ersten Anfragedaten Merkmale der ersten Anwendungsenklave beschreiben und die zweiten Anfragedaten Merkmale der zweiten Anwendungsenklave beschreiben.
  12. System nach einem der Ansprüche 9-11, wobei der erste Bereitstellungsdienst eine erste kryptografische Technologie verwendet und der zweite Bereitstellungsdienst eine zweite verwendet.
  13. System nach Anspruch 12, wobei der erste Bestätigungsschlüssel ein erster Typ eines kryptografischen Schlüssels ist und der zweite Bestätigungsschlüssel ein zweiter Typ eines kryptografischen Schlüssels ist.
  14. System nach einem der Ansprüche 9-13, wobei die eine oder die mehreren sicheren Enklaven ferner eine Schlüsselgeneratorenklave umfassen, um einen dritten Bestätigungsschlüssel, der ein Paar aus einem öffentlichen und einem privaten Schlüssel umfasst, zu erzeugen, die Bereitstellungszertifizierungsenklave den öffentlichen Schlüssel des dritten Bestätigungsschlüssels signieren soll und der dritte Bestätigungsschlüssel bei der Bestätigung einer dritten Anwendung der Computerplattform verwendet werden soll.
  15. Verfahren zum Sichern eines Computersystems, das Verfahren umfassend: Bereitstellen eines ersten Bestätigungsschlüssels für eine gesicherte erste anfragende Enklave des Computersystems, wobei das Bereitstellen des ersten Bestätigungsschlüssels für die erste anfragende Enklave umfasst: Signieren von ersten Daten an einer gesicherten Bereitstellungszertifizierungsenklave mit einem Bereitstellungsbestätigungsschlüssel basierend auf Hardware des Computersystems, wobei die ersten Daten eine gesicherte erste Bereitstellungsenklave beschreiben; Senden der signierten ersten Daten an einen ersten Bereitstellungsdienst, um die erste Bereitstellungsenklave an den ersten Bereitstellungsdienst zu authentifizieren und einen sicheren Kanal zwischen der ersten Bereitstellungsenklave und dem ersten Bereitstellungsdienst herzustellen; Empfangen eines ersten Bestätigungsschlüssels über den sicheren Kanal zwischen der ersten Bereitstellungsenklave und dem ersten Bereitstellungsdienst; und Übertragen des ersten Bestätigungsschlüssels von der ersten Bereitstellungsenklave an die erste anfragende Enklave; und Bereitstellen eines zweiten Bestätigungsschlüssels an eine gesicherte zweite anfragende Enklave des Computersystems, wobei das Bereitstellen des zweiten Bestätigungsschlüssels an die zweite anfragende Enklave umfasst: Signieren von zweiten Daten an einer gesicherten Bereitstellungszertifizierungsenklave mit dem Bereitstellungsbestätigungsschlüssel, wobei die zweiten Daten eine gesicherte zweite Bereitstellungsenklave beschreiben; Senden der signierten zweiten Daten an einen zweiten Bereitstellungsdienst, um die zweite Bereitstellungsenklave an den zweiten Bereitstellungsdienst zu authentifizieren und einen sicheren Kanal zwischen der zweiten Bereitstellungsenklave und dem zweiten Bereitstellungsdienst herzustellen; Empfangen eines zweiten Bestätigungsschlüssels über den sicheren Kanal zwischen der zweiten Bereitstellungsenklave und dem zweiten Bereitstellungsdienst, und Übertragen des zweiten Bestätigungsschlüssels von der zweiten Bereitstellungsenklave zur zweiten anfragenden Enklave.
  16. Verfahren nach Anspruch 15, wobei die Authentifizierung des ersten und des zweiten Bereitstellungsdiensts auf einem gemeinsamen Zertifikat basiert, das von dem ersten und dem zweiten Bereitstellungsdienst gehalten wird, wobei das gemeinsame Zertifikat dem Bereitstellungsbestätigungsschlüssel entspricht.
  17. Verfahren nach Anspruch 16, wobei der Bereitstellungsbestätigungsschlüssel und das gemeinsame Zertifikat auf einem Geheimnis basieren, das dauerhaft in der Hardware des Computersystems gespeichert ist.
  18. System, das Mittel umfasst, um das Verfahren nach einem der Ansprüche 15-17 durchzuführen.
  19. Maschinenzugreifbares Speichermedium oder mehrere maschinenzugreifbare Speichermedien, die darauf gespeicherte Anweisungen aufweisen, wobei die Anweisungen, wenn sie auf einer Maschine ausgeführt werden, die Maschine zu Folgendem veranlassen: Implementieren einer sicheren Schlüsselerzeugungsenklave auf einer Computerplattform, wobei die sichere Schlüsselerzeugungsenklave einen Bestätigungsschlüssel erzeugen soll, der einen öffentlichen Schlüssel und einen privaten Schlüssel umfasst, wobei der Bestätigungsschlüssel zur Verwendung bei der Bestätigung mindestens einer Anwendung der Computerplattform ist; und Implementieren einer sicheren Bereitstellungszertifizierungsenklave auf einer Computerplattform, wobei die Bereitstellungszertifizierungsenklave Folgendes durchführen soll: Empfangen einer Anfrage von der Schlüsselerzeugungsenklave, um den öffentlichen Schlüssel unter Verwendung eines hardwarebasierten Bereitstellungsbestätigungsschlüssels zu signieren; Signieren des öffentlichen Schlüssels unter Verwendung des Bereitstellungsbestätigungsschlüssels; Rücksenden des signierten öffentlichen Schlüssels an die Schlüsselerzeugungsenklave, wobei der signierte öffentliche Schlüssel die Schlüsselerzeugungsenklave an einen Bereitstellungsdienst in Verbindung mit der Bestätigung der mindestens einen Anwendung authentifizieren soll.
  20. Speichermedium nach Anspruch 19, wobei der Bestätigungsschlüssel zufällig erzeugt wird.
  21. Speichermedium nach einem der Ansprüche 19-20, wobei der Bestätigungsschlüssel ein RSA-Schlüsselpaar umfasst.
  22. Speichermedium nach einem der Ansprüche 19-21, wobei der Bestätigungsschlüssel einen ersten Bestätigungsschlüssel umfasst und die Anwendung eine erste Anwendung umfasst, die Schlüsselerzeugungsenklave den signierten öffentlichen Schlüssel und den privaten Schlüssel an eine erste anfragende Enklave, die der ersten Anwendung zugeordnet ist, bereitstellen soll und die Schlüsselerzeugungsenklave ferner einen zweiten Bestätigungsschlüssel zur Verwendung bei der Bestätigung einer zweiten Anwendung unter Verwendung einer zweiten anfragenden Enklave erzeugen soll, und die Bereitstellungszertifizierungsenklave einen öffentlichen Schlüssel des zweiten Bestätigungsschlüssels unter Verwendung des Bereitstellungsbestätigungsschlüssels signieren soll.
  23. Speichermedium nach einem der Ansprüche 19-22, wobei der Bereitstellungsbestätigungsschlüssel von hardwareverankerten geheimen Daten auf der Computerplattform stammt.
  24. Speichermedium nach Anspruch 23, wobei die hardwareverankerten geheimen Daten einen Root-Schlüssel umfassen.
  25. Verfahren, umfassend: Bereitstellen eines ersten Bestätigungsschlüssels an eine gesicherte erste anfragende Enklave eines Computersystems, wobei das Bereitstellen des ersten Bestätigungsschlüssels an die erste anfragende Enklave umfasst: Erzeugen eines ersten Bestätigungsschlüsselpaars an einer Schlüsselgeneratorenklave des Computersystems, wobei das erste Bestätigungsschlüsselpaar einen ersten öffentlichen Schlüssel und einen ersten privaten Schlüssel umfasst; Signieren des ersten öffentlichen Schlüssels an einer gesicherten Bereitstellungszertifizierungsenklave des Computersystems mit einem Bereitstellungsbestätigungsschlüssel basierend auf Hardware des Computersystems; und Senden des ersten privaten Schlüssels und des signierten ersten öffentlichen Schlüssels an die erste anfragende Enklave; und Bereitstellen eines zweiten Bestätigungsschlüssels an eine gesicherte zweite anfragende Enklave des Computersystems, wobei das Bereitstellen des zweiten Bestätigungsschlüssels an die zweite anfragende Enklave umfasst: Erzeugen eines zweiten Bestätigungsschlüsselpaars an einer Schlüsselgeneratorenklave des Computersystems, wobei das zweite Bestätigungsschlüsselpaar einen zweiten öffentlichen Schlüssel und einen zweiten privaten Schlüssel umfasst; Signieren des zweiten öffentlichen Schlüssels an der Bereitstellungszertifizierungsenklave mit dem Bereitstellungsbestätigungsschlüssel; und Senden des zweiten privaten Schlüssels und des signierten zweiten öffentlichen Schlüssels an die zweite anfragende Enklave.
  26. System, das Mittel umfasst, um das Verfahren nach Anspruch 25 durchzuführen.
DE112017001853.6T 2016-06-03 2017-05-28 Flexible Bereitstellung von Bestätigungsschlüsseln in sicheren Enklaven Pending DE112017001853T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201662345325P 2016-06-03 2016-06-03
US62/345,325 2016-06-03
US15/279,527 2016-09-29
US15/279,527 US10135622B2 (en) 2016-06-03 2016-09-29 Flexible provisioning of attestation keys in secure enclaves
PCT/US2017/034897 WO2017210145A1 (en) 2016-06-03 2017-05-28 Flexible provisioning of attestation keys in secure enclaves

Publications (1)

Publication Number Publication Date
DE112017001853T5 true DE112017001853T5 (de) 2018-12-20

Family

ID=60478951

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112017001853.6T Pending DE112017001853T5 (de) 2016-06-03 2017-05-28 Flexible Bereitstellung von Bestätigungsschlüsseln in sicheren Enklaven

Country Status (4)

Country Link
US (2) US10135622B2 (de)
CN (1) CN109074449B (de)
DE (1) DE112017001853T5 (de)
WO (1) WO2017210145A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021209691B3 (de) 2021-09-03 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Überwachen einer Komponente einer Wirkkette
DE112019003808B4 (de) 2018-11-15 2022-12-08 International Business Machines Corporation Zweckspezifische Zugriffssteuerung auf Grundlage einer Datenverschlüsselung
DE102021209689A1 (de) 2021-09-03 2023-03-09 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Überwachen einer Komponente einer Wirkkette

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017147355A1 (en) * 2016-02-25 2017-08-31 ACS (US), Inc. Platform for computing at the mobile edge
US10135622B2 (en) 2016-06-03 2018-11-20 Intel Corporation Flexible provisioning of attestation keys in secure enclaves
US10482034B2 (en) * 2016-11-29 2019-11-19 Microsoft Technology Licensing, Llc Remote attestation model for secure memory applications
US10609006B2 (en) * 2017-01-13 2020-03-31 Fortanix, Inc. Self-encrypting key management system
US10372945B2 (en) * 2017-01-24 2019-08-06 Microsoft Technology Licensing, Llc Cross-platform enclave identity
US10423791B2 (en) * 2017-04-27 2019-09-24 Microsoft Technology Licensing, Llc Enabling offline restart of shielded virtual machines using key caching
GB201707168D0 (en) * 2017-05-05 2017-06-21 Nchain Holdings Ltd Computer-implemented system and method
US10819696B2 (en) * 2017-07-13 2020-10-27 Microsoft Technology Licensing, Llc Key attestation statement generation providing device anonymity
US11349822B2 (en) * 2017-11-20 2022-05-31 Fortanix, Inc. Runtime encryption plugin for a key management system
US11544372B2 (en) 2018-04-11 2023-01-03 Google Llc Mutually distrusting enclaves
EP3776323A1 (de) 2018-04-30 2021-02-17 Google LLC Sichere zusammenarbeit zwischen prozessoren und verarbeitungsbeschleunigern in enklaven
WO2019212580A1 (en) 2018-04-30 2019-11-07 Google Llc Enclave interactions
WO2019212579A1 (en) 2018-04-30 2019-11-07 Google Llc Managing enclave creation through a uniform enclave interface
US11646890B2 (en) 2018-05-16 2023-05-09 Telefonaktiebolaget Lm Ericsson (Publ) Enclave population
US11240007B1 (en) * 2018-08-14 2022-02-01 Amazon Technologies, Inc. Using secure enclaves for decryption in unsecured locations
CN110120869B (zh) * 2019-03-27 2022-09-30 上海隔镜信息科技有限公司 密钥管理系统及密钥服务节点
US10790979B1 (en) 2019-08-29 2020-09-29 Alibaba Group Holding Limited Providing high availability computing service by issuing a certificate
US11038699B2 (en) 2019-08-29 2021-06-15 Advanced New Technologies Co., Ltd. Method and apparatus for performing multi-party secure computing based-on issuing certificate
CN110535628B (zh) * 2019-08-29 2020-07-17 阿里巴巴集团控股有限公司 通过证书签发进行多方安全计算的方法及装置
US11019033B1 (en) 2019-12-27 2021-05-25 EMC IP Holding Company LLC Trust domain secure enclaves in cloud infrastructure
US20210334380A1 (en) * 2020-04-24 2021-10-28 Vmware, Inc. Trusted firmware verification
US11909874B2 (en) * 2020-11-09 2024-02-20 Hub data security Ltd. Secure confidential use of communication session keys
US11750384B2 (en) * 2021-05-27 2023-09-05 Microsoft Technology Licensing, Llc Binding with cryptographic key attestation
CN114282237B (zh) * 2021-12-21 2023-01-17 北京百度网讯科技有限公司 一种通信方法、装置、设备及存储介质

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7711951B2 (en) * 2004-01-08 2010-05-04 International Business Machines Corporation Method and system for establishing a trust framework based on smart key devices
US8112798B2 (en) * 2005-11-09 2012-02-07 Microsoft Corporation Hardware-aided software code measurement
US7805512B2 (en) * 2007-12-29 2010-09-28 Intel Corporation Remote configuration, provisioning and/or updating in a layer two authentication network
US8176336B1 (en) * 2008-12-19 2012-05-08 Emc Corporation Software trusted computing base
DK2462507T3 (da) * 2009-08-04 2019-09-23 Univ Carnegie Mellon Fremgangsmåder og apparater til brugerverificerbar sikker sti i tilstedeværelsen af malware
US8625788B2 (en) * 2011-01-05 2014-01-07 Intel Corporation Method and apparatus for building a hardware root of trust and providing protected content processing within an open computing platform
WO2012148324A1 (en) * 2011-04-26 2012-11-01 Telefonaktiebolaget Lm Ericsson (Publ) Secure virtual machine provisioning
EP2807790B1 (de) * 2011-12-28 2019-04-17 Intel Corporation Fahrzeugdatenverteilung mit erhöhtem datenschutz
US20140006776A1 (en) * 2012-06-29 2014-01-02 Mark Scott-Nash Certification of a virtual trusted platform module
US20140007087A1 (en) 2012-06-29 2014-01-02 Mark Scott-Nash Virtual trusted platform module
US9009854B2 (en) * 2012-12-19 2015-04-14 Intel Corporation Platform-hardened digital rights management key provisioning
US9219607B2 (en) 2013-03-14 2015-12-22 Arris Technology, Inc. Provisioning sensitive data into third party
US9646150B2 (en) * 2013-10-01 2017-05-09 Kalman Csaba Toth Electronic identity and credentialing system
US9998438B2 (en) * 2013-10-23 2018-06-12 Microsoft Technology Licensing, Llc Verifying the security of a remote server
US9652631B2 (en) * 2014-05-05 2017-05-16 Microsoft Technology Licensing, Llc Secure transport of encrypted virtual machines with continuous owner access
US9407636B2 (en) * 2014-05-19 2016-08-02 Intel Corporation Method and apparatus for securely saving and restoring the state of a computing platform
US20160134621A1 (en) 2014-11-12 2016-05-12 Qualcomm Incorporated Certificate provisioning for authentication to a network
US10135622B2 (en) 2016-06-03 2018-11-20 Intel Corporation Flexible provisioning of attestation keys in secure enclaves

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112019003808B4 (de) 2018-11-15 2022-12-08 International Business Machines Corporation Zweckspezifische Zugriffssteuerung auf Grundlage einer Datenverschlüsselung
DE102021209691B3 (de) 2021-09-03 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Überwachen einer Komponente einer Wirkkette
DE102021209689A1 (de) 2021-09-03 2023-03-09 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Überwachen einer Komponente einer Wirkkette

Also Published As

Publication number Publication date
US20170353319A1 (en) 2017-12-07
CN109074449A (zh) 2018-12-21
WO2017210145A1 (en) 2017-12-07
US10880097B2 (en) 2020-12-29
US10135622B2 (en) 2018-11-20
CN109074449B (zh) 2024-04-23
US20190052469A1 (en) 2019-02-14

Similar Documents

Publication Publication Date Title
DE112017001853T5 (de) Flexible Bereitstellung von Bestätigungsschlüsseln in sicheren Enklaven
DE112017002044T5 (de) Plattformattestierung und registrierung für server
DE102018101307A1 (de) Techniken für SGX-Enklaven-Fernauthentifizierung
DE202016107487U1 (de) Authentifizierung eines lokalen Gerätes
DE112008001436T5 (de) Sichere Kommunikation
DE102013202001B4 (de) Verfahren zum Versehen eines mobilen Endgeräts mit einem Authentisierungszertifikat
DE102018129420A1 (de) Indirektionsverzeichnis für den kryptografischen speicherschutz
DE102010028133A1 (de) Verfahren zum Lesen eines Attributs aus einem ID-Token
EP3246839B1 (de) Zugangskontrolle mit einem mobilfunkgerät
DE102012219618A1 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
DE102014204252A1 (de) Sicherheitssystem mit Zugriffskontrolle
EP3465513B1 (de) Nutzerauthentifizierung mittels eines id-tokens
DE102022100111A1 (de) Netzwerkschnittstelle mit Datenschutz
DE102017121648B3 (de) Verfahren zum anmelden eines benutzers an einem endgerät
WO2018162109A1 (de) Sicherheitseinheit insbesondere ein für iot-gerät und verfahren zur ausführung einer oder mehrerer applikationen zum gesicherten datenaustausch mit einem oder mehrere web-dienste bereitstellenden servern
EP3321832A1 (de) Verteilen zum lesen von attributen aus einem id-token
DE102017006200A1 (de) Verfahren, Hardware und System zur dynamischen Datenübertragung an ein Blockchain Rechner Netzwerk zur Abspeicherung Persönlicher Daten um diese Teils wieder Blockweise als Grundlage zur End zu Endverschlüsselung verwendet werden um den Prozess der Datensammlung über das Datenübertragungsmodul weitere Daten in Echtzeit von Sensoreinheiten dynamisch aktualisiert werden. Die Blockmodule auf dem Blockchaindatenbanksystem sind unbegrenzt erweiterbar.
DE60311328T2 (de) Verfahren und vorrichtung zur netzwerksicherheit
EP3244331B1 (de) Verfahren zum lesen von attributen aus einem id-token
DE112022000340T5 (de) Attributgestützte verschlüsselungsschlüssel als schlüsselmaterial zum authentifizieren und berechtigen von benutzern mit schlüssel-hash-nachrichtenauthentifizierungscode
WO2017186445A1 (de) Verfahren zur sicheren interaktion eines nutzers mit einem mobilen endgerät und einer weiteren instanz
DE102014114432B4 (de) Verfahren, Vorrichtung und Computerprogramm zum Kontrollieren eines Zugriffsauf einen Service innerhalb eines Netzwerkes
DE102017012249A1 (de) Mobiles Endgerät und Verfahren zum Authentifizieren eines Benutzers an einem Endgerät mittels mobilem Endgerät
DE102016208038A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
DE102014211839A1 (de) Verfahren zum Authentifizieren einer Entität