WO2018153559A1 - Verfahren und validierungseinheit zum steuern des ladens von in it-systemen, insbesondere eingebetteten systemen, benutzbaren krypto-schlüsseln, insbesondere "key blobs" - Google Patents

Verfahren und validierungseinheit zum steuern des ladens von in it-systemen, insbesondere eingebetteten systemen, benutzbaren krypto-schlüsseln, insbesondere "key blobs" Download PDF

Info

Publication number
WO2018153559A1
WO2018153559A1 PCT/EP2018/050611 EP2018050611W WO2018153559A1 WO 2018153559 A1 WO2018153559 A1 WO 2018153559A1 EP 2018050611 W EP2018050611 W EP 2018050611W WO 2018153559 A1 WO2018153559 A1 WO 2018153559A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
crypto
khwe
hardware unit
unit
Prior art date
Application number
PCT/EP2018/050611
Other languages
English (en)
French (fr)
Inventor
Christian Peter Feist
Dominik Merli
Original Assignee
Siemens Aktiengesellschaft
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 Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2018153559A1 publication Critical patent/WO2018153559A1/de

Links

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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits

Definitions

  • Method and validation unit for controlling the loading of cryptographic keys that can be used in IT systems, in particular embedded systems, in particular "key blobs"
  • the invention relates to a method for controlling the loading of in IT systems, in particular embedded systems, usable crypto keys, in particular "Key BLOBs", according to the preamble of claim 1 and a validation ⁇ tion unit for controlling the loading of IT systems, embedded into ⁇ special systems, encryption keys, in particular "Key BLOBs", according to the preamble of Patentanspru ⁇ ches 10th
  • IT systems Integrated cryptographic protection for components of information technology systems, so-called IT systems, is required to prevent attacks (e.g., tampering, spying, etc.) against the information security of such systems.
  • attacks e.g., tampering, spying, etc.
  • An IT system is an electronically-data-processing Sys ⁇ tem to which because VNA-based (based on the basis of a Von Neumann architecture), for example, any type of distributed systems and embedded systems, but based on a Harvard architecture electronically Data processing systems, individual computers, mainframe computers, high-performance computers, etc., in some cases including communication systems and the Internet in its entirety.
  • VNA-based based on the basis of a Von Neumann architecture
  • a Harvard architecture electronically Data processing systems, individual computers, mainframe computers, high-performance computers, etc., in some cases including communication systems and the Internet in its entirety.
  • Crypto-modules that are integrated in the main processors, used to provide the necessary for the implementation of cryptographic protection rule cryptographic operations si ⁇ insurers or run faster to when this is the case with the software-based implementation.
  • TPMs Trusted Platform Modules
  • Intel® e.g. Intel®
  • crypto processors or co-processors such as the
  • CAA module “Cryptographic Acceleration and Assurance” module (CAA module) of the "i. MXX” processor system of NXP Semiconductors®.
  • crypto-hardware units allow the storage of secret ones
  • Keys in their built-in non-volatile memory are usually sufficient only for a very small number of keys.
  • Others allow keys to be stored in dedicated, built-in volatile key storages. In this case, the keys must be stored externally and loaded into the crypto hardware unit at runtime.
  • Image can be signed. They are therefore usually created in egg ⁇ ner initialization phase of the processor system in the pro ⁇ production. In addition, since firmware-images specific to the processor system are usually not possible for practical reasons, the "key blobs" must then be stored outside the image. As a result, they would no longer be subject to the protection of "Secure Boot".
  • the CAA module allows (crypto module) of the "i .MX6" -Prozessorsystems for example, that when He ⁇ generation of a "Key BLOBs" a chosen by the manufacturer, a so-called “key modifiers", the CAA Module is loaded. This "key modifiers" is separated from “Key BLOB” ge ⁇ stores and should also be changed in the update of "Key BLOBs”.
  • the problem underlying the invention is to provide a method and a validation unit for controlling the loading of IT systems, in particular embedded systems, usable crypto keys, in particular "key BLOBs", in which a manipulated loading the crypto key, in particular the "key blob”, for example as ⁇ by that the externally stored "key BLOBs” generated by obsolete “key blob” or a hacker attack on the system by the aggressor (hacker) "key BLOBs "can be exchanged, which provides the opportunity for the attacker (hacker) to bring in keys that help him in the ongoing hacker attack on the system to prevent.
  • the validity check of whether the cryptographic key is valid is done in particular before the crypto key is used in the crypto hardware unit and is used by a system-specific application software.
  • the core element of the invention according to claim 1 is a validity check method that is compatible with the loading process of the crypto-processor.
  • Key in particular of the "key BLOB” is upstream, and according to claim 10, a validation unit, which is the crypto-hardware unit into which the crypto-key, in particular ⁇ the special "key BLOB" is to be loaded upstream.
  • the validation unit can be integrated in an operating system kernel, implemented as a signed kernel module (claim 19) or as a digital circuit of a "field programmable gate array" -based circuit, in short Called FPGA circuit, (claim 20) can be realized.
  • "Secure Boot” should possibly protect the operating system kernel and / or the bitstream of the FPGA circuit from manipulation. Direct access to the crypto hardware unit, past the validation unit, should not be possible.
  • the crypto-key in particular the "Key BLOBs", the "positive list
  • the crypto keys in particular the "key BLOBs”
  • both new private signature keys and new public verification keys are generated in pairs
  • the public verification keys updated Siert by the new public verification key and inte ⁇ grated / stored particularly in the validation unit as well as all crypto-key, especially all "key BLOBs”, ie both new crypto-key, in particular ⁇ sondere new "key BLOBs”, as also the changed crypto keys, in particular the changed "key BLOBs", signed with the new private signature keys corresponding to the new public verification keys (see claims 5 and 14).
  • test variant (II) is that the public verification keys can / be stored in the integrated validation ⁇ unit, without the
  • Krypto keys in particular the "Key BLOBs” to know.
  • the (processor system specific) crypto keys in particular "key BLOBs” must later be signed with the appropriate private signature keys.
  • the match indicates that the metadata does not match the reference metadata, e.g. a metadata-specific version number is older than a reference metadata-specific version number
  • the respective private signature key ⁇ "private key”> is not accepted, which is why the crypto key signed with this private signature key ⁇ "private key”>,
  • the signed "key BLOB" is not forwarded to the crypto hardware unit for loading.
  • the crypto keys are, in particular in pairs so ⁇ probably new private signing key and new public che verification key generated , the metadata, preferably ⁇ the version numbers, the generation data, etc., in the second "white list (whitelist)" adjusted and integrated in particular in the validation / stored and new crypto keys, especially new "key BLOBs" with the public Verification keys corresponding private signature keys and the adapted metadata, preferably the adapted version numbers, the adapted generation data, etc., signed (see claims 7 and 16).
  • the (processor system-specific) crypto keys in particular the "key BLOBs", however, must later be signed with the private signature keys corresponding to the public verification keys and the adapted metadata, preferably the adapted version numbers, the adapted generation data etc., provided and signed.
  • the validity test is carried out on the basis of a CHALLENGE RESPONSE procedure with CHALLENGE-RESPONSE pairs of numbers contained in a third "whitelist".
  • a crypto key in particular "Key BLOB”
  • a predetermined crypto operation based on a CHALLENGE-RESPONSE number pair selected from the third "whitelist", preferably an encryption, with the loaded crypto key and a CHALLENGE number of the selected CHALLENGE RESPONSE number pair.
  • the loaded crypto-key is considered valid, preferably stored in the crypto-hardware unit, otherwise the loaded crypto-key becomes Invalid classified / viewed, and before ⁇ preferably removed from the crypto hardware unit or denied access to the crypto hardware unit.
  • the third "positive list of the crypto key in particular of the "Key BLOB”
  • the advantage of this test variant (IV) is that the crypto keys, in particular the "key BLOBs”, need not be changed (for example, signed) and that no public key cryptography is necessary. Furthermore, the CHALLEENGE RESPONSE number pairs can be calculated solely by knowing the key encrypted in the crypto key, in particular in the "key BLOB”. The crypto key, in particular "key BLOB”, itself can therefore be processor system-specific and therefore needs to be generated during its production.
  • FIGS. 1 and 2 show:
  • FIGURE 1 is a from crypto processor and validation unit ge ⁇ formed first functional unit for controlling the charging of IT systems, in particular embedded systems, usable cryptographic keys, in particular "key blob"
  • FIGURE 2 is a from encryption module and validation unit gebil ⁇ finished second functional unit for controlling the charging of IT systems, in particular embedded systems, usable cryptographic keys, in particular "key blob.”
  • FIGURE 1 shows one of a as a crypto-processor CPC out ⁇ formed crypto hardware unit KHWE and a validation ⁇ unit VDE formed first functional unit RTD 1 to STEU ⁇ ren of loading in an IT system ITS, preferably as an embedded system EBS is formed, nutzba ⁇ ren, preferably in the form of "Key BLOBs" or "Wrapped Keys” formed, crypto-keys KS-A ... KS-X.
  • the first function ⁇ unit FTE-1 results in / for the IT system ITS, EBS, that system based cryptographic operations, the (prior art) of the crypto hardware unit KHWE or from the bis- forth Crypto processor KPZ have been executed.
  • the starting point for loading the crypto key and "Key BLOBs" KS-A ... KS-X is in the IT system ITS, EBS system- ⁇ -specific application software ASW with several, each ei ⁇ nen separate crypto key or "Key BLOB" KS-A, KS-B, ... KS-X of the usable cryptographic keys KS-A ... KS-X or "Key BLOBs” assigned / containing software applications (SW applications) SW-A, SW-B, ... SW-X. Each of these software applications (SW) applications SW-A, SW-B, SW-X ...
  • validation unit VDE engages indirectly via validation unit VDE, (and no longer UNMIT ⁇ telbar as in the prior art) to the crypto hardware unit KHWE or the crypto processor KPZ, which acts as a co-processor to a main processor, not shown in FIG.
  • the corresponding crypto key or "key BLOB" KS-A... KS-X is to be stored in the crypto hardware unit KHWE or KHWE . be loaded into the crypto processor KPZ.
  • this loading does not happen as in the prior art directly, but with the interposition of the validation unit VDE.
  • this validation unit VDE becomes the crypto-key or the "Key BLOß" KS-A ... KS-X before being loaded into the crypto hardware unit KHWE or into the crypto processor KPZ for validity.
  • the validation unit VDE points out:
  • a control device STE which is connected to the crypto interface KSS and the software interface SWSS and there ⁇ forming a functional unit is designed such that on the made via the software interface SWSS access each SW applications SW-A ... SW-X of the system-specific application software ASW the crypto key to be loaded with the access or "Key BLOß" KS-A ... KS-X in the
  • Control unit STE is checked for validity before the crypto key or "key BLOß" KS-A ... KS-X KS-A ... KS-X via the crypto interface KSS in the crypto hardware unit KHWE or loaded into the crypto processor KPZ.
  • the control device STE (i) contains a non-volatile, readable memory SP in which computer-readable control program instructions of a program controlling the loading. PGM module is stored, and (ii) an affiliated with the SpeI ⁇ cher SP arithmetic unit RW that the Steuerprogrammbe ⁇ lack of the program module PGM executes.
  • the validation unit VDE shown in FIG. 1 may preferably - in a first embodiment - as a
  • validation unit VDE is either integrated into the operating system kernel or implemented as signed Ker ⁇ nel module.
  • the function of the controller STE and the functionality of the controller STE repre sented ⁇ by the program module PGM exporting rake ⁇ factory RW and the program module PGM storing memory SP is applied in this first embodiment by the main processor.
  • validation ⁇ approximation unit VDE can again preferably - in a second off ⁇ guide die - as a digital circuit of an FPGA circuit of the IT system ITS, EBS with the belonging to the IT system ITS, EBS Governing main Processor and the crypto processor KPZ be formed.
  • test variants (I)... (IV) test variants (I)... (IV)] that can be carried out in the course of the execution of the system-related cryptographic operations.
  • a first variant (I) for checking the validity of the crypto key or "key BLOSS" KS-A ... KS-X the memory SP and the arithmetic unit RW executing the program module PGM are embodied in the control unit STE that on the Ba ⁇ sis a hash function mapping
  • the memory SP and the arithmetic unit RW executing the program module PGM are further embodied in the control unit STE such that upon a change / exchange, in particular during a crypto key update, the crypto Key or
  • the second test variant (II) are the SpeI ⁇ cher SP and the program module PGM executing arithmetic unit RW in the control unit STE further configured such that when a modification / replacement of the encryption key "Key BLOB" KS- A ... KS-X pairs both a new private Sig ⁇ natur key and a new public verification key are generated, the public verification key is updated by the new public verification key and both a new crypto key or "Key BLOB" as well as the modified crypto key or "key BLOB” with the new corresponding to the new public verification key private signature key sig ⁇ ned.
  • the memory SP and the arithmetic unit RW executing the program module PGM are embodied in the control unit STE that on the Ba ⁇ sis an extended digital signature
  • a fourth variant (IV) for checking the validity of the crypto key or "key BLOB" KS-A ... KS-X the spoke SP and the arithmetic unit RW executing the program module PGM are embodied in the control unit STE in that based on a CHALLENGE RESPONSE procedure with in the memory SP in a third "whitelist" stored CHAL ⁇ LENGE RESPONSE number pairs
  • KHWE crypto hardware unit
  • Krypto key or "key BLOß" KS-A ... KS-X is validated ⁇ considered / viewed, and preferably stored in the crypto hardware unit KHWE or in the crypto processor KPZ is.
  • the memory SP and the arithmetic unit RW executing the program module PGM are furthermore embodied in the control unit STE such that in the event of a change / replacement, in particular in the case of a crypto key update, of the crypto key or "key BLOß" KS-A ... KS-X the third "positive list
  • FIG. 2 shows a second functional unit FTE-2 formed from a crypto-hardware unit KHWE designed as a crypto module KM and a validation unit VDE for controlling the loading of an IT system ITS, which is preferably embodied as an embedded system EBS.
  • an IT system ITS which is preferably embodied as an embedded system EBS.
  • EBS embedded system
  • the secondmetsein ⁇ integral RTD 2 leads in / for the IT system ITS, EBS, that system based cryptographic operations which previously (according to the prior art) of the crypto hardware unit KHWE or from the crypto Module KM have been executed.
  • the corresponding cryptographic key or "key BLOB” KS-A ... KS-X is to be transferred to the crypto hardware unit KHWE or to the crypto hardware unit KHWE . loaded into the crypto module KM who ⁇ .
  • this loading does not happen again as in the prior art directly, but with the interposition of the validation unit VDE.
  • the cryptographic key or the "key BLOSSESS" KS-A ... KS-X is checked for validity before being loaded into the crypto hardware unit KHWE or into the crypto module KM.
  • the validation unit VDE points out:
  • a control device STE which is connected to the crypto interface KSS and the software interface SWSS and there ⁇ forming a functional unit is designed such that on the made via the software interface SWSS access each SW applications SW-A ... SW-X of the system-specific application software ASW the crypto key to be loaded with the access or "Key BLOß" KS-A ... KS-X in the
  • Control unit STE is checked for validity before the crypto key or "key BLOß" KS-A ... KS-X KS-A ... KS-X via the crypto interface KSS in the crypto hardware unit KHWE or is loaded into the crypto module KM.
  • the control device STE (i) contains a non-volatile, readable memory SP in which computer-readable control program instructions of a program controlling the loading. PGM module is stored, and (ii) an affiliated with the SpeI ⁇ cher SP arithmetic unit RW that the Steuerprogrammbe ⁇ lack of the program module PGM executes.
  • the validation unit shown in FIGURE 2 VDE and the crypto module KM can preferably - in a Favor ⁇ th embodiment - as components of an operating system kernel of the IT system ITS, EBS with the IT system ITS, EBS belonging to the main processor HPZ be trained.
  • This case designed as a software module second functional ⁇ unit FTE-2, ie the validation unit VDE and the
  • Krypto module KM is either integrated in the operating system kernel or implemented as a signed kernel module.
  • the function of the control device STE and the functionality of the control device STE represented by the program module PGM exporting arithmetic unit RW and the program module PGM storing memory SP is exercised in this first embodiment by the main processor HPZ.
  • test variants (I)... (IV) test variants (I)... (IV)] that can be carried out in the course of the execution of the system-related cryptographic operations.
  • a first variant (I) for checking the validity of the crypto key or "key BLOSS" KS-A ... KS-X the memory SP and the arithmetic unit RW executing the program module PGM are embodied in the control unit STE that on the Ba ⁇ sis a hash function mapping
  • Krypto key or "key BLOB” KS-A ... KS-X with a hash value of the reference crypto key in the first "positive ⁇ list (whitelist)" thus agrees in the "positive list (whitelist)” included is that then the crypto-key or "Key BLOß” KS-A ... KS-X is loaded into the crypto hardware unit KHWE or into the crypto module KM.
  • the memory SP and the arithmetic unit RW executing the program module PGM are further embodied in the control unit STE such that upon a change / exchange, in particular during a crypto key update, the crypto -Key or "key BLOß" KS-A ... KS-X the first "whitelist" for a new crypto key or "key BLOB" is updated.
  • the memory SP and the arithmetic unit RW executing the program module PGM are embodied in the control unit STE that on the Ba ⁇ sis of a digital signature
  • the second test variant (II) are the SpeI ⁇ cher SP and the program module PGM executing arithmetic unit RW in the control unit STE further configured such that when a modification / replacement of the encryption key "Key BLOB" KS- A ... KS-X pairs both a new private Sig ⁇ natur key and a new public verification key are generated, the public verification key is updated by the new public verification key and both a new crypto key or "Key BLOB" as well as the modified crypto key or "key BLOB” with the new corresponding to the new public verification key private signature key sig ⁇ ned.
  • the processor system is a Linux system with "Secure Boot” on an “i. MX6" processor (including CAA crypto co-processor and Secure Memory Store with “Key BLOB” load function) from Freescale®.
  • the validation unit is designed as a signed Linux kernel module and contains an ECC public key (Elliptic Curve Cryptography).
  • KS-A for checking the validity of the crypto key or "key BLOB"
  • KS-A for checking the validity of the crypto key or "key BLOB"
  • KS-A for checking the validity of the crypto key or "key BLOB"
  • KS-A for checking the validity of the crypto key or "key BLOB"
  • KS-A for checking the validity of the crypto key or "key BLOB"
  • KS-A for checking the validity of the crypto key or "key BLOB"
  • KS-X are the memory SP and the program module PGM exporting arithmetic unit RW in the control unit STE formed such that on the Ba ⁇ sis an extended digital signature
  • KS-X including crypto-key-specific metadata, preferably a version number, a creation date, etc., with a private signature key ⁇ "private key” > is signed,
  • the SpeI ⁇ cher SP and the program module PGM executing arithmetic unit RW in the control unit STE are further formed such that in a modification / replacement, particularly at a crypto-key Update, the crypto key or "key BLOB" KS-A ... KS-X, in particular both a new private signature key and a new public ⁇ Verification Verification key are generated in pairs, the metadata in the second "whitelist" and a new crypto key is signed with the private signature key corresponding to the public verification key and the adapted metadata.
  • the validation unit is implemented as a digital circuit in an FPGA module and contains ECC Public Key (Elliptic
  • the signature is verified first and the version number is checked. Only if the signature verification was successful and the version number matches that of the validation unit will the "Key BLOB" be loaded into the Trust Anchor.
  • a fourth variant (IV) for checking the validity of the cryptographic key or "key BLOB" KS-A ... KS-X the memory SP and the arithmetic unit RW executing the program module PGM are embodied in the control unit STE that on the Ba ⁇ sis a challenge-response procedure with in the memory SP in a third "whitelist" saved CHALLENGE RESPONSE number pairs
  • KHWE crypto hardware unit
  • Krypto key or "key BLOß" KS-A ... KS-X is validated ⁇ considered / viewed, and preferably stored in the crypto hardware unit KHWE or in the crypto module KM is.
  • the SpeI ⁇ cher SP and the program module PGM executing arithmetic unit RW in the control unit STE are further formed such that, at a modification / replacement, particularly at a crypto-key update- of the crypto key or "key BLOß" KS-A ... KS-X the third "positive list
  • the validation unit loads the "Key BLOB” or “Wrapped Key” to be loaded into the “Trusted Platform Module (TPM)” and thus calculates a “keyed-hash message authentication code (HMAC)" from the stored CHALLENGE.
  • TPM Trusted Platform Module
  • the HMAC result is compared with the stored RESPONSE; in case of equality of the key in the "Trusted Plat ⁇ form Module (TPM)" is left, this is removed again from the “Trusted Platform Module (TPM)” represented by inequality.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

Verfahren und Validierungseinheit zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere "Key BLOBs" Um ein manipuliertes Laden der Krypto-Schlüssel, insbesondere der "Key BLOBs", beispielsweise dadurch, dass die extern abgelegten "Key BLOBs" durch veraltete "Key BLOBs" oder bei einem Hacker-Angriff auf das System von dem Angreifer (Hacker) generierte "Key BLOBs" ausgetauscht werden können, womit sich die Möglichkeit für den Angreifer (Hacker) ergibt, Schlüssel einzubringen, die ihm beim weitergehenden Hacker-Angriff auf das System behilflich sind, zu verhindern, wird es vorgeschlagen, dass zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren und in einer Krypto-Hardwareeinheit (KHWE) ladbaren Krypto-Schlüsseln, insbesondere "Key BLOBs", der Krypto-Schlüssel vor dem Laden in die Krypto-Hardwareeinheit KHWE) auf Validität geprüft wird. Die Validitätsprüfung, ob der der Krypto-Schlüssel valide ist, geschieht dabei insbesondere bevor der Krypto-Schlüssel in der Krypto-Hardwareeinheit (KHWE) verwendet und durch eine systemspezifische Anwendungssoftware (ASW) genutzt wird.

