DE112020005459T5 - Delegation eines kryptografischen schlüssels an ein speichersubsystem - Google Patents

Delegation eines kryptografischen schlüssels an ein speichersubsystem Download PDF

Info

Publication number
DE112020005459T5
DE112020005459T5 DE112020005459.4T DE112020005459T DE112020005459T5 DE 112020005459 T5 DE112020005459 T5 DE 112020005459T5 DE 112020005459 T DE112020005459 T DE 112020005459T DE 112020005459 T5 DE112020005459 T5 DE 112020005459T5
Authority
DE
Germany
Prior art keywords
public key
key
digital signature
root
new
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
DE112020005459.4T
Other languages
English (en)
Inventor
James Ruane
Robert W. Strong
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.)
Micron Technology Inc
Original Assignee
Micron Technology Inc
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 Micron Technology Inc filed Critical Micron Technology Inc
Publication of DE112020005459T5 publication Critical patent/DE112020005459T5/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/3271—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 using challenge-response
    • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

Eine Schlüsseldelegationsanforderung wird von einem Hostsystem empfangen. Die Schlüsseldelegationsanforderung beinhaltet einen neuen öffentlichen Schlüssel. Basierend auf dem neuen öffentlichen Schlüssel und einem öffentlichen Root-Schlüssel wird eine Aufforderung generiert, die dem Hostsystem als Reaktion auf die Anforderung bereitgestellt wird. Eine erste und eine zweite digitale Signatur werden von dem Hostsystem empfangen. Die erste digitale Signatur wird durch kryptografisches Signieren der Aufforderung unter Verwendung eines neuen privaten Schlüssels erzeugt, der dem neuen öffentlichen Schlüssel entspricht, und die zweite digitale Signatur wird durch kryptografisches Signieren der Aufforderung unter Verwendung eines privaten Root-Schlüssels erzeugt, der dem öffentlichen Root-Schlüssel entspricht. Die erste digitale Signatur wird unter Verwendung des neuen öffentlichen Schlüssels validiert und die zweite digitale Signatur wird unter Verwendung des öffentlichen Root-Schlüssels validiert. Basierend auf der erfolgreichen Validierung der beiden Signaturen wird der neue öffentliche Schlüssel in einer oder mehreren kryptografischen Operationen verwendet.

