DE112021005155T5 - Verfahren zum schnellen, sicheren booten aus einer nichtflüchtigen speichereinrichtung und korrespondierende systeme und einrichtungen dafür - Google Patents

Verfahren zum schnellen, sicheren booten aus einer nichtflüchtigen speichereinrichtung und korrespondierende systeme und einrichtungen dafür Download PDF

Info

Publication number
DE112021005155T5
DE112021005155T5 DE112021005155.5T DE112021005155T DE112021005155T5 DE 112021005155 T5 DE112021005155 T5 DE 112021005155T5 DE 112021005155 T DE112021005155 T DE 112021005155T DE 112021005155 T5 DE112021005155 T5 DE 112021005155T5
Authority
DE
Germany
Prior art keywords
nvm
code
host
value
host device
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
DE112021005155.5T
Other languages
English (en)
Inventor
Daisuke Nakata
Shinsuke Okada
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.)
Infineon Technologies LLC
Original Assignee
Infineon Technologies LLC
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 Infineon Technologies LLC filed Critical Infineon Technologies LLC
Publication of DE112021005155T5 publication Critical patent/DE112021005155T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • 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/3236—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 cryptographic hash functions
    • H04L9/3242—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 cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • 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/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • 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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • 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/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software
    • 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/26—Testing cryptographic entity, e.g. testing integrity of encryption key or encryption algorithm
    • 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/84—Vehicles

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Power Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

Ein Verfahren kann das Speichern von durch eine Hosteinrichtung ausführbarem Hostcode in einer nichtflüchtigen Speichereinrichtung (NVM-Einrichtung) und durch die NVM-Einrichtung ausführbarem NVM-Code umfassen. Die NVM-Einrichtung kann die Integrität des NVM-Codes als Antwort auf vorgegebene Bedingungen validieren und einen Codeintegritätswert zum Validieren des NVM-Codes generieren. Der Codeintegritätswert weist eine Größe auf, die von der Größe des Hostcodes unabhängig ist. An die Hosteinrichtung kann ein Authentifizierungscode gesendet werden, der mit mindestens dem Codeintegritätswert generiert wird. Als Antwort auf Leseanforderungen von der Hosteinrichtung werden mindestens Abschnitte des Hostcodes zur Ausführung durch die Hosteinrichtung zurückgesendet. Es werden auch korrespondierende Einrichtungen und Systeme offenbart.