Description

Beschreibung
Verfahren und Validierungseinheit zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutz- baren Krypto-Schlüsseln, insbesondere "Key BLOBs"
Die Erfindung bezieht sich auf ein Verfahren zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere "Key BLOBs", gemäß dem Oberbegriff des Patentanspruches 1 und eine Vali¬ dierungseinheit zum Steuern des Ladens von IT-Systemen, ins¬ besondere Eingebetteten Systemen, Krypto-Schlüsseln, insbesondere "Key BLOBs", gemäß dem Oberbegriff des Patentanspru¬ ches 10.
Ein integrierter kryptographischer Schutz für Komponenten von Informationstechnischen Systemen, so genannten IT-Systemen ist erforderlich, um Angriffe (z.B. Manipulation, Ausspähen etc.) gegen die Informationssicherheit solcher Systeme abzu- wehren.
Ein IT-System ist ein elektronisch-datenverarbeitendes Sys¬ tem, zu dem weil VNA-basierend (beruht auf der Basis einer Von-Neumann-Architektur) z.B. jegliche Art von Verteilten Systemen und Eingebetteten Systemen, aber auch auf einer Harvard-Architektur basierende elektronisch-datenverarbeitende Systeme, einzelne Computer, Großrechner, Hochleistungsrechner etc., teilweise auch Kommunikationssysteme sowie das Internet in seiner Gesamtheit zu zählen sind.
Die Implementierung des kryptografischen Schutzes in die genannten IT-Systeme erfolgt bislang überwiegend softwareba¬ siert. In letzter Zeit kommen aber insbesondere in Eingebet¬ teten Systemen immer mehr leistungsfähigere, hochintegrierte Prozessorsysteme mit Krypto-Hardwareeinheiten, vorzugsweise Krypto-Prozessoren, die als Co-Prozessoren zu in dem Prozessorsystem vorhandenen Haupt-Prozessoren fungieren, oder
Krypto-Module, die in den Haupt-Prozessoren integriert sind, zum Einsatz, um die für die Implementierung des kryptografi- schen Schutzes notwendigen kryptographische Operationen si¬ cherer oder schneller ausführen zu können als dieses bei der softwarebasierten Implementierung der Fall ist.
Beispiele für solche Krypto-Hardwareeinheiten sind Trusted Platform Modules (TPMs) , z.B. von Infineon® oder Intel®, oder aber Krypto-Prozessoren bzw. Co-Prozessoren, wie das
"Cryptographic Acceleration and Assurance"-Modul (CAA-Modul) des "i .MX6"-Prozessorsystems von NXP Semiconductors® .
Manche dieser Krypto-Hardwareeinheiten (Krypto-Prozessoren oder Krypto-Module) erlauben das Speichern von geheimen
Schlüsseln in ihrem integrierten nicht-flüchtigen Speicher, jedoch ist dieser meist nur für eine sehr kleine Anzahl von Schlüsseln ausreichend. Andere ermöglichen das Ablegen von Schlüsseln in dedizierten, integrierten flüchtigen Schlüsselspeichern. In diesem Fall müssen die Schlüssel extern gespeichert und zur Laufzeit in die Krypto-Hardwareeinheit geladen werden.
Um jedoch Schlüssel auch extern, also außerhalb der Krypto- Hardwareeinheit, sicher speichern zu können, werden diese mit einem internen Schlüssel verschlüsselt und extern als soge- nannte "Key BLOBs" oder "Wrapped Keys" abgelegt. Beim Einle¬ sen wird der "Key BLOB" entschlüsselt und steht anschließend der Krypto-Hardwareeinheit zur Verfügung.
Daraus ergibt sich jedoch das Problem, dass die extern abge- legten "Key BLOBs" durch veraltete "Key BLOBs" oder von einem Angreifer generierte "Key BLOBs" ausgetauscht werden können.
So ergibt sich die Möglichkeit für den Angreifer Schlüssel einzubringen, die ihnen beim Angriff auf das IT-System wei- terhelfen können, was es zu verhindern gilt.
Bisher wurden "Key BLOBs" eher selten eingesetzt, da es kaum Chips gab, die eine Krypto-Hardwareeinheit respektive einen Krypto-Prozessor bzw. Co-Prozessor oder ein Krypto-Modul hatten, die/der/das es erlaubt, verschlüsselte "Key BLOBs" zu laden . Eine bekannte Lösung, die einen gewissen Schutz für die Unversehrtheit eines "Key BLOBs" bietet, wäre "Secure Boot", bei dem ein "Key BLOB" zusammen mit einem Betriebssystem- Image signiert und beim Booten verifiziert würde. Jedoch ist es oft so, dass die "Key BLOBs" spezifisch in Bezug auf das Prozessorsystem sind und daher nicht in einem allgemeinen
Image signiert werden können. Sie werden deshalb meist in ei¬ ner Initialisierungsphase des Prozessorsystems bei der Pro¬ duktion erstellt. Da zudem für das Prozessorsystem spezifische Firmware-Images meist aus praktischen Gründen nicht mög- lieh sind, muss man die "Key BLOBs" dann außerhalb des Images ablegen. Dadurch würden sie aber nicht mehr dem Schutz von "Secure Boot" unterliegen.
Daher ist dieser aus bekannten Überlegungen resultierende Lö- sungsansatz eher schwer umsetzbar. Zusätzlich bietet diese Lösung keinen Schutz gegen Angriffe, die den "Key BLOB" zur Laufzeit des Prozessorsystems mit der Krypto-Hardwareeinheit austauschen . Es sind aber auch herstellerspezifische Methoden (Vorgehens¬ weisen) bekannt, die einen Austausch von externen "Key BLOBs" erschweren sollen. So ermöglicht das CAA-Modul (Krypto-Modul) des "i .MX6"-Prozessorsystems zum Beispiel, dass bei der Er¬ zeugung eines "Key BLOBs" auch ein vom Hersteller gewählter Wert, ein sogenannter "Key Modifier", ins CAA-Modul geladen wird. Dieser "Key Modifier" wird getrennt vom "Key BLOB" ge¬ speichert und sollte sich bei der Aktualisierung des "Key BLOBs" ebenfalls ändern. Dadurch wird eine Bindung zwischen dem "Key BLOB" und dem "Key Modifier" erzeugt. So können zum Beispiel "Key BLOBs" weder ausgetauscht noch vertauscht wer¬ den und sie lassen sich durch eine vom Hersteller getriebene (z.B. initiierte, veranlasste) Änderung des verwendeten "Key Modifier" revozieren. Die der Erfindung zugrundeliegende Aufgabe besteht darin, ein Verfahren und eine Validierungseinheit zum Steuern des Ladens von IT-Systemen, insbesondere Eingebetteten Systemen, benutz- baren Krypto-Schlüsseln, insbesondere "Key BLOBs", anzugeben, bei dem bzw. bei der ein manipuliertes Laden der Krypto- Schlüssel, insbesondere der "Key BLOBs", beispielsweise da¬ durch, dass die extern abgelegten "Key BLOBs" durch veraltete "Key BLOBs" oder bei einem Hacker-Angriff auf das System von dem Angreifer (Hacker) generierte "Key BLOBs" ausgetauscht werden können, womit sich die Möglichkeit für den Angreifer (Hacker) ergibt, Schlüssel einzubringen, die ihm beim weitergehenden Hacker-Angriff auf das System behilflich sind, zu verhindern .
Diese Aufgabe wird ausgehend von dem im Oberbegriff des Pa¬ tentanspruchs 1 definierten Verfahren durch die im Kennzeichen des Patentanspruches 1 angegebenen Merkmale gelöst. Darüber hinaus wird die Aufgabe ausgehend von der im Oberbe¬ griff des Patentanspruchs 10 definierten Validierungseinheit durch die im Kennzeichen des Patentanspruches 10 angegebenen Merkmale gelöst. Die der Erfindung zugrundeliegende Idee gemäß der in den An¬ sprüchen 1 und 10 jeweils angegebenen technischen Lehre besteht darin, dass zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren und in einer Krypto-Hardwareeinheit ladbaren Krypto-Schlüsseln, insbeson- dere "Key BLOBs", der Krypto-Schlüssel vor dem Laden in die Krypto-Hardwareeinheit auf Validität geprüft wird. Die
Validitätsprüfung, ob der der Krypto-Schlüssel valide ist, geschieht dabei insbesondere bevor der Krypto-Schlüssel in der Krypto-Hardwareeinheit verwendet und durch eine system- spezifische Anwendungssoftware genutzt wird.
Das Kernelement der Erfindung sind dabei gemäß Anspruch 1 ein Validität-Prüfungsverfahren, das dem Ladevorgang des Krypto- Schlüssels, insbesondere des "Key BLOB", vorgelagert wird, und gemäß dem Anspruch 10 eine Validierungseinheit, die der Krypto-Hardwareeinheit , in die der Krypto-Schlüssel , insbe¬ sondere der "Key BLOB", geladen werden soll, vorgeschaltet ist .
Die gemäß dem Anspruch 10 spezifizierte Validierungseinheit, vorzugsweise integraler funktionaler Bestandteil der Krypto- Hardwareeinheit, fungiert dabei als Schnittstelle zu der Krypto-Hardwareeinheit.
Die Validierungseinheit kann in vorteilhaften Ausgestaltungen gemäß der Ansprüche 19 und 20 in einem Betriebssystem-Kernel integriert, als signiertes Kernel-Modul implementiert (An- spruch 19) oder als Digitale Schaltung eines "Field Program- mable Gate Array"-basierten Schaltkreis, kurz auch FPGA- Schaltkreis genannt, (Anspruch 20) realisiert werden. Dabei soll "Secure Boot" gegebenenfalls den Betriebssystem-Kernel und/oder den Bitstream des FPGA-Schaltkreises vor Manipulati- onen schützen. Ein direkter Zugriff auf die Krypto- Hardwareeinheit, vorbei an der Validierungseinheit, soll nicht möglich sein.
In einer vorteilhaften Weiterbildung der Erfindung kommen bei der Prüfung auf Validität vorzugsweise sowohl für das Validi- tät-Prüfungsverfahren (Ansprüche 2, 4, 6 und 8) als auch für die Validierungseinheit (Ansprüche 11, 13, 15 und 17) ver¬ schiedene Prinzipien (Prüfungsvarianten) in Frage, z.B. die nachfolgenden vier Prüfungsvarianten ( I ) ... ( IV) .
( I ) Die Prüfung auf Validität erfolgt auf der Basis einer Hashfunktion-Abbildung mit in einer ersten "Positivliste (Whitelist) " enthaltenen, zu erlaubten Krypto-Schlüsseln (Re- ferenz-Krypto-Schlüsseln) , insbesondere erlaubten "Key BLOBs" (Referenz- "Key BLOBs"), korrespondierenden Referenz-Hash- Werten. Dabei wird durch "Hashen" von zu ladenden Krypto- Schlüsseln, insbesondere "Key BLOBs", (Generieren von zu den Krypto-Schlüsseln, insbesondere "Key BLOBs", korrespondieren- den Hash-Werten) und anschließendes Vergleichen dieser Hash- Werte mit den Referenz-Hash-Werten in der "Positivliste
(Whitelist) " die Validität geprüft. Nicht in der "Positivlis¬ te (Whitelist) " vorhandene Krypto-Schlüssel , insbesondere "Key BLOBs", werden nicht zum Laden an die Krypto- Hardwareeinheit weitergeleitet.
Im Fall einer Änderung/einem Austausch, insbesondere einer Krypto-Schlüssel-Aktualisierung, der Krypto-Schlüssel, insbe- sondere der "Key BLOBs", muss auch die "Positivliste
(Whitelist)" entsprechend aktualisiert werden (vgl. Ansprüche 3 und 12 ) .
Der Vorteil dieser Prüfungsvariante ( I ) besteht darin, dass die Krypto-Schlüssel, insbesondere "Key BLOBs", nicht verän¬ dert werden müssen. Jedoch müssen die Krypto-Schlüssel, ins¬ besondere "Key BLOBs", zum Zeitpunkt der Erstellung der "Po¬ sitivliste (Whitelist) " bekannt sein, sodass korrespondieren¬ de Referenz-Hash-Werte berechnet werden können. Alternativ sind auch Prozessorsystem-spezifische "Positivlisten
(Whitelists) " im Falle von Prozessorsystem-spezifischen
Krypto-Schlüsseln, insbesondere "Key BLOBs", prinzipiell mög¬ lich, aber die Implementierung ist sehr aufwändig und daher eher unpraktisch.
( II ) Die Prüfung auf Validität erfolgt auf der Basis der Ve¬ rifikation einer digitalen Signatur. Dabei werden private Signatur-Schlüssel <"privat keys">, mit denen Krypto- Schlüssel, insbesondere "Key BLOBs", z.B. vom Krypto- Schlüssel-Hersteller, signiert worden sind, mit öffentlichen, z.B. in der Validierungseinheit enthaltenen, Verifikation- Schlüsseln <"public keys">, die zu den privaten Signatur- Schlüsseln korrespondieren und dementsprechende Schlüsselpaa¬ re bilden, verifiziert. Schlägt die Signatur-Verifikation fehl, wird der jeweilige private Signatur-Schlüssel <"privat key"> nicht akzeptiert, weshalb der mit diesem privaten Sig¬ natur-Schlüssel <"privat key"> signierte Krypto-Schlüssel, insbesondere der signierte "Key BLOB", nicht zum Laden an die Krypto-Hardwareeinheit weitergeleitet wird.
Bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, der Krypto-Schlüssel , insbesondere der "Key BLOBs", werden paarweise sowohl neue private Signatur-Schlüssel als auch neue öffentliche Verifikation- Schlüssel generiert, die öffentliche Verifikation-Schlüssel durch die neuen öffentlichen Verifikation-Schlüssel aktuali- siert und insbesondere in die Validierungseinheit inte¬ griert/gespeichert sowie alle Krypto-Schlüssel, insbesondere alle "Key BLOBs", d.h. sowohl neue Krypto-Schlüssel, insbe¬ sondere neue "Key BLOBs", als auch die geänderten Krypto- Schlüssel, insbesondere die geänderten "Key BLOBs", mit den neuen zu den neuen öffentlichen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüsseln signiert (vgl. Ansprüche 5 und 14) .
Der Vorteil dieser Prüfungsvariante ( II ) besteht darin, dass die öffentlichen Verifikation-Schlüssel in die Validierungs¬ einheit integriert/gespeichert werden können, ohne die
Krypto-Schlüssel, insbesondere die "Key BLOBs", zu kennen. Die (Prozessorsystem-spezifischen) Krypto-Schlüssel, insbesondere "Key BLOBs", müssen jedoch später mit den passenden privaten Signatur-Schlüsseln signiert werden.
( III ) Die Prüfung auf Validität erfolgt auf der Basis der Ve¬ rifikation einer erweiterten digitalen Signatur. Dabei werden private Signatur-Schlüssel <"privat keys">, mit denen Krypto- Schlüssel, insbesondere "Key BLOBs", einschließlich Krypto- Schlüssel-spezifischer Metadaten, vorzugsweise Versionsnummern, Erzeugungsdaten etc., z.B. vom Krypto-Schlüssel- Hersteller, signiert worden sind, mit öffentlichen, z.B. in der Validierungseinheit enthaltenen, Verifikation-Schlüsseln <"public keys">, die zu den privaten Signatur-Schlüsseln korrespondieren und dementsprechende Schlüsselpaare bilden, ve¬ rifiziert. Nur wenn die Signatur-Verifikation erfolgreich ist, also der jeweilige private Signatur-Schlüssel <"privat key"> eigentlich akzeptiert werden könnte, kommt es, bevor der mit diesem privaten Signatur-Schlüssel <"privat key"> signierte Krypto-Schlüssel , insbesondere der signierte "Key BLOB", zum Laden an die Krypto-Hardwareeinheit weitergeleitet werden kann, zu einem Abgleich der Krypto-Schlüssel- spezifischen Metadaten. Bei diesem Abgleich werden die Metadaten mit zu den Metadaten korrespondierenden, in einer zweiten "Positivliste (Whitelist) " enthaltenen Referenz-Metadaten abgeglichen .
Ergibt der Abgleich, dass die Metadaten mit den Referenz- Metadaten nicht übereinstimmen, weil z.B. eine metadatenspezifische Versionsnummer älter ist als eine Referenz- Metadaten-spezifische Versionsnummer, so wird der jeweilige private Signatur-Schlüssel <"privat key"> nicht akzeptiert, weshalb der mit diesem privaten Signatur-Schlüssel <"privat key"> signierte Krypto-Schlüssel, insbesondere der signierte "Key BLOB", nicht zum Laden an die Krypto-Hardwareeinheit weitergeleitet wird.
Bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, der Krypto-Schlüssel, insbesondere der "Key BLOBs", werden, insbesondere paarweise so¬ wohl neue private Signatur-Schlüssel als auch neue öffentli- che Verifikation-Schlüssel generiert, die Metadaten, vorzugs¬ weise die Versionsnummern, die Erzeugungsdaten etc., in der zweiten "Positivliste (Whitelist) " angepasst und insbesondere in die Validierungseinheit integriert/gespeichert sowie neue Krypto-Schlüssel, insbesondere neue "Key BLOBs" mit den zu den öffentlichen Verifikation-Schlüsseln korrespondierenden privaten Signatur-Schlüsseln und den angepassten Metadaten, vorzugsweise den angepassten Versionsnummern, den angepassten Erzeugungsdaten etc., signiert (vgl. Ansprüche 7 und 16) . Der Vorteil dieser Prüfungsvariante (III) besteht darin, dass nur die Metadaten bzw. die Versionsnummern, die Erzeugungsdaten etc., in der zweiten "Positivliste (Whitelist)" geändert werden, während neue Schlüsselpaare, jeweils bestehend aus einem neuen privaten Signatur-Schlüssel und einem neuen öffentlichen Verifikation-Schlüssel, nicht zwingend erzeugt werden müssen, sondern optional erzeugt werden können. Darüber hinaus können die Metadaten, insbesondere die Versi¬ onsnummern, die Erzeugungsdaten etc., in der zweiten "Positivliste (Whitelist ) " , vorzugsweise in die Validierungsein¬ heit, festgelegt werden, ohne dass die Krypto-Schlüssel , ins¬ besondere die "Key BLOBs" zu diesem Zeitpunkt bekannt sind.
Allerdings müssen die (Prozessorsystem-spezifischen) Krypto- Schlüssel, insbesondere die "Key BLOBs", jedoch später mit den zu den öffentlichen Verifikation-Schlüsseln korrespondierenden privaten Signatur-Schlüsseln signiert und den ange- passten Metadaten, vorzugsweise den angepassten Versionsnummern, den angepassten Erzeugungsdaten etc., versehen und signiert werden.
( IV) Die Prüfung auf Validität erfolgt auf der Basis einer CHALLENGE-RESPONSE-Prozedur mit in einer dritten "Positivliste (Whitelist)" enthaltenen CHALLENGE-RESPONSE-Zahlenpaaren . Hierzu wird zunächst ein Krypto-Schlüssel, insbesondere "Key BLOB", in die Krypto-Hardwareeinheit geladen. Danach wird mit der Krypto-Hardwareeinheit eine vorgegebene, auf einem aus der dritten "Positivliste (Whitelist) " ausgewählten CHALLEN- GE-RESPONSE-Zahlenpaar basierende Krypto-Operation, vorzugsweise eine Verschlüsselung, mit dem geladenen Krypto- Schlüssel und einer CHALLENGE-Zahl des ausgewählten CHALLEN- GE-RESPONSE-Zahlenpaars durchgeführt .
Ist das Ergebnis der durchgeführten Krypto-Operation eine RESPONSE-Zahl des ausgewählten CHALLENGE-RESPONSE- Zahlenpaars, so wird der geladene Krypto-Schlüssel als valide eingestuft/angesehen, und vorzugsweise in der Krypto- Hardwareeinheit gespeichert, anderenfalls wird der geladene Krypto-Schlüssel als invalide eingestuft/angesehen, und vor¬ zugsweise aus der Krypto-Hardwareeinheit entfernt bzw. ein Zugriff auf die Krypto-Hardwareeinheit verweigert. Bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels , insbesondere des "Key BLOB", wird die dritte "Positivliste
(Whitelist) " für einen neuen Krypto-Schlüssel aktualisiert (vgl. Ansprüche 9 und 18) .
Der Vorteil dieser Prüfungsvariante ( IV) besteht darin, dass die Krypto-Schlüssel, insbesondere die "Key BLOBs", nicht verändert (z.B. signiert) werden müssen und dass keine Public Key Kryptographie notwendig ist. Weiterhin können die CHAL- LENGE-RESPONSE-Zahlenpaare alleine durch die Kenntnis des im Krypto-Schlüssel, insbesondere im "Key BLOB", verschlüsselten Schlüssels berechnet werden. Der Krypto-Schlüssel, insbeson- dere "Key BLOB", selbst kann daher Prozessorsystem-spezifisch sein und braucht deshalb auch erst während dessen Produktion erzeugt werden.
Fazit : Das auf diese Prinzipien beruhende Validität- Prüfungsverfahren oder die darauf beruhende Validierungseinheit bietet den Vorteil, dass Angriffe verhindert werden kön¬ nen, die darauf aufbauen, den Krypto-Schlüssel, insbesondere den "Key BLOB", austauschen zu können. Des Weiteren lässt sich das auf diesen Prinzipien beruhende Validität- Prüfungsverfahren oder die darauf beruhende Validierungseinheit je nach Anwendungs- und Produktionsszenario effizient und unabhängig von der Zielplattform umsetzen.
Weitere Vorteile der Erfindung ergeben sich aus der nachfol- genden Beschreibung eines Ausführungsbeispieles der Erfindung anhand der FIGUREN 1 und 2. Diese zeigen:
FIGUR 1 eine aus Krypto-Prozessor und Validierungseinheit ge¬ bildete erste Funktionseinheit zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere "Key BLOBs", FIGUR 2 eine aus Krypto-Modul und Validierungseinheit gebil¬ dete zweite Funktionseinheit zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere "Key BLOBs".
FIGUR 1 zeigt eine aus einer als Krypto-Prozessor KPZ ausge¬ bildeten Krypto-Hardwareeinheit KHWE und einer Validierungs¬ einheit VDE gebildete erste Funktionseinheit FTE-1 zum Steu¬ ern des Ladens von in einem IT-System ITS, das vorzugsweise als ein Eingebettetes System EBS ausgebildet ist, benutzba¬ ren, vorzugsweise in Form von "Key BLOBs" oder "Wrapped Keys" gebildeten, Krypto-Schlüsseln KS-A...KS-X. Die erste Funktions¬ einheit FTE-1 führt dazu in dem/für das IT-System ITS, EBS, also systembezogen, kryptografische Operationen aus, die bis- her (gemäß dem Stand der Technik) von der Krypto- Hardwareeinheit KHWE bzw. von dem Krypto-Prozessor KPZ ausgeführt worden sind.
Ausgangspunkt für das Laden der Krypto-Schlüssel bzw. "Key BLOBs" KS-A...KS-X ist in dem IT-System ITS, EBS eine system¬ spezifische Anwendungssoftware ASW mit mehreren, jeweils ei¬ nen separaten Krypto-Schlüssel bzw. "Key BLOB" KS-A, KS- B,...KS-X der benutzbaren Krypto-Schlüsseln KS-A...KS-X bzw. "Key BLOBs" zugewiesenen/beinhaltenden Software-Anwendungen (SW- Anwendungen) SW-A, SW-B, ...SW-X . Jede dieser Software- Anwendungen ( SW-Anwendungen) SW-A, SW-B,...SW-X greift mittelbar, über die Validierungseinheit VDE, (und nicht mehr unmit¬ telbar wie beim Stand der Technik) auf die Krypto- Hardwareeinheit KHWE bzw. den Krypto-Prozessor KPZ zu, der als Co-Prozessor zu einem in der FIGUR 1 nicht dargestellten Haupt-Prozessor fungiert. Mit dem durch die jeweilige SW- Anwendung SW-A...SW-X der Anwendungssoftware ASW erfolgten Zugriff soll der korrespondierende Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen werden. Dieses Laden passiert jedoch nicht wie beim Stand der Technik unmittelbar, sondern unter Zwischenschaltung der Validierungseinheit VDE. In dieser Validierungseinheit VDE wird der Krypto-Schlüssel bzw. der "Key BLOß" KS-A...KS-X vor dem Laden in die Krypto- Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ auf Validität geprüft. Die Validierungseinheit VDE weist hierzu auf:
1) Eine Krypto-Schnittstelle KSS, über die die Validierungs¬ einheit VDE zur Ausführung der systembezogenen kryptografi- schen Operationen mit der Krypto-Hardwareeinheit KHWE bzw. mit dem Krypto-Prozessor KPZ verbunden ist,
2) eine Software-Schnittstelle SWSS, über die jede einzelne SW-Anwendungen SW-A...SW-X der systemspezifischen Anwendungssoftware ASW auf die Krypto-Hardwareeinheit KHWE bzw. den Krypto-Prozessor KPZ initial zugreift,
3) eine Steuereinrichtung STE, die verbunden mit der Krypto- Schnittstelle KSS und der Software-Schnittstelle SWSS und da¬ bei eine Funktionseinheit bildend derart ausgebildet ist, dass auf den über die Software-Schnittstelle SWSS erfolgten Zugriff jeder einzelnen SW-Anwendungen SW-A...SW-X der systemspezifischen Anwendungssoftware ASW der mit dem Zugriff zu ladende Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X in der
Steuereinrichtung STE auf Validität geprüft wird, bevor der Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X KS-A...KS-X über die Krypto-Schnittstelle KSS in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird.
Für die Validitätsprüfung des Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X enthält die Steuereinrichtung STE (i) einen nicht-flüchtigen, lesbaren Speicher SP, in dem rechenwerklesbare Steuerprogrammbefehle eines das Laden steuernden Pro- gramm-Moduls PGM gespeichert sind, und (ii) ein mit dem Spei¬ cher SP verbundenes Rechenwerk RW, das die Steuerprogrammbe¬ fehle des Programm-Moduls PGM ausführt.
Die in der FIGUR 1 dargestellte Validierungseinheit VDE kann vorzugsweise - in einer ersten Ausführungsform - als eine
Komponente eines Betriebssystem-Kernels des IT-Systems ITS, EBS mit den zum IT-System ITS, EBS gehörenden Haupt-Prozessor (in der FIGUR 1 nicht dargestellt) und dem Krypto-Prozessor KPZ ausgebildet sein. Die in diesem Fall als Software-Modul ausgebildete Validierungseinheit VDE ist dabei entweder in dem Betriebssystem-Kernel integriert oder als signiertes Ker¬ nel-Modul implementiert. Die Funktion der Steuereinrichtung STE sowie die Funktionalität der Steuereinrichtung STE reprä¬ sentiert durch das das Programm-Modul PGM ausführende Rechen¬ werk RW und den das Programm-Modul PGM speichernde Speicher SP wird in dieser ersten Ausführungsform durch den Haupt- Prozessor ausgeübt.
Alternativ dazu kann die in der FIGUR 1 dargestellte Validie¬ rungseinheit VDE wieder vorzugsweise - in einer zweiten Aus¬ führungsform - als Digitale Schaltung eines FPGA-Schaltkreis des IT-Systems ITS, EBS mit den zum IT-System ITS, EBS gehö- renden Haupt-Prozessor und dem Krypto-Prozessor KPZ ausgebildet sein.
Bei der Prüfung auf Validität in der Steuereinrichtung STE gibt es vorzugsweise verschiedene Prinzipien [ Prüfungsvarian- ten ( I ) ... ( IV) ] , die im Zuge der Ausführung der systembezogenen kryptografischen Operationen durchgeführt werden können.
In einer ersten Variante ( I ) zur Prüfung der Validität des Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Ba¬ sis einer Hashfunktion-Abbildung
zunächst in dem die Steuerprogrammbefehle des Programm-Moduls PGM ausführenden Rechenwerk RW der Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X und ein durch die Hashfunktion-Abbildung generierter und zum Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X korrespondierender Hash-Wert mit mindestens einem für das La¬ den in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto- Prozessor KPZ erlaubten Referenz-Krypto-Schlüssel und mindes- tens einem durch die Hashfunktion-Abbildung generierten, zu dem erlaubten Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X kor¬ respondierenden Referenz-Hash-Wert , der in dem Speicher SP in einer ersten "Positivliste (Whitelist) " gespeichert ist, ver¬ glichen wird, und
dann, wenn der Vergleich ergibt, dass der Hash-Wert des
Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X mit einem Hash- Wert des Referenz-Krypto-Schlüssels in der ersten "Positiv¬ liste (Whitelist) " übereinstimmt also in der "Positivliste (Whitelist) " enthalten ist, dass dann der Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird.
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. "Key BLOB" in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ .
In Bezug auf die erste Prüfungsvariante ( I ) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw.
"Key BLOB" KS-A...KS-X die erste "Positivliste (Whitelist) " für einen neuen Krypto-Schlüssel bzw. "Key BLOB" aktualisiert wird . In einer zweiten Variante ( II ) zur Prüfung der Validität des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Ba¬ sis einer digitalen Signatur
zunächst der Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X mit einem privaten Signatur-Schlüssel <"privat key"> signiert wird,
dann die Signatur des Krypto-Schlüssels bzw. "Key BLOB" KS- A...KS-X mit einem zu dem privaten Signatur-Schlüssel korres- pondierenden öffentlichen Verifikation-Schlüssel <"public key">, der in dem Speicher SP gespeichert ist, verifiziert wird, und schließlich, wenn die Signatur des Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X gültig ist, der Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird.
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. "Key BLOB" KS- A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto- Prozessor KPZ.
In Bezug auf die zweite Prüfungsvariante ( II ) sind der Spei¬ cher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch des Krypto-Schlüssels "Key BLOB" KS-A...KS-X paarweise sowohl ein neuer privater Sig¬ natur-Schlüssel als auch ein neuer öffentlicher Verifikation- Schlüssel generiert werden, der öffentliche Verifikation- Schlüssel durch den neuen öffentlichen Verifikation-Schlüssel aktualisiert wird und sowohl ein neuer Krypto-Schlüssel bzw. "Key BLOB" als auch der geänderte Krypto-Schlüssel bzw. "Key BLOB" mit dem neuen zu dem neuen öffentlichen Verifikation- Schlüssel korrespondierenden privaten Signatur-Schlüssel sig¬ niert werden. In einer dritten Variante ( III ) zur Prüfung der Validität des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Ba¬ sis einer erweiterten digitalen Signatur
zunächst der Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X ein¬ schließlich Krypto-Schlüssel-spezifischer Metadaten, vorzugsweise einer Versionsnummer, einem Erzeugungsdatum etc., mit einem privaten Signatur-Schlüssel <"privat key"> signiert wird,
dann die Signatur des Krypto-Schlüssels bzw. "Key BLOB" KS- A...KS-X mit einem zu dem privaten Signatur-Schlüssel korres¬ pondierenden öffentlichen Verifikation-Schlüssel <"public key">, der in dem Speicher SP gespeichert ist, verifiziert wird,
dann, wenn die Signatur des Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X gültig ist, die Metadaten mit zu den Metadaten kor- respondierenden, in dem Speicher SP in einer zweiten "Positivliste (Whitelist) " gespeicherten Referenz-Metadaten abge¬ glichen werden anderenfalls wird das Laden des Krypto- Schlüssels bzw. "Key BLOß" KS-A...KS-X abgebrochen und
schließlich, wenn der Abgleich ergibt, dass die Metadaten mit den Referenz-Metadaten übereinstimmen, dass dann der Krypto- Schlüssel bzw. "Key BLOß" KS-A...KS-X in die Krypto- Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird .
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. "Key BLOß" KS A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto Prozessor KPZ. In Bezug auf die dritte Prüfungsvariante ( III ) sind der Spei¬ cher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X, insbesondere paarweise sowohl ein neuer privater Signatur-Schlüssel als auch ein neuer öffent¬ licher Verifikation-Schlüssel generiert werden, die Metadaten in der zweiten "Positivliste (Whitelist) " angepasst werden und ein neuer Krypto-Schlüssel bzw. "Key BLOB" mit dem zu dem öffentlichen Verifikation-Schlüssel korrespondierenden priva¬ ten Signatur-Schlüssel und den angepassten Metadaten signiert wird .
In einer vierten Variante ( IV) zur Prüfung der Validität des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X sind der Speiche SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf Basis einer CHALLENGE-RESPONSE-Prozedur mit in dem Speicher SP in einer dritten "Positivliste (Whitelist) " gespeicherten CHAL¬ LENGE-RESPONSE-Zahlenpaaren
zunächst der Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird,
dann mit der Krypto-Hardwareeinheit (KHWE) eine vorgegebene, auf einem aus der dritten "Positivliste (Whitelist) " ausge¬ wählten CHALLENGE-RESPONSE-Zahlenpaar basierende Krypto- Operation, vorzugsweise eine Verschlüsselung, mit dem gelade- nen Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X und einer CHALLENGE-Zahl des ausgewählten CHALLENGE-RESPONSE- Zahlenpaars durchgeführt wird, und
schließlich, wenn das Ergebnis der durchgeführten Krypto- Operation der RESPONSE-Zahl des ausgewählten CHALLENGE- RESPONSE-Zahlenpaars entspricht, dass dann der geladene
Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X als valide einge¬ stuft/angesehen, und vorzugsweise in der Krypto- Hardwareeinheit KHWE bzw. in dem Krypto-Prozessor KPZ gespeichert, wird.
Liefert die durchgeführte Krypto-Operation hingegen ein ande¬ res Ergebnis, so wird der geladene Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X als invalide eingestuft/angesehen, und vor¬ zugsweise aus der Krypto-Hardwareeinheit KHWE bzw. aus dem Krypto-Prozessor KPZ entfernt oder ein Zugriff auf die
Krypto-Hardwareeinheit KHWE bzw. auf den Krypto-Prozessor KPZ verweigert .
In Bezug auf die vierte Prüfungsvariante ( IV) sind der Spei- eher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X die dritte "Positivliste
(Whitelist)" für einen neuen Krypto-Schlüssel bzw. "Key BLOB" aktualisiert wird. FIGUR 2 zeigt eine aus einer als Krypto-Modul KM ausgebildete Krypto-Hardwareeinheit KHWE und einer Validierungseinheit VDE gebildete zweite Funktionseinheit FTE-2 zum Steuern des La¬ dens von in einem IT-System ITS, das vorzugsweise als ein Eingebettetes System EBS ausgebildet ist, benutzbaren, vor¬ zugsweise in Form von "Key BLOBs" oder "Wrapped Keys" gebil¬ deten, Krypto-Schlüsseln KS-A...KS-X. Die zweite Funktionsein¬ heit FTE-2 führt dazu in dem/für das IT-System ITS, EBS, also systembezogen, kryptografische Operationen aus, die bisher (gemäß dem Stand der Technik) von der Krypto-Hardwareeinheit KHWE bzw. von dem Krypto-Modul KM ausgeführt worden sind.
Ausgangspunkt für das Laden der Krypto-Schlüssel bzw. "Key BLOBs" KS-A...KS-X ist in dem IT-System ITS, EBS wieder die systemspezifische Anwendungssoftware ASW mit den mehreren, jeweils die separaten Krypto-Schlüssel bzw. "Key BLOB" KS-A, KS-B,...KS-X der benutzbaren Krypto-Schlüsseln KS-A...KS-X bzw. "Key BLOBs" zugewiesenen/beinhaltenden Software-Anwendungen (SW-Anwendungen) SW-A, SW-B, ...SW-X . Jede dieser Software- Anwendungen (SW-Anwendungen) SW-A, SW-B,...SW-X greift mittelbar, über die Validierungseinheit VDE, (und nicht mehr unmit¬ telbar wie beim Stand der Technik) auf die Krypto- Hardwareeinheit KHWE bzw. das Krypto-Modul KM zu, das wie die Validierungseinheit VDE in einem Haupt-Prozessor HPZ des IT- Systems ITS, EBS integriert/implementiert ist. Auf das Ver¬ hältnis zwischen dem aus der Krypto-Hardwareeinheit KHWE bzw. dem Krypto-Modul KM und der Validierungseinheit VDE gebilde¬ ten zweiten Funktionseinheit FTE-2 einerseits sowie und dem Haupt-Prozessor HPZ andererseits wird weiter unten noch näher eingegangen.
Mit dem durch die jeweilige SW-Anwendung SW-A...SW-X der Anwendungssoftware ASW erfolgten Zugriff soll der korrespondierende Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X in die Krypto- Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wer¬ den. Dieses Laden passiert jedoch wieder nicht wie beim Stand der Technik unmittelbar, sondern unter Zwischenschaltung der Validierungseinheit VDE. In dieser Validierungseinheit VDE wird der Krypto-Schlüssel bzw. der "Key BLOß" KS-A...KS-X vor dem Laden in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM auf Validität geprüft. Die Validierungseinheit VDE weist hierzu auf:
1) Eine Krypto-Schnittstelle KSS, über die die Validierungs¬ einheit VDE zur Ausführung der systembezogenen kryptografi- schen Operationen mit der Krypto-Hardwareeinheit KHWE bzw. mit dem Krypto-Modul KM verbunden ist,
2) eine Software-Schnittstelle SWSS, über die jede einzelne SW-Anwendungen SW-A...SW-X der systemspezifischen Anwendungssoftware ASW auf die Krypto-Hardwareeinheit KHWE bzw. das Krypto-Modul KM initial zugreift,
3) eine Steuereinrichtung STE, die verbunden mit der Krypto- Schnittstelle KSS und der Software-Schnittstelle SWSS und da¬ bei eine Funktionseinheit bildend derart ausgebildet ist, dass auf den über die Software-Schnittstelle SWSS erfolgten Zugriff jeder einzelnen SW-Anwendungen SW-A...SW-X der systemspezifischen Anwendungssoftware ASW der mit dem Zugriff zu ladende Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X in der
Steuereinrichtung STE auf Validität geprüft wird, bevor der Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X KS-A...KS-X über die Krypto-Schnittstelle KSS in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird.
Für die Validitätsprüfung des Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X enthält die Steuereinrichtung STE (i) einen nicht-flüchtigen, lesbaren Speicher SP, in dem rechenwerklesbare Steuerprogrammbefehle eines das Laden steuernden Pro- gramm-Moduls PGM gespeichert sind, und (ii) ein mit dem Spei¬ cher SP verbundenes Rechenwerk RW, das die Steuerprogrammbe¬ fehle des Programm-Moduls PGM ausführt.
Die in der FIGUR 2 dargestellte Validierungseinheit VDE und das Krypto-Modul KM können vorzugsweise - in einer bevorzug¬ ten Ausführungsform - als Komponenten eines Betriebssystem- Kernels des IT-Systems ITS, EBS mit den zum IT-System ITS, EBS gehörenden Haupt-Prozessor HPZ ausgebildet sein. Die in diesem Fall als Software-Modul ausgebildete zweite Funktions¬ einheit FTE-2, also die Validierungseinheit VDE und das
Krypto-Modul KM, ist dabei entweder in dem Betriebssystem- Kernel integriert oder als signiertes Kernel-Modul implemen- tiert. Die Funktion der Steuereinrichtung STE sowie die Funktionalität der Steuereinrichtung STE repräsentiert durch das das Programm-Modul PGM ausführende Rechenwerk RW und den das Programm-Modul PGM speichernde Speicher SP wird in dieser ersten Ausführungsform durch den Haupt-Prozessor HPZ ausge- übt.
Bei der Prüfung auf Validität in der Steuereinrichtung STE gibt es vorzugsweise verschiedene Prinzipien [ Prüfungsvarian- ten ( I ) ... ( IV) ] , die im Zuge der Ausführung der systembezogenen kryptografischen Operationen durchgeführt werden können.
In einer ersten Variante ( I ) zur Prüfung der Validität des Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Ba¬ sis einer Hashfunktion-Abbildung
zunächst in dem die Steuerprogrammbefehle des Programm-Moduls PGM ausführenden Rechenwerk RW der Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X und ein durch die Hashfunktion-Abbildung ge- nerierter und zum Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X korrespondierender Hash-Wert mit mindestens einem für das La¬ den in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto- Modul KM erlaubten Referenz-Krypto-Schlüssel und mindestens einem durch die Hashfunktion-Abbildung generierten, zu dem erlaubten Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X korres¬ pondierenden Referenz-Hash-Wert , der in dem Speicher SP in einer ersten "Positivliste (Whitelist) " gespeichert ist, ver¬ glichen wird, und
dann, wenn der Vergleich ergibt, dass der Hash-Wert des
Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X mit einem Hash- Wert des Referenz-Krypto-Schlüssels in der ersten "Positiv¬ liste (Whitelist) " übereinstimmt also in der "Positivliste (Whitelist) " enthalten ist, dass dann der Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird.
Liefert der Vergleich hingegen ein anderes Ergebnis, so un- terbleibt ein Laden des Krypto-Schlüssels bzw. "Key BLOß" in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM.
In Bezug auf die erste Prüfungsvariante ( I ) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X die erste "Positivliste (Whitelist) " für einen neuen Krypto-Schlüssel bzw. "Key BLOB" aktualisiert wird.
In einer zweiten Variante ( II ) zur Prüfung der Validität des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Ba¬ sis einer digitalen Signatur
zunächst der Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X mit einem privaten Signatur-Schlüssel <"privat key"> signiert wird,
dann die Signatur des Krypto-Schlüssels bzw. "Key BLOB" KS- A...KS-X mit einem zu dem privaten Signatur-Schlüssel korres¬ pondierenden öffentlichen Verifikation-Schlüssel <"public key">, der in dem Speicher SP gespeichert ist, verifiziert wird, und
schließlich, wenn die Signatur des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X gültig ist, der Krypto-Schlüssel bzw. "Key BLOB" KS-A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird. Liefert der Vergleich hingegen ein anderes Ergebnis, so un¬ terbleibt ein Laden des Krypto-Schlüssels bzw. "Key BLOB" KS- A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto- Modul KM. In Bezug auf die zweite Prüfungsvariante ( II ) sind der Spei¬ cher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch des Krypto-Schlüssels "Key BLOB" KS-A...KS-X paarweise sowohl ein neuer privater Sig¬ natur-Schlüssel als auch ein neuer öffentlicher Verifikation- Schlüssel generiert werden, der öffentliche Verifikation- Schlüssel durch den neuen öffentlichen Verifikation-Schlüssel aktualisiert wird und sowohl ein neuer Krypto-Schlüssel bzw. "Key BLOB" als auch der geänderte Krypto-Schlüssel bzw. "Key BLOB" mit dem neuen zu dem neuen öffentlichen Verifikation- Schlüssel korrespondierenden privaten Signatur-Schlüssel sig¬ niert werden.
Hierzu jetzt ein in der Praxis mögliches Implementierungssze¬ nario :
- Als Prozessorsystem ist ein Linux System mit "Secure Boot" auf einem "i .MX6"-Prozessor (inkl. CAA-Krypto-Co-Prozessor und Secure Memory Store mit "Key BLOB"-Lade-Funktion) von Freescale®.
- Die Validierungseinheit ist als signiertes Linux Kernel Mo¬ dul ausgeführt und enthält einen ECC-Public Key (Elliptic Curve Cryptography) .
- "Key BLOBs" wurden in der Produktion generiert und mit pas¬ sendem "Private Key" signiert.
- Beim Laden des "Key BLOB" und der dazugehörigen Signatur in die Validierungseinheit wird zuerst die Signatur verifiziert und nur dann der "Key BLOB"in den Secure Memory Store geladen, wenn die Verifikation erfolgreich war.
- Ein "Key BLOB"-Update erfolgt durch Generierung von
o neuem "Public Key'V'Private Key"-Paar,
o neuen "Key BLOBs", signiert mit neuem "Private Key" und o neuem signierten Validierungs-Modul mit neuem "Public Key".
In einer dritten Variante ( III ) zur Prüfung der Validität des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Ba¬ sis einer erweiterten digitalen Signatur
zunächst der Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X ein- schließlich Krypto-Schlüssel-spezifischer Metadaten, vorzugsweise einer Versionsnummer, einem Erzeugungsdatum etc., mit einem privaten Signatur-Schlüssel <"privat key"> signiert wird,
dann die Signatur des Krypto-Schlüssels bzw. "Key BLOß" KS- A...KS-X mit einem zu dem privaten Signatur-Schlüssel korres¬ pondierenden öffentlichen Verifikation-Schlüssel <"public key">, der in dem Speicher SP gespeichert ist, verifiziert wird,
dann, wenn die Signatur des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X gültig ist, die Metadaten mit zu den Metadaten kor¬ respondierenden, in dem Speicher SP in einer zweiten "Positivliste (Whitelist) " gespeicherten Referenz-Metadaten abge¬ glichen werden anderenfalls wird das Laden des Krypto- Schlüssels bzw. "Key BLOB" KS-A...KS-X abgebrochen und
schließlich, wenn der Abgleich ergibt, dass die Metadaten mit den Referenz-Metadaten übereinstimmen, dass dann der Krypto- Schlüssel bzw. "Key BLOB" KS-A...KS-X in die Krypto- Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird .
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. "Key BLOB" KS- A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto- Modul KM.
In Bezug auf die dritte Prüfungsvariante ( III ) sind der Spei¬ cher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei ei- ner Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X, insbesondere paarweise sowohl ein neuer privater Signatur-Schlüssel als auch ein neuer öffent¬ licher Verifikation-Schlüssel generiert werden, die Metadaten in der zweiten "Positivliste (Whitelist) " angepasst werden und ein neuer Krypto-Schlüssel bzw. "Key BLOß" mit dem zu dem öffentlichen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüssel und den angepassten Metadaten signiert wird.
Hierzu jetzt ein in der Praxis mögliches Implementierungssze¬ nario : - Als Prozessorsystem wird ein Linux System mit "Secure Boot" (inkl. Bitstream) auf einem "Cyclone V SoC" von Altera® mit proprietärem FPGA-spezifischen Trust Anchor mit "Key BLOB"- Lade-Funktion verwendet.
- Die Validierungseinheit ist als Digitale Schaltung in einem FPGA-Modul realisiert und enthält ECC-Public Key (Elliptic
Curve Cryptography) und Versionsnummer.
- "Key BLOBs" wurden in der Produktion generiert, mit aktuel¬ ler Versionsnummer versehen und mit passendem "Private Key" signiert .
- Beim Laden des "Key BLOB" und der dazugehörigen Signatur in die Validierungseinheit wird zuerst die Signatur verifiziert und die Versionsnummer überprüft. Nur wenn die Signaturverifikation erfolgreich war und die Versionsnummer mit der der Validierungseinheit übereinstimmt wird der "Key BLOB" in den Trust Anchor geladen.
- Ein Update der "Key BLOBs" erfolgt durch Bereitstellung von o neuer Versionsnummer,
o neuen "Key BLOBs", versehen mit neuer Versionsnummer und signiert mit aktuellem "Private Key" und
o neuem FPGA-Bitstream mit neuer Versionsnummer, signiert für "Secure Boot".
In einer vierten Variante ( IV) zur Prüfung der Validität des Krypto-Schlüssels bzw. "Key BLOB" KS-A...KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Ba¬ sis einer CHALLENGE-RESPONSE-Prozedur mit in dem Speicher SP in einer dritten "Positivliste (Whitelist) " gespeicherten CHALLENGE-RESPONSE-Zahlenpaaren
zunächst der Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird,
dann mit der Krypto-Hardwareeinheit (KHWE) eine vorgegebene, auf einem aus der dritten "Positivliste (Whitelist) " ausge¬ wählten CHALLENGE-RESPONSE-Zahlenpaar basierende Krypto- Operation, vorzugsweise eine Verschlüsselung, mit dem gelade- nen Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X und einer CHALLENGE-Zahl des ausgewählten CHALLENGE-RESPONSE- Zahlenpaars durchgeführt wird, und
schließlich, wenn das Ergebnis der durchgeführten Krypto- Operation der RESPONSE-Zahl des ausgewählten CHALLENGE- RESPONSE-Zahlenpaars entspricht, dass dann der geladene
Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X als valide einge¬ stuft/angesehen, und vorzugsweise in der Krypto- Hardwareeinheit KHWE bzw. in dem Krypto-Modul KM gespeichert, wird .
Liefert die durchgeführte Krypto-Operation hingegen ein ande¬ res Ergebnis, so wird der geladene Krypto-Schlüssel bzw. "Key BLOß" KS-A...KS-X als invalide eingestuft/angesehen, und vor¬ zugsweise aus der Krypto-Hardwareeinheit KHWE bzw. aus dem Krypto-Modul KM entfernt oder ein Zugriff auf die Krypto- Hardwareeinheit KHWE bzw. auf das Krypto-Modul KM verweigert.
In Bezug auf die vierte Prüfungsvariante ( IV) sind der Spei¬ cher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. "Key BLOß" KS-A...KS-X die dritte "Positivliste
(Whitelist)" für einen neuen Krypto-Schlüssel bzw. "Key BLOB" aktualisiert wird
Hierzu jetzt ein in der Praxis mögliches Implementierungssze¬ nario : - Als Prozessorsystem wird ein Linux System mit "Secure Boot" auf CPU von Intel® mit einer integrierten "Trusted Platform Module (TPM) "-Firmware .
- Die Validierungseinheit ist in einem Linux Kernel inte¬ griert und enthält in einer "Positivliste (Whitelist) " ge¬ speicherte CHALLENGE-RESPONSE-Zahlenpaare , die offline mit den korrekten Schlüsseln erzeugt wurden.
- "Key BLOBs" oder "Wrapped Keys" wurden in der Produktion generiert.
- Die Validierungseinheit lädt den zu ladenden "Key BLOB" oder "Wrapped Key" in das "Trusted Platform Module (TPM) " und berechnet damit einen "keyed-Hash Message Authentication Code (HMAC) " von der gespeicherten CHALLENGE .
- Das HMAC-Ergebnis wird mit der gespeicherten RESPONSE verglichen; bei Gleichheit wird der Schlüssel im "Trusted Plat¬ form Module (TPM) " belassen, bei Ungleichheit wird dieser wieder aus dem "Trusted Platform Module (TPM)" entfernt.
- Eine Aktualisierung von "Key BLOBs" oder "Wrapped Keys" er- folgt durch Erzeugung von
o neuen "Key BLOBs" oder "Wrapped Keys",
o neuem Kernel inkl. Validierungsmodul mit neuen CHALLENGE- RESPONSE-Zahlenpaaren, signiert für "Secure Boot".