Description

  • PRIORITÄTSANMELDUNG
  • Diese Anmeldung beansprucht die Priorität der US-Anmeldung mit der Seriennummer 16/677,306, eingereicht am 7. November 2019, die hierin durch Bezugnahme in vollem Umfang aufgenommen wird.
  • Technisches Gebiet
  • Ausführungsformen der Offenbarung betreffen allgemein Speichersubsysteme und insbesondere die Delegation eines kryptografischen Schlüssels an ein Speichersubsystem.
  • STAND DER TECHNIK
  • Ein Speichersubsystem kann eine oder mehrere Speicherkomponenten beinhalten, die Daten speichern. Bei den Speicherkomponenten kann es sich zum Beispiel um nichtflüchtige Speicherkomponenten und flüchtige Speicherkomponenten handeln. Im Allgemeinen kann ein Hostsystem ein Speichersubsystem zum Speichern von Daten in den Speicherkomponenten und zum Abrufen von Daten aus den Speicherkomponenten verwenden.
  • Figurenliste
  • Die vorliegende Offenbarung wird anhand der nachstehenden detaillierten Beschreibung und der beigefügten Zeichnungen verschiedener Ausführungsformen der Offenbarung besser verstanden.
    • 1 veranschaulicht eine beispielhafte Computerumgebung, die ein Speichersubsystem beinhaltet, gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
    • 2 ist ein Datenflussdiagramm, das die Interaktionen zwischen Komponenten in einer sicheren Kommunikationsumgebung veranschaulicht, wenn ein beispielhaftes Verfahren zur Delegation eines kryptografischen Schlüssels gemäß einigen Ausführungsformen der vorliegenden Offenbarung ausgeführt wird.
    • 3 ist ein Swimlane-Diagramm, das die Interaktionen zwischen Komponenten in der sicheren Kommunikationsumgebung veranschaulicht, wenn ein beispielhaftes Verfahren zur Delegation eines kryptografischen Schlüssels gemäß einigen Ausführungsformen der vorliegenden Offenbarung ausgeführt wird.
    • 4 und 5 sind Flussdiagramme, die ein beispielhaftes Verfahren zur Delegation eines kryptografischen Schlüssels in einem Speichersubsystem gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulichen.
    • 6 ist ein Blockdiagramm eines beispielhaften Computersystems, in dem Ausführungsformen der vorliegenden Offenbarung arbeiten können.
  • DETAILLIERTE BESCHREIBUNG
  • Aspekte der vorliegenden Offenbarung sind auf die Delegation des kryptografischen Schlüssels an ein Speichersubsystem gerichtet. Ein Speichersubsystem kann eine Speichervorrichtung, ein Speichermodul oder eine Mischform aus Speichervorrichtung und Speichermodul sein. Beispiele für Speichervorrichtungen und Speichermodule werden im Folgenden in Verbindung mit 1 beschrieben. Im Allgemeinen kann ein Hostsystem ein Speichersubsystem verwenden, das eine oder mehrere Speichervorrichtungen beinhaltet, die Daten speichern. Das Hostsystem kann Daten bereitstellen, die im Speichersubsystem gespeichert werden sollen, und kann Daten anfordern, die vom Speichersubsystem abgerufen werden sollen.
  • Ein Speichersubsystem kann vertrauliche, geschützte oder andere sensible Informationen speichern, auf die nur speziell autorisierte Benutzer, wie z. B. Außendiensttechniker, Zugriff haben sollten. Zum Schutz der im Speichersubsystem gespeicherten vertraulichen Informationen wird häufig eine Public Key Infrastructure (PKI) verwendet, um vertrauliche Informationen kryptografisch zu signieren und zu verifizieren. Auf diese Weise können Vertrauen in die Herkunft und die Fähigkeit zur Erkennung unbefugter Änderungen geschaffen werden. Beispielhafte Verwendungen von PKI umfassen das Signieren und Verifizieren von Firmware sowie die Autorisierung von Befehlen, die die Sicherheit eines Speichersubsystems gefährden können.
  • In bestimmten Implementierungen wird ein öffentlicher Schlüssel eines asymmetrischen Schlüsselpaares (hierin auch als „kryptografische Schlüssel“ bezeichnet) einem Speichersubsystem von einem Erstausrüster (original equipment manufacturer - OEM) vor der Auslieferung an den Kunden zur Verfügung gestellt, während der private Schlüssel durch ein Hardware-Sicherheitsmodul (HSM) eines sicheren Systems (z. B. vom OEM betrieben) gesichert wird, das extern und unabhängig vom Speichersubsystem ist. Der öffentliche Schlüssel, der dem Speichersubsystem ursprünglich zur Verfügung gestellt wurde, kann als öffentlicher „Root“-Schlüssel bezeichnet werden, während der entsprechende private Schlüssel, der von dem HSM des sicheren Servers gespeichert wird, als privater „Root“-Schlüssel bezeichnet werden kann. Rivest-Shamir-Adleman (RSA)-PKI-Operationen ermöglichen Ver- und Entschlüsselungsoperationen sowie Signaturerstellung und - Überprüfung. Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können nur mit dem entsprechenden privaten Schlüssel entschlüsselt werden.
  • In manchen Situationen kann es erwünscht sein, den vom Speichersubsystem verwendeten öffentlichen Schlüssel zu ändern. Das heißt, dass das Speichersubsystem anstelle des öffentlichen Root-Schlüssels einen neuen öffentlichen Schlüssel zur Verschlüsselung und/oder Verifizierung sensibler Informationen verwenden soll. Zum Beispiel kann es wünschenswert sein, dass das Speichersubsystem einen neuen öffentlichen Schlüssel verwendet, der einem neuen privaten Schlüssel entspricht, der von einem tragbaren HSM (z. B. in einem Laptop enthalten) und nicht vom HSM des sicheren Servers gespeichert wird. In einem anderen Beispiel kann es wünschenswert sein, dass das Speichersubsystem einen neuen öffentlichen Schlüssel verwendet, der einem neuen privaten Schlüssel entspricht, der auf einer Chipkarte gespeichert ist, die eine Krypto-Bibliothek beinhaltet. In einem weiteren Beispiel kann es wünschenswert sein, dass das Speichersubsystem einen neuen öffentlichen Schlüssel verwendet, der einem neuen privaten Schlüssel entspricht, der auf demselben HSM des sicheren Servers gespeichert ist. In jedem Fall muss der neue öffentliche Schlüssel dem Speichersubsystem auf eine sichere Art und Weise übertragen werden, die ein Vertrauensverhältnis aufrechterhält, um zu vermeiden, dass Sicherheitslücken entstehen, die ausgenutzt werden können, um unbefugten Zugriff auf sensible Informationen zu erhalten, die vom Speichersubsystem gespeichert werden.
  • Aspekte der vorliegenden Offenbarung gehen auf die obigen und andere Probleme ein, indem sie ein sicheres Protokoll zur Delegierung eines neuen kryptografischen Schlüssels an ein Speichersubsystem implementieren. Wie oben angemerkt, wird ein asymmetrisches Schlüsselpaar, das einen öffentlichen Root-Schlüssel und einen privaten Root-Schlüssel umfasst, erzeugt, und ein Speichersubsystemcontroller wird anfänglich mit dem öffentlichen Root-Schlüssel ausgestattet, während ein sicherer Server den privaten Root-Schlüssel speichert. Um einen neuen öffentlichen Schlüssel an das Speichersubsystem zu delegieren, kann ein Benutzer eines Hostsystems (z. B. ein Anwendungsingenieur (field application engineer - FAE)) das Hostsystem veranlassen, um eine neue Schlüsseldelegationsanforderung an den Speichersubsystemcontroller zu senden. Die neue Schlüsseldelegationsanforderung beinhaltet den neuen öffentlichen Schlüssel, der an den Speichersubsystemcontroller delegiert werden soll. Als Reaktion auf den Empfang der Anforderung erzeugt der Speichersubsystemcontroller eine Aufforderung und sendet sie an das Hostsystem zurück, die den neuen öffentlichen Schlüssel, den öffentlichen Root-Schlüssel und eindeutige Daten (z. B. eine Zufallszahl und/oder eindeutige Gerätedaten) beinhaltet. Die eindeutigen Daten können zum Beispiel eindeutige Daten der Vorrichtung und/oder eine Zufallszahl beinhalten, die eindeutig ist und sich von nachfolgend generierten Aufforderungen unterscheidet. Die in der Aufforderung enthaltenen eindeutigen Daten stellen sicher, dass die Aufforderung nur von dem Speichersubsystemcontroller erzeugt werden kann und verhindern, dass die Aufforderung von anderen Vorrichtungen reproduziert wird. Die eindeutigen Daten verhindern auch, dass die Antwort auf die Aufforderung zu einem späteren Zeitpunkt an die Vorrichtung zurückgespielt werden kann.
  • Damit der Speichersubsystemcontroller den neuen öffentlichen Schlüssel akzeptiert und für kryptografische Operationen verwendet, muss der Benutzer des Hostsystems die Aufforderung sowohl mit dem privaten Root-Schlüssel als auch mit einem neuen privaten Schlüssel, der dem neuen öffentlichen Schlüssel entspricht, signieren lassen und dem Speichersubsystem die beiden digitalen Signaturen bereitstellen. Diese beiden digitalen Signaturen beweisen, dass der OEM die Delegation des neuen Schlüssels an das Speichersubsystem genehmigt und dass der Benutzer im Besitz des neuen privaten Schlüssels ist. Um diese Signaturen zu erhalten, kann der Benutzer des Hostsystems eine erste Signaturanforderung an den sicheren Server, der den privaten Root-Schlüssel speichert, und eine zweite Signaturanforderung an eine sichere Ausführungsumgebung für die Schlüsseldelegation (z. B. ein tragbares HSM, eine Smartcard oder einen sicheren Server) senden.
  • Als Reaktion auf die erste Signaturanforderung gibt der sichere Server eine erste digitale Signatur zurück, die durch kryptografisches Signieren der Aufforderung mit dem privaten Root-Schlüssel erzeugt wurde, und basierend auf der zweiten Signaturanforderung gibt die sichere Ausführungsumgebung der Schlüsseldelegation eine zweite digitale Signatur zurück, die durch kryptografisches Signieren der Aufforderung mit dem neuen privaten Schlüssel erzeugt wurde. Der Benutzer des Hostsystems stellt die beiden digitalen Signaturen dem Speichersubsystemcontroller über das Hostsystem bereit, und der Speichersubsystemcontroller validiert seinerseits die beiden digitalen Signaturen mit dem öffentlichen Root-Schlüssel bzw. dem neuen öffentlichen Schlüssel. Basierend auf der erfolgreichen Validierung der beiden Unterschriften kopiert der Speichersubsystemcontroller den neuen öffentlichen Schlüssel in den Speicher und kann ihn anschließend in einer oder mehreren kryptografischen Operationen verwenden.
  • Die Verwendung des oben beschriebenen Sicherheitsprotokolls reduziert Schwachstellen in einem Speichersubsystem, indem es den Zugriff auf sensible Informationen durch Unbefugte verhindert. Darüber hinaus stellt das Sicherheitsprotokoll einen sicheren Mechanismus für autorisiertes Personal bereit, um sicher auf sensible Informationen aus einem Speichersubsystem zuzugreifen, während es die Verwendung anderer kryptografischer Schlüssel als des ursprünglich für das Speichersubsystem bereitgestellten Root-Schlüssels ermöglicht.
  • 1 veranschaulicht eine beispielhafte Computerumgebung 100, die ein Speichersubsystem 110 beinhaltet, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Speichersubsystem 110 kann Medien beinhalten, wie z. B. die Speicherkomponenten 112-1 bis 112-N (im Folgenden auch als „Speichervorrichtungen“ bezeichnet). Die Speicherkomponenten 112-1 bis 112-N können flüchtige Speicherkomponenten, nichtflüchtige Speicherkomponenten oder eine Kombination davon sein. Ein Speichersubsystem 110 kann eine Speichervorrichtung, ein Speichermodul oder eine Mischform aus Speichervorrichtung und Speichermodul sein. Beispiele für eine Speichervorrichtung beinhalten ein Solid-State-Laufwerk (solid-state drive - SSD), ein Flash-Laufwerk, ein USB-Flash-Laufwerk (Universal Serial Bus), ein eMMC-Laufwerk (Embedded Multi-Media Controller), ein UFS-Laufwerk (Universal Flash Storage) und ein Festplattenlaufwerk (HDD). Beispiele für Speichermodule beinhalten ein Dual In-Line Memory Module (DIMM), ein Small Outline DIMM (SO-DIMM) und ein nichtflüchtiges Dual In-Line Memory Module (NVDIMM).
  • Die Computerumgebung 100 kann ein Hostsystem 120 beinhalten, das mit einem Speichersystem gekoppelt ist. Das Arbeitsspeichersystem kann ein oder mehrere Speichersubsysteme 110 beinhalten. In einigen Ausführungsformen ist das Hostsystem 120 mit verschiedenen Typen von Speichersubsystemen 110 gekoppelt. 1 veranschaulicht ein Beispiel für ein Hostsystem 120, das mit einem Speichersubsystem 110 gekoppelt ist. Das Hostsystem 120 verwendet das Speichersubsystem 110 zum Beispiel dazu, Daten in das Speichersubsystem 110 zu schreiben und Daten aus dem Speichersubsystem 110 zu lesen. Wie hierin verwendet, bezieht sich „gekoppelt an“ im Allgemeinen auf eine Verbindung zwischen Komponenten, bei der es sich um eine indirekte kommunikative Verbindung oder eine direkte kommunikative Verbindung (z. B. ohne zwischengeschaltete Komponenten) handeln kann, unabhängig davon, ob sie verdrahtet oder drahtlos ist und Verbindungen wie elektrische, optische, magnetische usw. beinhaltet.
  • Das Hostsystem 120 kann eine Computervorrichtung sein, wie z. B. ein Desktop-Computer, ein Laptop-Computer, ein Netzwerkserver, ein mobiles Gerät, ein eingebetteter Computer (z. B. einer, der in einem Fahrzeug, einer Industrieanlage oder einer vernetzten kommerziellen Vorrichtung enthalten ist) oder eine solche Computervorrichtung, die einen Speicher und eine Verarbeitungsvorrichtung beinhaltet. Das Hostsystem 120 kann das Speichersubsystem 110 beinhalten oder mit diesem gekoppelt sein, so dass das Hostsystem 120 Daten aus dem Speichersubsystem 110 lesen oder in dieses schreiben kann. Das Hostsystem 120 kann über eine physische Host-Schnittstelle mit dem Speichersubsystem 110 gekoppelt sein. Beispiele für eine physische Host-Schnittstelle beinhalten, sind aber nicht beschränkt auf, eine Serial Advanced Technology Attachment (SATA)-Schnittstelle, eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle, eine Universal Serial Bus (USB)-Schnittstelle, eine Fibre Channel-Schnittstelle, eine Serial Attached SCSI (SAS) und so weiter. Die physische Host-Schnittstelle kann verwendet werden, um Daten zwischen dem Hostsystem 120 und dem Speichersubsystem 110 zu übermitteln. Das Hostsystem 120 kann ferner eine NVM-Express-Schnittstelle (NVMe) verwenden, um auf die Speicherkomponenten 112-1 bis 112-N zuzugreifen, wenn das Speichersubsystem 110 über die PCIe-Schnittstelle mit dem Hostsystem 120 gekoppelt ist. Die physische Host-Schnittstelle kann eine Schnittstelle zur Weiterleitung von Steuer-, Adress-, Daten- und anderen Signalen zwischen dem Speichersubsystem 110 und dem Hostsystem 120 bereitstellen.
  • Die Speicherkomponenten 112-1 bis 112-N können eine beliebige Kombination der verschiedenen Typen von nichtflüchtigen Speicherkomponenten und/oder flüchtigen Speicherkomponenten beinhalten. Ein Beispiel für nichtflüchtige Speicherkomponenten beinhaltet einen Flash-Speicher vom Negative-and-(NAND)-Typ. Jede der Speicherkomponenten 112-1 bis 112-N kann ein oder mehrere Arrays von Speicherzellen beinhalten, z. B. Single-Level-Zellen (SLCs), Multi-Level-Zellen (MLCs), Triple-Level-Zellen (TLCs) oder Quad-Level-Zellen (QLCs). In einigen Ausführungsformen kann eine bestimmte Speicherkomponente sowohl einen SLC-Anteil als auch einen anderen Typ (z. B. MLC, TLC, QLC) von Speicherzellen beinhalten. Jede der Speicherzellen kann ein oder mehrere Bits von Daten speichern, die vom Hostsystem 120 verwendet werden. Obwohl nichtflüchtige Speicherkomponenten wie Flash-Speicher des Typs NAND beschrieben werden, können die Speicherkomponenten 112-1 bis 112-N auf jedem anderen Speichertyp basieren, z. B. auf einem flüchtigen Speicher. In einigen Ausführungsformen können die Speicherkomponenten 112-1 bis 112-N unter anderem ein Direktzugriffsspeicher (random access memory - RAM), ein Nur-Lese-Speicher (read-only memory - ROM), ein dynamischer Direktzugriffsspeicher (dynamic random access memory - DRAM), ein synchroner dynamischer Direktzugriffsspeicher (synchronous dynamic random access memory - SDRAM), ein Phasenänderungsspeicher (phase change memory - PCM), ein Magneto-Direktzugriffsspeicher (magneto random access memory - MRAM), ein Negativ-oder-(NOR)-Flash-Speicher, ein elektrisch löschbarer programmierbarer Festwertspeicher (electrically erasable programmable read-only memory - EEPROM) und ein Kreuzpunkt-Array aus nichtflüchtigen Speicherzellen sein. Ein Kreuzpunkt-Array aus nichtflüchtigen Speicherzellen kann die Bitspeicherung basierend auf einer Änderung des Volumenwiderstands in Verbindung mit einem stapelbaren Kreuzgitter-Datenzugriffs-Array ausführen. Darüber hinaus kann ein nichtflüchtiger Kreuzpunktspeicher im Gegensatz zu vielen Flash-Speichern eine Write-in-Place-Operation ausführen, bei der eine nichtflüchtige Speicherzelle programmiert werden kann, ohne dass die nichtflüchtige Speicherzelle zuvor gelöscht wurde. Außerdem können, wie oben erwähnt, die Speicherzellen der Speicherkomponenten 112-1 bis 112-N zu Seiten zusammengefasst werden, die sich auf eine Einheit der Speicherkomponente beziehen können, die zum Speichern von Daten verwendet wird. Bei einigen Speichertypen (z. B. NAND) können Seiten zu Blöcken gruppiert werden.
  • Ein Speichersubsystemcontroller 115 (im Folgenden als „Controller“ bezeichnet) kann mit den Speicherkomponenten 112-1 bis 112-N kommunizieren, um Operationen wie das Lesen von Daten, das Schreiben von Daten oder das Löschen von Daten an den Speicherkomponenten 112-1 bis 112-N und andere derartige Operationen auszuführen. Der Controller 115 kann Hardware wie eine oder mehrere integrierte Schaltungen und/oder diskrete Komponenten, einen Pufferspeicher oder eine Kombination daraus enthalten. Der Controller 115 kann ein Mikrocontroller, eine spezielle Logikschaltung (z. B. ein Field Programmable Gate Array (FPGA), eine anwendungsspezifische integrierte Schaltung (application - specific integrated circuit - ASIC)) oder ein anderer geeigneter Prozessor sein. Der Controller 115 kann einen Prozessor (Verarbeitungsvorrichtung) 117 beinhalten, der dazu konfiguriert ist, im lokalen Speicher 119 gespeicherte Anweisungen auszuführen. In dem veranschaulichten Beispiel beinhaltet der lokale Speicher 119 des Controllers 115 einen eingebetteten Speicher, der dazu konfiguriert ist, Anweisungen zum Ausführen verschiedener Prozesse, Operationen, logischer Abläufe und Routinen zu speichern, die den Betrieb des Speichersubsystems 110 steuern, einschließlich der Abwicklung der Kommunikation zwischen dem Speichersubsystem 110 und dem Hostsystem 120. In einigen Ausführungsformen kann der lokale Speicher 119 Speicherregister beinhalten, die Speicherzeiger, abgerufene Daten usw. speichern. Der lokale Speicher 119 kann auch einen ROM zum Speichern von Mikrocode beinhalten. Während das beispielhafte Speichersubsystem (110) in 1 so veranschaulicht wurde, dass es den Controller 115 beinhaltet, kann ein Speichersubsystem 110 in einer anderen Ausführungsform der vorliegenden Offenbarung keinen Controller 115 beinhalten und sich stattdessen auf eine externe Steuerung verlassen (z. B. durch einen externen Host oder durch einen vom Speichersubsystem getrennten Prozessor oder Controller).
  • Im Allgemeinen kann der Controller 115 Befehle oder Operationen vom Hostsystem 120 empfangen und die Befehle oder Operationen in Anweisungen oder geeignete Befehle umsetzen, um den gewünschten Zugriff auf die Speicherkomponenten 112-1 bis 112-N zu erreichen. Der Controller 115 kann für andere Operationen wie Wear-Leveling-Operationen, Garbage-Collection-Operationen, Operationen zur Fehlererkennung und Fehlerkorrekturcode (error-correcting code - ECC), Verschlüsselungsoperationen, Caching-Operationen und Adressübersetzungen zwischen einer logischen Blockadresse und einer physischen Blockadresse zuständig sein, die den Speicherkomponenten 112-1 bis 112-N zugeordnet sind. Der Controller 115 kann ferner einen Schaltkreis für die Host-Schnittstelle beinhalten, um über die physische Host-Schnittstelle mit dem Hostsystem 120 zu kommunizieren. Der Host-Schnittstellenschaltkreis kann die vom Hostsystem 120 empfangenen Befehle in Befehlsanweisungen umwandeln, um auf die Speicherkomponenten 112-1 bis 112-N zuzugreifen, und die mit den Speicherkomponenten 112-1 bis 112-N verbundenen Antworten in Informationen für das Hostsystem 120 umwandeln.
  • Das Speichersubsystem 110 kann auch zusätzliche Schaltkreise oder Komponenten beinhalten, die nicht veranschaulicht sind. In einigen Ausführungsformen kann das Speichersubsystem 110 einen Cache oder Puffer (z. B. DRAM) und einen Schaltkreis für Adressen (z. B. einen Zeilendekodierer und einen Spaltendekodierer) beinhalten, der eine Adresse vom Controller 115 empfangen und die Adresse dekodieren kann, um auf die Speicherkomponenten 112-1 bis 112-N zuzugreifen.
  • Das Speichersubsystem 110 beinhaltet auch eine Sicherheitskomponente 113, die eine sichere Kommunikation mit dem Speichersubsystem 110 ermöglicht. Die Sicherheitskomponente 113 kann im Controller 115 oder in einer oder mehreren der Speicherkomponenten 112-1 bis 112-N enthalten sein. In einigen Ausführungsformen beinhaltet der Controller 115 zumindest einen Teil der Sicherheitskomponente 113. Zum Beispiel kann der Controller 115 den Prozessor 117 (Verarbeitungsvorrichtung) beinhalten, der dazu konfiguriert ist, im lokalen Speicher 119 gespeicherte Anweisungen auszuführen, um die hierin beschriebenen Operationen auszuführen. In einigen Ausführungsformen ist die Sicherheitskomponente 113 Teil des Hostsystems 120, einer Anwendung oder eines Betriebssystems.
  • Die Sicherheitskomponente 113 kann ferner einen Schlüsselspeicher 109 beinhalten, um einen oder mehrere kryptografische Schlüssel zu speichern, die von der Sicherheitskomponente 113 zum Verschlüsseln und/oder Überprüfen von Informationen verwendet werden. Zum Beispiel kann der Schlüsselspeicher 109 einen öffentlichen Root-Schlüssel speichern, der von der Sicherheitskomponente 113 verwendet wird, um Informationen zu verschlüsseln oder Informationen zu verifizieren, die mit einem entsprechenden privaten Root-Schlüssel signiert wurden. In einigen Ausführungsformen ist der Schlüsselspeicher 109 in einem lokalen Speicher des Speichersubsystemcontrollers 115 (z. B. dem lokalen Speicher 119) implementiert. In einigen Ausführungsformen ist der Schlüsselspeicher 109 in einer oder mehreren der Speicherkomponenten 112-1 bis 112-N implementiert. Der Schlüsselspeicher 109 kann in einem nichtflüchtigen Speicher implementiert sein, sodass die darin gespeicherten kryptografischen Schlüssel bei einem Neustart des Systems nicht verloren gehen.
  • Die Sicherheitskomponente 113 kann eine Anforderung vom Hostsystem 120 zur Verwendung eines neuen öffentlichen Schlüssels bei kryptografischen Operationen empfangen. Als Reaktion auf die Anforderung stellt die Sicherheitskomponente 113 dem Hostsystem 120 eine Aufforderung bereit, die den öffentlichen Root-Schlüssel, den neuen öffentlichen Schlüssel, der in der Anforderung enthalten ist, und eine Zufallszahl enthält. In einigen Ausführungsformen kann die Aufforderung auch gerätespezifische Informationen beinhalten. Jede von der Sicherheitskomponente 113 erzeugte Aufforderung ist einzigartig für die Anforderung. Vor der Verwendung des neuen öffentlichen Schlüssels erhält die Sicherheitskomponente 113 zwei digitale Signaturen basierend auf der Aufforderung. Eine erste digitale Signatur wird durch Signieren der Aufforderung mit dem privaten Root-Schlüssel und eine zweite digitale Signatur wird durch Signieren der Aufforderung mit einem neuen privaten Schlüssel, der dem neuen öffentlichen Schlüssel entspricht, erzeugt. Die erste Signatur bestätigt, dass der neue öffentliche Schlüssel ein autorisierter Schlüssel ist (z. B. vom OEM autorisiert), während die zweite Signatur bestätigt, dass der anfordernde Benutzer im Besitz des neuen privaten Schlüssels ist. Nach Erhalt und Validierung der beiden Signaturen kann die Sicherheitskomponente 113 den neuen öffentlichen Schlüssel in den Speicher kopieren und ihn in einer oder mehreren kryptografischen Operationen verwenden.
  • Die Sicherheitskomponente 113 kann mit dem Hostsystem 120 über die physische Host-Schnittstelle oder einen nativen Seitenband-Kommunikationsport kommunizieren (z. B. einen Universal Asynchronous Receiver/Transmitter (UART)-Port oder einen anderen seriellen Kommunikationsport, der Zweiwegekommunikation unterstützt), der speziell als Diagnose- oder Wartungsport konfiguriert sein kann.
  • 2 ist ein Datenflussdiagramm, das die Interaktionen zwischen Komponenten in einer sicheren Kommunikationsumgebung veranschaulicht, wenn ein beispielhaftes Verfahren zur Delegation eines kryptografischen Schlüssels gemäß einigen Ausführungsformen der vorliegenden Offenbarung ausgeführt wird. Im Kontext von 2 kann ein anfängliches asymmetrisches Verschlüsselungsschlüsselpaar - ein öffentlicher Root-Schlüssel 207 und ein privater Root-Schlüssel 211 - vorab generiert werden, und die Sicherheitskomponente 113 kann mit dem öffentlichen Root-Schlüssel 207 ausgestattet werden, während ein sicherer Server 200 mit dem privaten Root-Schlüssel 211 ausgestattet wird. Die Sicherheitskomponente 113 speichert den öffentlichen Root-Schlüssel 207 in dem Schlüsselspeicher 109. Der sichere Server 200 umfasst ein HSM zum Speichern des privaten Root-Schlüssels 211. Zusätzlich kann im Kontext von 2 ein neues asymmetrisches Schlüsselpaar - ein neuer öffentlicher Schlüssel 205 und ein neuer privater Schlüssel 213 - erzeugt werden. Der neue öffentliche Schlüssel 205 ist in der unten beschriebenen Weise an die Sicherheitskomponente 113 zu delegieren, und der neue private Schlüssel 213 wird in einer sicheren Ausführungsumgebung 202 für die Schlüsseldelegation gespeichert.
  • In einigen Ausführungsformen kann die sichere Ausführungsumgebung 202 für die Schlüsseldelegation eine Smartcard sein oder eine solche beinhalten. Eine Smartcard ist eine Vorrichtung, die einen eingebetteten Schaltkreis zur Ausführung einer oder mehrerer Funktionen und einen internen Speicher zur Speicherung mindestens des privaten Schlüssels beinhaltet. Die Smartcard kann mit einer Lesekomponente (nicht abgebildet) durch direkten physischen Kontakt oder über eine entfernte kontaktlose Funkschnittstelle verbunden werden. Die Lesekomponente kann Informationen von der Smartcard lesen und über eine Schnittstelle mit dem Hostsystem 120 kommunizieren. Zum Beispiel kann das Speichersubsystem 110 eine API beinhalten, die es der Lesekomponente ermöglicht, Informationen mit dem Speichersubsystem 110 auszutauschen. In einigen Ausführungsformen muss ein Benutzer möglicherweise eine persönliche Identifikationsnummer (PIN) an die Smartcard übermitteln, um auf die auf der Smartcard gespeicherten Informationen wie den privaten Schlüssel zuzugreifen. In Ausführungsformen, in denen eine Smartcard zum Speichern des privaten Schlüssels verwendet wird, bindet der Multifaktor-Authentifizierungsprozess das Speichersubsystem 110 an einen bestimmten Benutzer - den Benutzer, dem die Smartcard zugeordnet ist. In Übereinstimmung mit diesen Ausführungsformen bleibt das Speichersubsystem 110 in einem gesperrten Zustand, in dem kein Zugriff auf Daten möglich ist, bis die Smartcard von der Lesekomponente gelesen wird.
  • In einigen Ausführungsformen kann die sichere Ausführungsumgebung 202 für die Schlüsseldelegation ein tragbares HSM sein oder umfassen (z. B. eingebettet in einen Laptop). In einigen Ausführungsformen kann die sichere Ausführungsumgebung 202 für die Schlüsseldelegation ein zweiter sicherer Server sein oder umfassen (z. B. der vom OEM betriebene sichere Server 200 oder ein von einem Dritten betriebener sicherer Server).
  • Wie dargestellt, sendet das Hostsystem 120 bei 204 eine Schlüsseldelegationsanforderung an den Controller 115. Die Schlüsseldelegationsanforderung umfasst den neuen öffentlichen Schlüssel 205, der an den Controller 115 delegiert wird.
  • Als Reaktion auf die Anforderung erzeugt die Sicherheitskomponente 113 des Controllers 115 eine Aufforderung 206. Die Aufforderung 206 umfasst den neuen öffentlichen Schlüssel 205, den öffentlichen Root-Schlüssel 207 und eine Zufallszahl. Die in der Aufforderung 206 enthaltene Zufallszahl ist einmalig und unterscheidet sich von später generierten Aufforderungen. Auf diese Weise stellt die Zufallszahl sicher, dass die Aufforderung 206 nur vom Controller 115 generiert werden kann und verhindert, dass die Aufforderung 206 von anderen Vorrichtungen reproduziert werden kann. Bei 208 antwortet der Controller 115 auf die Aufforderung des Hostsystems 120 mit der Aufforderung 206.
  • Bei 210 übermittelt ein Benutzer 201 des Hostsystems 120 (z. B. ein FAE) eine erste Signaturanforderung an die sichere Ausführungsumgebung 202 für die Schlüsseldelegation, um eine erste digitale Signatur durch kryptografisches Signieren der Aufforderung 206 mit dem privaten Root-Schlüssel 211 zu erzeugen. Bei 212 übermittelt der Benutzer 201 des Hostsystems 120 (z. B. ein FAE) eine zweite Signaturanforderung an den sicheren Server 200, um eine zweite digitale Signatur durch kryptografisches Signieren der Aufforderung 206 mit dem neuen privaten Schlüssel 213 zu erzeugen. Bei 214 antwortet die sichere Ausführungsumgebung 202 der Schlüsseldelegation auf die erste Signaturanforderung mit einer ersten digitalen Signatur 215, die durch kryptografisches Signieren der Aufforderung 206 mit dem neuen privaten Schlüssel 213 erzeugt wird, und bei 216 antwortet der sichere Server 200 auf die zweite Signaturanforderung mit einer zweiten digitalen Signatur 217, die durch kryptografisches Signieren der Aufforderung 206 mit dem privaten Root-Schlüssel 211 erzeugt wird.
  • Bei 218 stellt das Hostsystem 120 die doppelt signierte Aufforderung 206 dem Controller 115 bereit. Das heißt, das Hostsystem 120 stellt die erste digitale Signatur 215 und die zweite digitale Signatur 217 für den Controller 115 bereit. Nach Erhalt der ersten digitalen Signatur 215 und der zweiten digitalen Signatur 217 verwendet der Controller 115 den neuen öffentlichen Schlüssel 205 zur Validierung der ersten digitalen Signatur 215 und den öffentlichen Root-Schlüssel 207 zur Validierung der zweiten digitalen Signatur 217. Nach erfolgreicher Validierung beider Signaturen kopiert der Controller 115 den neuen öffentlichen Schlüssel 205 in den Speicher und verwendet ihn anschließend für eine oder mehrere kryptografische Operationen. Wenn die Validierung einer der beiden Signaturen nicht erfolgreich ist, verwirft der Controller 115 den neuen öffentlichen Schlüssel 205.
  • 3 ist ein Swimlane-Diagramm, das die Interaktionen zwischen Komponenten in der sicheren Kommunikationsumgebung veranschaulicht, wenn ein beispielhaftes Verfahren 300 zur Delegation eines kryptografischen Schlüssels gemäß einigen Ausführungsformen der vorliegenden Offenbarung ausgeführt wird. Vor dem Verfahren 300 wird ein erstes asymmetrisches Verschlüsselungsschlüsselpaar - ein öffentlicher Root-Schlüssel und ein privater Root-Schlüssel - im Voraus erzeugt, und die Sicherheitskomponente 113 wird mit dem öffentlichen Root-Schlüssel ausgestattet, während der sichere Server 200 mit dem privaten Root-Schlüssel ausgestattet wird. Die Sicherheitskomponente 113 speichert den öffentlichen Root-Schlüssel in dem Schlüsselspeicher 109. Darüber hinaus wird ein neues asymmetrisches Schlüsselpaar - ein neuer öffentlicher Schlüssel und ein neuer privater Schlüssel - erzeugt. Der neue öffentliche Schlüssel ist in der unten beschriebenen Weise an die Sicherheitskomponente 113 zu delegieren, und der neue private Schlüssel wird in einer sicheren Ausführungsumgebung (z. B. 202) gespeichert.
  • Wie in 3 dargestellt, beginnt das Verfahren 300 mit der Operation 302, bei dem das Hostsystem 120 eine Schlüsseldelegationsanforderung an den Controller 115 sendet. Die Schlüsseldelegationsanforderung umfasst den neuen öffentlichen Schlüssel, der an den Controller 115 delegiert wird.
  • Als Reaktion auf die Anforderung erzeugt die Sicherheitskomponente 113 des Controllers 115 in Operation 304 eine Aufforderung, die den neuen öffentlichen Schlüssel, den öffentlichen Root-Schlüssel und eine nur einmal verwendete Zahl (nonce) umfasst. Dementsprechend erzeugt die Sicherheitskomponente 113 bei der Generierung der Aufforderung die Nonce und kombiniert die Nonce mit dem öffentlichen Root-Schlüssel und dem neuen öffentlichen Schlüssel. In einigen Ausführungsformen kann die Aufforderung zusätzliche Felder wie gerätespezifische Informationen beinhalten (z. B. Informationen, die das Speichersubsystem 110 beschreiben). Die in der Aufforderung enthaltene Zufallszahl (und gerätespezifische Informationen) stellt sicher, dass die Aufforderung nur von dem Controller 115 generiert werden kann, und verhindert, dass die Aufforderung von anderen Vorrichtungen reproduziert werden kann.
  • Der Controller 115 antwortet in Operation 306 auf die Aufforderung des Hostsystems 120 mit der Aufforderung. Nach dem Empfang der Aufforderung sendet das Hostsystem 120 bei Operation 308 eine erste Signaturanforderung an die sichere Ausführungsumgebung 202 für die Schlüsseldelegation, um eine erste digitale Signatur durch kryptografisches Signieren der Aufforderung mit dem privaten Root-Schlüssel 211 zu erzeugen. Die sichere Ausführungsumgebung 202 für die Schlüsseldelegation kann ein tragbares HSM (z. B. eingebettet in einen Laptop), eine Smartcard oder ein sicherer Server (z. B. der vom OEM betriebene sichere Server 200 oder ein von einem Dritten betriebener sicherer Server) sein oder umfassen.
  • Parallel zur Übermittlung der ersten Signaturanforderung sendet das Hostsystem 120 bei Operation 310 eine zweite Signaturanforderung an den sicheren Server 200, um eine zweite digitale Signatur durch kryptografische Signierung der Aufforderung mit dem neuen privaten Schlüssel zu erzeugen. Die zweite Signaturanforderung kann über eine drahtgebundene oder drahtlose Netzwerkverbindung übermittelt werden. Zum Beispiel kann die Anforderung über eine Anwendungsprogrammierschnittstelle (application programming interface - API) empfangen werden, die vom sicheren Server 200 bereitgestellt wird.
  • Bei Operation 312 erzeugt die sichere Ausführungsumgebung 202 für die Schlüsseldelegation eine erste digitale Signatur, indem sie die Aufforderung unter Verwendung des neuen privaten Schlüssels kryptografisch signiert, und bei Operation 314 antwortet die sichere Ausführungsumgebung 202 für die Schlüsseldelegation auf die erste Signaturanforderung mit der ersten digitalen Signatur.
  • Bei Operation 316 erzeugt der sichere Server 200 eine zweite digitale Signatur, indem er die Aufforderung unter Verwendung des privaten Root-Schlüssels kryptografisch signiert, und bei Operation 318 antwortet der sichere Server 200 auf die zweite Signaturanforderung mit der zweiten digitalen Signatur.
  • Das Hostsystem 120 stellt die erste digitale Signatur 215 und die zweite digitale Signatur 217 der Sicherheitskomponente 113 bereit (bei Operation 320). Der Controller 115 validiert die erste und die zweite digitale Signatur in Operation 322. Genauer gesagt verwendet die Sicherheitskomponente 113 den neuen öffentlichen Schlüssel, um die erste digitale Signatur zu validieren, und verwendet den öffentlichen Root-Schlüssel, um die zweite digitale Signatur zu validieren. In einem Beispiel verwendet die Sicherheitskomponente 113 bei der Validierung einer digitalen Signatur einen öffentlichen Schlüssel, um Hash-Daten basierend auf der Aufforderung zu erzeugen, und die Sicherheitskomponente 113 entschlüsselt die digitale Signatur unter Verwendung des öffentlichen Schlüssels. Wenn die Hash-Daten und die entschlüsselten Daten übereinstimmen, wird der Schlüssel als gültig angesehen. Andernfalls wird der Schlüssel als ungültig betrachtet, da entweder ein anderer Schlüssel zur Erzeugung der digitalen Signatur verwendet wurde oder die der digitalen Signatur zugrunde liegenden Daten (z. B. die Aufforderung) verändert wurden.
  • Nach erfolgreicher Validierung beider Signaturen kopiert der Controller 115 den neuen öffentlichen Schlüssel bei Operation 324 in den Speicher. Nachdem der neue öffentliche Schlüssel in den Speicher kopiert wurde, kann die Sicherheitskomponente 113 den neuen öffentlichen Schlüssel in einer oder mehreren kryptografischen Operationen verwenden. In einigen Ausführungsformen kann der neue öffentliche Schlüssel in einem flüchtigen Speicher gespeichert werden, sodass der neue öffentliche Schlüssel beim Neustart des Systems verworfen wird.
  • 4 und 5 sind Flussdiagramme, die ein beispielhaftes Verfahren 400 zur Delegation eines kryptografischen Schlüssels in einem Speichersubsystem gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulichen. Das Verfahren 400 kann von einer Verarbeitungslogik ausgeführt werden, die Hardware (z. B. eine Verarbeitungsvorrichtung, Schaltkreise, dedizierte Logik, programmierbare Logik, Mikrocode, Hardware einer Vorrichtung, eine integrierte Schaltung usw.), Software (z. B. Anweisungen, die auf einer Verarbeitungsvorrichtung ausgeführt werden) oder eine Kombination davon beinhalten kann. In einigen Ausführungsformen wird das Verfahren 400 von der Sicherheitskomponente 113 von 1 ausgeführt. Obwohl Prozesse in einer bestimmten Sequenz oder Reihenfolge dargestellt sind, kann die Reihenfolge der Prozesse, sofern nicht anders angegeben, geändert werden. Somit sind die veranschaulichten Ausführungsformen nur als Beispiele zu verstehen, und die veranschaulichten Prozesse können in einer anderen Reihenfolge ausgeführt werden, und einige Prozesse können parallel ausgeführt werden. Zusätzlich können ein oder mehrere Prozesse in verschiedenen Ausführungsformen ausgelassen werden. Somit sind nicht alle Prozesse in jeder Ausführungsform erforderlich. Andere Prozessabläufe sind möglich.
  • Bei Operation 405 empfängt die Verarbeitungsvorrichtung eine Schlüsseldelegationsanforderung. Die Schlüsseldelegationsanforderung beinhaltet einen neuen öffentlichen Schlüssel. Die Anforderung kann von dem Host-System 120 empfangen werden. In einigen Ausführungsformen beinhaltet der Empfang der Anforderung den Empfang eines oder mehrerer Befehle vom Hostsystem über eine Hostsystem-Schnittstelle. In einigen Ausführungsformen beinhaltet der Empfang der Anforderung den Empfang der Anforderung vom Hostsystem über einen Kommunikationsport (z. B. einen UART-Port oder einen anderen seriellen Kommunikationsport, der eine bidirektionale Kommunikation unterstützt).
  • Die Verarbeitungsvorrichtung erzeugt bei Operation 410 eine Aufforderung als Reaktion auf den Empfang der Anforderung. Das Erzeugen der Aufforderung beinhaltet das Erzeugen eines Nonce und das Kombinieren des Nonce mit dem neuen öffentlichen Schlüssel und einem öffentlichen Root-Schlüssel, der von der Vorrichtung gespeichert wird. Der öffentliche Root-Schlüssel kann der Vorrichtung während der Herstellung zur Verfügung gestellt und in einem Schlüsselspeicher (z. B. Schlüsselspeicher 109) gespeichert werden. Die Nonce umfasst eine Zufallszahl. Dementsprechend beinhaltet das Erzeugen der Nonce das Erzeugen einer Zufallszahl. Die Verarbeitungsvorrichtung kann die Zufallszahl mit einem der vielen bekannten Zufallszahlengeneratoren erzeugen. In einigen Ausführungsformen kann die Aufforderung zusätzliche Felder enthalten, die bestimmte gerätespezifische Informationen beinhalten. Die in der Aufforderung enthaltene Zufallszahl stellt sicher, dass die Aufforderung nur vom Controller 115 generiert werden kann und verhindert, dass die Aufforderung von anderen Vorrichtungen reproduziert werden kann. Da es sich bei der Zufallszahl auch um eine eindeutige, nur einmal verwendete Zahl handelt, schützt die Zufallszahl auch vor der Wiederholung einer zuvor signierten Aufforderung.
  • Bei Operation 415 stellt die Verarbeitungsvorrichtung die Aufforderung als Antwort auf die Anforderung bereit. Zum Beispiel kann die Verarbeitungsvorrichtung die Aufforderung als Antwort auf eine vom Hostsystem 120 empfangene Aufforderung an das Hostsystem 120 zurücksenden.
  • Die Verarbeitungsvorrichtung empfängt eine erste digitale Signatur, die durch kryptografisches Signieren der Aufforderung mit einem neuen privaten Schlüssel erzeugt wird, der mit dem neuen öffentlichen Schlüssel verknüpft ist (bei Operation 420). Das heißt, der neue private Schlüssel und der neue öffentliche Schlüssel bilden ein asymmetrisches Schlüsselpaar.
  • Die Verarbeitungsvorrichtung empfängt bei Operation 425 eine zweite digitale Signatur, die durch kryptografisches Signieren der Aufforderung mit einem privaten Root-Schlüssel erzeugt wird, der mit dem öffentlichen Root-Schlüssel verbunden ist. Das heißt, der private Root-Schlüssel und der öffentliche Root-Schlüssel bilden ein asymmetrisches Schlüsselpaar.
  • Bei Operation 430 validiert die Verarbeitungsvorrichtung die erste digitale Signatur unter Verwendung des neuen öffentlichen Schlüssels. Zum Beispiel kann die Verarbeitungsvorrichtung einen ersten Hash der Aufforderung unter Verwendung des neuen öffentlichen Schlüssels berechnen, die erste digitale Signatur unter Verwendung des neuen öffentlichen Schlüssels entschlüsseln und den ersten Hash mit den entschlüsselten Daten vergleichen. Wenn die beiden Werte übereinstimmen (z. B. wenn der erste Hash und die entschlüsselten Daten identisch sind), ist die Validierung der ersten digitalen Signatur erfolgreich. Stimmen sie überein, gilt die Signatur als gültig. Stimmen die Werte nicht überein, wurde entweder ein anderer Schlüssel zur Erstellung der ersten Signatur verwendet oder die Aufforderung wurde (absichtlich oder unabsichtlich) geändert. Wenn somit ein Unterschied zwischen den beiden Werten besteht, schlägt die Validierung fehl.
  • Die Verarbeitungsvorrichtung validiert die zweite digitale Signatur unter Verwendung des öffentlichen Root-Schlüssels (bei Operation 435). Zum Beispiel kann die Verarbeitungsvorrichtung einen zweiten Hash der Aufforderung mit dem öffentlichen Root-Schlüssel berechnen, die zweite digitale Signatur mit dem öffentlichen Root-Schlüssel entschlüsseln und den zweiten Hash mit den entschlüsselten Daten vergleichen. Wie bei der ersten digitalen Signatur ist die Validierung der ersten digitalen Signatur erfolgreich, wenn die beiden Werte übereinstimmen. Andernfalls schlägt die Validierung fehl.
  • Die Verarbeitungsvorrichtung kopiert bei Operation 440 den neuen öffentlichen Schlüssel basierend auf der erfolgreichen Validierung der beiden digitalen Signaturen in den Speicher. In einem Beispiel speichert die Verarbeitungsvorrichtung den neuen öffentlichen Schlüssel in einer flüchtigen Speicherkomponente, sodass eine Unterbrechung der Stromversorgung der Verarbeitungsvorrichtung zum Verlust des neuen öffentlichen Schlüssels führt.
  • Bei Operation 445 verwendet die Verarbeitungsvorrichtung den neuen öffentlichen Schlüssel in einer kryptografischen Operation basierend auf der erfolgreichen Validierung sowohl der ersten als auch der zweiten digitalen Unterschrift. Zum Beispiel kann die Verarbeitungsvorrichtung den neuen öffentlichen Schlüssel verwenden, um Informationen zu verschlüsseln.
  • Wie in 5 dargestellt, kann das Verfahren 400 in einigen Ausführungsformen die Operationen 450 und 455 beinhalten. In Übereinstimmung mit diesen Beispielen speichert die Verarbeitungsvorrichtung den neuen öffentlichen Schlüssel in einer flüchtigen Speicherkomponente bei Operation 440. Bei Operation 450 empfängt die Verarbeitungsvorrichtung einen Befehl, um den neuen öffentlichen Schlüssel dauerhaft zu machen. Der Befehl kann von dem Hostsystem 120 über eine Hostsystem-Schnittstelle empfangen werden. Basierend auf dem Empfang des Befehls speichert die Verarbeitungsvorrichtung bei Operation 455 den neuen öffentlichen Schlüssel in einer nichtflüchtigen Speicherkomponente, sodass der neue öffentliche Schlüssel beim Neustart des Systems erhalten bleibt. Zum Beispiel kann die Verarbeitungsvorrichtung den neuen öffentlichen Schlüssel in dem Schlüsselspeicher 109 speichern. Einige Beispielsysteme sind im Folgenden aufgeführt.
  • Beispiel 1 ist ein System, umfassend: eine Speicherkomponente; und einen Speichersubsystemcontroller, der betriebsfähig mit der Speicherkomponente gekoppelt ist, um Operationen auszuführen, umfassend: Empfangen einer Schlüsseldelegationsanforderung, die einen neuen öffentlichen Schlüssel umfasst, von einem Hostsystem; Erzeugen einer Aufforderung basierend auf dem neuen öffentlichen Schlüssel und einem öffentlichen Root-Schlüssel basierend auf dem Empfang der Anforderung; Bereitstellen der Aufforderung an das Hostsystem in Reaktion auf die Schlüsseldelegationsanforderung; Empfangen einer ersten digitalen Signatur, die durch kryptografisches Signieren der Aufforderung mit einem neuen privaten Schlüssel, der dem neuen öffentlichen Schlüssel entspricht, erzeugt wird, von dem Hostsystem; Empfangen einer zweiten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem privaten Root-Schlüssel erzeugt wird, der dem öffentlichen Root-Schlüssel entspricht; Validieren der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels; Validieren der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels; und Verwenden des neuen öffentlichen Schlüssels in einer oder mehreren kryptografischen Operationen basierend auf dem Validieren der ersten und zweiten digitalen Signaturen.
  • In Beispiel 2 umfasst das System von Beispiel 1 optional eine flüchtige Speicherkomponente, und die Operationen von Beispiel 1 umfassen optional das Kopieren des neuen öffentlichen Schlüssels in die flüchtige Speicherkomponente basierend auf dem Validieren der ersten und zweiten digitalen Unterschrift.
  • In Beispiel 3 umfasst das System eines der Beispiele 1-2 optional eine nichtflüchtige Speicherkomponente, um den öffentlichen Root-Schlüssel zu speichern, und die Operationen eines der Beispiele 1-2 umfassen optional das Empfangen eines Befehls vom Hostsystem, um den neuen öffentlichen Schlüssel dauerhaft zu machen; und basierend auf dem Befehl, das Speichern des neuen öffentlichen Schlüssels in der nichtflüchtigen Speicherkomponente.
  • In Beispiel 4 umfasst die Aufforderung aus einem der Beispiele 1-3 optional ein Nonce, den neuen öffentlichen Schlüssel und den öffentlichen Root-Schlüssel.
  • In Beispiel 5 umfasst das Erzeugen der Aufforderung in einem der Beispiele 1-4 optional: Erzeugen der Nonce, wobei die Nonce eine Zufallszahl umfasst; und Kombinieren der Nonce, des neuen öffentlichen Schlüssels und des öffentlichen Root-Schlüssels.
  • In Beispiel 6 umfasst der Gegenstand eines der Beispiele 1-5 optional einen sicheren Server zum Speichern des privaten Root-Schlüssels und eine sichere Ausführungsumgebung zum Speichern des neuen privaten Schlüssels.
  • In Beispiel 7 umfasst der Gegenstand eines der Beispiele 1-6 optional einen sicheren Server, der ein Hardware-Sicherheitsmodul (HSM) umfasst, und eine sichere Ausführungsumgebung, die eines der folgenden Elemente umfasst: ein tragbares HSM, eine Smartcard oder einen zweiten sicheren Server.
  • In Beispiel 8 umfassen die Operationen eines der Beispiele 1-7 optional: Erzeugen, unter Verwendung des neuen öffentlichen Schlüssels, erster Hash-Daten basierend auf der Aufforderung; Entschlüsseln der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels, wobei die Entschlüsselung der ersten digitalen Signatur zu ersten entschlüsselten Daten führt; und Vergleichen der ersten Hash-Daten mit den ersten entschlüsselten Daten; Erzeugen, unter Verwendung des öffentlichen Root-Schlüssels, zweiter Hash-Daten basierend auf der Aufforderung; Entschlüsseln der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels, wobei die Entschlüsselung der zweiten digitalen Signatur zu zweiten entschlüsselten Daten führt; und Vergleichen der zweiten Hash-Daten mit den zweiten entschlüsselten Daten.
  • In Beispiel 9 umfasst das System aus einem der Beispiele 1-8 optional einen Schlüsselspeicher, der einen Speicher zum Speichern des öffentlichen Root-Schlüssels umfasst.
  • In Beispiel 10 umfasst das System aus einem der Beispiele 1-9 optional eine Host-Schnittstelle, wobei die Schlüsseldelegationsanforderung, die erste digitale Signatur und die zweite digitale Signatur über die Host-Schnittstelle empfangen werden.
  • Beispiel 11 ist ein Verfahren umfassend: Empfangen einer Schlüsseldelegationsanforderung, die einen neuen öffentlichen Schlüssel umfasst, von einem Hostsystem; Erzeugen einer Aufforderung, basierend auf dem neuen öffentlichen Schlüssel und einem öffentlichen Root-Schlüssel, durch einen oder mehrere Hardwareprozessoren, basierend auf dem Empfang der Anforderung; Bereitstellen der Aufforderung an das Hostsystem als Reaktion auf die Schlüsseldelegationsanforderung; Empfangen einer ersten digitalen Signatur, die durch kryptografisches Signieren der Aufforderung mit einem neuen privaten Schlüssel, der dem neuen öffentlichen Schlüssel entspricht, erzeugt wird, von dem Hostsystem; Empfangen einer zweiten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem privaten Root-Schlüssel erzeugt wird, der dem öffentlichen Root-Schlüssel entspricht; Validieren der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels durch den einen oder die mehreren Hardware-Prozessoren; Validieren der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels durch den einen oder die mehreren Hardware-Prozessoren; und Verwenden des neuen öffentlichen Schlüssels in einer oder mehreren kryptografischen Operationen basierend auf dem Validieren der ersten und zweiten digitalen Signatur.
  • In Beispiel 12 umfasst das Verfahren von Beispiel 11 optional das Kopieren des neuen öffentlichen Schlüssels in eine flüchtige Speicherkomponente basierend auf der Validierung der ersten und zweiten digitalen Unterschrift.
  • In Beispiel 13 umfasst das Verfahren aus einem der Beispiele 11 und 12 optional: Empfangen eines Befehls vom Hostsystem, den neuen öffentlichen Schlüssel dauerhaft zu machen; und basierend auf dem Befehl, Speichern des neuen öffentlichen Schlüssels in der nichtflüchtigen Speicherkomponente.
  • In Beispiel 14 umfasst die Aufforderung aus einem der Beispiele 11-13 optional: ein Nonce, den neuen öffentlichen Schlüssel und den öffentlichen Root-Schlüssel.
  • In Beispiel 15 umfasst das Erzeugen der Aufforderung in einem der Beispiele 11-14 optional: Erzeugen der Nonce, wobei die Nonce eine Zufallszahl umfasst; und Kombinieren der Nonce, des neuen öffentlichen Schlüssels und des öffentlichen Root-Schlüssels.
  • In Beispiel 16 umfasst der Gegenstand eines der Beispiele 11-15 optional einen sicheren Server zum Speichern des privaten Root-Schlüssels und eine sichere Ausführungsumgebung zum Speichern des neuen privaten Schlüssels.
  • In Beispiel 17 umfasst der Gegenstand eines der Beispiele 11-16 optional einen sicheren Server, der ein Hardware-Sicherheitsmodul (HSM) umfasst, und eine sichere Ausführungsumgebung, die eines der folgenden Elemente umfasst: ein tragbares HSM, eine Smartcard oder einen zweiten sicheren Server.
  • In Beispiel 18 umfassen die Verfahren eines der Beispiele 11-17 optional: Erzeugen, unter Verwendung des neuen öffentlichen Schlüssels, erster Hash-Daten basierend auf der Aufforderung; Entschlüsseln der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels, wobei die Entschlüsselung der ersten digitalen Signatur zu ersten entschlüsselten Daten führt; und Vergleichen der ersten Hash-Daten mit den ersten entschlüsselten Daten; Erzeugen, unter Verwendung des öffentlichen Root-Schlüssels, zweiter Hash-Daten basierend auf der Aufforderung; Entschlüsseln der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels, wobei die Entschlüsselung der zweiten digitalen Signatur zu zweiten entschlüsselten Daten führt; und Vergleichen der zweiten Hash-Daten mit den zweiten entschlüsselten Daten.
  • In Beispiel 19 entsprechen der eine oder die mehreren Hardwareprozessoren aus einem der Beispiele 11-18 optional einem Speichersubsystemcontroller.
  • Beispiel 20 ist ein nicht-transitorisches computerlesbares Speichermedium, das Anweisungen umfasst, die, wenn sie von einer Verarbeitungsvorrichtung ausgeführt werden, die Verarbeitungsvorrichtung so konfigurieren, dass sie Operationen ausführt, umfassend: Empfangen einer Schlüsseldelegationsanforderung von einem Hostsystem, die einen neuen öffentlichen Schlüssel umfasst; basierend auf dem Empfangen der Anforderung, Erzeugen einer Aufforderung auf der Grundlage des neuen öffentlichen Schlüssels und eines öffentlichen Root-Schlüssels; Bereitstellen der Aufforderung an das Hostsystem als Reaktion auf die Schlüsseldelegationsanforderung; Empfangen einer ersten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem neuen privaten Schlüssel erzeugt wird, der dem neuen öffentlichen Schlüssel entspricht; Empfangen einer zweiten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem privaten Root-Schlüssel erzeugt wird, der dem öffentlichen Root-Schlüssel entspricht; Validieren der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels; Validieren der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels; undVerwenden des neuen öffentlichen Schlüssels in einer oder mehreren kryptografischen Operationen basierend auf der Validierung der ersten und zweiten digitalen Signatur.
  • 6 veranschaulicht eine beispielhafte Maschine in Form eines Computersystems 600, in dem ein Satz von Anweisungen ausgeführt werden kann, um die Maschine zu veranlassen, eine oder mehrere der hierin erörterten Verfahren auszuführen. In einigen Ausführungsformen kann das Computersystem 600 einem Hostsystem (z. B. dem Hostsystem 120 von 1) entsprechen, das ein Speichersubsystem (z. B. das Speichersubsystem 110 von 1) beinhaltet, mit ihm gekoppelt ist oder es verwendet, um die Operationen eines Controllers auszuführen (z. B. um ein Betriebssystem auszuführen, um Operationen entsprechend der Sicherheitskomponente 113 von 1 auszuführen). In alternativen Ausführungsformen kann die Maschine mit anderen Maschinen in einem lokalen Netzwerk (LAN), einem Intranet, einem Extranet und/oder dem Internet verbunden (z. B. vernetzt) sein. Die Maschine kann in der Funktion eines Servers oder einer Client-Maschine in einer Client-Server-Netzwerkumgebung, als Peer-Maschine in einer Peer-to-Peer- (oder verteilten) Netzwerkumgebung oder als Server oder Client-Maschine in einer Cloud-Computing-Infrastruktur oder -Umgebung betrieben werden.
  • Die Maschine kann ein Personalcomputer (PC), ein Tablet-PC, eine Settopbox (STB), ein persönlicher digitaler Assistant (PDA), ein Mobiltelefon, eine Webanwendung, ein Netzwerkrouter, ein Switch oder eine Bridge oder eine beliebige Maschine sein, die in der Lage ist, Anweisungen (aufeinanderfolgend oder anderweitig) auszuführen, die Maßnahmen festlegen, die von der Maschine unternommen werden sollen. Ferner ist zwar eine einzelne Maschine veranschaulicht, doch soll der Begriff „Maschine“ auch eine beliebige Sammlung von Maschinen beinhalten, die einzeln oder gemeinsam einen Satz (oder mehrere Sätze) von Anweisungen ausführen, um eine oder mehrere der hierin erörterten Methoden auszuführen.
  • Das beispielhafte Computersystem 600 beinhaltet eine Verarbeitungsvorrichtung 602, einen Hauptspeicher 604 (z. B. ROM, Flash-Speicher, DRAM wie SDRAM oder Rambus DRAM (RDRAM) usw.), einen statischen Speicher 606 (z. B. Flash-Speicher, statischen Direktzugriffsspeicher (SRAM) usw.) und ein Datenspeichersystem 618, die über einen Bus 630 miteinander kommunizieren.
  • Die Verarbeitungsvorrichtung 602 ist eine oder mehrere universelle Verarbeitungsvorrichtungen wie ein Mikroprozessor, eine Zentraleinheit und dergleichen. Insbesondere kann die Verarbeitungsvorrichtung 602 ein Mikroprozessor für die Berechnung eines komplexen Anweisungssatzes (complex instruction set computing - CISC), ein Mikroprozessor für die Berechnung eines verringerten Anweisungssatzes (reduced instruction set computing - RISC), ein Mikroprozessor für sehr lange Anweisungswörter (very long instruction word - VLIW), ein Prozessor, der andere Anweisungssätze implementiert, oder Prozessoren sein, die eine Kombination von Anweisungssätzen implementieren. Die Verarbeitungsvorrichtung 602 kann auch eine oder mehrere spezielle Verarbeitungsvorrichtungen wie ein ASIC, ein FPGA, ein digitaler Signalprozessor (DSP), ein Netzwerkprozessor oder dergleichen sein. Die Verarbeitungsvorrichtung 602 ist dazu konfiguriert, Anweisungen 626 auszuführen, um die hierin besprochenen Operationen und Schritte auszuführen. Das Computersystem 600 kann ferner eine Netzwerk-Schnittstellenvorrichtung 608 beinhalten, um über ein Netzwerk 620 zu kommunizieren.
  • Das Datenspeichersystem 618 kann ein maschinenlesbares Speichermedium 624 (auch als computerlesbares Medium bekannt) beinhalten, auf dem ein oder mehrere Sätze von Anweisungen 626 oder Software gespeichert sind, die eine oder mehrere der hierin beschriebenen Methoden oder Funktionen verkörpern. Die Anweisungen 626 können sich auch vollständig oder zumindest teilweise im Hauptspeicher 604 und/oder in der Vorrichtung 602 befinden, während sie von dem Computersystem 600 ausgeführt werden, wobei der Hauptspeicher 604 und die Vorrichtung 602 ebenfalls maschinenlesbare Speichermedien darstellen. Das maschinenlesbare Speichermedium 624, das Datenspeichersystem 618 und/oder der Hauptspeicher 604 können dem Speichersubsystem 110 von 1 entsprechen
  • In einer Ausfuhrungsform beinhalten die Befehle 626 Befehle zur Implementierung einer Funktionalität, die einer Sicherheitskomponente (z. B. der Sicherheitskomponente 113 von 1) entspricht. Während das maschinenlesbare Speichermedium 624 in einem Ausführungsbeispiel als einzelnes Medium dargestellt ist, sollte der Begriff „maschinenlesbares Speichermedium“ ein einzelnes Medium oder mehrere Medien beinhalten, die den einen oder mehrere Sätze von Anweisungen speichern. Der Begriff „maschinenlesbares Medium“ ist außerdem so zu verstehen, dass er ein beliebiges Medium beinhaltet, das in der Lage ist, einen Satz von Anweisungen zur Ausführung durch die Maschine zu speichern oder zu kodieren und welche die Maschine veranlassen, eine oder mehrere der Vorgehensweisen der vorliegenden Offenbarung durchzuführen. Der Begriff „maschinenlesbares Medium“ ist dementsprechend so zu verstehen, dass er, ohne darauf beschränkt zu sein, Festkörperspeicher und optische Medien und magnetische Medien beinhaltet.
  • Einige Abschnitte der vorhergehenden detaillierten Beschreibungen wurden hinsichtlich Algorithmen und symbolischen Darstellungen von Vorgängen an Datenbits innerhalb eines Computerspeichers dargestellt. Diese algorithmischen Beschreibungen und Darstellungen sind die Wege, die von Fachleuten der Datenverarbeitung verwendet werden, um die Substanz ihrer Arbeit anderen Fachleuten am effektivsten zu vermitteln. Ein Algorithmus ist hier und im Allgemeinen konzipiert, eine selbstkonsistente Sequenz an Operationen zu sein, die zu einem gewünschten Ergebnis führt. Die Operationen sind diejenigen, die physische Manipulationen physischer Mengen erfordern. In der Regel, aber nicht zwingend, nehmen diese Mengen die Form von elektrischen oder magnetischen Signalen an, die dazu in der Lage sind, gespeichert, kombiniert, verglichen und anderweitig manipuliert zu werden. Es hat sich manchmal als praktisch erwiesen, hauptsächlich aus Gründen der gewöhnlichen Verwendung, diese Signale als Bits, Werte, Elemente, Symbole, Charakter, Begriffe, Zahlen oder dergleichen zu bezeichnen.
  • Es sollte jedoch bedacht werden, dass alle diese und ähnliche Begriffe mit den entsprechenden physischen Mengen in Verbindung zu bringen sind und lediglich praktische Bezeichnungen für diese Mengen darstellen. Die vorliegende Offenbarung kann sich auf die Vorgänge und Prozesse eines Computersystems oder einer ähnlichen elektronischen Rechenvorrichtung beziehen, die Daten, die als physische (elektronische) Mengen in den Registern und Speichern des Computersystems dargestellt werden, manipulieren und in andere Daten umwandeln, die in ähnlicher Weise als physische Mengen in den Speichern oder Registern des Computersystems oder anderen derartigen Informationsspeichersystemen dargestellt werden.
  • Die vorliegende Offenbarung bezieht sich auch auf ein Gerät zum Ausführen der hierin beschriebenen Operationen. Dieses Gerät kann speziell für die beabsichtigten Zwecke konstruiert sein oder einen Allzweckcomputer beinhalten, der durch ein im Computer gespeichertes Computerprogramm selektiv aktiviert oder rekonfiguriert wird. Ein solches Computerprogramm kann in einem computerlesbaren Speichermedium gespeichert werden, wie z. B., aber nicht beschränkt auf, jede Art von Diskette, die Disketten, optische Disketten, CD-ROMs und magnetisch-optische Disketten beinhaltet; ROMs; RAMs; löschbare programmierbare Festwertspeicher (EPROMs); EEPROMs; magnetische oder optische Karten; oder jede Art von Medien, die zur Speicherung elektronischer Anweisungen geeignet sind, jeweils gekoppelt an einen Computersystembus.
  • Die hierin vorgestellten Algorithmen und Anzeigen sind nicht von Natur aus an einen bestimmten Computer oder ein anderes Gerät gebunden. Verschiedene Allzwecksysteme können mit Programmen gemäß den hierin enthaltenen Lehren verwendet werden, oder es kann sich als zweckmäßig erweisen, ein spezielleres Gerät zu konstruieren, um das Verfahren auszuführen. Die Struktur für eine Vielfalt dieser Systeme wird wie in der obigen Beschreibung dargestellt. Darüber hinaus wird die vorliegende Offenbarung nicht unter Bezugnahme auf eine bestimmte Programmiersprache beschrieben. Es versteht sich, dass eine Reihe von Programmiersprachen verwendet werden kann, um die hierin beschriebenen Lehren der Offenbarung umzusetzen.
  • Die vorliegende Offenbarung kann als ein Computerprogrammprodukt oder eine Software bereitgestellt sein, das/die ein maschinenlesbares Medium beinhalten kann, das darauf gespeicherte Anweisungen aufweist, die verwendet werden können, um ein Computersystem (oder andere elektronische Vorrichtungen) zu programmieren, um einen Prozess gemäß der vorliegenden Offenbarung durchzuführen. Ein maschinenlesbares Medium beinhaltet jeden Mechanismus zur Speicherung von Informationen in einer Form, die von einer Maschine (z. B. einem Computer) gelesen werden kann. In einigen Ausführungsformen beinhaltet ein maschinenlesbares (z. B. computerlesbares) Medium ein maschinenlesbares (z. B. computerlesbares) Speichermedium, wie z. B. ein ROM, ein RAM, Magnetplattenspeichermedien, optische Speichermedien, Flash-Speicherkomponenten und so weiter.
  • In der vorangehenden Beschreibung wurden Ausführungsformen der Offenbarung unter Bezugnahme auf spezifische Beispielausführungen beschrieben. Es ist offensichtlich, dass verschiedene Modifikationen daran vorgenommen werden können, ohne vom breiteren Geltungsbereich der Ausführungsformen der Offenbarung, wie in den folgenden Ansprüchen dargelegt, abzuweichen. Die Beschreibung und die Zeichnungen sind dementsprechend eher in einem veranschaulichenden als in einem einschränkenden Sinne zu verstehen.