Description

  • VERWANDTE ANMELDUNGEN
  • Diese Patentanmeldung ist eine internationale Patentanmeldung der am 15. Dezember 2020 eingereichten US-Patentanmeldung Nr. 17/122,927 , die die Priorität und den Vorteil der am 2. Oktober 2020 eingereichten vorläufigen US-Patentanmeldung mit dem Aktenzeichen 63/086,750 beansprucht, deren jeweilige Inhalte durch Bezugnahme hierin aufgenommen sind.
  • GEBIET DER TECHNIK
  • Die vorliegende Offenbarung betrifft allgemein Systeme mit einer Hosteinrichtung, die in einer nichtflüchtigen Speichereinrichtung gespeicherten Code ausführt, und insbesondere Systeme, in denen eine Hosteinrichtung in einer nichtflüchtigen Speichereinrichtung gespeicherten Code authentifiziert.
  • ALLGEMEINER STAND DER TECHNIK
  • Systeme, die Prozessoren umfassen, können Bootvorgänge aufweisen, bei denen Code zur Ausführung durch einen Prozessor, z. B. Software (SW) oder Firmware (FW), aus einer Speichereinrichtung geladen werden kann. Bootvorgänge erfolgen zum Beispiel als Antwort auf Einschalt- und/oder Power-On-Reset-Ereignisse. Der Code für Bootvorgänge wird in der Regel in einer nichtflüchtigen Speichereinrichtung (NVM-Einrichtung, NVM = Nonvolatile Memory) gespeichert.
  • Die Möglichkeit eines „sicheren“ Bootens ist für viele Systeme unerlässlich. Für ein sicheres Booten ist es nötig, dass die Integrität des Codes ermittelt wird, bevor er durch einen Prozessor ausgeführt wird. Bislang kann die Integrität von Code dadurch ermittelt werden, dass eine Hosteinrichtung die Codeinhalte beim Booten eines Systems misst. Das Messen von Codeinhalten ist abhängig von der Größe des Codes (z. B. eines SW-Abbilds), wie durch die nichtflüchtige Einrichtung gespeichert. Eine Gesamtbootzeit (time) kann sich wie folgt ergeben: time = tbl + tapp tapp = BWmeasure * Sizeapp
    Figure DE112021005155T5_0001
    wobei tbl die Bootloader-Ladezeit, tapp die Zeit einer Anwendungsmessung (des Prüfens der Integrität), BWmeasure die Transferrate (z. B. Zeit pro Byte) und Sizeapp die Größe des SW-Abbilds (z. B. in Byte) ist. Die Bootzeit kann mithin von der Größe des SW-Abbilds abhängig sein.
  • 17 ist ein Blockschaltbild, das einen herkömmlichen Bootablauf für ein System 1701 zeigt. Das System 1701 kann eine NVM-Einrichtung 1703 und eine Hosteinrichtung 1705 umfassen. Bei dem Bootablauf können Power-On-Reset-Schaltungen 1707-0 in der NVM-Einrichtung 1703 eine Einschalt- oder Power-On-Reset-Bedingung erkennen und die NVM-Einrichtung 1703 einschalten, damit sie betriebsbereit ist.
  • In der Hosteinrichtung 1705 können Host-POR-Schaltungen 1707-1 eine Einschalt- oder Power-On-Reset-Bedingung erkennen. Als Antwort kann die Hosteinrichtung 1705 einen Read-Only-Memory(ROM)-Bootvorgang 1709 durchführen, bei dem Bootdaten aus einem ROM geladen werden können. Die Hosteinrichtung 1705 kann dann einen Bootladevorgang 1715 ausführen, der umfasst, dass Bootladedaten 1711 aus der NVM-Einrichtung 1703 gelesen werden. Die Integrität der Bootladedaten 1711 kann an einen Messungsvorgang 1717-0 gebunden sein. Dieser kann umfassen, dass aus den Bootladedaten 1711 mit einer Hashfunktion 1717 ein Hashwert generiert wird und/oder Bootloaderdaten mit einer Entschlüsselungsfunktion 1719 entschlüsselt werden. Der ROM-Bootvorgang 1709 und der Bootladevorgang 1715 können während einer Bootladezeit tbl 1721 erfolgen.
  • Die Hosteinrichtung 1705 kann dann einen Anwendungssoftware(AppSW)-Integritätsvorgang 1723 durchführen. Dieser kann einen Vorgang einer Messung 1717-1 einer in der NVM-Einrichtung 1703 gespeicherten AppSW 1725 umfassen. Der AppSW-Integritätsvorgang 1723 kann eine Zeit tapp 1727 beanspruchen, die in Abhängigkeit von der Größe der AppsSW variieren kann, wie oben angemerkt.
  • Ein Nachteil eines herkömmlichen Bootablaufs wie desjenigen in 17 besteht darin, dass das Booten umso länger dauert, je größer die SW ist. Dies kann in einigen Systemen problematisch sein, etwa in denjenigen, die in einem Controller Area Network (CAN) betrieben werden, in denen die Bootzeit die Busantwortzeitgrenzen für größere SW-Größen überschreiten kann, um nur ein Beispiel zu nennen.
  • Figurenliste
    • Die 1A bis 1C sind eine Reihe von Blockschaltbildern, die ein Authentifizierungsverfahren für ein System mit einer Hosteinrichtung und einer nichtflüchtigen Speichereinrichtung (NVM-Einrichtung) gemäß einer Ausführungsform zeigen.
    • 2 ist ein Blockschaltbild, das ein Verfahren zum Authentifizieren von in einer NVM-Einrichtung gespeicherter Software gemäß einer Ausführungsform zeigt.
    • 3 ist ein Blockschaltbild eines Systems und eines korrespondierenden Verfahrens zum Authentifizieren eines NVM-Einrichtungszustands mit einer symmetrischen Verschlüsselung gemäß einer Ausführungsform.
    • 4 ist ein Blockschaltbild eines Systems und eines korrespondierenden Verfahrens zum Authentifizieren eines NVM-Einrichtungszustands mit einer asymmetrischen Verschlüsselung gemäß einer Ausführungsform.
    • 5 ist ein Blockschaltbild eines Systems und eines korrespondierenden Verfahrens zum Authentifizieren eines NVM-Einrichtungszustands mit einer asymmetrischen Verschlüsselung gemäß einer anderen Ausführungsform.
    • 6 ist ein Diagramm, das eine herkömmliche Bootzeit im Vergleich mit Bootzeiten verschiedener Ausführungsformen zeigt.
    • 7 ist ein Blockschaltbild einer NVM-Einrichtung gemäß einer Ausführungsform.
    • 8 ist ein Schaltbild eines NVM-Arrays, das in Ausführungsformen umfasst sein kann.
    • 9 ist ein Blockschaltbild einer IC-NVM-Einrichtung (IC = Integrated Circuit, integrierte Schaltung) gemäß einer Ausführungsform.
    • 10 ist ein Blockschaltbild einer Hosteinrichtung gemäß einer Ausführungsform.
    • 11 ist ein Blockschaltbild eines Kraftfahrzeugsystems gemäß einer Ausführungsform.
    • 12 veranschaulicht ein Kraftfahrzeugsystem gemäß einer anderen Ausführungsform.
    • 13 ist ein Ablaufschema eines NVM-Einrichtungsauthentifizierungsverfahrens gemäß einer Ausführungsform.
    • 14 ist ein Ablaufschema eines Hosteinrichtungsauthentifizierungsverfahrens gemäß einer Ausführungsform.
    • 15 ist ein Ablaufschema eines Authentifizierungsverfahrens gemäß einer Ausführungsform.
    • 16 ist ein Ablaufschema eines Vorgangs einer Aktualisierung von Code (z. B. Firmware) gemäß einer Ausführungsform.
    • 17 ist ein Blockschaltbild eines herkömmlichen sicheren Bootvorgangs.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Gemäß Ausführungsformen kann eine nichtflüchtige Speichereinrichtung (NVM-Einrichtung) Hostcode zur Ausführung durch eine Hosteinrichtung und NVM-Code zur Ausführung durch die NVM-Einrichtung selbst speichern. Die NVM-Einrichtung kann als Antwort auf vorgegebene Bedingungen (z. B. eine Einschaltung oder ein Power-On-Reset) die Integrität des NVM-Codes prüfen. Die NVM-Einrichtung kann einen Codeintegritätswert speichern, der in einem Authentifizierungscode an die Hosteinrichtung übertragen wird. Die Hosteinrichtung kann den durch die NVM gespeicherten Code basierend auf dem Authentifizierungscode und nicht durch eine Messung des gespeicherten Hostcodes authentifizieren.
  • In einigen Ausführungsformen ist der Codeintegritätswert ein Hashwert einer bekannten authentischen Version des NVM-Codes.
  • In einigen Ausführungsformen kann die NVM-Einrichtung den Authentifizierungscode mit einem privaten Schlüssel verschlüsseln, und die Hosteinrichtung kann den Authentifizierungscode mit einem öffentlichen Schlüssel entschlüsseln.
  • In einigen Ausführungsformen kann die NVM-Einrichtung einen Hashwert des NVM-Codes generieren, der durch die Hosteinrichtung ausgelesen wird. Die Hosteinrichtung kann den aus der NVM-Einrichtung ausgelesenen Hashwert mit einem bekannten gültigen Hashwert vergleichen, um die NVM-Einrichtung und mithin den durch die NVM-Einrichtung gespeicherten Hostcode zu authentifizieren.
  • In den verschiedenen Ausführungsformen unten sind gleiche Elemente mit den gleichen Bezugszeichen versehen, wobei das führende Zeichen (die führenden Zeichen) mit der Nummer der Figur korrespondiert (korrespondieren).
  • Die 1A bis 1C sind Blockschaltbilder eines Systems 100 gemäß einer Ausführungsform. Das System 100 kann eine NVM-Einrichtung 102 und eine Hosteinrichtung 104 umfassen. Die NVM-Einrichtung 102 kann einen NVM-Benutzerraum 106, eine Host-Firmware (Host-FW) 108, eine NVM-Firmware 109, einen Codeintegritätswert 110 und einen Codeintegritätsprüfer 112 umfassen. Der NVM-Benutzerraum 106 kann ein oder mehrere Arrays von NVM-Zellen zum Speichern von Daten umfassen, die die Host-FW (z. B. Code) 108 und die NVM-FW 109 umfassen. NVM-Arrays können beliebig ausgebildet sein, etwa als eine NOR-Konfiguration, ohne jedoch darauf begrenzt zu sein. Die Host-FW 108 kann ein Firmwareabbild sein, das durch die Hosteinrichtung 104 ausführbar ist. Die NVM-FW 109 kann ein Firmwareabbild sein, das durch die NVM-Einrichtung 102 ausführbar ist. In einigen Ausführungsformen wird die NVM-FW 109 in einem sicheren Speicherbereich der NVM-Einrichtung 102 gespeichert, und außerhalb der NVM-Einrichtung kann nicht darauf zugegriffen werden, oder es kann nur mit einer Prozedur für einen sicheren Zugriff darauf zugegriffen werden.
  • Der Codeintegritätswert 110 kann ein Wert sein, der die Integrität der NVM-Einrichtung 102 repräsentiert und mithin die Integrität der Host-FW 108 authentifizieren kann. Der Codeintegritätswert 110 kann von der Hosteinrichtung 104 zum Authentifizieren der NVM-Einrichtung 102 genutzt werden, und die Hosteinrichtung 102 muss mithin die Host-FW 108 nicht mit einem Messungsvorgang wie bei herkömmlichen Verfahrensweisen bewerten. Der Codeintegritätswert 110 kann eine Bitgröße aufweisen, die nicht in Abhängigkeit von der Größe der Host-FW 108 variiert. In einigen Ausführungsformen ist der Codeintegritätswert 110 ein Hashwert, der durch eine an einer bekannten authentischen Version der NVM-FW 109 ausgeführte Hashfunktion generiert wird. In einigen Ausführungsformen wird der Codeintegritätswert 110 an einem (nicht gezeigten) sicheren Ort der NVM-Einrichtung 102 gespeichert. Bei dem sicheren Ort kann es sich um einen Speicherbereich handeln, auf den nur durch eine Sicherheitsprozedur (wie beispielsweise eine Authentifizierung) zugegriffen werden kann. In einigen Ausführungsformen wird der Codeintegritätswert 110 in einem unverschlüsselten Zustand (z. B. in einem sicheren Bereich) gespeichert. Jedoch könnte ein solcher Wert in anderen Ausführungsformen auch in einem verschlüsselten Zustand in der NVM-Einrichtung 102 gespeichert werden.
  • Der Codeintegritätsprüfer 112 kann die NVM-FW 109 zur Nutzung bei einer Integritätsbewertung der NVM-Einrichtung 102 (und mithin der durch die NVM-Einrichtung 102 gespeicherten Host-FW 108) messen. Dieser Vorgang kann in einer beliebigen geeigneten Weise erfolgen, etwa durch eine Messung der gesamten NVM-FW 109 oder von Abschnitten davon. In einigen Ausführungsformen generiert der Codeintegritätsprüfer 112 aus der NVM-FW 109 einen einzigen Hashwert. In einigen Ausführungsformen wird ein solcher generierter Hashwert mit einem bekannten gültigen Hashwert (z. B. dem Codeintegritätswert 110) verglichen. Der Codeintegritätsprüfer 112 kann beliebig ausgebildet sein, etwa als ein NVM-Prozessor, der gespeicherte Anweisungen ausführt, und/oder Logikschaltungen, die für die Funktion ausgelegt sind, ohne jedoch darauf begrenzt zu sein. Wenn der Codeintegritätsprüfer 112 bestimmt, dass die gespeicherte NVM-FW 109 nicht gültig ist, kann die NVM 102 in einigen Ausführungsformen jegliche Zugriffe auf die Host-FW 108 verhindern (da nicht garantiert werden kann, dass sie gültig ist).
  • Die Hosteinrichtung 104 kann mit der NVM 102 über beliebige geeignete Mittel kommunizieren, die eine Kabel- oder kabellose Verbindung umfassen. In einigen Ausführungsformen kommuniziert die Hosteinrichtung 104 mit der NVM-Einrichtung 102 über einen seriellen Bus. Die Hosteinrichtung 104 kann eine Authentifizierungsfunktion 114 und eine Host-FW-Ausführungsfunktion 116 umfassen. Die Authentifizierungsfunktion 114 kann die FW 108 unter Nutzung eines aus der NVM 102 bereitgestellten Codeintegritätswerts 110 authentifizieren. Die Host-FW-Ausführungsfunktion 116 kann die in der NVM-Einrichtung 102 gespeicherte Host-FW 108 ausführen, um verschiedene Systemanwendungen bereitzustellen. In einigen Ausführungsformen ist die Host-FW-Ausführungsfunktion 116 eine Execute-In-Place(XIP)-Funktion, die Code direkt aus der NVM 102 ausführt. Jedoch könnte die Host-FW-Ausführungsfunktion 116 in anderen Ausführungsformen die Host-FW 108 auch in einen Hostspeicher (z. B. ein DRAM, das nicht gezeigt wird) in der Hosteinrichtung 104 laden. Die Hosteinrichtung 104 kann die Host-FW dann aus dem Hostspeicher ausführen.
  • Nunmehr werden Vorgänge des Systems 100 beschrieben.
  • Die NVM-Einrichtung 102 in 1A, auf die hierzu Bezug genommen wird, kann als Antwort auf bestimmte Bedingungen die Integrität der NVM-FW 109 prüfen ①. In einigen Ausführungsformen umfassen solche Bedingungen eine Einschaltung oder ein Power-On-Reset. Jedoch könnte ein Integritätsprüfungsvorgang auch als Antwort auf beliebige andere geeignete Bedingungen, die einen vorgegebenen, durch die Hosteinrichtung 104 ausgegebenen Befehl umfassen, ausgelöst werden. Der FW-Integritätsprüfungsvorgang ① kann so wie jegliche der hierin beschriebenen Vorgänge oder auf eine äquivalente Weise erfolgen.
  • Die NVM-Einrichtung 102 in 1 B, auf die nunmehr Bezug genommen wird, kann einen verschlüsselten Codeintegritätswert 110' an die Hosteinrichtung 104 senden. Die Hosteinrichtung 104 kann die NVM-FW 109 basierend auf dem verschlüsselten Codeintegritätswert 110' authentifizieren. In einigen Ausführungsformen kann die Hosteinrichtung 104 auf die NVM-Einrichtung 102 zugreifen, um bei einem Authentifizierungsvorgang zusätzliche Daten auszulesen (z. B. um einen Hashwert von aktuell gespeicherter FW 108 abzurufen). Der verschlüsselte Codeintegritätswerts 110' kann eine Größe aufweisen, die unabhängig von der Größe der Host-FW 108 ist, und es kann mithin in einem vorgegebenen Zeitabschnitt (z. B. bei einem einzigen Lesevorgang) darauf zugegriffen werden. Infolgedessen kann die Zeit für Bootvorgänge schneller und/oder deterministischer als bei herkömmlichen Verfahrensweisen sein. Bei der Authentifizierung der NVM-FW 109 lassen sich der Zustand der NVM-Einrichtung 102 und mithin der Zustand der durch die NVM-Einrichtung 102 gespeicherten Host-FW 108 authentifizieren.
  • Sobald die Hosteinrichtung 104 in 1C, auf die nunmehr Bezug genommen wird, die Host-FW 108 authentifiziert hat, kann die Hosteinrichtung 104 auf die Host-FW 108 zur Ausführung durch die FW-Ausführungsfunktion 116 zugreifen. In einigen Ausführungsformen wird die Host-FW 108 im Execute-In-Place-Verfahren ausgeführt. In anderen Ausführungsformen kann die FW 108 in einen (nicht gezeigten) Hostspeicher geladen werden.
  • Gemäß Ausführungsformen kann eine Hosteinrichtung, statt die Integrität von in einer NVM-Einrichtung gespeichertem Code (z. B. SW oder FW) durch einen Messungsvorgang nachzuweisen, die Integrität des kryptografischen Zustands der NVM-Einrichtung nachweisen. Durch das Nachweisen, dass die Hardware (HW) und die NVM-FW der NVM-Einrichtung in einem gültigen kryptografischen Zustand sind, kann nachgewiesen werden, dass an der NVM-Einrichtung keine unbefugten Änderungen vorgenommen worden sind. Es kann also verifiziert werden, dass ein in die NVM-Einrichtung einprogrammierter Inhalt (z. B. Code) korrekt in einem gültigen kryptografischen Zustand ist. Wenn an der NVM-Einrichtung keine unbefugten Änderungen vorgenommen worden sind, kann mithin der in der NVM-Einrichtung gespeicherte Inhalt (z. B. Hostcode) nicht kompromittiert worden sein.
  • Das Nachweisen eines kryptografischen Zustands einer NVM-Einrichtung anstelle des kryptografischen Zustands eines durch die NVM-Einrichtung gespeicherten Abbilds (z. B. von SW) kann ein Vorgang in einer festen Zeit und unabhängig von der Abbildgröße sein. Dies ist anders als bei herkömmlichen Verfahrensweisen wie derjenigen, die in 17 gezeigt ist.
  • 2 ist ein Blockschaltbild eines Systems 200, das einen Bootablauf gemäß einer Ausführungsform zeigt. Das System 200 kann eine sichere NVM-Einrichtung 202 und eine Hosteinrichtung 204 umfassen. Die NVM-Einrichtung 202 kann eine Anwendungssoftware (AppSW) 208 zur Ausführung durch die Hosteinrichtung 204 speichern. Die NVM-Einrichtung 202 kann eine Power-On-Reset(POR)-Schaltung 218-0, eine Hashfunktion 220-0, einen Bootloadercode 222 und eine kryptografische Funktion 224-0 umfassen. Die Hosteinrichtung 204 kann POR-Schaltungen 218-1, eine Hosthashfunktion 220-1 und eine Messungsfunktion 228 umfassen.
  • Die POR-Schaltungen 218-0 können beim Bootablauf als Antwort auf eine Einschalt- oder Power-On-Reset-Bedingung die NVM-Einrichtung 202 einschalten. In einigen Ausführungsformen wird die Hashfunktion 220-0 dazu genutzt, um einen Codeintegritätswert aus durch die NVM-Einrichtung 202 gespeichertem NVM-Code zu generieren.
  • In der Hosteinrichtung 204 können die POR-Schaltungen 218-1 die Hosteinrichtung 204 starten, wodurch ein Read-Only-Memory(ROM)-Bootvorgang 226 eingeleitet werden kann. Dies kann umfassen, dass (nicht gezeigte) Verarbeitungsschaltungen auf einen Read-Only-Memory(ROM)-Bootcode zugreifen, um eine Anfangsfunktionalität zuzuschalten.
  • Sobald die Hosteinrichtung 204 hochgefahren und funktionsbereit ist, kann sie Bootloadercode aus der NVM-Einrichtung 202 auslesen 234-0. Die Hosteinrichtung 204 kann durch die Abarbeitung des ROM-Bootcodes einen Messungsvorgang 228 an dem Bootloadercode 222 ausführen und, wenn der Bootloadercode 222 gültig ist, den Bootloadercode 222 laden. Die Hosteinrichtung 204 kann in einer Bootloaderfunktion 222 durch die Abarbeitung des installierten Bootloadercodes 222 die NVM-Einrichtung 202 (und mithin die durch sie gespeicherte AppsSW 208) authentifizieren. In einigen Ausführungsformen kann die Hosteinrichtung 204 mit einem Lesebefehl oder dergleichen auf Authentifizierungsdaten zugreifen. Authentifizierungsdaten 234-1, die durch die Hosteinrichtung 204 aus der NVM-Einrichtung 202 ausgelesen werden, können eine begrenzte Größe haben und unabhängig von der Größe von durch die NVM-Einrichtung 202 gespeicherter Firmware sein. Die Authentifizierungsdaten 234-1 können einen Codeintegritätswert gemäß der Beschreibung hierin oder gemäß einem Äquivalent umfassen.
  • Sobald der Zustand der NVM-Einrichtung 202 authentifiziert worden ist, kann die Hosteinrichtung 204 einen Anwendungsausführungsvorgang 232 durchführen, bei dem ein Zugriff auf in der NVM-Einrichtung 202 gespeicherte Software (z. B. die AppsSW 208) erfolgt und diese ausgeführt wird. In einigen Ausführungsformen kann dies umfassen, dass Software 234-2 für ein Execute-In-Place-Verfahren oder zur Speicherung in einem Hostspeicher in der Hosteinrichtung 204 zur Ausführung aus der NVM-Einrichtung 202 ausgelesen wird.
  • Die von der Hosteinrichtung 204 zum Booten und Entsperren (z. B. Authentifizieren) der NVM-Einrichtung 204 benötigte Zeit, die als tbl_unlock 236 gezeigt ist, kann den ROM-Bootvorgang 226 und einen Bootloadervorgang 230 umfassen. Es versteht sich, dass die Zeit tbl_unlock 236 anders als beim herkömmlichen Bootablauf in 17 ein Einstellwert sein kann, der unabhängig von der Größe von durch die NVM-Einrichtung 202 gespeicherter Firmware ist, da nicht an der Firmware, sondern nur am Bootloadercode 222 eine Messung vorgenommen wird.
  • Ein Authentifizierungsvorgang zwischen einer NVM-Einrichtung und einer Hosteinrichtung kann in einer beliebigen geeigneten Weise erfolgen, und in einigen Ausführungsformen basiert die Authentifizierung auf der symmetrischen Kryptografie. 3 zeigt eine solche Ausführungsform.
  • 3 zeigt ein System 300, das eine NVM-Einrichtung 302 und eine Hosteinrichtung 304 umfasst. Es wird davon ausgegangen, dass die NVM-Einrichtung 302 im System 300 beim Booten ihre eigene FW-Integrität prüfen kann. Ferner verwenden die NVM-Einrichtung 302 und die Hosteinrichtung 304 denselben geheimen Schlüssel.
  • Gemäß Ausführungsformen kann die Hosteinrichtung 304 beim Booten (z. B. bei einer Einschaltung oder einem Power-On-Reset) eine Aufforderung an die NVM-Einrichtung 302 senden. Als Antwort auf die Aufforderung kann die NVM-Einrichtung 302 eine Antwort generieren. Die Hosteinrichtung 304 kann die Antwort validieren. Wenn die Antwort der NVM-Einrichtung 302 gültig ist, kann die NVM-Einrichtung 302 (und die durch sie gespeicherte FW) authentifiziert werden, und auf die FW kann von der Hosteinrichtung 304 zur Ausführung zugegriffen werden.
  • Die NVM-Einrichtung 302 in 3, auf die weiterhin Bezug genommen wird, kann über eine oder mehrere Verbindungen mit der Hosteinrichtung 304 kommunizieren. Solche Verbindungen können Kabel- oder kabellose Verbindungen umfassen, und insbesondere können Ausführungsformen einen seriellen Bus umfassen.
  • Bei der NVM-Einrichtung 302 kann es sich um eine sichere Einrichtung mit Speicherorten handeln, auf die ohne eine Authentifizierungs- oder andere Sicherheitsprozedur von außerhalb der NVM-Einrichtung 302 nicht zugegriffen werden kann. Die NVM-Einrichtung 302 kann einen Benutzerraum 306 umfassen, einen geheimen Schlüssel 338 speichern, einen Authentifizierungscode 310 generieren und einen NVM-Code speichern, der geprüft werden kann, um einen Codeprüfwert 312 zu generieren. Der Benutzerraum 306 kann einen Speicherort umfassen, auf den von anderen Einrichtungen (z. B. der Hosteinrichtung 304) zugegriffen werden kann und der eine Host-FW zur Ausführung durch die Hosteinrichtung 304 umfasst. Der Benutzerraum 306 kann durch ein oder mehrere NVM-Arrays gebildet werden. Der geheime Schlüssel 338 kann an einem sicheren Ort in der NVM-Einrichtung 302 gespeichert werden. In einigen Ausführungsformen handelt es sich bei diesem sicheren Ort um ein NVM-Array oder einen Teil eines NVM-Arrays, das für einen sicheren Zugriff ausgelegt ist. Ein Authentifizierungscodegenerator 310 kann einen Authentifizierungscode in einer beliebigen geeigneten Weise generieren und kann in der gezeigten Ausführungsform einen Hash-Nachrichtenauthentifizierungscode (HMAC) generieren. Ein Authentifizierungscode (R) kann mit einem verschlüsselten Codeintegritätswert (FW Hash) generiert werden. Der Codeintegritätswert (FW Hash) kann zum Validieren von durch die NVM-Einrichtung 302 gespeicherter NVM-FW genutzt werden. In der gezeigten Ausführungsform kann FW Hash ein Hashwert sein, der aus einem bekannten authentischen NVM-FW-Abbild generiert wird. Ein Codeintegritätswertgenerator 312 kann einen Codeprüfwert (FW Hash_r) für aktuell durch die NVM-Einrichtung 302 gespeicherte NVM-FW generieren (wobei jedoch nicht zwangsläufig bekannt ist, ob sie gültig ist).
  • Die Hosteinrichtung 304 kann denselben geheimen Schlüssel 338 wie die NVM-Einrichtung 302 speichern, einen Hostnoncewert (nonce_host) 340 generieren, ebenso wie die NVM-Einrichtung 302 einen Prüfungsauthentifizierungswert 310' generieren und Authentifizierungswerte vergleichen 344.
  • Nach der Beschreibung der Komponenten des Systems 300 wird nunmehr ein Authentifizierungsvorgang für das System 300 beschrieben.
  • Bei ① speichern die NVM-Einrichtung 302 und die Hosteinrichtung 304 denselben geheimen Schlüssel (für eine symmetrische Authentifizierung).
  • Bei ② generiert die NVM-Einrichtung 302 einen Codeprüfwert (FW Hash_r) für NVM-FW. Der Codeprüfwert (FW Hash_r) kann eine Messung der aktuell in der NVM-Einrichtung 302 gespeicherten NVM-FW repräsentieren. In der gezeigten Ausführungsform ist FW Hash_r ein Hashwert von NVM-FW, der mit derjenigen Hashfunktion generiert wird, die auch zum Generieren eines gültigen Codeintegritätswerts (FW Hash), der durch die NVM-Einrichtung 302 gespeichert wird, genutzt wird.
  • Bei ③ liest die Hosteinrichtung 304 den Codeprüfwert (FW Hash_r) 342 aus der NVM-Einrichtung 302 aus. Dies ist anders als bei herkömmlichen Verfahrensweisen, bei denen die Hosteinrichtung 304 die gesamte Host-FW aus dem NVM-Benutzerraum 306 für einen Messungsvorgang ausliest.
  • Bei ④ sendet die Hosteinrichtung 304 einen Hostnoncewert (nonce_host) an die NVM-Einrichtung 302. Der Hostnoncewert ist möglicherweise ein nur einmal verwendbarer Wert, der in einer beliebigen geeigneten Weise generiert wird, etwa indem hierzu ein gespeicherter Noncewert abgerufen oder ein in der Hosteinrichtung 304 untergebrachter Noncewertgenerator (z. B. ein Zufalls- oder Pseudozufallszahlengenerator) genutzt wird, ohne jedoch darauf begrenzt zu sein. Nonce_host kann in einer beliebigen geeigneten Weise an die NVM-Einrichtung 302 gesendet werden, etwa indem hierzu ein vorgegebener Befehl, der den Noncewert umfasst, übertragen wird oder ein Schreibvorgang an einem vorgegebenen Ort (z. B. in einem Register) der NVM-Einrichtung 302 erfolgt, ohne jedoch darauf begrenzt zu sein.
  • Bei ⑤ generiert die NVM-Einrichtung 302 einen Authentifizierungscode (R) 310 und sendet ihn an die Hosteinrichtung 304. In der gezeigten Ausführungsform lässt sich der Authentifizierungscode (R) 310 dadurch generieren, dass ein Codeintegritätswert FW Hash, der nonce_host-Wert und ein durch die NVM generierter Noncewert (nonce_nvm) mit dem geheimen Schlüssel 338 verschlüsselt werden. Der resultierende verschlüsselte Wert kann an eine HMAC-Funktion zum Generieren eines Hashwerts, um R zu generieren, gebunden sein. Der Authentifizierungswert R kann dann zusammen mit dem nonce_nvm-Wert an die Hosteinrichtung 304 gesendet werden. Die Werte R und nonce_nvm können in einer beliebigen geeigneten Weise an die Hosteinrichtung 304 gesendet werden, etwa als Daten als Antwort auf eine Leseanforderung von der Hosteinrichtung 304 (z. B. durch das Auslesen aus einem Register), ohne jedoch darauf begrenzt zu sein.
  • Bei ⑥ generiert die Hosteinrichtung 304 einen Vergleichsauthentifizierungscode (R'). In der gezeigten Ausführungsform wird der Vergleichsauthentifizierungscode (R') 310 dadurch generiert, dass der aus der NVM-Einrichtung 302 ausgelesene Codeintegritätswert FW Hash_r, der nonce_host-Wert und der von der NVM-Einrichtung empfangene nonce_nvm-Wert mit dem geheimen Schlüssel 338 verschlüsselt werden. Der resultierende verschlüsselte Wert kann an dieselbe HMAC-Funktion wie die NVM-Einrichtung, um R zu generieren, gebunden sein.
  • Bei ® vergleicht die Hosteinrichtung 304 den von der NVM-Einrichtung 302 empfangenen Authentifizierungscode (R) 310 mit dem durch sie generierten Vergleichsauthentifizierungscode (R') 310'. Wenn die zwei Authentifizierungscodes übereinstimmen (R' = R), kann die NVM-Einrichtung authentifiziert werden, und die Hosteinrichtung 302 kann auf im Benutzerraum 306 gespeicherte FW zugreifen und sie nutzen.
  • 3 zeigt die Nutzung eines speziellen Authentifizierungscodes (HMAC), jedoch können Ausführungsformen hierin jegliche geeigneten Authentifizierungscodes und Authentifizierungscodeprozesse umfassen, die auf einer Verschlüsselung basierende Authentifizierungscodes wie AES-CMAC oder andere kryptografische Funktionen umfassen, ohne jedoch darauf begrenzt zu sein. Andere Ausführungsformen umfassen möglicherweise eindeutige Gerätekennungen, die eine zusammengesetzte Gerätekennung wie etwa die durch eine Device Identifier Composition Engine (DICE) generierte Gerätekennung umfassen.
  • Ein Authentifizierungsvorgang zwischen einer NVM-Einrichtung und einer Hosteinrichtung kann die symmetrische Kryptografie umfassen, jedoch kann in anderen Ausführungsformen auch von der asymmetrischen Kryptografie Gebrauch gemacht werden. 4 zeigt eine solche Ausführungsform.
  • 4 zeigt ein System 400, das eine NVM-Einrichtung 402 und eine Hosteinrichtung 404 umfasst. Es wird davon ausgegangen, dass die NVM-Einrichtung 402 im System 400 beim Booten ihre eigene NVM-FW-Integrität prüfen kann und dass durch die NVM-Einrichtung 402 ein digitales Zertifikat 410 gespeichert wird. Das digitale Zertifikat 410 kann von einer der Hosteinrichtung 404 zugeordneten Entität (z. B. einem OEM-Hersteller) generiert und unter Nutzung eines privaten Schlüssels signiert werden. Das digitale Zertifikat 410 kann einen öffentlichen Schlüssel, der mit dem privaten Schlüssel korrespondiert, umfassen. Eine digitale Signatur kann einen verschlüsselten Codeintegritätswert (z. B. FW Hash) umfassen. Es wird zudem davon ausgegangen, dass die Hosteinrichtung 404 ihre eigene Version des öffentlichen Schlüssels speichert.
  • Gemäß Ausführungsformen kann die Hosteinrichtung 404 beim Booten einen öffentlichen Schlüssel und eine digitale Signatur, die durch die NVM-Einrichtung bereitgestellt werden, validieren. Die Hosteinrichtung 404 kann dann einen Codeintegritätswert mit einem Codeprüfwert vergleichen, der dadurch generiert wird, dass die NVM-Einrichtung 402 durch sie gespeicherte NVM-FW misst.
  • Die NVM-Einrichtung 402 in 4, auf die weiterhin Bezug genommen wird, kann über eine oder mehrere Verbindungen mit der Hosteinrichtung 404 kommunizieren. Die NVM-Einrichtung 402 kann einen Benutzerraum 406 umfassen, das digitale Zertifikat 410 speichern und einen NVM-Code speichern, der geprüft werden kann, um einen Codeprüfwert 412 zu generieren. Das digitale Zertifikat 410 kann einen öffentlichen Schlüssel 446 und einen Codeintegritätswert umfassen. In einigen Ausführungsformen ist das digitale Zertifikat 410 mit dem Standard X.509 konform. Das digitale Zertifikat 410 kann eine mit einem privaten Schlüssel generierte digitale Signatur 452 umfassen. Wie unten noch beschrieben wird, kann das digitale Zertifikat 410 durch die Hosteinrichtung 404 in die NVM-Einrichtung 402 geladen werden.
  • Die Hosteinrichtung 404 kann denselben öffentlichen Schlüssel 446' wie die NVM-Einrichtung 402 speichern. In einigen Ausführungsformen wird der öffentliche Schlüssel 446' mit in der Hosteinrichtung 404 untergebrachten nichtflüchtigen Schaltungen, wie etwa One-Time-Programmable(OTP)-Speicherzellen oder „eFuse“-Schaltungen, gespeichert. Die Hosteinrichtung 404 kann auch noch andere Funktionen ausführen, wie unten noch beschrieben wird.
  • Nunmehr wird ein Authentifizierungsvorgang für das System 400 beschrieben.
  • Bei ① installiert die Hosteinrichtung 404 das digitale Zertifikat 410 in der NVM-Einrichtung 404. Das digitale Zertifikat 410 in der gezeigten Ausführungsform kann einen öffentlichen Schlüssel, einen gültigen Codeintegritätswert (FW Hash) 450 und eine digitale Signatur aufweisen, die mit dem privaten Schlüssel, der mit dem öffentlichen Schlüssel korrespondiert, signiert worden ist.
  • Bei ② generiert die NVM-Einrichtung 402 einen Codeprüfwert (FW Hash_r) für gespeicherte NVM-FW. Der FW-Hash_r-Wert kann ein Hashwert der gespeicherten NVM-FW sein, der mit derjenigen Hashfunktion generiert wird, die auch zum Generieren eines Codeintegritätswerts (FW Hash), der in das digitale Zertifikat 410 aufgenommen wird, genutzt wird.
  • Bei ③ empfängt die Hosteinrichtung 404 den durch die NVM-Einrichtung 402 gespeicherten öffentlichen Schlüssel 446 und führt einen Vergleichsvorgang 448 mit dem durch sie gespeicherten öffentlichen Schlüssel 446' aus. Wenn die öffentlichen Schlüssel übereinstimmen, kann der Authentifizierungsvorgang fortgesetzt werden. Wenn die öffentlichen Schlüssel nicht übereinstimmen, kann die Authentifizierung der NVM-Einrichtung 402 fehlschlagen. In einigen Ausführungsformen umfasst dieser Vergleichsvorgang 448 das Auslesen eines adressierbaren Orts der NVM-Einrichtung 402 (z. B. einer Speicher- und/oder Registeradresse).
  • Bei ④ führt die Hosteinrichtung 404 einen Signaturverifizierungsvorgang 456 durch, um die von der NVM-Einrichtung 402 bereitgestellte digitale Signatur 452 zu verifizieren. Die NVM-Einrichtung 402 kann der Hosteinrichtung 404 die mit dem digitalen Zertifikat 410 korrespondierende digitale Signatur 452 bereitstellen. Die digitale Signatur 452 kann ein Wert sein, der zuvor mit einem privaten Schlüssel, der mit den öffentlichen Schlüsseln 446/446' korrespondiert, verschlüsselt worden ist. In einigen Ausführungsformen nutzt die NVM-Einrichtung 402 eine Hashfunktion 454, um aus dem gesamten digitalen Zertifikat oder Abschnitten davon (z. B. dem öffentlichen Schlüssel 446 oder FW Hash 450) einen Hashwert zu generieren. Der resultierende Hashwert kann der Hosteinrichtung 404 zur Nutzung beim Authentifizierungsprozess bereitgestellt werden. In diesem Fall kann die digitale Signatur 452 mit dem Hashwert korrespondieren (z. B. den mit dem privaten Schlüssel verschlüsselten Hashwert umfassen). In anderen Ausführungsformen kann die Signaturverifizierung 456 hingegen auch umfassen, dass die NVM-Einrichtung 402 das digitale Zertifikat 410 mit der korrespondierenden digitalen Signatur 452 sendet. Die Hosteinrichtung 404 kann die digitale Signatur 452 unter Nutzung des öffentlichen Schlüssels 446' entschlüsseln. Wenn die entschlüsselte Signatur mit der korrespondierenden Nachricht (z. B. einem Hashwert oder einem digitalen Zertifikat) übereinstimmt, lässt sich der in das digitale Zertifikat aufgenommene Codeintegritätswert (FW Hash) validieren. In einigen Ausführungsformen werden Signaturverifizierungswerte von der NVM-Einrichtung 402 als Antwort auf einen Hosteinrichtungsbefehl (z. B. einen Lesebefehl von einer Speicher- oder Registeradresse) an die Hosteinrichtung 404 gesendet.
  • Bei ⑤ vergleicht die Hosteinrichtung 404 einen Codeintegritätswert (FW Hash) mit dem durch die NVM-Einrichtung 402 generierten Codeprüfwert (FW Hash_r). Wenn die zwei Werte übereinstimmen (FW Hash = FW Hash_r), kann die NVM-Einrichtung 402 authentifiziert werden, und die Hosteinrichtung 404 kann auf im Benutzerraum 406 gespeicherte Host-FW zugreifen und sie nutzen. In einigen Ausführungsformen ist möglicherweise ein Codeintegritätswert (FW Hash) mit dem digitalen Zertifikat 410 empfangen worden. In Ausführungsformen, in denen ein Hashwert zur Signaturverifizierung genutzt wird, liest die Hosteinrichtung 404 den gültigen Codeintegritätswert (FW Hash) hingegen aus der NVM-Einrichtung 402 aus.
  • Manche Ausführungsformen können eine Authentifizierung mit einer asymmetrischen Verschlüsselung umfassen, bei der ein von einer Hosteinrichtung stammender privater Schlüssel (z. B. ein privater Schlüssel eines OEM-Herstellers) gebraucht wird, während in anderen Ausführungsformen von einem von einer NVM-Einrichtung stammenden privaten Schlüssel Gebrauch gemacht wird. 5 ist ein Blockschaltbild einer solchen Ausführungsform.
  • 5 zeigt ein System 500, das eine NVM-Einrichtung 502 und eine Hosteinrichtung 504 umfasst. Es wird davon ausgegangen, dass die NVM-Einrichtung 502 im System 500 beim Booten ihre eigene NVM-FW-Integrität prüfen und einen privaten Verschlüsselungsschlüssel (einen privaten NVM-Schlüssel), auf den die Hosteinrichtung 504 nicht zugreifen kann, sicher speichern kann. Es wird zudem davon ausgegangen, dass die Hosteinrichtung 504 einen öffentlichen Schlüssel, der mit dem privaten NVM-Schlüssel korrespondiert, speichert.
  • Gemäß Ausführungsformen kann die Hosteinrichtung 504 beim Booten einen Noncewert an die NVM-Einrichtung 502 senden. Die NVM-Einrichtung 502 kann ein Zertifikat mit einer on-the-fly generierten digitalen Signatur zurücksenden. Die Hosteinrichtung 504 kann die Signatur validieren, um die NVM-Einrichtung 502 zu authentifizieren.
  • Die NVM-Einrichtung 502 in 5, auf die weiterhin Bezug genommen wird, kann mit der Hosteinrichtung 504 über eine oder mehrere Verbindungen kommunizieren. Die NVM-Einrichtung 502 kann einen privaten Schlüssel (einen privaten NVM-Schlüssel) 558 und einen korrespondierenden öffentlichen Schlüssel (einen öffentlichen NVM-Schlüssel) 560 umfassen. Die NVM-Einrichtung 502 kann zudem on-the-fly einen Codeprüfwert und eine digitale Signatur generieren und hierzu den privaten NVM-Schlüssel nutzen.
  • Die Hosteinrichtung 504 kann denselben öffentlichen Schlüssel 560' wie die NVM-Einrichtung 502 speichern. In einigen Ausführungsformen wird der öffentliche Schlüssel 560' mit in der Hosteinrichtung untergebrachten nichtflüchtigen Schaltungen gespeichert. Die Hosteinrichtung 504 kann auch noch andere Funktionen ausführen, wie unten noch beschrieben wird.
  • Nunmehr wird ein Authentifizierungsvorgang für das System 500 beschrieben.
  • Bei ① prüft die NVM-Einrichtung 502 die Integrität ihrer eigenen NVM-FW 512. In einigen Ausführungsformen umfasst dieser Schritt, dass aus der NVM-FW ein Hashwert generiert und mit einem gültigen Hashwert verglichen wird, wobei dieser zum Beispiel an einem sicheren Ort in der NVM-Einrichtung 502 gespeichert ist. In einigen Ausführungsformen generiert die NVM-Einrichtung 502 einen FW-Zustandswert (FW_state), der die Integrität (oder die Nichtintegrität) der NVM-FW anzeigen kann. Wenn die Integritätsprüfung der NVM-FW 512 fehlschlägt, kann die NVM-Einrichtung in einigen Ausführungsformen den Zugang zu FW, die sie speichert, auch etwa zu Host-FW, sperren.
  • Bei ② sendet die Hosteinrichtung 504 einen Noncewert (nonce_host) an die NVM-Einrichtung 502. In einigen Ausführungsformen kann dieser Schritt umfassen, dass eine Hosteinrichtung einen Befehl mit dem nonce_host-Wert sendet und/oder den nonce_host-Wert an einen vorgegebenen Ort in der NVM-Einrichtung 502 (z. B. an einer Register- oder Speicheradresse) schreibt, ohne jedoch darauf begrenzt zu sein.
  • Bei ③ generiert die NVM-Einrichtung 502 unter Nutzung des privaten NVM-Schlüssels 558 eine digitale Signatur 562. Die digitale Signatur 562 kann „on-the-fly“ (z. B. als Antwort darauf, dass die Hosteinrichtung 504 den Authentifizierungsvorgang initiiert) generiert werden. Die digitale Signatur 562 kann aus einem digitalen Zertifikat generiert werden, das den (durch die NVM-Einrichtung 502 gespeicherten) öffentlichen NVM-Schlüssel 560, den empfangenen nonce_host-Wert 540 und optional den FW_state-Wert umfasst. Die digitale Signatur 562 kann aus den reinen Werten eines digitalen Zertifikats oder aus einem aus dem digitalen Zertifikat generierten Hashwert oder einer Kombination aus beidem generiert werden. In einigen Ausführungsformen sendet die NVM-Einrichtung 502 das gesamte digitale Zertifikat oder einen Abschnitt davon an die Hosteinrichtung 504.
  • Bei ④ vergleicht die Hosteinrichtung 504 den öffentlichen Schlüssel (560'), den sie speichert, mit dem von der NVM-Einrichtung 502 empfangenen öffentlichen Schlüssel (560). In einigen Ausführungsformen empfängt die Hosteinrichtung 504 den öffentlichen Schlüssel (560) als Teil eines signierten digitalen Zertifikats von der NVM-Einrichtung 502. Wenn die öffentlichen Schlüssel nicht übereinstimmen, kann die Authentifizierung der NVM-Einrichtung 502 fehlschlagen.
  • Bei ⑤ führt die Hosteinrichtung 504 einen Signaturverifizierungsvorgang 556 durch, um die von der NVM-Einrichtung 502 bereitgestellte digitale Signatur 562 zu verifizieren. Die NVM-Einrichtung 502 kann der Hosteinrichtung 504 eine mit dem digitalen Zertifikat korrespondierende digitale Signatur 562 bereitstellen. Wie oben angemerkt, nutzt die NVM-Einrichtung 502 in einigen Ausführungsformen eine Hashfunktion 554 zum Generieren eines Hashwerts aus dem gesamten digitalen Zertifikat oder Abschnitten davon. Der FW_state-Wert 561 kann in Ausführungsformen als Nachrichtendaten in den Hashwert aufgenommen werden. Der resultierende Hashwert kann (mit eventuellen korrespondierenden Nachrichtendaten) der Hosteinrichtung 504 zur Nutzung beim Authentifizierungsprozess bereitgestellt werden. In anderen Ausführungsformen umfasst der Signaturverifizierungsvorgang 556, dass die NVM-Einrichtung 502 das digitale Zertifikat (z. B. den öffentlichen NVM-Schlüssel 560, nonce_host 540 und optional FW_state) mit einer korrespondierenden digitalen Signatur 562 sendet.
  • Die Hosteinrichtung 504 kann die digitale Signatur 562 unter Nutzung des öffentlichen Schlüssels 560' entschlüsseln. Wenn bei dem Authentifizierungsprozess die Hashfunktion 554 genutzt wird, kann die Hosteinrichtung 504 dieselbe Hashfunktion zum Generieren eines übereinstimmenden Hashwerts (z. B. aus dem öffentlichen Schlüssel 560' und nonce_host 540) nutzen. Wenn der entschlüsselte Wert mit einem Erwartungswert übereinstimmt, lässt sich die NVM-Einrichtung 502 authentifizieren. In Ausführungsformen, die den FW_state-Wert 561 umfassen, kann die Authentifizierung der NVM-Einrichtung 502 fehlschlagen, wenn der FW_state-Wert 561 anzeigt, dass eine Integritätsprüfung von gespeicherter FW (nämlich 512) fehlgeschlagen ist (und mithin kann auch die Authentifizierung eventueller Inhalte in einem NVM-Benutzerraum 506, wie etwa von durch die Hosteinrichtung 504 ausführbarem Hostcode, fehlschlagen).
  • Gemäß Ausführungsformen kann ein System schnelle, sichere Bootzeiten aufweisen, die von der Größe des Codes einer Anwendung (z. B. von FW oder SW) unabhängig sein können. 6 ist ein Diagramm, in dem Bootzeiten gegenüber der Codegröße für verschiedene hierin offenbarte Verfahren verglichen werden. Die auf der y-Achse auf einer logarithmischen Skala gezeigte Bootzeit kann mit der Zeit zwischen einer Einschaltung oder einem Power-On-Reset und der Zeit, zu der Hostcode (z. B. Host-FW oder Anwendungs-SW) authentifiziert wird und zur Nutzung verfügbar ist, korrespondieren. 6 zeigt vier Antworten: eine Antwort 664 kann ein herkömmliches Verfahren wie das in 17 gezeigte sein; eine Antwort 666-0 kann ein Verfahren wie die in 3 gezeigte Ausführungsform sein; eine Antwort 666-1 kann ein Verfahren wie die in 4 gezeigte Ausführungsform sein; und eine Antwort 666-2 kann ein Verfahren wie die in 5 gezeigte Ausführungsform sein. Wie gezeigt, können Ausführungsformen (666-0, 666-1, 666-2) konstante, von der Hostcodegröße unabhängige Bootzeiten bereitstellen. Dahingegen können die Bootzeiten bei herkömmlichen Verfahrensweisen 664 umso länger sein, je größer der Hostcode ist.
  • 7 ist ein Blockschaltbild einer NVM-Einrichtung 702 gemäß einer Ausführungsform. Die NVM-Einrichtung 702 kann ein oder mehrere NVM-Arrays 757, einen Einrichtungsspeicherbereich 768-0, einen sicheren Speicherbereich 768-1, Arrayzugriffsschaltungen 772, einen Steuerteil 774, POR-Schaltungen 786 sowie Eingabe-/Ausgabe-Schaltungen (E/A-CKTs) 784 umfassen. Das eine oder die mehreren NVM-Arrays 757 können ein oder mehrere mit NVM-Zellen von einem beliebigen geeigneten Typ gebildete Arrays umfassen und können Decodier- und Schreibschaltungen (z. B. zum Programmieren, Löschen oder Verifizieren) umfassen. Das eine oder die mehreren NVM-Arrays 757 können einen Benutzerbereich 706 umfassen, der Hostcode zur Ausführung durch eine Hosteinrichtung 708 speichern kann.
  • Der Einrichtungsspeicherbereich 768-0 kann Werte zur Nutzung durch die NVM-Einrichtung 702 speichern. Diese Werte können Folgendes umfassen: eine digitale Signatur 752 (die in die NVM-Einrichtung geladen oder durch sie generiert wird), ein digitales Zertifikat 710 und/oder einen öffentlichen Schlüssel 760 (z. B. für Vorgänge einer asymmetrischen Verschlüsselung). Der Einrichtungsspeicherbereich 768-0 kann zudem Konfigurationsregister 770-0 umfassen und Parameter- und/oder ID-Informationen 770-1 für die NVM-Einrichtung 702 speichern. Bei dem Einrichtungsspeicherbereich 768-0 kann es sich um einen sicheren Bereich handeln oder nicht. Abschnitte des Einrichtungsspeicherbereichs 768-0 können zu dem einen oder den mehreren NVM-Arrays 757 gehören oder nicht.
  • Der sichere Speicherbereich 768-1 kann geheim zu haltende Datenwerte speichern. Der sichere Speicherbereich 768-1 kann NVM-Code 709, einen oder mehrere private Schlüssel 758 (z. B. für Vorgänge einer asymmetrischen Verschlüsselung) und/oder einen oder mehrere geheime Schlüssel 738 (z. B. für Vorgänge einer symmetrischen Verschlüsselung) speichern. Abschnitte des sicheren Einrichtungsspeicherbereichs 768-1 können zu dem einen oder den mehreren NVM-Arrays 757 gehören oder nicht. Bei dem NVM-Code 709 kann es sich um Code zur Ausführung durch die NVM-Einrichtung 702 zum Bereitstellen verschiedener Funktionen handeln.
  • Die Arrayzugriffsschaltungen 772 können Zugriff auf das eine oder die mehreren NVM-Arrays 757 als Antwort auf vom Steuerteil 744 empfangene Signale und Daten gewähren. In einigen Ausführungsformen umfassen die Arrayzugriffsschaltungen 772 eine Befehlsdecodierlogik zum Verarbeiten von Befehlen. Für NVM-Einrichtungen 702, die einen sicheren Bereich 768-1 umfassen, können die Arrayzugriffsschaltungen 772 für einen sicheren Zugriff ausgelegte Schaltungen 772-0 umfassen, die nur als Antwort auf ein vorgegebenes Sicherheitsprotokoll (z. B. eine auf einer Verschlüsselung basierende Authentifizierung) Zugriff auf den sicheren Bereich 768-1 von externen Entitäten aus gewähren.
  • Der Steuerteil 774 kann Funktionen der NVM-Einrichtung 702 steuern, die Authentifizierungsvorgänge gemäß Ausführungsformen umfassen. Der Steuerteil 774 kann einen Controller 776, einen Eingabepuffer 778 und einen Ausgabepuffer 780 umfassen. Der Controller 776 kann Prozessorschaltungen (Prozessor-CKTs) 776-0 umfassen, die Anweisungen 776-1 ausführen können. Die Anweisungen 776-1 können verschiedene Authentifizierungsfunktionen umfassen, die Folgendes umfassen, ohne jedoch darauf begrenzt zu sein: eine Hashfunktion 754, eine kryptografische Funktion 762, einen Noncewertgenerator 782 und einen Codeintegritätsprüfer 712. Die Hashfunktion 754 kann Hashwerte für durch die NVM-Einrichtung 702 gespeicherte oder empfangene Hashwerte generieren. In einigen Ausführungsformen stimmt die Hashfunktion 754 mit einer von einer korrespondierenden Hosteinrichtung genutzten Hashfunktion überein oder ist so konfiguriert, dass sie mit ihr übereinstimmt. Die kryptografische Funktion 762 kann verschiedene kryptografische Vorgänge durchführen, die das Verschlüsseln und/oder Entschlüsseln von durch die NVM-Einrichtung 702 gespeicherten Werten sowie das Erzeugen von Authentifizierungscodes unter Nutzung von Schlüsselwerten umfassen, ohne jedoch darauf begrenzt zu sein. Der Noncewertgenerator 782 kann einen Noncewert (z. B. nonce_nvm) zur Nutzung bei Authentifizierungsvorgängen generieren. Der Codeintegritätsprüfer 712 kann die Integrität von in einem oder mehreren NVM-Benutzerarrays gespeichertem Code, der den NVM-Code 709 umfasst, prüfen. In einigen Ausführungsformen ist der Codeintegritätsprüfer 712 eine Hashfunktion (z. B. 754).
  • Der Eingabepuffer 778 kann durch die NVM-Einrichtung 702 empfangene Eingabebefehle und/oder -daten empfangen. Solche Befehle können durch die Arrayzugriffsschaltungen 772 für einen Zugriff auf das eine oder die mehreren NVM-Arrays 757, den Einrichtungsspeicherbereich 768-0 und den sicheren Einrichtungsspeicherbereich 768-1 verarbeitet werden. Der Ausgabepuffer 780 kann aus der NVM-Einrichtung 702 ausgegebene Daten, die Daten aus dem einen oder den mehreren NVM-Arrays 757, dem Einrichtungsspeicherbereich 768-0 und dem sicheren Speicherbereich 768-1 umfassen, transferieren. Der sichere Speicherbereich 768-1 ist möglicherweise nicht über die E/A-Schaltungen 784 zugänglich.
  • Die POR-Schaltung 786 kann Einschalt- und Power-On-Reset-Bedingungen erkennen und die verschiedenen Abschnitte der NVM-Einrichtung 702 mit Strom versorgen. In einigen Ausführungsformen umfasst die POR-Schaltung 786 Schaltungen zum Laden von Basisfunktionsanweisungen (z. B. ROM-Daten) zur Ausführung durch die Prozessorschaltungen 776-0.
  • Die E/A-Schaltungen 784 können über einen oder mehrere Busse 788 mit anderen Einrichtungen (z. B. einer Hosteinrichtung) verbunden sein. In einigen Ausführungsformen ist ein Bus 788 ein serieller Bus, der serielle Busse umfasst, die mit einem Controller Area Network (CAN), dem Serial Peripheral Interface (SPI) and I2C kompatibel sind, ohne jedoch darauf begrenzt zu sein. Die E/A-Schaltungen 784 können Ein- und Ausgänge für die NVM-Einrichtung 702 und andere Signalisierungsschaltungen umfassen, die physikalische Schnittstellen (PHY) und Serialisierungs- und Deserialisierungsschaltungen umfassen, ohne jedoch darauf begrenzt zu sein.
  • Manche Ausführungsformen können eine beliebige geeignete NVM-Arraystruktur und einen beliebigen geeigneten NVM-Zellentyp umfassen, während andere Ausführungsformen Arrays vom 1-Transistor-NOR-Typ (1T NOR) umfassen können. 8 ist ein Schaltbild eines 1T-NOR-Arrays 857, das in Ausführungsformen umfasst sein kann. Das Array 857 kann etliche Speicherzellen umfassen (von denen eine mit dem Bezugszeichen 857-0 gezeigt ist), die in Zeilen und Spalten angeordnet sind, wobei Speicherzellen einer selben Reihe mit einer selben Wortleitung verbunden sind (von denen eine mit dem Bezugszeichen 857-2 gezeigt ist) und Speicherzellen einer selben Spalte mit einer selben Bitleitung 857-3 verbunden sind. In einigen Ausführungsformen sind die Speicherzellen (857-0) mit einer einzigen Transistorstruktur mit einer Ladungsspeicherungsstruktur 857-1 zwischen einem Steuergate und einem Kanal gebildet. Die Ladungsspeicherungsstruktur 857-1 kann ein oder mehrere Datenbits als Ladung speichern.
  • Manche Ausführungsformen umfassen möglicherweise Systeme mit Speichereinrichtungen, die mit einer Hosteinrichtung zusammenarbeiten, während andere Ausführungsformen möglicherweise eigenständige Speichereinrichtungen, die zum Authentifizieren eines Zustands der Speichereinrichtung und folglich des Zustands von durch die Einrichtung gespeichertem Code fähig sind, umfassen. Eine derartige Authentifizierung kann innerhalb kurzer Zeit erfolgen und ändert sich nicht in Abhängigkeit von der Größe des Codes, wie hierin beschrieben wird oder gemäß Äquivalenten möglich ist. Solche Speichereinrichtungen können mehrere im selben Gehäuse untergebrachte integrierte Schaltungen umfassen, jedoch könnten die Speichereinrichtungen in einigen Ausführungsformen vorteilhaft auch kompakte einzelne integrierte Schaltungen (also Chips) sein. 9 zeigt eine in einem Gehäuse untergebrachte Einchip-NVM-Einrichtung 902. Es versteht sich jedoch, dass Speichereinrichtungen gemäß Ausführungsformen auch beliebige andere geeignete Gehäusetypen umfassen können, auch etwa ein direktes Bonden eines Speichereinrichtungschips auf ein Leiterplattensubstrat.
  • 10 ist ein Blockschaltbild einer Hosteinrichtung 1004 gemäß einer Ausführungsform. Die Hosteinrichtung 1004 kann einen oder mehrere Hostprozessoren 1092, einen Hostdatenspeicher 1094 und E/A-Schaltungen (E/A-CKTs) 1096 umfassen. Der Hostdatenspeicher 1094 kann Bootfunktionen 1094-0 und einen nichtflüchtigen Datenspeicher 1094-1 umfassen. Der nichtflüchtige Datenspeicher 1094-1 kann Werte zur nichtflüchtigen Nutzung durch die Hosteinrichtung 1004 (z. B. OTP-Schaltungen oder eFuses) speichern. Die gespeicherten Werte können öffentliche Schlüssel 1046 und geheime Schlüssel 1038 umfassen. In einigen Ausführungsformen ist der gesamte nichtflüchtige Datenspeicher 1094-1 oder ein Teil davon ein sicherer Datenspeicher 1098.
  • Die Bootfunktionen 1094-0 können eine Codeintegritätslesefunktion 1042, einen Noncewertgenerator 1044, eine kryptografische Funktion 1024-1, eine Schlüsselvergleichsfunktion 1048 und eine Hashfunktion 1049 umfassen, ohne jedoch darauf begrenzt zu sein. Die Codeintegritätslesefunktion 1042 kann einen Prüfwert (z. B. FW Hash_r) aus der bei einem Authentifizierungsvorgang genutzten NVM-Einrichtung auslesen. In einigen Ausführungsformen umfasst dieser Schritt einen Lesevorgang an einer vorgegebenen Register- oder Speicheradresse. Der Noncewertgenerator 1044 kann einen Noncewert (z. B. nonce_host) zur Nutzung bei Authentifizierungsvorgängen generieren. Dieser Noncewert kann an eine NVM-Einrichtung übertragen werden. Die kryptografische Funktion 1024-1 kann kryptografische Funktionen durchführen, die das Verschlüsseln und/oder Entschlüsseln von in der Hosteinrichtung 1004 oder durch sie gespeicherten Werten und das Erzeugen von Authentifizierungscodes unter Nutzung von Verschlüsselungsschlüsselwerten (z. B. 1046, 1038) umfassen, ohne jedoch darauf begrenzt zu sein. Die Schlüsselvergleichsfunktion 1048 kann einen durch die Hosteinrichtung 1004 gespeicherten Schlüssel (z. B. 1046) mit einem von einer anderen Einrichtung (z. B. einer NVM-Einrichtung) empfangenen Schlüssel vergleichen. Die Hashfunktion 1049 kann Hashwerte für durch die Hosteinrichtung 1004 gespeicherte oder empfangene Hashwerte generieren. In einigen Ausführungsformen stimmt die Hashfunktion 1049 mit einer von einer korrespondierenden NVM-Einrichtung genutzten Hashfunktion überein oder ist so konfiguriert, dass sie mit ihr übereinstimmt.
  • Der nichtflüchtige Datenspeicher 1094-1 kann Werte zur Nutzung durch die Hosteinrichtung 1004 bei Authentifizierungsvorgängen speichern. Diese Werte können den öffentlichen Schlüssel 1046 und/oder den geheimen Schlüssel 1038 umfassen, ohne jedoch darauf begrenzt zu sein. Der geheime Schlüssel 1038 kann im sicheren Datenspeicher 1098 gespeichert werden, wozu vorgegebene Zugriffsprozeduren erforderlich sein können, wie hierin beschrieben.
  • Die E/A-Schaltungen 1096 können über einen oder mehrere Busse 1088 mit anderen Einrichtungen (z. B. einer Hosteinrichtung) verbunden sein. Die E/A-Schaltungen 1096 können so wie diejenigen, die hierin beschrieben werden, ausgebildet sein.
  • Ausführungsformen können ein beliebiges geeignetes System mit einer Einrichtung umfassen, die in einer anderen Einrichtung gespeicherte Daten schnell authentifizieren muss. Ausführungsformen können aber auch in Systemen, die Bootdaten in hochzuverlässigen Speichereinrichtungen speichern, vorteilhaft sein, etwa in Kraftfahrzeugsystemen. 11 zeigt ein Kraftfahrzeugsystem 1100 gemäß einer Ausführungsform. Das System 1100 kann eine erste NVM-Einrichtung 1102-0, eine zweite NVM-Einrichtung 1102-1, ein System-on-Chip (SoC) 1104-0, einen Kraftfahrzeug-Mikrocontroller (eine Kfz-MCU) 1104-1, ein Dynamic Random Access Memory (DRAM) 1197, Sensoren 1193, Kfz-Bedienelemente 1195-0, Kfz-Kommunikationssysteme 1195-1 und Kfz-Stromversorgungssysteme 1195-2 umfassen.
  • Bei dem SoC 1104-0 und der ersten NVM-Einrichtung 1102-0 kann es sich um eine Hosteinrichtung und eine korrespondierende NVM-Einrichtung gemäß beliebigen der hierin gezeigten Ausführungsformen handeln. Bei einer Einschalt- oder Power-On-Reset-Bedingung kann das SoC 1104-0 in der ersten NVM-Einrichtung 1102-0 gespeicherten Code gemäß beliebigen der hierin gezeigten Ausführungsformen oder gemäß einem Äquivalent authentifizieren. Analog können die MCU 1104-1 und die zweite NVM-Einrichtung 1102-1 eine Hosteinrichtung und eine korrespondierende NVM-Einrichtung gemäß beliebigen der hierin gezeigten Ausführungsformen oder gemäß Äquivalenten sein.
  • In 12, auf die nunmehr Bezug genommen wird, ist ein Kraftfahrzeug 1291 gemäß einer Ausführungsform in einem Schaubild gezeigt. Das Kraftfahrzeug 1291 kann zahlreiche Teilsysteme (von denen zwei mit den Bezugszeichen 1200-0 und 1200-1 gezeigt sind) aufweisen, die mit aus der NVM-Einrichtung gebooteter Firmware betrieben werden können. Diese Teilsysteme (1200-0, 1200-1) können ein elektronisches Steuergerät (ABS) und/oder ein Fahrerassistenzsystem (ADAS) umfassen. In anderen Ausführungsformen umfassen diese Teilsysteme möglicherweise ein Armaturenbrettanzeige-/Regelungsteilsystem und/oder ein Infotainmentteilsystem, wobei es sich lediglich um zwei von zahlreichen möglichen Beispielen handelt. Jedes Teilsystem (1200-0, 1200-1) kann eine Hosteinrichtung und eine oder mehrere NVM-Einrichtungen umfassen und Firmware-Authentifizierungsvorgänge gemäß der Beschreibung hierin oder gemäß Äquivalenten verwenden.
  • Anhand der obigen Ausführungsformen sind verschiedene Systeme, Einrichtungen und korrespondierende Verfahren gezeigt worden, und es werden nun weitere Verfahren mit Bezug auf Ablaufschemata beschrieben.
  • 13 ist ein Ablaufschema eines Authentifizierungsverfahrens 1391 für eine NVM-Einrichtung gemäß einer Ausführungsform. Das Verfahren 1391 kann umfassen, dass eine NVM-Einrichtung ein Bootauslöseereignis, wie etwa ein Einschalt- oder Power-On-Reset-Ereignis 1391-0, durchläuft. Die NVM-Einrichtung kann eine Authentifizierungsanforderung von einer Hosteinrichtung empfangen 1391-1. Dieser Schritt kann umfassen, dass die NVM-Einrichtung einen vorgegebenen Befehl über eine Kommunikationsverbindung, wie etwa einen seriellen Bus, von einer Hosteinrichtung empfängt, wobei es sich lediglich um eines von vielen möglichen Beispielen handelt.
  • Als Antwort auf die Authentifizierungsanforderung kann die NVM-Einrichtung einen verschlüsselten FW-Integritätswert zurücksenden, dessen Größe von dem Hostcode, den sie validiert, unabhängig ist 1391-3. Der FW-Integritätswert kann zum Validieren von in der NVM-Einrichtung gespeichertem Code (z. B. SW oder FW) genutzt werden. In einigen Ausführungsformen wird der FW-Integritätswert aus einem bekannten authentischen NVM-Codesatz (z. B. einem Hashwert von bekanntem authentischem NVM-Code) generiert. Dieser Schritt kann umfassen, dass die NVM-Einrichtung den FW-Integritätswert über eine Kommunikationsverbindung zurücksendet. Die Hosteinrichtung kann durch die NVM-Einrichtung gespeicherten Code unter Nutzung des FW-Integritätscodes validieren. Weil die Größe des FW-Integritätswerts von der Größe des gespeicherten Codes unabhängig ist, ist eine schnelle und deterministische Authentifizierung möglich.
  • Wenn die Hosteinrichtung den NVM-Code mit dem verschlüsselten gültigen FW-Integritätswert authentifiziert, kann die NVM-Einrichtung eine Leseanforderung für einen Zugriff auf durch die NVM-Einrichtung gespeicherte Host-FW empfangen 1391-5. Die NVM-Einrichtung kann als Antwort auf solche Leseanforderungen FW-Daten senden. In einigen Ausführungsformen umfasst dies, dass Code zur Ausführung durch eine Hosteinrichtung gesendet wird.
  • 14 ist ein Ablaufschema eines Authentifizierungsverfahrens 1491 für eine Hosteinrichtung gemäß einer Ausführungsform. Das Verfahren 1491 kann umfassen, dass die Hosteinrichtung ein Bootauslöseereignis (z. B. ein POR) durchläuft 1491-0.
  • Die Hosteinrichtung kann die NVM-Einrichtung in einem Bus erkennen 1491-1. Dieser Schritt kann umfassen, dass ein Erkennungsprotokoll gemäß einem Kommunikationsstandard ausgeführt wird. Wenn die NVM-Einrichtung erkannt wird, kann bei dem Verfahren 1491 die Authentifizierung der erkannten NVM-Einrichtung initiiert werden 1491-3. Dieser Schritt kann umfassen, dass die Hosteinrichtung Authentifizierungsaufforderungen (z. B. vorgegebene Befehle) über einen Bus oder eine andere geeignete Kommunikationsverbindung an die NVM-Einrichtung ausgibt.
  • Die Hosteinrichtung kann als Antwort auf eine Authentifizierungsanforderung einen verschlüsselten FW-Integritätswert empfangen, dessen Größe von dem Hostcode, den sie validiert, unabhängig ist 1491-5. Der FW-Integritätswert kann zum Validieren von in der NVM-Einrichtung gespeichertem Hostcode (z. B. SW oder FW) genutzt werden. In einigen Ausführungsformen wird ein gültiger FW-Integritätswert aus einem bekannten authentischen NVM-Codesatz (z. B. einem Hashwert von bekanntem authentischem NVM-Code, der durch die NVM-Einrichtung sicher gespeichert wird) generiert. Dieser Schritt kann umfassen, dass die NVM-Einrichtung den gültigen FW-Integritätswert über eine Kommunikationsverbindung zurücksendet. Die Hosteinrichtung kann durch die NVM-Einrichtung gespeicherten Code unter Nutzung des FW-Integritätscodes validieren 1491-7. Weil die Größe des gültigen FW-Integritätswerts von der Größe des gespeicherten Hostcodes unabhängig ist, ist eine schnelle und deterministische Authentifizierung möglich.
  • Wenn die Hosteinrichtung den NVM-Code mit dem verschlüsselten FW-Integritätswert authentifiziert (J bei 1491-7), kann die Hosteinrichtung auf durch die NVM-Einrichtung gespeicherte Host-FW zugreifen 1491-11. Dieser Schritt kann umfassen, dass Leseanweisungen für XiP-Codevorgänge ausgegeben werden. Wenn die Hosteinrichtung den NVM-Code nicht authentifiziert (N bei 1491-7), kann die Hosteinrichtung eine Anzeige eines ungültigen Codes generieren 1491-9. Als Antwort auf eine solche Anzeige lässt sich verhindern, dass die Hosteinrichtung auf die Host-FW zugreift. In einigen Ausführungsformen generiert die Hosteinrichtung einen Bootfehlercode, der anzeigt, dass die Host-FW für ungültig befunden worden ist.
  • 15 ist ein Ablaufschema eines Authentifizierungsverfahrens 1591 zwischen einer NVM-Einrichtung 1502 und einer Hosteinrichtung 1504. Die NVM-Einrichtung 1502 oder die Hosteinrichtung 1504 kann ein Bootereignis (z. B. ein POR) durchlaufen (1591-0H/0N). Als Antwort auf das Booten der NVM-Einrichtung kann die NVM-Einrichtung einen Hashwert für NVM-FW, die sie speichert, (FW Hash_r) generieren 1591-1. Bei der NVM-FW kann es sich um FW handeln, die durch die NVM-Einrichtung ausführbar ist, um NVM-Einrichtungsfunktionen zuzuschalten. Die NVM-FW kann an einem sicheren Ort gespeichert werden, und von Entitäten außerhalb der NVM-Einrichtung kann nicht darauf zugegriffen werden, oder es kann nur über Funktionen für einen sicheren Zugriff darauf zugegriffen werden. Die Hosteinrichtung kann einen Lesebefehl für einen Zugriff auf FW Hash_r an die NVM-Einrichtung senden 1591-2. Als Antwort auf eine solche Leseanforderung kann die NVM-Einrichtung den FW-Hash_r-Wert an die Hosteinrichtung zurücksenden 1591-3.
  • Das Verfahren 1591 kann umfassen, dass die Hosteinrichtung einen Authentifizierungswert von der NVM-Einrichtung anfordert 1591-4. In einigen Ausführungsformen generiert die NVM-Einrichtung als Antwort auf eine solche Anforderung einen Authentifizierungswert unter Nutzung eines gültigen Hashwerts FW Hash 1591-5. Der gültige Hashwert (FW Hash) kann ein Wert sein, der mit einer bekannten authentischen Version der NVM-FW generiert wird. In einigen Ausführungsformen generiert die NVM-Einrichtung den Authentifizierungswert durch eine On-the-fly-Datenverschlüsselung. Diese Verschlüsselung erfolgt entweder symmetrisch (d. h. mit einem geheimen Schlüssel, der ebenfalls durch die Hosteinrichtung gespeichert wird) oder asymmetrisch (d. h. mit einem privaten Schlüssel, der mit einem öffentlichen Schlüssel, der durch die Hosteinrichtung gespeichert wird, korrespondiert). In anderen Ausführungsformen wird hingegen ein Authentifizierungswert (z. B. ein digitales Zertifikat mit einer digitalen Signatur) vorher in die NVM-Einrichtung geladen. Unabhängig davon, ob durch die Hosteinrichtung ein Authentifizierungswert generiert oder vorher in die NVM-Einrichtung geladen wird, kann die NVM-Einrichtung den Authentifizierungscode an die Hosteinrichtung zurücksenden 1591-6.
  • Die Hosteinrichtung kann den gesamten von der NVM-Einrichtung empfangenen Authentifizierungscode oder einen Teil davon entschlüsseln, um den gültigen FW-Hash-Wert abzuleiten 1591-7. Der gültige FW-Hash-Wert kann mit dem aus der NVM-Einrichtung ausgelesenen Hashwert (FW Hash_r) verglichen werden 1591-8, um die NVM-Einrichtung (und folglich eine eventuelle Host-FW, die sie speichert) zu validieren. Das heißt, wenn die Werte übereinstimmen, lässt sich die durch die NVM-Einrichtung gespeicherte Host-FW zur Nutzung durch die Hosteinrichtung authentifizieren. Wenn die Werte nicht übereinstimmen, lässt sich bestimmen, dass die durch die NVM-Einrichtung gespeicherte Host-FW nicht authentifiziert werden kann.
  • 16 ist ein Ablaufschema eines Verfahrens 1691, bei dem eine Hosteinrichtung 1604 NVM-FW in einer NVM-Einrichtung 1602 aktualisiert, gemäß einer Ausführungsform. Das Verfahren 1691 kann umfassen, dass die Hosteinrichtung neue NVM-FW für einen Aktualisierungsvorgang empfängt 1691-0. Dieser Schritt kann beliebige geeignete Verfahren umfassen, die einen Authentifizierungsvorgang zwischen der Hosteinrichtung und der Quelle der neuen NVM-FW umfassen. Die Hosteinrichtung 1602 kann die NVM-Einrichtung und alte FW (durch die NVM-Einrichtung aktuell gespeicherte FW) authentifizieren (1691-1/2). Dieser Vorgang kann beliebige geeignete Verfahren wie etwa diejenigen, die hierin beschrieben werden, oder Äquivalente umfassen. Die Hosteinrichtung 1604 kann die neue NVM-FW in die NVM-Einrichtung schreiben 1691-3. In einigen Ausführungsformen umfasst dieser Schritt das Schreiben eines durch die NVM-Einrichtung ausführbaren NVM-FW-Abbilds.
  • Die NVM-Einrichtung kann die neue NVM-FW sicher speichern 1691-4. Dieser Schritt kann umfassen, dass die NVM-FW an einen vorgegebenen Ort, der durch eine NVM-Einrichtungskonfiguration oder durch die Hosteinrichtung bestimmt wird, geschrieben wird. Die NVM-Einrichtung kann einen neuen Hashwert (FW Hash) für die neue NVM-FW generieren 1691-5. Dieser Wert kann in der NVM 1691-6 zur Nutzung bei künftigen Authentifizierungsvorgängen, wie etwa denjenigen gemäß der Beschreibung hierin oder gemäß Äquivalenten, sicher gespeichert werden. Sobald die neue NVM-FW gespeichert und ein gültiger FW-Hash-Wert generiert worden ist, kann die NVM-Einrichtung eine Bestätigung, dass der NVM-FW-Aktualisierungsvorgang abgeschlossen ist, an die Hosteinrichtung senden 1691-7.
  • Gemäß Ausführungsformen kann eine Hosteinrichtung einen NVM-Einrichtungszustand authentifizieren, um dadurch den durch die NVM-Einrichtung gespeicherten Code zu authentifizieren. Bei einer solchen Verfahrensweise erübrigt sich der Zugriff der Hosteinrichtung auf durch die NVM-Einrichtung gespeicherten Code bei einem Authentifizierungsvorgang, wie er bei herkömmlichen Verfahren erfolgt. Infolgedessen können Systeme sichere Bootzeiten aufweisen, die schnell und von der Größe des durch die NVM-Einrichtung gespeicherten Codes unabhängig sind.
  • Ausführungsformen unterscheiden sich von herkömmlichen Verfahrensweisen insofern, als ein Authentifizierungsmechanismus einer Hosteinrichtung den Zustand einer NVM-Einrichtung und nicht den Zustand von durch die NVM-Einrichtung gespeichertem Hostcode authentifizieren kann. Ferner kann die NVM-Einrichtung einen Mechanismus zum Nachweisen der Integrität des NVM-Codes, den sie aktuell speichert, umfassen. In einigen Ausführungsformen umfasst dies, dass die NVM-Einrichtung sichere Speicherorte zum Speichern von Codeintegritätswerten aufweist, die zum Nachweisen der Integrität von durch die NVM-Einrichtung gespeichertem NVM-Code genutzt werden.
  • Es wird darauf hingewiesen, dass Bezugnahmen in der gesamten vorliegenden Patentbeschreibung auf „eine Ausführungsform“ bedeuten, dass ein betreffendes Merkmal, eine betreffende Struktur oder eine betreffende Eigenschaft, das/die im Zusammenhang mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform der vorliegenden Erfindung umfasst ist. Es ist deshalb unbedingt zu beachten, dass mit zwei oder mehr Bezugnahmen auf „eine Ausführungsform“ oder „eine alternative Ausführungsform“ in verschiedenen Abschnitten dieser Patentbeschreibung nicht immer zwangsläufig auf dieselbe Ausführungsform Bezug genommen wird. Im Übrigen lassen sich die betreffenden Merkmale, Strukturen oder Eigenschaften in einer für eine oder mehrere Ausführungsformen der Erfindung geeigneten Weise kombinieren.
  • Es wird zudem darauf hingewiesen, dass verschiedene Merkmale der Erfindung in der obigen Beschreibung von Ausführungsbeispielen der Erfindung manchmal in einer einzigen Ausführungsform, Figur oder zugehörigen Beschreibung zusammengefasst werden, um die Offenbarung zu straffen und hierdurch ein besseres Verständnis eines oder mehrerer der verschiedenen erfinderischen Aspekte zu vermitteln. Das vorliegende Verfahren der Offenbarung ist jedoch nicht so zu interpretieren, dass darauf abgestellt wird, dass für die Ansprüche mehr Merkmale erforderlich sind als ausdrücklich in jedem Anspruch definiert. Es können nämlich auch weniger als alle Merkmale einer einzelnen der oben offenbarten Ausführungsformen erfinderische Aspekte ausmachen. Mithin werden die Ansprüche, die sich an die ausführliche Beschreibung anschließen, ausdrücklich als ein Bestandteil der ausführlichen Beschreibung in sie aufgenommen, wobei jeder Anspruch als separate Ausführungsform dieser Erfindung für sich allein steht.
  • 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 17122927 [0001]
    • US 63/086750 [0001]

Claims (23)

  1. Ein Verfahren, beinhaltend: Speichern von durch eine Hosteinrichtung ausführbarem Hostcode in einer nichtflüchtigen Speichereinrichtung (NVM-Einrichtung) und durch die NVM-Einrichtung ausführbarem NVM-Code; durch den Betrieb der NVM-Einrichtung: Validieren der Integrität des NVM-Codes als Antwort auf vorgegebene Bedingungen; Generieren eines Codeintegritätswerts zum Validieren des NVM-Codes, wobei der Codeintegritätswert eine Größe aufweist, die von der Größe des Hostcodes unabhängig ist; Senden eines Authentifizierungscodes an die Hosteinrichtung, wobei der Authentifizierungscode mit mindestens dem Codeintegritätswert generiert wird; und als Antwort auf Leseanforderungen von der Hosteinrichtung Zurücksenden mindestens von Abschnitten des Hostcodes zur Ausführung durch die Hosteinrichtung.
  2. Verfahren gemäß Anspruch 1, wobei der Codeintegritätswert einen Hashwert mindestens eines Abschnitts des NVM-Codes beinhaltet.
  3. Verfahren gemäß Anspruch 1, wobei der Codeintegritätswert aus der Gruppe aus Folgendem ausgewählt wird: einem Message Authentication Code (MAC) und einer eindeutigen Gerätekennung.
  4. Verfahren gemäß Anspruch 1, ferner umfassend: durch den Betrieb der NVM-Einrichtung Generieren eines Hashwerts des NVM-Codes; und als Antwort auf eine Anforderung von einer Hosteinrichtung Senden eines mit dem Hashwert generierten Authentifizierungscodes an die Hosteinrichtung.
  5. Verfahren gemäß Anspruch 1, ferner umfassend: durch den Betrieb der NVM-Einrichtung Generieren eines Authentifizierungscodes mit einem für die NVM-Einrichtung spezifischen Wert und mindestens einem Abschnitt des NVM-Codes; und durch den Betrieb der Hosteinrichtung Authentifizieren des Authentifizierungscodes unter Nutzung eines durch die Hosteinrichtung gespeicherten sicheren Werts.
  6. Verfahren gemäß Anspruch 1, ferner umfassend: Empfangen eines Hostnoncewerts an der NVM-Einrichtung; und Ausführen einer kryptografischen Funktion an mindestens dem Hostnoncewert und dem Codeintegritätswert, um den Authentifizierungscode zu generieren.
  7. Verfahren gemäß Anspruch 6, ferner umfassend: Verschlüsseln mindestens des Hostnoncewerts, des Codeintegritätswerts und eines NVM-Einrichtungsnoncewerts, um den Authentifizierungscode zu generieren.
  8. Verfahren gemäß Anspruch 1, ferner umfassend: Speichern eines digitalen Zertifikats in der NVM-Einrichtung, wobei das digitale Zertifikat einen öffentlichen Schlüssel, den Codeintegritätswert und eine mit einem privaten Schlüssel generierte digitale Signatur umfasst; und als Antwort auf eine Zertifikatsanforderung von einer Hosteinrichtung Senden des digitalen Zertifikats an die Hosteinrichtung.
  9. Eine nichtflüchtige Speichereinrichtung (NVM-Einrichtung), beinhaltend: mindestens ein NVM-Array, beinhaltend eine Vielzahl von NVM-Zellen, die konfiguriert sind, um Hostcode zur Ausführung durch eine Hosteinrichtung und NVM-Code zur Ausführung durch die NVM zu speichern; Eingabe-/Ausgabe(E/A)-Schaltungen, die konfiguriert sind, um über mindestens eine Kommunikationsverbindung mit einer Hosteinrichtung zu kommunizieren; einen Speicherbereich, der konfiguriert ist, um einen Codeintegritätswert zum Validieren des NVM-Codes zu speichern, wobei der Codeintegritätswert eine Größe aufweist, die von der Größe des Hostcodes unabhängig ist; und einen NVM-Controllerteil, der für Folgendes konfiguriert ist: beim Starten der NVM-Einrichtung Validieren der Integrität des NVM-Codes und als Antwort auf eine Anforderung von der Hosteinrichtung Ausgeben eines Authentifizierungscodes über die E/A-Schaltungen, wobei der Authentifizierungswert mit mindestens dem Codeintegritätswert generiert wird; wobei das mindestens eine NVM-Array, die E/A-Schaltungen, der Speicherbereich und der Controllerteil mit einem selben Substrat einer integrierten Schaltung gebildet sind.
  10. NVM-Einrichtung gemäß Anspruch 9, wobei der NVM-Controllerteil mindestens einen Prozessor beinhaltet, der konfiguriert ist, um NVM-Einrichtungsprozessoranweisungen auszuführen.
  11. NVM-Einrichtung gemäß Anspruch 9, wobei der NVM-Controllerteil einen Hashwertgenerator umfasst, der konfiguriert ist, um einen Hashwert aus dem NVM-Code zu generieren.
  12. NVM-Einrichtung gemäß Anspruch 9, wobei der NVM-Controllerteil kryptografische Schaltungen umfasst, die konfiguriert sind, um mindestens den Codeintegritätswert mit einem vorgegebenen Verschlüsselungsschlüssel zu generieren.
  13. NVM-Einrichtung gemäß Anspruch 12, wobei die kryptografischen Schaltungen Schaltungen für die asymmetrische Kryptografie umfassen und der vorgegebene Verschlüsselungsschlüssel einen privaten Schlüssel, der mit einem öffentlichen Schlüssel korrespondiert, umfasst.
  14. NVM-Einrichtung gemäß Anspruch 9, wobei der NVM-Controllerteil einen Noncewertgenerator umfasst.
  15. NVM-Einrichtung gemäß Anspruch 9, wobei der NVM-Controllerteil eine Authentifizierungsschaltung umfasst, die konfiguriert ist, um einen Message Authentication Code (MAC), der mindestens den Codeintegritätswert umfasst, zu generieren, und der NVM-Controllerteil konfiguriert ist, um den MAC an die Hosteinrichtung zu senden.
  16. NVM-Einrichtung gemäß Anspruch 9, ferner umfassend, dass das mindestens eine NVM-Array einen sicheren Speicherbereich umfasst, der konfiguriert ist, um Zugriff auf darin gespeicherten NVM-Code nur als Antwort auf mindestens eine Prozedur für einen sicheren Zugriff zu gewähren.
  17. Ein System, beinhaltend: eine nichtflüchtige Speichereinrichtung (NVM-Einrichtung), die Folgendes umfasst: mindestens ein NVM-Zellenarray, das konfiguriert ist, um durch eine Hosteinrichtung ausführbaren Code und durch die NVM-Einrichtung ausführbaren NVM-Code zu speichern, eine NVM-Controllerschaltung, die für Folgendes konfiguriert ist: beim Starten der NVM-Einrichtung Validieren der Integrität des NVM-Codes und Ausgeben eines Authentifizierungscodes, der generiert wird, indem eine kryptografische NVM-Funktion an einem Codeintegritätswert ausgeführt wird, wobei der Codeintegritätswert eine Größe aufweist, die von der Größe des Hostcodes unabhängig ist; wobei die Hosteinrichtung mindestens einen Hostprozessor umfasst, der für Folgendes konfiguriert ist: Ausführen einer kryptografischen Hostfunktion als Antwort auf den Authentifizierungscode, um die NVM-Einrichtung und durch die NVM-Einrichtung gespeicherten Hostcode zu authentifizieren, und Ausführen des durch die NVM-Einrichtung gespeicherten Hostcodes.
  18. System gemäß Anspruch 17, wobei das mindestens eine NVM-Zellenarray ein NOR-Flasharray beinhaltet.
  19. System gemäß Anspruch 17, wobei der mindestens eine Hostprozessor ferner konfiguriert ist, um einen Hostnoncewert zur Übertragung an die NVM-Einrichtung zu generieren.
  20. System gemäß Anspruch 17, wobei der mindestens eine Hostprozessor ferner für Folgendes konfiguriert ist zum Zugreifen auf einen Hostschlüssel und Ausführen einer kryptografischen Funktion mit dem Hostschlüssel als Antwort auf das Empfangen der Authentifizierung.
  21. System gemäß Anspruch 17, wobei der Hostprozessor über einen Bus mit der NVM-Speichereinrichtung gekoppelt ist.
  22. System gemäß Anspruch 17, wobei die Hosteinrichtung konfiguriert ist, um den Hostcode direkt aus der NVM-Einrichtung auszuführen.
  23. System gemäß Anspruch 17, wobei die Hosteinrichtung und die NVM-Einrichtung zu einem Teilsystem in einem Kraftfahrzeug gehören.
DE112021005155.5T 2020-10-02 2021-10-01 Verfahren zum schnellen, sicheren booten aus einer nichtflüchtigen speichereinrichtung und korrespondierende systeme und einrichtungen dafür Pending DE112021005155T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202063086750P 2020-10-02 2020-10-02
US63/086,750 2020-10-02
US17/122,927 2020-12-15
US17/122,927 US11809566B2 (en) 2020-10-02 2020-12-15 Methods for fast, secure boot from nonvolatile memory device and corresponding systems and devices for the same
PCT/US2021/053138 WO2022072810A1 (en) 2020-10-02 2021-10-01 Methods for fast, secure boot from nonvolatile memory device and corresponding systems and devices for the same

Publications (1)

Publication Number Publication Date
DE112021005155T5 true DE112021005155T5 (de) 2023-08-10

Family

ID=80931406

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021005155.5T Pending DE112021005155T5 (de) 2020-10-02 2021-10-01 Verfahren zum schnellen, sicheren booten aus einer nichtflüchtigen speichereinrichtung und korrespondierende systeme und einrichtungen dafür

Country Status (5)

Country Link
US (1) US11809566B2 (de)
JP (1) JP2023544050A (de)
CN (1) CN116324992A (de)
DE (1) DE112021005155T5 (de)
WO (1) WO2022072810A1 (de)

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8104085B2 (en) 2003-06-27 2012-01-24 Oracle America, Inc. Hybrid system implementing distinct and co-existing application execution environments and methods for implementing the same
US20080082819A1 (en) * 2006-09-28 2008-04-03 Jack Brizek Authenticating data returned from non-volatile memory commands
IL187044A0 (en) * 2007-10-30 2008-02-09 Sandisk Il Ltd Fast secure boot implementation
KR101642819B1 (ko) 2009-08-31 2016-07-26 삼성전자주식회사 비휘발성 메모리 장치, 그것의 구동 방법, 그것을 포함하는 메모리 시스템
US9612979B2 (en) * 2010-10-22 2017-04-04 Intel Corporation Scalable memory protection mechanism
US8866213B2 (en) 2013-01-30 2014-10-21 Spansion Llc Non-Volatile memory with silicided bit line contacts
US9613214B2 (en) 2013-07-09 2017-04-04 Micron Technology, Inc. Self-measuring nonvolatile memory devices with remediation capabilities and associated systems and methods
US20170063853A1 (en) 2015-07-10 2017-03-02 Infineon Technologies Ag Data cipher and decipher based on device and data authentication
KR101887974B1 (ko) * 2016-12-01 2018-08-13 현대오트론 주식회사 엔진제어기의 안전부팅을 위한 시스템 및 방법
TWI647610B (zh) * 2017-11-14 2019-01-11 慧榮科技股份有限公司 認證韌體資料之資料儲存裝置與資料儲存方法
US11347861B2 (en) * 2018-04-10 2022-05-31 Raytheon Company Controlling security state of commercial off the shelf (COTS) system
US10956576B2 (en) * 2018-09-06 2021-03-23 Micron Technology, Inc. Secure boot via system and power management microcontroller
US11106796B2 (en) * 2018-11-07 2021-08-31 Dell Products L.P. Staging memory for accessory firmware update
US20220021544A1 (en) * 2020-07-15 2022-01-20 Micron Technology, Inc. Secure Serial Peripheral Interface (SPI) Flash

Also Published As

Publication number Publication date
JP2023544050A (ja) 2023-10-19
US20220108016A1 (en) 2022-04-07
WO2022072810A1 (en) 2022-04-07
CN116324992A (zh) 2023-06-23
US11809566B2 (en) 2023-11-07

Similar Documents

Publication Publication Date Title
US20240037045A1 (en) Apparatuses and methods for securing an access protection scheme
DE102015209116A1 (de) Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
CN110502932B (zh) 处理系统、相关集成电路和方法
DE102015209108A1 (de) Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
US8671242B2 (en) Boot block features in synchronous serial interface NAND
CN107797827A (zh) 安全储存系统以及用于安全储存的方法
US20220286274A1 (en) Local ledger block chain for secure updates
DE102009013384A1 (de) System und Verfahren zur Bereitstellung einer sicheren Anwendungsfragmentierungsumgebung
US9092322B2 (en) Processor system and control method thereof
CN107092833B (zh) 用于处理数据的组件和用于实施安全功能的方法
US11271720B2 (en) Validating data stored in memory using cryptographic hashes
US11914718B2 (en) Secured boot of a processing unit
US20220272090A1 (en) Validating an electronic control unit of a vehicle
EP3432190B1 (de) Verarbeitungssystem und integrierter schaltungschip für passwortverwaltung
DE112021005155T5 (de) Verfahren zum schnellen, sicheren booten aus einer nichtflüchtigen speichereinrichtung und korrespondierende systeme und einrichtungen dafür
US20230010319A1 (en) Deriving independent symmetric encryption keys based upon a type of secure boot using a security processor
JP2020149236A (ja) 電子機器及び電子機器の制御方法
DE102013223234A1 (de) Zugriff auf einen Speicher
DE102022202691A1 (de) Verfahren zur Durchführung einer abgesicherten Startsequenz einer Recheneinheit
DE102023133660A1 (de) Verfahren, vorrichtungen und systeme mit authentifizierten speichervorrichtungszugriffstransaktionen
JP2023178262A (ja) セキュアな証明書認証を用いた書き込み保護機能
CN117271232A (zh) 处理系统、相关集成电路、设备和方法
CN117171824A (zh) 具有安全证书认证的写保护功能
DE102022209628A1 (de) Verfahren zum Überprüfen von Daten in einer Recheneinheit
JP2022107288A (ja) 自動車用電子制御装置

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R083 Amendment of/additions to inventor(s)