Claims

Patentansprüche
1. Verfahren zum Steuern des Ladens von in IT-Systemen (ITS), insbesondere Eingebetteten Systemen (EBS) , benutzbaren
Krypto-Schlüsseln (KS-A...KS-X) , insbesondere "Key BLOBs", bei dem
a) eine systemspezifische Anwendungssoftware (ASW) auf eine zur Ausführung systembezogener kryptografischer Operationen ausgebildete Krypto-Hardwareeinheit (KHWE) , insbesondere ein in dem System (ITS, EBS) als Co-Prozessor zu einem Haupt- Prozessor (HPZ) genutzter Krypto-Prozessor (KPZ) oder ein in dem Haupt-Prozessor (HPZ) enthaltenes Krypto-Modul (KM) , zugreift und
b) mit diesem Zugriff der Krypto-Schlüssel (KS-A...KS-X) in die Krypto-Hardwareeinheit (KHWE) geladen wird,
dadurch gekennzeichnet, dass
c ) der Krypto-Schlüssel (KS-A...KS-X) vor dem Laden in die Krypto-Hardwareeinheit (KHWE) , insbesondere bevor der Krypto- Schlüssel (KS-A...KS-X) in der Krypto-Hardwareeinheit (KHWE) verwendet und durch die systemspezifische Anwendungssoftware (ASW) genutzt wird, auf Validität geprüft wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Validitätsprüfung des Krypto-Schlüssels (KS-A...KS-X) auf der Basis einer Hashfunktion-Abbildung derart realisiert wird, dass
a) der Krypto-Schlüssel (KS-A...KS-X) und ein durch die Hash- funktion-Abbildung generierter und zum Krypto-Schlüssel (KS- A...KS-X) korrespondierender Hash-Wert mit mindestens einem für das Laden in die Krypto-Hardwareeinheit (KHWE) erlaubten Re- ferenz-Krypto-Schlüssel und mindestens einem durch die Hash- funktion-Abbildung generierten, zu dem erlaubten Krypto- Schlüssel korrespondierenden Referenz-Hash-Wert , der in einer ersten "Positivliste (Whitelist) " enthalten ist, verglichen wird,
b) wenn der Vergleich ergibt, dass der Hash-Wert des Krypto- Schlüssels (KS-A...KS-X) mit einem Referenz-Hash-Wert des Refe- renz-Krypto-Schlüssels in der ersten "Positivliste (Whitelist) " übereinstimmt also in der "Positivliste
(Whitelist) " enthalten ist, dass dann der Krypto-Schlüssel (KS-A...KS-X) in die Krypto-Hardwareeinheit (KHWE) geladen wird anderenfalls unterbleibt ein Laden des Krypto-Schlüssels (KS- A...KS-X) in die Krypto-Hardwareeinheit (KHWE) .
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels (KS- A...KS-X) die erste "Positivliste (Whitelist) " für einen neuen Krypto-Schlüssel aktualisiert wird.
4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass
die Validitätsprüfung des Krypto-Schlüssels (KS-A...KS-X) auf der Basis einer digitalen Signatur derart realisiert wird, dass
a) der Krypto-Schlüssel (KS-A...KS-X) mit einem privaten Signa¬ tur-Schlüssel <"privat key"> signiert wird,
b) die Signatur des Krypto-Schlüssels (KS-A...KS-X) mit einem zu dem privaten Signatur-Schlüssel korrespondierenden öffentlichen Verifikation-Schlüssel <"public key"> verifiziert wird,
c ) wenn die Signatur des Krypto-Schlüssels (KS-A...KS-X) gültig ist, der Krypto-Schlüssel (KS-A...KS-X) in die Krypto- Hardwareeinheit (KHWE) geladen wird anderenfalls unterbleibt ein Laden des Krypto-Schlüssels (KS-A...KS-X) in die Krypto- Hardwareeinheit (KHWE) .
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels (KS- A...KS-X) paarweise sowohl ein neuer privater Signatur- Schlüssel als auch ein neuer öffentlicher Verifikation- Schlüssel generiert werden, der öffentliche Verifikation- Schlüssel durch den neuen öffentlichen Verifikation-Schlüssel aktualisiert wird und sowohl ein neuer Krypto-Schlüssel als auch der geänderte Krypto-Schlüssel mit dem neuen zu dem neu- en öffentlichen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüssel signiert werden.
6. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeich- net, dass
die Validitätsprüfung des Krypto-Schlüssels (KS-A...KS-X) auf der Basis einer erweiterten digitalen Signatur derart realisiert wird, dass
a) der Krypto-Schlüssel (KS-A...KS-X) einschließlich Krypto- Schlüssel-spezifischer Metadaten, vorzugsweise einer Versionsnummer, einem Erzeugungsdatum etc., mit einem privaten Signatur-Schlüssel <"privat key"> signiert wird,
b) die Signatur des Krypto-Schlüssels (KS-A...KS-X) mit einem zu dem privaten Signatur-Schlüssel korrespondierenden öffent- liehen Verifikation-Schlüssel <"public key"> verifiziert wird,
c ) wenn die Signatur des Krypto-Schlüssels (KS-A...KS-X) gültig ist, die Metadaten mit zu den Metadaten korrespondierenden, in einer zweiten "Positivliste (Whitelist) " enthaltenen Refe- renz-Metadaten abgeglichen werden anderenfalls wird das Laden des Krypto-Schlüssels (KS-A...KS-X) abgebrochen,
d) wenn der Abgleich ergibt, dass die Metadaten mit den Referenz-Metadaten übereinstimmen, dass dann der Krypto-Schlüssel (KS-A...KS-X) in die Krypto-Hardwareeinheit (KHWE) geladen wird anderenfalls unterbleibt ein Laden des Krypto-Schlüssels (KS- A...KS-X) in die Krypto-Hardwareeinheit (KHWE) .
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels (KS- A...KS-X) , insbesondere paarweise sowohl ein neuer privater Signatur-Schlüssel als auch ein neuer öffentlicher Verifika¬ tion-Schlüssel generiert werden, die Metadaten in der zweiten "Positivliste (Whitelist) " angepasst werden und ein neuer Krypto-Schlüssel mit dem zu dem öffentlichen Verifikation- Schlüssel korrespondierenden privaten Signatur-Schlüssel und den angepassten Metadaten signiert wird.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass
die Validitätsprüfung des Krypto-Schlüssels (KS-A...KS-X) auf der Basis einer CHALLENGE-RESPONSE-Prozedur mit in einer dritten "Positivliste (Whitelist) " enthaltenen CHALLENGE- RESPONSE-Zahlenpaaren derart realisiert wird, dass
a) der Krypto-Schlüssel (KS-A...KS-X) in die Krypto- Hardwareeinheit (KHWE) geladen wird,
b) mit der Krypto-Hardwareeinheit (KHWE) eine vorgegebene, auf einem aus der dritten "Positivliste (Whitelist) " ausge¬ wählten CHALLENGE-RESPONSE-Zahlenpaar basierende Krypto- Operation, vorzugsweise eine Verschlüsselung, mit dem geladenen Krypto-Schlüssel (KS-A...KS-X) und einer CHALLENGE-Zahl des ausgewählten CHALLENGE-RESPONSE-Zahlenpaars durchgeführt wird,
c ) wenn das Ergebnis der durchgeführten Krypto-Operation einer RESPONSE-Zahl des ausgewählten CHALLENGE-RESPONSE- Zahlenpaars entspricht, dass dann der geladene Krypto- Schlüssel (KS-A...KS-X) als valide eingestuft/angesehen, und vorzugsweise in der Krypto-Hardwareeinheit (KHWE) gespei¬ chert, wird anderenfalls wird der geladene Krypto-Schlüssel (KS-A...KS-X) als invalide eingestuft/angesehen, und vorzugs¬ weise aus der Krypto-Hardwareeinheit (KHWE) entfernt oder ein Zugriff auf die Krypto-Hardwareeinheit (KHWE) verweigert.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels (KS- A...KS-X) die dritte "Positivliste (Whitelist) " für einen neuen Krypto-Schlüssel aktualisiert wird.
10. Validierungseinheit (VDE) zum Steuern des Ladens von in IT-Systemen (ITS), insbesondere Eingebetteten Systemen (EBS) , benutzbaren Krypto-Schlüsseln (KS-A...KS-X) , insbesondere "Key BLOBs", wobei für das Laden
a) eine systemspezifische Anwendungssoftware (ASW) auf eine zur Ausführung systembezogener kryptografischer Operationen ausgebildete Krypto-Hardwareeinheit (KHWE) , insbesondere ein in dem System (IST, EBS) als Co-Prozessor zu einem Haupt- Prozessor (HPZ) genutzter Krypto-Prozessor (KPZ) oder ein in dem Haupt-Prozessor (HPZ) enthaltenes Krypto-Modul (KM) , zugreift und
b) mit diesem Zugriff der Krypto-Schlüssel (KS-A...KS-X) in die Krypto-Hardwareeinheit (KHWE) ladbar ist,
gekennzeichnet durch
c) eine Krypto-Schnittstelle (KSS) , über die die Validie¬ rungseinheit (VDE) zur Ausführung der systembezogenen krypto- grafischen Operationen mit der Krypto-Hardwareeinheit (KHWE) verbindbar ist,
d) eine Software-Schnittstelle (SWSS) , über die der Zugriff der systemspezifischen Anwendungssoftware (ASW) auf die
Krypto-Hardwareeinheit (KHWE) initial erfolgt,
e) eine Steuereinrichtung (STE) , die verbunden mit der
Krypto-Schnittstelle (KSS) und der Software-Schnittstelle (SWSS) und dabei eine Funktionseinheit bildend derart ausge¬ bildet ist, dass auf den über die Software-Schnittstelle (SWSS) erfolgten Zugriff der systemspezifischen Anwendungs- Software (ASW) der mit dem Zugriff zu ladende Krypto- Schlüssel (KS-A...KS-X) in der Steuereinrichtung (STE) auf Va¬ lidität geprüft wird, bevor der Krypto-Schlüssel (KS-A...KS-X) über die Krypto-Schnittstelle (KSS) in die Krypto- Hardwareeinheit (KHWE) geladen, insbesondere in der Krypto- Hardwareeinheit (KHWE) verwendet und durch die systemspezifi¬ sche Anwendungssoftware (ASW) genutzt, wird.
11. Validierungseinheit (VDE) nach Anspruch 10, dadurch ge¬ kennzeichnet, dass
ein nicht-flüchtiger, lesbarer Speicher (SP) , in dem rechen- werk-lesbare Steuerprogrammbefehle eines das Laden steuernden Programm-Moduls (PGM) gespeichert sind, und ein mit dem Spei¬ cher (SP) verbundenes Rechenwerk (RW) , das die Steuerpro¬ grammbefehle des Programm-Moduls (PGM) ausführt, in der Steu- ereinrichtung (STE) enthalten sind, die für die
Validitätsprüfung des Krypto-Schlüssels (KS-A...KS-X) auf der Basis einer Hashfunktion-Abbildung derart ausgebildet sind, dass a) in dem die Steuerprogrammbefehle des Programm-Moduls (PGM) ausführenden Rechenwerk (RW) der Krypto-Schlüssel (KS-A...KS-X) und ein durch die Hashfunktion-Abbildung generierter und zum Krypto-Schlüssel (KS-A...KS-X) korrespondierender Hash-Wert mit mindestens einem für das Laden in die Krypto-Hardwareeinheit (KHWE) erlaubten Referenz-Krypto-Schlüssel und mindestens ei¬ nem durch die Hashfunktion-Abbildung generierten, zu dem erlaubten Krypto-Schlüssel (KS-A...KS-X) korrespondierenden Refe- renz-Hash-Wert , der in dem Speicher (SP) in einer ersten "Po- sitivliste (Whitelist) " gespeichert ist, verglichen wird, b) wenn der Vergleich ergibt, dass der Hash-Wert des Krypto- Schlüssels (KS-A...KS-X) mit einem Referenz-Hash-Wert des Refe- renz-Krypto-Schlüssels in der ersten "Positivliste
(Whitelist) " übereinstimmt also in der "Positivliste
(Whitelist) " enthalten ist, dass dann der Krypto-Schlüssel
(KS-A...KS-X) in die Krypto-Hardwareeinheit (KHWE) geladen wird anderenfalls unterbleibt ein Laden des Krypto-Schlüssels (KS- A...KS-X) in die Krypto-Hardwareeinheit (KHWE) .
12. Validierungseinheit (VDE) nach Anspruch 11, dadurch gekennzeichnet, dass
der Speicher (SP) und das das Programm-Modul (PGM) ausführen¬ de Rechenwerk (RW) in der Steuereinrichtung (STE) derart ausgebildet sind, dass bei einer Änderung/einem Austausch, ins- besondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels (KS-A...KS-X) die erste "Positivliste
(Whitelist) " für einen neuen Krypto-Schlüssel aktualisiert wird .
13. Validierungseinheit (VDE) nach Anspruch 10, 11 oder 12, dadurch gekennzeichnet, dass
der Speicher (SP) und das das Programm-Modul (PGM) ausführen¬ de Rechenwerk (RW) in der Steuereinrichtung (STE) für die Validitätsprüfung des Krypto-Schlüssels (KS-A...KS-X) auf der Basis einer digitalen Signatur derart ausgebildet sind, dass a) der Krypto-Schlüssel (KS-A...KS-X) mit einem privaten Signa¬ tur-Schlüssel <"privat key"> signiert wird, b) die Signatur des Krypto-Schlüssels (KS-A...KS-X) mit einem zu dem privaten Signatur-Schlüssel korrespondierenden öffentlichen Verifikation-Schlüssel <"public key">, der in dem Speicher (SP) gespeichert ist, verifiziert wird,
c ) wenn die Signatur des Krypto-Schlüssels (KS-A...KS-X) gültig ist, der Krypto-Schlüssel (KS-A...KS-X) in die Krypto- Hardwareeinheit (KHWE) geladen wird anderenfalls unterbleibt ein Laden des Krypto-Schlüssels (KS-A...KS-X) in die Krypto- Hardwareeinheit (KHWE) .
14. Validierungseinheit (VDE) nach Anspruch 13, dadurch gekennzeichnet, dass
der Speicher (SP) und das das Programm-Modul (PGM) ausführen¬ de Rechenwerk (RW) in der Steuereinrichtung (STE) derart aus- gebildet sind, dass bei einer Änderung/einem Austausch des
Krypto-Schlüssels (KS-A...KS-X) paarweise sowohl ein neuer pri¬ vater Signatur-Schlüssel als auch ein neuer öffentlicher Verifikation-Schlüssel generiert werden, der öffentliche Veri¬ fikation-Schlüssel durch den neuen öffentlichen Verifikation- Schlüssel aktualisiert wird und sowohl ein neuer Krypto- Schlüssel als auch der geänderte Krypto-Schlüssel mit dem neuen zu dem neuen öffentlichen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüssel signiert werden.
15. Validierungseinheit (VDE) nach Anspruch 10, 11 oder 12, dadurch gekennzeichnet, dass
der Speicher (SP) und das das Programm-Modul (PGM) ausführen¬ de Rechenwerk (RW) in der Steuereinrichtung (STE) für die Validitätsprüfung des Krypto-Schlüssels (KS-A...KS-X) auf der Basis einer erweiterten digitalen Signatur derart ausgebildet sind, dass
a) der Krypto-Schlüssel (KS-A...KS-X) einschließlich Krypto- Schlüssel-spezifischer Metadaten, vorzugsweise einer Versionsnummer, einem Erzeugungsdatum etc., mit einem privaten Signatur-Schlüssel <"privat key"> signiert wird,
b) die Signatur des Krypto-Schlüssels (KS-A...KS-X) mit einem zu dem privaten Signatur-Schlüssel korrespondierenden öffent- liehen Verifikation-Schlüssel <"public key">, der in dem Speicher (SP) gespeichert ist, verifiziert wird,
c ) wenn die Signatur des Krypto-Schlüssels (KS-A...KS-X) gültig ist, die Metadaten mit zu den Metadaten korrespondierenden, in dem Speicher (SP) in einer zweiten "Positivliste
(Whitelist) " gespeicherten Referenz-Metadaten abgeglichen werden anderenfalls wird das Laden des Krypto-Schlüssels (KS- A...KS-X) abgebrochen,
d) wenn der Abgleich ergibt, dass die Metadaten mit den Refe- renz-Metadaten übereinstimmen, dass dann der Krypto-Schlüssel
(KS-A...KS-X) in die Krypto-Hardwareeinheit (KHWE) geladen wird anderenfalls unterbleibt ein Laden des Krypto-Schlüssels (KS- A...KS-X) in die Krypto-Hardwareeinheit (KHWE) .
16. Validierungseinheit (VDE) nach Anspruch 15, dadurch ge¬ kennzeichnet, dass
der Speicher (SP) und das das Programm-Modul (PGM) ausführen¬ de Rechenwerk (RW) in der Steuereinrichtung (STE) derart ausgebildet sind, dass bei einer Änderung/einem Austausch des Krypto-Schlüssels (KS-A...KS-X) , insbesondere paarweise sowohl ein neuer privater Signatur-Schlüssel als auch ein neuer öffentlicher Verifikation-Schlüssel generiert werden, die Meta¬ daten in der zweiten "Positivliste (Whitelist) " angepasst werden und ein neuer Krypto-Schlüssel mit dem zu dem öffent- liehen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüssel und den angepassten Metadaten signiert wird .
17. Validierungseinheit (VDE) nach einem der Ansprüche 10 bis 16, dadurch gekennzeichnet, dass
der Speicher (SP) und das das Programm-Modul (PGM) ausführen¬ de Rechenwerk (RW) in der Steuereinrichtung (STE) für die Validitätsprüfung des Krypto-Schlüssels (KS-A...KS-X) auf der Basis einer CHALLENGE-RESPONSE-Prozedur mit in dem Speicher (SP) in einer dritten "Positivliste (Whitelist) " gespeicher¬ ten CHALLENGE-RESPONSE-Zahlenpaaren derart ausgebildet sind, dass a) der Krypto-Schlüssel (KS-A...KS-X) in die Krypto- Hardwareeinheit (KHWE) geladen wird,
b) mit der Krypto-Hardwareeinheit (KHWE) eine vorgegebene, auf einem aus der dritten "Positivliste (Whitelist) " ausge- wählten CHALLENGE-RESPONSE-Zahlenpaar basierende Krypto-
Operation, vorzugsweise eine Verschlüsselung, mit dem geladenen Krypto-Schlüssel (KS-A...KS-X) und einer CHALLENGE-Zahl des ausgewählten CHALLENGE-RESPONSE-Zahlenpaars durchgeführt wird,
c ) wenn das Ergebnis der durchgeführten Krypto-Operation einer RESPONSE-Zahl des ausgewählten CHALLENGE-RESPONSE- Zahlenpaars entspricht, dass dann der geladene Krypto- Schlüssel (KS-A...KS-X) als valide eingestuft/angesehen, und vorzugsweise in der Krypto-Hardwareeinheit (KHWE) gespei- chert, wird anderenfalls wird der geladene Krypto-Schlüssel (KS-A...KS-X) als invalide eingestuft/angesehen, und vorzugs¬ weise aus der Krypto-Hardwareeinheit (KHWE) entfernt oder ein Zugriff auf die Krypto-Hardwareeinheit (KHWE) verweigert.
18. Validierungseinheit (VDE) nach Anspruch 17, dadurch ge¬ kennzeichnet, dass
der Speicher (SP) und das das Programm-Modul (PGM) ausführen¬ de Rechenwerk (RW) in der Steuereinrichtung (STE) derart ausgebildet sind, dass bei einer Änderung/einem Austausch, ins- besondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels (KS-A...KS-X) die dritte "Positivliste
(Whitelist) " für einen neuen Krypto-Schlüssel aktualisiert wird .
19. Validierungseinheit (VDE) nach einem der Ansprüche 10 bis 18, gekennzeichnet durch
das Ausgebildet Sein als Komponente eines Betriebssystem- Kernels des IT-Systems (ITS, EBS) mit den zum IT-System (ITS, EBS) gehörenden Haupt-Prozessor (HPZ) und dem Krypto- Prozessor (KPZ) oder dem Krypto-Modul (KM) , wobei die Vali¬ dierungseinheit (VDE) dabei entweder in dem Betriebssystem- Kernel integriert oder als signiertes Kernel-Modul implemen¬ tiert ist und wobei Funktion der Steuereinrichtung (STE) so- wie die Funktionalität der Steuereinrichtung (STE) repräsentiert durch das das Programm-Modul (PGM) ausführende Rechen¬ werk (RW) und den das Programm-Modul (PGM) speichernde Spei¬ cher (SP) durch den Haupt-Prozessor (HPZ) ausgeübt wird.
20. Validierungseinheit (VDE) nach einem der Ansprüche 9 bis 16, gekennzeichnet durch
das Ausgebildet Sein als Digitale Schaltung eines FPGA- Schaltkreis des IT-Systems (ITS, EBS) mit den zum System (ITS, EBS) gehörenden Haupt-Prozessor (HPZ) und dem Krypto- Prozessor (KPZ) oder dem Krypto-Modul (KM) .
PCT/EP2018/050611 2017-02-21 2018-01-11 Verfahren und validierungseinheit zum steuern des ladens von in it-systemen, insbesondere eingebetteten systemen, benutzbaren krypto-schlüsseln, insbesondere "key blobs" WO2018153559A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017202787.8 2017-02-21
DE102017202787.8A DE102017202787A1 (de) 2017-02-21 2017-02-21 Verfahren und Validierungseinheit zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere "Key BLOBs"