Claims (20)

  1. System, umfassend: eine Speicherkomponente; und einen Speichersubsystemcontroller, der betreibbar mit der Speicherkomponente gekoppelt ist, um Operationen auszuführen, umfassend: Empfangen einer Schlüsseldelegationsanforderung, die einen neuen öffentlichen Schlüssel umfasst, von einem Hostsystem; Erzeugen, basierend auf dem Empfangen der Anforderung, einer Aufforderung basierend auf dem neuen öffentlichen Schlüssel und einem öffentlichen Root-Schlüssel; Bereitstellen der Aufforderung an das Hostsystem als Reaktion auf die Schlüsseldelegationsanforderung; Empfangen einer ersten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem neuen privaten Schlüssel erzeugt wird, der dem neuen öffentlichen Schlüssel entspricht; Empfangen einer zweiten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem privaten Root-Schlüssel erzeugt wird, der dem öffentlichen Root-Schlüssel entspricht; Validieren der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels; Validieren der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels; und Verwenden des neuen öffentlichen Schlüssels in einer oder mehreren kryptografischen Operationen basierend auf dem Validieren der ersten und zweiten digitalen Signatur.
  2. System nach Anspruch 1, ferner umfassend eine flüchtige Speicherkomponente; wobei die Operationen ferner Folgendes umfassen: Kopieren des neuen öffentlichen Schlüssels in die flüchtige Speicherkomponente basierend auf dem Validieren der ersten und zweiten digitalen Signatur.
  3. System nach Anspruch 2, ferner umfassend eine nichtflüchtige Speicherkomponente, um den öffentlichen Root-Schlüssel zu speichern; wobei die Operationen ferner Folgendes umfassen: Empfangen eines Befehls von dem Hostsystem, um den neuen öffentlichen Schlüssel dauerhaft zu machen; und basierend auf dem Befehl, Speichern des neuen öffentlichen Schlüssels in der nichtflüchtigen Speicherkomponente.
  4. System nach Anspruch 1, wobei die Aufforderung eine Nonce, den neuen öffentlichen Schlüssel und den öffentlichen Root-Schlüssel umfasst.
  5. System nach Anspruch 4, wobei das Erzeugen der Aufforderung Folgendes umfasst: Erzeugen der Nonce, wobei die Nonce eine Zufallszahl umfasst; und Kombinieren der Nonce, des neuen öffentlichen Schlüssels und des öffentlichen Root-Schlüssels.
  6. System nach Anspruch 1, wobei: ein sicherer Server den privaten Root-Schlüssel speichert; und eine sichere Ausführungsumgebung den neuen privaten Schlüssel speichert.
  7. System nach Anspruch 6, wobei: der sichere Server ein Hardware-Sicherheitsmodul (HSM) umfasst; und die sichere Ausführungsumgebung eines der Folgenden umfasst: ein tragbares HSM, eine Smartcard oder einen zweiten sicheren Server.
  8. System nach Anspruch 1, wobei: das Validieren der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels Folgendes umfasst: Erzeugen, unter Verwendung des neuen öffentlichen Schlüssels, erster Hash-Daten basierend auf der Aufforderung; Entschlüsseln der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels, wobei das Entschlüsseln der ersten digitalen Signatur zu ersten entschlüsselten Daten führt; und Vergleichen der ersten Hash-Daten mit den ersten entschlüsselten Daten; das Validieren der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels Folgendes umfasst: Erzeugen, unter Verwendung des öffentlichen Root-Schlüssels, zweiter Hash-Daten basierend auf der Aufforderung; Entschlüsseln der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels, wobei das Entschlüsseln der zweiten digitalen Signatur zu zweiten entschlüsselten Daten führt; und Vergleichen der zweiten Hash-Daten mit den zweiten entschlüsselten Daten.
  9. System nach Anspruch 1, ferner umfassend einen Schlüsselspeicher, der einen Speicher zum Speichern des öffentlichen Root-Schlüssels umfasst.
  10. System nach Anspruch 1, ferner umfassend eine Host-Schnittstelle, wobei die Schlüsseldelegationsanforderung, die erste digitale Signatur und die zweite digitale Signatur über die Host-Schnittstelle empfangen werden.
  11. Verfahren, umfassend: Empfangen einer Schlüsseldelegationsanforderung, die einen neuen öffentlichen Schlüssel umfasst, von einem Hostsystem; Erzeugen, basierend auf dem Empfangen der Anforderung, einer Aufforderung durch einen oder mehrere Hardware-Prozessoren, basierend auf dem neuen öffentlichen Schlüssel und einem öffentlichen Root-Schlüssel; Bereitstellen der Aufforderung an das Hostsystem als Reaktion auf die Schlüsseldelegationsanforderung; Empfangen einer ersten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem neuen privaten Schlüssel erzeugt wird, der dem neuen öffentlichen Schlüssel entspricht; Empfangen einer zweiten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem privaten Root-Schlüssel erzeugt wird, der dem öffentlichen Root-Schlüssel entspricht; Validieren der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels durch den einen oder die mehreren Hardware-Prozessoren; Validieren der zweiten digitalen Unterschrift unter Verwendung des öffentlichen Root-Schlüssels durch den einen oder die mehreren Hardware-Prozessoren; und Verwenden des neuen öffentlichen Schlüssels in einer oder mehreren kryptografischen Operationen basierend auf dem Validieren der ersten und zweiten digitalen Signatur.
  12. Verfahren nach Anspruch 11, ferner umfassend Kopieren des neuen öffentlichen Schlüssels in eine flüchtige Speicherkomponente basierend auf dem Validieren der ersten und zweiten digitalen Signatur.
  13. Verfahren nach Anspruch 12, ferner umfassend: Empfangen eines Befehls von dem Hostsystem, um den neuen öffentlichen Schlüssel dauerhaft zu machen; und basierend auf dem Befehl, Speichern des neuen öffentlichen Schlüssels in der nichtflüchtigen Speicherkomponente.
  14. Verfahren nach Anspruch 11, wobei die Aufforderung eine Nonce, den neuen öffentlichen Schlüssel und den öffentlichen Root-Schlüssel umfasst.
  15. Verfahren nach Anspruch 14, wobei das Erzeugen der Aufforderung Folgendes umfasst: Erzeugen der Nonce, wobei die Nonce eine Zufallszahl umfasst; und Kombinieren der Nonce, des neuen öffentlichen Schlüssels und des öffentlichen Root-Schlüssels.
  16. Verfahren nach Anspruch 13, wobei: ein sicherer Server den privaten Root-Schlüssel speichert; und eine sichere Ausführungsumgebung den neuen privaten Schlüssel speichert.
  17. Verfahren nach Anspruch 16, wobei: der sichere Server ein Hardware-Sicherheitsmodul (HSM) umfasst; und die sichere Ausführungsumgebung eines der Folgenden umfasst: ein tragbares HSM, eine Smartcard oder einen zweiten sicheren Server.
  18. Verfahren nach Anspruch 17, wobei: das Validieren der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels Folgendes umfasst: Erzeugen, unter Verwendung des neuen öffentlichen Schlüssels, erster Hash-Daten basierend auf der Aufforderung; Entschlüsseln der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels, wobei das Entschlüsseln der ersten digitalen Signatur zu ersten entschlüsselten Daten führt; und Vergleichen der ersten Hash-Daten mit den ersten entschlüsselten Daten; das Validieren der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels Folgendes umfasst: Erzeugen, unter Verwendung des öffentlichen Root-Schlüssels, zweiter Hash-Daten basierend auf der Aufforderung; Entschlüsseln der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels, wobei das Entschlüsseln der zweiten digitalen Signatur zu zweiten entschlüsselten Daten führt; und Vergleichen der zweiten Hash-Daten mit den zweiten entschlüsselten Daten.
  19. Verfahren nach Anspruch 11, wobei der eine oder die mehreren Hardware-Prozessoren einem Speichersubsystemcontroller entsprechen.
  20. Nicht-transitorisches, computerlesbares Speichermedium, das Anweisungen umfasst, die, wenn sie von einer Verarbeitungsvorrichtung ausgeführt werden, die Verarbeitungsvorrichtung so konfigurieren, dass sie Operationen ausführt, die Folgendes umfassen: Empfangen einer Schlüsseldelegationsanforderung, die einen neuen öffentlichen Schlüssel umfasst, von einem Hostsystem; Erzeugen, basierend auf dem Empfangen der Anforderung, einer Aufforderung basierend auf dem neuen öffentlichen Schlüssel und einem öffentlichen Root-Schlüssel; Bereitstellen der Aufforderung an das Hostsystem als Reaktion auf die Schlüsseldelegationsanforderung; Empfangen einer ersten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem neuen privaten Schlüssel erzeugt wird, der dem neuen öffentlichen Schlüssel entspricht; Empfangen einer zweiten digitalen Signatur von dem Hostsystem, die durch kryptografisches Signieren der Aufforderung mit einem privaten Root-Schlüssel erzeugt wird, der dem öffentlichen Root-Schlüssel entspricht; Validieren der ersten digitalen Signatur unter Verwendung des neuen öffentlichen Schlüssels; Validieren der zweiten digitalen Signatur unter Verwendung des öffentlichen Root-Schlüssels; und Verwenden des neuen öffentlichen Schlüssels in einer oder mehreren kryptografischen Operationen basierend auf dem Validieren der ersten und zweiten digitalen Signatur.