Publications (1)

Publication Number Publication Date
WO2018153559A1 true WO2018153559A1 (de) 2018-08-30

Family

ID=61094415

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/050611 WO2018153559A1 (de) 2017-02-21 2018-01-11 Verfahren und validierungseinheit zum steuern des ladens von in it-systemen, insbesondere eingebetteten systemen, benutzbaren krypto-schlüsseln, insbesondere "key blobs"

Country Status (2)

Country Link
DE (1) DE102017202787A1 (de)
WO (1) WO2018153559A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110909316A (zh) * 2019-11-14 2020-03-24 武汉正维电子技术有限公司 一种单片机软件的加密保护方法及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060013402A1 (en) * 2004-07-14 2006-01-19 Sutton James A Ii Method of delivering Direct Proof private keys to devices using an on-line service
WO2009018481A1 (en) * 2007-07-31 2009-02-05 Viasat, Inc. Multi-level key manager
WO2014155363A1 (en) * 2013-03-29 2014-10-02 Ologn Technologies Ag Systems, methods and apparatuses for secure storage of data using a security-enhancing chip

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7908483B2 (en) 2005-06-30 2011-03-15 Intel Corporation Method and apparatus for binding TPM keys to execution entities
CN103595530B (zh) 2012-08-17 2017-04-26 华为技术有限公司 软件密钥更新方法和装置
US9838367B2 (en) 2015-06-26 2017-12-05 Intel Corporation Binding a trusted input session to a trusted output session

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060013402A1 (en) * 2004-07-14 2006-01-19 Sutton James A Ii Method of delivering Direct Proof private keys to devices using an on-line service
WO2009018481A1 (en) * 2007-07-31 2009-02-05 Viasat, Inc. Multi-level key manager
WO2014155363A1 (en) * 2013-03-29 2014-10-02 Ologn Technologies Ag Systems, methods and apparatuses for secure storage of data using a security-enhancing chip

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110909316A (zh) * 2019-11-14 2020-03-24 武汉正维电子技术有限公司 一种单片机软件的加密保护方法及存储介质
CN110909316B (zh) * 2019-11-14 2023-05-09 武汉正维电子技术有限公司 一种单片机软件的加密保护方法及存储介质

Also Published As

Publication number Publication date
DE102017202787A1 (de) 2018-08-23

Similar Documents

Publication Publication Date Title
EP2899714B1 (de) Gesichertes Bereitstellen eines Schlüssels
DE102013227184A1 (de) Verfahren zur Absicherung eines Systems-on-a-Chip
DE102009013384B4 (de) System und Verfahren zur Bereitstellung einer sicheren Anwendungsfragmentierungsumgebung
DE102013105042A1 (de) Sicheres Flashprogrammieren eines sekundären Prozessors
DE102014114607A1 (de) Programmierung von Fahrzeugmodulen mit Remotevorrichtungen und zugehörige Methoden und Systeme
DE102012110499A1 (de) Sicherheitszugangsverfahren für elektronische Automobil-Steuergeräte
DE102015209108A1 (de) Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
DE102013108022A1 (de) Verfahren zum Aktivieren des Entwicklungsmodus eines gesicherten elektronischen Steuergeräts
DE102013108020A1 (de) Authentifizierungsschema zum Aktivieren eines Spezial-Privileg-Modus in einem gesicherten elektronischen Steuergerät
DE102014220616A1 (de) Verfahren zum Laden von ausführbaren Programminstruktionen in eine Chipkarte im Wirkbetrieb
DE102014208855A1 (de) Verfahren zum Durchführen einer Kommunikation zwischen Steuergeräten
DE102015113468A1 (de) Datenverarbeitungsvorrichtung und verfahren zum sichern einer datenverarbeitungsvorrichtung gegen angriffe
WO2017102295A1 (de) Verfahren und sicherheitsmodul zum bereitstellen einer sicherheitsfunktion für ein gerät
DE102016210788A1 (de) Komponente zur Verarbeitung eines schützenswerten Datums und Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente
EP3811260B1 (de) Kryptografiemodul und betriebsverfahren hierfür
EP3314339B1 (de) Verfahren, server, firewall, steuergerät, und system zur programmierung eines steuergeräts eines fahrzeugs
WO2018153559A1 (de) Verfahren und validierungseinheit zum steuern des ladens von in it-systemen, insbesondere eingebetteten systemen, benutzbaren krypto-schlüsseln, insbesondere &#34;key blobs&#34;
EP3819804A1 (de) Integritätsüberprüfung eines registerinhalts
EP3286872B1 (de) Bereitstellen eines gerätespezifischen kryptographischen schlüssels aus einem systemübergreifenden schlüssel für ein gerät
DE102014222622A1 (de) Verfahren zur Änderung einer in einer Chipkarte gespeicherten Datenstruktur, Signaturvorrichtung und elektronisches System
DE102014208853A1 (de) Verfahren zum Betreiben eines Steuergeräts
DE102020207863A1 (de) Verfahren zur sicheren Aktualisierung von Steuergeräten
DE102020002055A1 (de) Datenverarbeitungsvorrichtung zur Provisionierung eines Hardware-Prozessorsystems
WO2019166398A1 (de) Computerprogramm, insbesondere für ein steuergerät eines kraftfahrzeugs
DE102023113779A1 (de) Sichere speicherarchitekturen für computergeräte

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18702096

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18702096

Country of ref document: EP

Kind code of ref document: A1