DE112020005459.4T 2019-11-07 2020-11-06 Delegation eines kryptografischen schlüssels an ein speichersubsystem Pending DE112020005459T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/677,306 US11296872B2 (en) 2019-11-07 2019-11-07 Delegation of cryptographic key to a memory sub-system
US16/677,306 2019-11-07
PCT/US2020/059489 WO2021092445A1 (en) 2019-11-07 2020-11-06 Delegation of cryptographic key to a memory sub-system

Publications (1)

Publication Number Publication Date
DE112020005459T5 true DE112020005459T5 (de) 2022-09-08

Family

ID=75847200

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020005459.4T Pending DE112020005459T5 (de) 2019-11-07 2020-11-06 Delegation eines kryptografischen schlüssels an ein speichersubsystem

Country Status (6)

Country Link
US (2) US11296872B2 (de)
JP (1) JP2022554288A (de)
KR (1) KR20220091578A (de)
CN (1) CN114830595B (de)
DE (1) DE112020005459T5 (de)
WO (1) WO2021092445A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11736276B2 (en) 2019-11-07 2023-08-22 Micron Technology, Inc. Delegation of cryptographic key to a memory sub-system

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11784799B2 (en) * 2019-12-16 2023-10-10 The Toronto-Dominion Bank Secure distribution and management of cryptographic keys within a computing environment using distributed ledgers
US11652626B2 (en) * 2020-02-18 2023-05-16 International Business Machines Corporation Safeguarding cryptographic keys from modification or deletion
US20230040468A1 (en) * 2021-08-04 2023-02-09 International Business Machines Corporation Deploying a system-specific secret in a highly resilient computer system
US20230122962A1 (en) * 2021-10-15 2023-04-20 Micron Technology, Inc. Ensuring Replacement of a Memory Device Key
CN114022259B (zh) * 2021-11-11 2023-08-25 陕西华春网络科技股份有限公司 一种基于公钥指定和身份验证的招标方法和装置
CN117056982B (zh) * 2023-08-28 2024-02-23 广州市粤港澳大湾区前沿创新技术研究院 一种多机数据验签方法、系统及存储介质

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001320356A (ja) * 2000-02-29 2001-11-16 Sony Corp 公開鍵系暗号を使用したデータ通信システムおよびデータ通信システム構築方法
JP2004528624A (ja) 2001-01-17 2004-09-16 アルコット システムズ インコーポレイテッド ワンタイムパスワードを用いてユーザを事前認証する装置
GB2410658B (en) 2002-10-14 2006-03-01 Toshiba Res Europ Ltd Methods and systems for flexible delegation
KR20050123105A (ko) 2003-03-24 2005-12-29 마츠시타 덴끼 산교 가부시키가이샤 데이터 보호 관리 장치 및 데이터 보호 관리 방법
JP4773123B2 (ja) * 2004-03-31 2011-09-14 株式会社リコー 通信装置、証明書転送装置、認証データ転送装置、証明書設定システム、認証データ設定システム、通信装置の制御方法、証明書設定方法、認証データ設定方法、プログラム、および記録媒体
JP4671783B2 (ja) * 2004-07-20 2011-04-20 株式会社リコー 通信システム
US8601283B2 (en) * 2004-12-21 2013-12-03 Sandisk Technologies Inc. Method for versatile content control with partitioning
US7613921B2 (en) * 2005-05-13 2009-11-03 Intel Corporation Method and apparatus for remotely provisioning software-based security coprocessors
US20100242102A1 (en) * 2006-06-27 2010-09-23 Microsoft Corporation Biometric credential verification framework
US9118467B2 (en) 2013-03-13 2015-08-25 Atmel Corporation Generating keys using secure hardware
US9774448B2 (en) * 2013-10-30 2017-09-26 Duo Security, Inc. System and methods for opportunistic cryptographic key management on an electronic device
JP6526244B2 (ja) * 2015-02-14 2019-06-05 ヴァリメール インコーポレイテッド ドメインネームサービスを介するプライベートキーの安全な委任された配信
JP7122964B2 (ja) * 2015-07-03 2022-08-22 アフェロ インコーポレイテッド モノのインターネット（ＩｏＴ）システムに安全な通信チャネルを確立するための装置及び方法
US10516654B2 (en) * 2016-03-15 2019-12-24 Intel Corporation System, apparatus and method for key provisioning delegation
US10637793B1 (en) * 2016-06-30 2020-04-28 EMC IP Holding Company LLC Capacity based licensing
US10356088B1 (en) * 2017-01-25 2019-07-16 Salesforce.Com, Inc. User authentication based on multiple asymmetric cryptography key pairs
KR101816652B1 (ko) 2017-02-14 2018-01-09 주식회사 코인플러그 Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 서비스 제공 서버에 의하여 제공되는 서비스를 이용하기 위한 사용자의 로그인 요청에 대하여 pki 기반의 인증을 통해 로그인을 대행하는 방법 및 이를 이용한 서버
US11025436B2 (en) * 2017-03-01 2021-06-01 Banco Bilbao Vizcaya Argentaria, S.A. Self-authenticating digital identity
JP2018019415A (ja) * 2017-09-19 2018-02-01 Kddi株式会社 システム、認証局、車載コンピュータ、公開鍵証明書発行方法、及びプログラム
US11296872B2 (en) 2019-11-07 2022-04-05 Micron Technology, Inc. Delegation of cryptographic key to a memory sub-system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11736276B2 (en) 2019-11-07 2023-08-22 Micron Technology, Inc. Delegation of cryptographic key to a memory sub-system

Also Published As

Publication number Publication date
JP2022554288A (ja) 2022-12-28
KR20220091578A (ko) 2022-06-30
WO2021092445A1 (en) 2021-05-14
CN114830595B (zh) 2023-09-22
CN114830595A (zh) 2022-07-29
US11296872B2 (en) 2022-04-05
US11736276B2 (en) 2023-08-22
US20210143990A1 (en) 2021-05-13
US20220200793A1 (en) 2022-06-23

Similar Documents

Publication Publication Date Title
DE112020005459T5 (de) Delegation eines kryptografischen schlüssels an ein speichersubsystem
DE112020000269T5 (de) Ferngewährung des zugangs zu einer gesperrten datenspeichervorrichtung
DE102017205948A1 (de) Nachrichtenauthentifizierung mit sicherer Codeverifikation
DE102015209116A1 (de) Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
DE102013105248A1 (de) Vorrichtung zum Erzeugen eines Sicherheitsschlüssels unter Verwendung einer Vorrichtungs-ID und von Benutzer-Authentifizierungsinformation
DE112009004491T5 (de) System und Verfahren zum sicheren Speichern von Daten in einem elektronischen Gerät
DE102018115683A1 (de) Domänenübergreifende sicherheit in kryptographisch partionierter cloud
US11748273B2 (en) Secure data communication with memory sub-system
US11783044B2 (en) Endpoint authentication based on boot-time binding of multiple components
DE112021000644T5 (de) Dynamische befehlserweiterung für ein speichersubsystem
DE102018114266A1 (de) Nichtflüchtige speichervorrichtung mit sicherem lesen
DE112020000238T5 (de) Wiederherstellungsschlüssel zum entriegeln einer datenspeicherungsvorrichtung
DE112020000244T5 (de) Initialisierung einer Datenspeicherungsvorrichtung mit einer Managervorrichtung
CN116941220A (zh) 以个人标识符对消息进行存储器内签名
DE112020000236T5 (de) Mehrrollenentsperrung einer datenspeicherungsvorrichtung
DE112020000180T5 (de) Mehrvorrichtungsentsperrung einer datenspeichervorrichtung
DE102010038179B4 (de) Individuelle Aktualisierung von Computerprogrammen
DE112020005474T5 (de) Passwortgenerierung zur einmaligen verwendung
KR20230130692A (ko) 보안 메모리 디바이스에 마운트된 파일 시스템에 파일을기록하는 것을 지원하는 메커니즘
DE112020000179T5 (de) Entsperren einer datenspeicherungsvorrichtung
DE112021000964T5 (de) Zur multi-faktor-authentifizierung fähiges speichersubsystem
DE102022127567A1 (de) Authentifizierte modifizierung von speichersystemdaten
US11736453B2 (en) Secure key storage devices
DE112021000149T5 (de) Verschlüsselung einer datenspeicherungsvorrichtung
DE112021000150T5 (de) Datenspeicherungsvorrichtungsverschlüsselung

Legal Events

Date Code Title Description
R012 Request for examination validly filed