WO2017108192A1 - Validierung und ausführung von provisionierungsdaten auf appliances - Google Patents

Validierung und ausführung von provisionierungsdaten auf appliances Download PDF

Info

Publication number
WO2017108192A1
WO2017108192A1 PCT/EP2016/002174 EP2016002174W WO2017108192A1 WO 2017108192 A1 WO2017108192 A1 WO 2017108192A1 EP 2016002174 W EP2016002174 W EP 2016002174W WO 2017108192 A1 WO2017108192 A1 WO 2017108192A1
Authority
WO
WIPO (PCT)
Prior art keywords
implementor
provisioning
mcu
validator
validation
Prior art date
Application number
PCT/EP2016/002174
Other languages
English (en)
French (fr)
Inventor
Udo Schwartz
Kurt Stadler
Original Assignee
Giesecke & Devrient Gmbh
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 Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Publication of WO2017108192A1 publication Critical patent/WO2017108192A1/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/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • provisioning means that data for setting up configurations, commands, etc. are loaded from an authorized server to a remote client appliance.
  • This provisioning causes changes to the configuration, in particular the operating mode, security model, user credentials (for example cryptographic
  • Provisioning data includes an actual payload, i. Configuration information (such as a feature enable pattern) that constitutes the actual provisioning instruction. Furthermore, the provisioning data comprise authentication information such as signatures and certificates with which the provisioning data, in particular the payload, can be validated. With the implementation or implementation of the provisioning data, in particular the payload, in connection with the invention the process is referred to, with which provisioning data, in particular payload, are converted into influencing the provisioned appliance.
  • provisioning data are transmitted from a server, eg a truncated service manager TSM, via insecure corri- ration connections and imported by untrustworthy (software) agents.
  • a server eg a truncated service manager TSM
  • the client device has to check whether the originator the provisioning data and / or the server sending the provisioning data is entitled to provisioning, and also whether the provisioning data is authentic.
  • Process refers to the security-relevant aspects of the provisioning data are checked or / and confirmed.
  • Secure provisioning thus consists of validation and execution of provisioning data.
  • Provisioning System For the entirety of device (Applicance) and servers or servers that are involved in the provisioning, the term Provisioning System is also used below.
  • the provisioning data is usually transmitted over an insecure communication link. They therefore provide an attack surface to compromise the security of the system.
  • the cryptographic check is performed before provisioning data can be used.
  • the cryptographic procedures required to verify and, as a result of positive verification, validation must be done in a secure environment as key material is usually used for verification.
  • provisioning data can be time consuming, making it incompatible with real-time requirements.
  • client appliances appliances used in industrial plants as control devices (control and / or measuring devices) often require provisioning in real time. So far, a common solution to the real-time problem is to compromise security and to largely or completely omit validation of provisioning data to meet the requirement of real-time provisioning.
  • the invention is based on the object to realize a secure and time-efficient provisioning, which can also be used if conventional leu due to real-time applications, requirements for technology or security (eg tamper proof) or limited availability of resources possible are.
  • the invention follows the approach of separating an appliance from the provisioning (validation) of provisioning data and its execution (i.e., interpretation) so that the process of provisioning the appliance is divided into a validation process and an execution process.
  • TEs Two secure environments TE are introduced, hereinafter referred to as TEs, "Trusted Environments", which are connected via a trust relationship.
  • a first TE the TE implementor, comprises an implementation functionality (or is at least to accommodate such a one). directed) and is responsible for executing the provisioning data, in particular a payload contained in the provisioning data, in order to implement the provisioning in the device.
  • the validation or (equivalent) validation of the provisioning data is delegated to another TE, the TE Validator.
  • the TE validator includes (or is at least established to include) a validation functionality by means of which provisioning data can be validated.
  • the TE Implementor will only accept provisioning data previously verified by the TE Validator.
  • the invention enables different implementation techniques for the participating TEs.
  • Validation by TE Validator may occur in another, especially an upstream, operational phase (provisioning phase of provisioning, in which provisioning data is sent externally (eg from an external server) to the MCU) as the execution / implementation (in an implementation phase, which may, for example, be in a boot phase when booting the MCU).
  • provisioning phase of provisioning in which provisioning data is sent externally (eg from an external server) to the MCU) as the execution / implementation
  • an implementation phase which may, for example, be in a boot phase when booting the MCU.
  • an appliance can be provided in particular: a client device in an industrial plant, in particular a control device (control and / or measuring device), or a chip package (a housed chip) for such a device.
  • the TE ⁇ -Implementor is an activation unit, the features (resource components such as individual hardware components) eg on a configurable controller chip unlocked and must be performed entirely in (trusted) hardware.
  • the cryptographic resources and storage capabilities are limited in the TE implementor.
  • the activation must occur every time the device is started up (since the activation unit usually has no non-volatile memory), and there are often stringent running time restrictions (of the order of less than 10 milliseconds) in this phase.
  • the TE validator can be implemented in a technology that is better equipped for security functions (eg as a secure element, or as TEE or software in safe execution mode). This special component is very well suited for cryptographic tasks. It can also perform time-consuming validation steps at the time of provisioning. However, the TE validator has no direct access to trusted hardware and is not fast enough to validate the provisioning data during the boot phase. The problem is solved by a collaboration of TE Validator and TE Implementor, whereby TE Validator and TE Implementor must be in a trust relationship.
  • the TE validator generates a "Secure Object" in a provisioning phase of the provisioning if the validation of the provisioning data was successful.
  • a "Secure Object” (SO) is a data structure (object) secured by cryptographic methods. , which enables the provisioning and the payload contains, that is, the actual, causing the Provisioning data.
  • the SO is made accessible to the TE implementor (eg via a shared memory).
  • the existence of a valid SO is sufficient proof for the TE implementor that the provisioning data has been verified. Based on the trust relationship between TE Implementor and TE Validator, the TE Implementor trusts this data.
  • the SO is also cryptographically secured, it is designed to be much easier and faster for the TE implementor.
  • the SO may be designed to be efficiently validated by symmetric crypto techniques.
  • the verification of provisioning data may require the verification of certificates (or entire certificate chains) and signatures, and therefore complex asymmetric procedures, as well as the observance of certificate revocations, depending on the relationship of the external authorities.
  • the appliance has at least one provisional object that can be provisioned by the implementation functionality of the TE implementor.
  • a secure object is stored in the non-volatile memory, which comprises a payload contained in the provisioning data and a validation element determined from the provisioning data.
  • the payload is set up to be executed by the TE implementor, whereby implementation of the payload results in implementation of the provisioning in the MCU.
  • the "payload” is, for example, a feature enable pattern that can directly configure the MCU
  • the validation element has been generated by means of a first authentication process of the authentication of the provisioning data by the validation functionality of the TE validator. Element enables the provisioning data to be authenticated by the TE implementor by means of a second, different authentication process.
  • non-volatile storage (outside the secure object) also stores those provisioning data from which the Secure Object has been created, e.g. in a provisioning package.
  • the provisioning data is e.g. received by the server and stored in non-volatile memory before the Secure Object is generated based on the stored provisioning data.
  • the secure object-equipped appliance has already passed through a provisioning phase of a provisioning process.
  • the provisioning data was provided to the MCU externally, for example, from an external server.
  • the TE Validator has taken steps to verify the provisioning data and generated the Secure Object as a result of the validation. The review can involve time-consuming steps such as signature verification.
  • the TE Validator generates the Secure Object and stores it in the non-volatile memory.
  • the Secure Object contains the payload of the validated provisioning data.
  • the appliance in particular the MCU, optionally remain for a long time.
  • TE implemen- tary is required to complete the provisioning of the MCU by applying the payload, but not TE validator anymore.
  • TE Implementor only needs to verify the secure object and, in the case of positive verification, can immediately apply the payload of the provisioning data to the MCU and thereby complete the provisioning.
  • the implementation phase may, for example, occur during a startup / booting of the MCU when the appliance, which was previously in a waiting position, is put into operation.
  • the second authentication process takes less time than the first authentication process.
  • a time-consuming complete validation of provisioning data can be advanced to a suitable time, for example before the MCU is put into operation.
  • the time-saving second authentication process which takes place using the previously generated Secure Object, takes place.
  • a hardware component of the MCU in particular a processor core, a memory, in particular ROM, RAM, EEPROM or Flash, a coprocessor, in particular crypto coprocessor, an interface , especially UART interface.
  • the provisioning data comprises as payload a feature enable pattern, ie a bit pattern that can be executed by the implementation functionality, wherein the execution of the feature enable pattern (bit pattern) by the implementation functionality causes a feature to be added to the MCU enable pattern corresponding configuration is set up.
  • the TE validator and the TE implementor have cryptographic keys with which the TE implementor can verify the authenticity of the TE validator and with which, in the non-volatile memory, a Secure Object is stored TE Implementor can verify the authenticity of the Secure Object.
  • the relocation of a complex, complex security procedure, such as the first authentication process into a less complex secure object and a less complex second authentication process, can a priori involve the risk of a security loss. Since TE validator and TE implementor are secure execution environments that are in mutual trust, e.g. by key agreement, the security is nevertheless maintained.
  • the TE validator is designed as a software-secured environment, in particular as a trusted execution environment or as a partial functionality of the MCU in a secure mode of operation, or as a secure element separate from the MCU, and where the validation functionality is validation Software, in particular a validation application, in particular a validation applet, by means of which the validation element can be verified.
  • the TE implementor is implemented as secure hardware in the MCU, and the implementation functionality is configured as hardware for configuring the MCU, particularly as a feature enable control to enable features of the MCU.
  • the payload is designed as a feature enable pattern and the implementation functionality is configured as the MCU-associated, trusted hardware-enabled feature enable controller.
  • the non-volatile memory is implemented either in the MCU or in an integrated circuit arrangement separate from the MCU.
  • the non-volatile memory may further be optionally disposed on the same chip as the MCU, or on a separate chip.
  • the separate chip can optionally be enclosed in the same housing as the MCU chip.
  • the appliance is designed as one of the following: control device, in particular control device, measuring device or combined control and measuring device, for an industrial plant; A chipset (comprising one or more chips, e.g., application controllers, baseband controllers, interface controllers) for a mobile terminal; M2M module for an industrial plant; Automotive M2M module.
  • control device in particular control device, measuring device or combined control and measuring device, for an industrial plant
  • a chipset comprising one or more chips, e.g., application controllers, baseband controllers, interface controllers
  • M2M module for an industrial plant
  • Automotive M2M module for an industrial plant.
  • the secure object as the validation element for the second authentication process includes one or more of the following: a A checksum, a cryptographic checksum, a hash value, a Message Authentication Code MAC, each formed using the provisioning data, a constant and well-defined value ("magic value"), leaving a check sum, a hash value, a MAC, a constant value Verify comparatively quickly.
  • a successful verification of a cryptographic signature or / and a certificate is provided, i. only under the condition that the signature or / and the certificate is successfully verified in a provisioning phase of the provisioning (and if other conditions are met, if applicable), the secure object is generated and output to the NVM.
  • the verification of a signature is more time consuming than the verification of a signature
  • Hash value MAC, check sum, etc.
  • a method for provisioning an appliance includes a microcontroller array, which in turn has a microcontroller unit MCU, a TE validator, a TE implementor, and a non-volatile memory (NVM) that is writable for the TE validator and for the TE implementor readable, includes, in a provisioning phase of provisioning:
  • provisioning data for provisioning the MCU from a server to the TE validator; optionally also storing the Provision istswolf in the MCU (especially in non-volatile memory) to have them for subsequent generation of the Secure Object available;
  • the TE validator performing a first authentication process in which the provisioning data is authenticated, and in the case of successful authentication of the provisioning data, generating a secure object containing a payload contained in the provisioning data; loacl and a validation element determined from the provisioning data, and storing the generated secure object in nonvolatile memory, wherein in the secure object:
  • the payload is arranged to be executed by the TE implementor, wherein execution of the payload causes implementation of the provisioning in the MCU;
  • the validation element enables an authentication of the provisioning data by the TE implementor by means of a second, different from the first, authentication process.
  • the MCU is in a state where completion of the provisioning is possible by the TE implementor, i. in particular without the TE validator, and only with the preferably less complex second authentication process.
  • the TE implementor reading the Secure Object from the non-volatile memory, and, by means of the read Secure Object, performing the second, different from the first, authentication process to authenticate the Provisioning data;
  • FIG. 1 shows a microcontroller arrangement (chip package) with an MCU, which comprises a TE validator and a TE implementor, as well as with a persistent data memory NVM, according to an embodiment of the invention
  • FIG. 2 shows a detail view of the device with microcontroller arrangement (chip package) from FIG. 1, with detail representation of the components TE validator, TE implementor and persistent data memory NVM;
  • Fig. 3 is a flowchart for establishing the trust relationship and the exchange or agreement of the keys
  • FIG. 5 is a flowchart of the boot process when the TE implementor can not trust the provisioning data.
  • FIG. 6 is a flowchart for the first authentication process in which the TE validator checks the provisioning data and generates the secure object from the provisioning data.
  • An appliance in a proofing system according to an embodiment of the invention shown in Fig. 1 is realized by the interaction of the following components integrated within the appliance (i.e., the technical appliance):
  • TE Validator A secure environment for reviewing provisioning data produced by Eco-System authorities.
  • the provisioning data generally comes from one or more Trusted Service Managers (TSMs).
  • TSMs Trusted Service Managers
  • TE Implementor a secure environment with logic to implement / process provisioning data, in particular the Payload.
  • the implementation means personalization, creation of credentials, activation of resources, features etc.
  • NVM a non-volatile (persistent, non-volatile) memory on the appliance.
  • the NVM is readable for the TE implementor and writable for the TE validator.
  • the NVM can be implemented as an external component.
  • ROM an immutable memory (content can not be changed) in the appliance. This memory is also accessible to the TE implementor.
  • ⁇ NWd the normal environment from which no security requirements are expected. This is the environment in which the operating software runs, including the kernel of the operating system. This component realizes the communication between the other components.
  • the provisioning system also includes an Eco system that generates commissioning data:
  • TSM external server that generates provisioning data (or obtains from a data creation server) and provides it to the appliance.
  • the Eco system may include multiple TSMs representing different authorities.
  • Fig. 2 shows a provisioning system comprising an appliance and an external server TSM which physically communicate with each other via the Internet
  • the trust relationship between the TE implementor and the TE validator is ensured by a cryptographically secured
  • PK.Root Public The public key of the issuer of the TE key validator. These keys may be in the TE itself or in the ROM area of the appliance accessible to the TE. It must be ensured that the PK.Root can not be exchanged
  • the key can be generated, for example, by a PUF (Physical Uncloneable Function), by "fuses” or by key injection during production.
  • PUF Physical Uncloneable Function
  • the nonce is not a real key, but optionally a one time value.
  • the purpose of the nonce is to prevent replay attacks on the secure object; Each time a trust relationship is rebuilt, a new nonce is generated and all existing secure objects automatically become invalid.
  • the nonce may have a lower bit length than key. This can reduce the burden on the TE implementor.
  • the nonce must be stored or created in the TE implementor
  • the TE validator has the following keys
  • Name Type Description SK.Val Private The private part of the key pair speci fi c fish for the TE validator. The key pair is generated by the issuer and entered into the TE validator.
  • PK.Val Public The public part of the key pair specifies the TE validator.
  • the signature is generated by means of the private key (SK.Root) of the issuer s the TE validator
  • FIG. 3 shows the structure of a trust relationship between a TE validator and a TE implementor in a setup phase prior to the actual provisioning.
  • the establishment of the trust relationship takes place in the setup phase, which can take place once.
  • the TE Implementor checks the certificate using the public key PK.Root, which is stored in the ROM of the appliance. This key can be trusted because the ROM is not changeable.
  • the TE Implementor generates a nonce and sends it and the K.SO to the TE validator.
  • the TE validator sends the Cert certificate.
  • Val Cert.TE2 to the TE Implementor.
  • the certificate contains the public key of the TE and is signed with the issuer's private key (SK.Root)
  • PK.Root The TE implementor reads the public key PK.Root of the issuer from the ROM of the chip.
  • the TE implementor checks the signature of the certificate Cert-TE2 using the public key P Root. If the verification is successful, the TE Implementor trusts the certificate and the public key contained in the TE Validator.
  • the TE Implementor generates a unique value (nonce). This can e.g. done by a random number generator.
  • the (optional) nonce is stored internally in the TE implementor.
  • the nonce is for replay protection.
  • the TE Implementor encrypts the nonce and the own key K.SO with the public key from the certificate Cert.TE2.
  • the cryptogram is given to the TE validator.
  • K.SO is a symmetric key that is generated or stored in the TE Implementor. Issuing this key to the TE Validator does not pose a security risk because the two TEs are in the same appliance, trusting each other and should be bound duaerhaft anyway.
  • the key K.SO can also be an asymmetric key, whereby the private part of the TE-Validator ("writer", the producer of the SO) and the public part of the TE-Implementor should be TE2 and PK.TE2 are used, the TE Implementor must internally save the public part. • A hybrid method can also be used.
  • the secure object is encrypted by a symmetric key K.SO, which is generated by the producer (TE validator).
  • the K.SO itself is wrapped with the private key SK.TE2. Both the wrapped key and the secure object are exposed in the NVM and are readable by the TE implementor.
  • the Secure Object contains, in a preferred version:
  • a validation element e.g. a checksum, or a key check value or MAC etc.
  • the nonce is optional.
  • the nonce serves only for replay protection and makes it possible to invalidate already issued secure objects. In some scenarios, however, this is not necessary (for example, because invalidated secure objects can be reliably deleted) or even not desired, for example if all ever issued secure objects are to remain valid.
  • One possible application scenario could be to switch dynamically during the boot process between different configurations (e.g., test and production).
  • the nonce requires a non-volatile storage facility in the TE Implementor.
  • the payload e.g., a feature enable pattern
  • the payload is inherited from the provisioning data as it was generated by the TSM.
  • the validation element ensures that the memory in the NVM really contains a secure object.
  • the validation element can and should be very easy to compute, hence the TE Implementor is not charged, as is the case for a checksum.
  • the hash can also be replaced with a hash or MAC, although this will often be too expensive for the underlying use case.
  • only a constant key check value can be used. This is a static value that exists between TE
  • Fig. 4 shows a flow diagram of a boot phase of an MCU following the setup phase, in the case of a successful boot, with successful verification of the secure object.
  • Fig. 5 shows the Fig. 4 corresponding flow chart for a faulty, unsuccessful verification of the Secure Object.
  • the TE Implementor enters the payload from the provisioning data into the MCU to provision the MCU
  • the TE Implementor exclusively uses the Secure Object SO for this purpose.
  • Provisioning data and verifying the Secure Object are Provisioning data and verifying the Secure Object.
  • FIG. 6 shows a flow diagram of the first validation process in the provisioning phase, in which case the TE validator generates the secure object in the event of success. It is a prerequisite that the TE validator and the TE implementor are in one of the ways already described, e.g. according to Fig. 3, the trust relationship have built.
  • provisioning data here in the form of a provisioning package, are requested by the external server (TSM).
  • TSM external server
  • the Provisioning Package is checked by the TE Validator. In the scenario shown, the check is positive and the provisioning data is accepted.
  • the TE Validator generates the Secure Object using the common key K.TE1; this key was exchanged or derived in the course of establishing the trust relationship with the TE Implementor.
  • the TE Validator stores the generated Secure Object SO in the non-volatile NVM memory.
  • the storage location is agreed in advance with the TE Implementor by convention.
  • the TE validator initiates a re-boot of the appliance to exit the provisioning mode and allow the newly provisioned provisioning to take effect, eg, with the method shown in FIGS. 4, 5. If the Secure Object and / or Nonce is invalid ( Figure 5), the TE Implementor denies provisioning. The boot process will be aborted and the appliance will be put into a fail-safe mode. Other fallback treatments as demolition are also possible.
  • the invention includes the case where the TE validator handles the validation of probe visa data for multiple TE implementors. In this scenario, the TE Validator establishes a bilateral trust relationship with each TE implementor to be served. After verifying the provisioning data, the TE validator generates a specialized secure object for each TE implementor.

Landscapes

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

Abstract

Die Erfindung schafft für eine Appliance umfassend eine Microcontroller-Anordnung umfassend eine Micro-Controller-Unit MCU, eine TE-Validator, eine TE-Implementor und einen nicht-flüchtigen Speicher (NVM), der für die TE-Validator schreibbar und für die TE-Implementor lesbar ist ein Verfahren, um eine sichere Provisionierung in zeitkritischen und Ressourcenbeschränkten Anwendungsfällen zu ermöglichen. Kern des beschriebenen Verfahrens ist die Trennung der notwendigen Validierung der Provisionierungsdaten von deren Implementierung, wobei nur die Implementierung ist von Echtzeit-Bedingungen und Ressourcen-Beschränkungen betroffen ist. Die Validierung erfolgt in einer eigenen Komponente (TE-Validator), die speziell für diese Aufgabe ausgestattet sein kann und unabhängig (d.h. zu einem anderen Zeitpunkt) als die Implementierung. Die Implementierung erfolgt auf der MCU (durch die Komponente TE-Validator) und muss in zeitkritischen Phasen der Ausführung möglich sein, insbesondere in der Boot-Phase. Das Verfahren beruht auf einer Vertrauensbeziehung zwischen der Validierungskomponente und der Implementierungskomponente. Die Validierungskomponente führt die aufwendige Validierung durch und signalisiert durch die Erzeugung eines kryptografisch gesichertes Objekt (Secure Object) die Korrektheit und Authentizität der Daten. Dieses kryptografische Objekt kann die den Implementierer unmittelbar und auf einfache Weise interpretiert und umgesetzt werden, jedenfalls deutlich effizienter als die eigentliche Validierung.

Description

Validierung und Ausführung von Provisionierungsdaten auf Appliances
Gebiet der Erfindung
Die Provisionierung von Client Geräten (auch Appliances genannt) ist ein wichtiger Bestandteil des Sicherheits-Managements von IT Systemen. Im Kontext dieser Erfindung bedeutet Provisionierung, dass Daten zum Einrichten von Konfigurationen, Kommandos usw. von einem autorisierten Server auf ein entferntes Client Gerät (Appliance) geladen werden. Diese Provisionierung bewirkt Veränderungen an der Konfiguration, insbesondere am Be- triebsmodus, Security-Model, User-Credentials (z.B. kryptographischen
Schlüsseln, Zertifikaten, etc.), Personalisierungszustand (z.B. personalisiert/ unpersonalisiert/ in welchem Ausmaß personalisiert ...) usw. des Appliance. Provisionierungsdaten umfassen einen eigentlichen Payload, d.h. Konfigurierungsinformation (wie z.B. ein feature enable pattern), das die eigent- lieh Anweisung zur Provisionierung bildet. Weiter umfassen die Provisionierungsdaten Authentisierungsinf ormation wie Signaturen und Zertifikate, mit denen die Provisionierungsdaten, insbesondere die Payload, validierbar sind. Mit Ausführung oder Implementierung der Provisionierungsdaten, insbesondere der Payload, wird im Zusammenhang mit der Erfindung der Vorgang bezeichnet, mit dem Provisionierungsdaten, insbesondere Payload, in eine Beeinflussung des provisionierten Appliance umgesetzt werden.
Meist werden Provisionierungsdaten von einem Server aus, z.B. einem Trus- ted Service Manager TSM, über unsichere Korrimunikationsverbindungen übertragen und durch nicht-vertrauenswürdige (Software-) Agenten eingespielt, deshalb muss aus Gründen der Sicherheit das Client Gerät (Appliance) prüfen, ob der Urheber der Provisionierungsdaten oder/ und der Server, der die Provisionierungsdaten sendet, zur Provisionierung berechtigt ist, und auch ob die Provisionierungsdaten authentisch sind. Im Zusammen- hang mit der Erfindung wird mit Validierung von Provisionierungsdaten ein Vorgang bezeichnet, mit dem sicherheitsrelevante Aspekte der Provisionie- rungsdaten überprüft oder/ und bestätigt werden.
Eine sichere Provisionierung setzt sich somit zusammen aus einer Validie- rung und einer Ausführung von Provisionierungsdaten.
Für die Gesamtheit von Gerät (Applicance) und Server oder Servern, die an der Provisionierung beteiligt sind, wird nachfolgend auch der Begriff Provi- sionierungs-System verwendet.
Stand der Technik
Die Provisionierungsdaten werden in der Regel über eine unsichere Kommunikationsverbindung übertragen. Sie bieten deshalb eine Angriffsfläche um die Sicherheit des Systems zu kompromittieren.
Provisionierungsdaten müssen deshalb geschützt werden, um sicherzustellen dass die Daten:
• Im Transport oder auf dem Client Gerät (Appliance) nicht verändert wurden (Integrität);
• Tatsächlich von einem zugelassenen Server stammen (Authentizität);
• Nicht von einem Angreifer eingesehen werden (Vertraulichkeit);
• Nicht von einem anderen Client Gerät (Appliance) kopiert wurden.
Um diesen Schutzeffekt zu bekommen, werden kryptographische Verfahren eingesetzt.
Die kryptographische Überprüfung erfolgt bevor Provisionierungsdaten verwendet werden können. Die zur Überprüfung und, als Ergebnis positiver Überprüfung, Validierung erforderlichen kryptographischen Verfahren müssen in einer sicheren Umgebung durchgeführt werden, da zur Überprüfung in der Regel Schlüsselmaterial verwendet wird.
Die notwendige Validierung der Provisionierungsdaten kann zeitaufwendig sein, sodass sie mit Echtzeit- Anforderungen unvereinbar wird. Gerade Client Geräte (Appliances), die in Industrieanlagen als Regelungsgeräte (Steueroder/ und Messgeräte) verwendet werden, fordern häufig eine Provisionierung in Echtzeit. Bislang ist eine verbreitete Lösung des Echtzeitproblems, Abstriche bei der Sicherheit zu machen und eine Validierung der Provisio- nierungsdaten weitgehend oder vollständig zu unterlassen, um dem Erfordernis der Echtzeit-Provisionierung zu genügen.
Der Erfindung liegt die Aufgabe zu Grunde, eine sichere und zeitlich effiziente Provisionierung zu realisieren, die auch einsetzbar ist, wenn herkömm- liehe Verfahren wegen Echzeitanf orderungen, Anforderungen an die Technologie oder Sicherheit (z.B. Tamper-Proof) oder wegen beschränkter Verfügbarkeit von Ressourcen nicht möglich sind.
Zusammenfassung der Erfindung
Die Erfindung verfolgt den Ansatz, bei der Provisionierung eines Appliance die Prüfung (Validierung) von Provisionierungsdaten und deren Ausführung (d.h. Interpretation) zu trennen, so dass der Vorgang der Provisionierung des Appliance geteilt wird in einen Validierungs- Vorgang und einen Ausführungs- Vorgang.
Dazu werden zwei sichere Umgebungen TE eingeführt, im Folgenden genannt TEs,„Trusted Environments", die über eine Vertrauensbeziehung verbunden sind. Eine erste TE, die TE-Implementor, umfasst eine Implementierungs-Funktionalität (oder ist zumindest zur Aufnahme einer solchen ein- gerichtet) und ist für die Ausführung der Provisionierungsdaten, insbesondere einer in den Provisionierungsdaten enthaltenen Payload, zuständig, um die Provisionierung im Gerät umzusetzen. Die Prüfung oder (gleichbedeutend) Validierung der Provisionierungsdaten wird an eine andere TE delegiert, die TE-Validator. Die TE-Validator umfasst eine Validierungs- Funktionalität (oder ist zumindest zur Aufnahme einer solchen eingerichtet), mittels derer Provisionierungsdaten validierbar sind. Die TE-Implementor wird nur Provisionierungsdaten akzeptieren, die zuvor von der TE-Validator geprüft wurden.
Der Ansatz bietet drei wesentliche Vorteile:
• Die Erfindung ermöglicht unterschiedliche Implementierungstechniken für die beteiligten TEs.
• Die Validierung der Provisionierungsdaten kann unabhängig von der Implementierung durchgeführt werden
• Die Validierung durch TE-Validator kann in einer anderen, insbesondere einer vorgelagerten, Betriebsphase erfolgen (Bereitstellungs- Phase des Provisioning, in der Provisionierungsdaten von extern (z.B. von einem externen Server) an die MCU gesendet werden) als die Ausführung/ Implementierung (in einer Implementierungs-Phase, die z.B. in einer Boot-Phase bei einem Booten der MCU liegen kann).
Folglich können zeitaufwendige Schritte zur Validierung der Provisionierungsdaten abgespalten werden und durch TE-Validator in einer vorgezogenen Phase durchgeführt werden. Zur Laufzeit der MCU muss dann nur noch die Implementierung der bereits vorhandenen und bereits validierten Provisionierungsdaten durch TE-Implementor durchgeführt werden. Hierdurch kann die MCU Echtzeit- Anforderungen besser erfüllen. Daher ist mit der Appliance gemäß Anspruch 1 eine Möglichkeit zur sicheren und zeitlich effizienten Provisionierung der Appliance realisiert, die auch einsetzbar ist, wenn Echzeitanforderungen gefordert sind. Als Appliance kann insbesondere vorgesehen sein: ein Client Gerät in einer Industrie- Anlage, insbesondere ein Regelungsgerät (Steuer- oder/ und Messgerät), oder ein Chip-Package (ein gehäuster Chip) für ein solches Gerät. In einem möglichen Anwendungsszenario ist die TE^-Implementor eine Aktivierungseinheit, die Features (Ressource-Komponenten wie z.B. einzelne Hardware-Komponenten) z.B. auf einem konfigurierbaren Controller Chip freischaltet und gänzlich in (trusted) Hardware ausgeführt werden muss. Um Chipfläche zu sparen, sind die kryptographischen Ressourcen und die Speicherfähigkeiten in der TE-Implementor beschränkt. Zudem muss die Freischaltung bei jedem Startvorgang des Devices erfolgen (da die Aktivie- rungseinheit in der Regel keinen nicht-flüchtigen Speicher hat) und häufig gibt es stringente Lauf Zeitbeschränkungen (in der Größenordnung weniger als 10 Millisekunden) in dieser Phase.
Die TE-Validator dagegen kann in einer Technologie ausgeführt sein, die besser für Sicherheitsfunktionen ausgestattet ist (z.B. als Secure Element, oder als TEE oder Software im sicheren Ausführungsmodus). Diese spezielle Komponente ist sehr gut für kryptographische Aufgaben geeignet. Sie kann zum Provisionierungszeitpunkt auch aufwändige Validierungsschritte ausführen. Allerdings hat die TE-Validator keinen direkten Zugriff auf trusted Hardware und ist auch nicht schnell genug, um in der Boot-Phase die Provi- sionierungsdaten validieren zu können. Das Problem wird durch eine Zusammenarbeit von TE-Validator und TE- Implementor gelöst, wobei sich TE-Validator und TE-Implementor in einer Vertrauensbeziehung befinden müssen. In der erfindungsgemäßen Umsetzung des Konzepts erzeugt die TE-Validator in einer Bereitstellungs-Phase der Provisionierung ein„Secure Object", wenn die Validierung der Provisionierungsdaten erfolgreich war. Ein „Secure Object" (SO) ist eine durch kryptographische Verfahren gesicherte Datenstruktur (Objekt), die die Provisionierung ermöglicht und die Payload enthält, also die eigentlichen, die Provisionierung bewirkenden Daten. Das SO wird dem TE-Implementor zugänglich gemacht (z.B. über einen gemeinsamen Speicher). Die Existenz eines gültigen SOs ist für die TE-Implementor der hinreichende Beweis, dass die Provisionierungsdaten geprüft wurden. Begründet durch die Vertrauensbeziehung zwischen TE-Implementor und TE-Validator vertraut die TE-Implementor diesen Daten.
Grundlegend ist, dass das SO zwar ebenfalls kryptographisch abgesichert ist, aber so gestaltet ist, dass es für die TE-Implementor wesentlich einfacher und schneller zu prüfen ist. Das SO kann beispielsweise so ausgeführt sein, dass es effizient durch symmetrische Crypto- Verfahren validiert werden kann. Die Prüfung der Provisionierungsdaten dagegen kann je nach der Beziehung der externen Autoritäten die Verifikation von Zertifikaten (oder ganzen Zertifikatsketten) und Signaturen, und damit aufwändige asymmetrische Verfahren, sowie die die Beachtung von Zertifikats-Rückrufen (Revo- cations) erfordern.
Nachfolgend werden bevorzugte Ausbildungen eines erfindungsgemäßen Appliance angegeben. Wahlweise ist im Appliance, in der MCU, mindestens ein provisiorüerbares Objekt eingerichtet, das durch die Implementierungs-Funktionalität der TE- Implementor provisionierbar ist. Weiter ist im nicht-volatilen Speicher ein Secure Object abgespeichert, das einen in den Provisionierungsdaten enthal- tenen Payload und ein aus den Provisionierungsdaten ermitteltes Validierungs-Element umf asst. Die Payload ist eingerichtet, durch die TE- Implementor ausgeführt zu werden, wobei durch eine Ausführung der Payload eine Umsetzung der Provisionierung in der MCU bewirkt wird. Das „Payload" ist z.B. ein feature enable pattern, das direkt die MCU konfigurie- ren kann. Das Validierungs-Element ist mittels eines ersten Authentisie- rungsvorgangs der Authentisierung der Provisionierungsdaten durch die Validierungs-Funktionalität der TE-Validator erzeugt worden. Das Validierungs-Element ermöglicht eine Authentisierung der Provisionierungsdaten durch die TE-Implementor mittels eines zweiten, vom ersten unterschiedli- chen, Authentisierungsvorgangs.
Wahlweise sind im nicht-volatilen Speicher (außerhalb des Secure Object) zudem diejenigen Provisionierungsdaten abgespeichert, ausgehend von welchen das Secure Object erzeugt worden ist, z.B. in einem Provisioning Pack- age. Die Provisionierungsdaten werden z.B. vom Server entgegengenommen und im nicht-volatilen Speicher abgespeichert, bevor das Secure Object ausgehend von den abgespeicherten Provisionierungsdaten erzeugt wird.
Das mit dem Secure Object ausgestattete Appliance hat eine Bereitstellungs- Phase eines Provisionierungs- Vorgangs bereits durchlaufen. In dieser Bereitstellungs-Phase wurden von extern, z.B. von einem externen Server, die Provisionierungsdaten an die MCU bereitgestellt. Die TE-Validator hat an den Provisionierungsdaten Schritte zur Überprüfung durchgeführt und als Resultat der Validierung das Secure Object erzeugt. Die Überprüfung kann zeitlich aufwendige Schritte wie Signatur- Verifizierung umfassen. Als Ergebnis der Überprüfung und Validierung erzeugt die TE-Validator das Secure Object und speichert es in den nicht-volatilen Speicher. Das Secure Object enthält die Payload der validierten Provisionierungsdaten. In dem so hergestellten Zustand kann das Appliance, insbesondere die MCU, wahlweise längere Zeit verbleiben. In einer Implementierungsphase des Provisionie- rungs- Vorgangs, die wahlweise später sein kann, ist nur noch TE-Implemen- tor erforderlich, um durch Anwenden der Payload die Provisionierung der MCU zu vollenden, aber nicht mehr TE-Validator. TE-Implementor braucht nur noch das Secure Object zu verifizieren und kann im Erfolgsfall positiver Verifizierung unmittelbar die Payload der Provisionierungsdaten auf die MCU anwenden, und hierdurch die Provisionierung vollenden. Die Implementierungsphase kann z.B. bei einem Hochfahren/ Booten der MCU erfolgen, wenn das zuvor in einer Wartestellung befindliche Appliance in Betrieb genommen wird.
Wahlweise dauert der zweite Authentisierungsvorgang kürzer als der erste Authentisierungsvorgang. Hierdurch lässt sich eine zeitaufwändige vollständige Validierung von Provisionierungsdaten auf einen geeigneten Zeit- punkt z.B. vor Inbetriebnahme der MCU vorverlagern. An einem anderen Zeitpunkt, der zeitkritischer ist und beispielsweise Echtzeitanforderungen hat, erfolgt nur noch der zeitsparende zweite Authentisierungsvorgang, der unter Verwendung des zuvor erzeugten Secure Object erfolgt. Wahlweise ist als provisionierbares Objekt eines der folgenden, oder mehrere davon, vorgesehen: eine Hardware-Komponente der MCU, insbesondere ein Prozessor-Core, ein Speicher, insbesondere ROM, RAM, EEPROM oder Flash, ein Coprozessor, insbesondere Crypto-Coprozessor, eine Schnittstelle, insbesondere UART-Schnittstelle. Wahlweise umfassen die Provisionierungsdaten als Payload ein feature enable pattern, also ein Bitmuster, das durch die Implementierungs- Funktionalität ausführbar ist, wobei die Ausführung des feature enable pat- tern (Bitmusters) durch die Implementierungs-Funktionalität bewirkt, dass an der MCU eine dem feature enable pattern entsprechende Konfiguration eingerichtet wird.
Wahlweise verfügen die TE-Validator und die TE-Implementor über krypto- graphische Schlüssel, mit welchen die TE-Implementor die Authentizität der TE-Validator prüfen kann, und mit welchen im Fall dass im nicht-flüchtigen Speicher ein Secure Object abgespeichert ist, die TE-Implementor die Authentizität des Secure Object prüfen kann. Die Verlagerung einer komplexen, aufwendigen Sicherheitsprozedur wie des ersten Authentisierungsvorgangs in ein weniger komplexes Secure Object und einen weniger komplexen zweiten Authentisierungsvorgang kann a priori das Risiko eines Sicherheitsverlusts bergen. Da TE-Validator und TE- Implementor gesicherte Ausführungsumgebungen sind, die untereinander in einem VertrauensverhäTtnis stehen, z.B. durch Schlüsselvereinbarung, bleibt die Sicherheit dennoch gewahrt.
Wahlweise ist die TE-Validator als auf Software-Ebene gesicherte Umgebung gestaltet, insbesondere als Trusted Execution Environment oder als Teilfunk- tionalität der MCU in einem sicheren Betriebsmodus, oder als von der MCU gesondertes Secure Element, und wobei die die Validierungs-Funktionalität als Validierungs-Software gestaltet ist, insbesondere Validierungs- Applikation, insbesondere Validierungs- Applet, durch welche das Validierungs- Element verifiziert werden kann. Wahlweise ist die TE-Implementor als sichere Hardware in der MCU implementiert und die Implementierungs-Funktionalität als Hardware zur Konfigurierung der MCU gestaltet, insbesondere als feature enable control- 1er zum Aktivieren von features (provisionierbaren Objekten) der MCU. Wahlweise ist die Payload als ein feature enable pattern gestaltet und die Implementierungs-Funktionalität als der MCU zugeordneter, in trusted Hardware gestalteter feature enable Controller gestaltet. Wird das feature enable pattern in ein dem feature enable Controller zugeordnetes Register geschrieben und die MCU gebootet, wird durch die MCU der Registerinhalt ausgeführt und dadurch in der MCU eine dem feature enable pattern entsprechende Konfigurierung der MCU hergestellt.
Wahlweise ist der nicht-volatile Speicher entweder in der MCU oder in einer von der MCU gesonderten integrierten Schaltungs- Anordnung implementiert. Als gesonderte integrierte Schaltungs- Anordnung kann der nicht- volatile Speicher weiter wahlweise auf demselben Chip wie die MCU angeordnet sein, oder auf einem gesonderten Chip. Der gesonderte Chip kann wahlweise im selben Gehäuse eingeschlossen sein wie der MCU-Chip.
Wahlweise ist das Appliance gestaltet als eines der Folgenden: Regelungsgerät, insbesondere Steuerungsgerät, Messgerät oder kombiniertes Steuerungsund Messgerät, für eine Industrieanlage; Chipset (umfassend ein oder mehrere Chips, z.B. Application Controller, Baseband-Controller, Schnittstellen- Controller) für ein Mobilfunk-Endgerät; M2M-Modul für eine Industrieanlage; Automotive M2M-Modul.
Wahlweise umf asst das Secure Object als Validierungs-Element für den zweiten Authentisierungsvorgang eines oder mehrere der folgenden: eine Prüfsumme, eine kryptographische Prüfsumme, einen Hashwert, einen Message Authentication Code MAC, jeweils gebildet unter Verwendung der Provisionierungsdaten, ein konstanter und wohldefinierter Wert („magic value"). Eine Prüf summe, ein Hashwert, ein MAC, ein konstanter Wert las- sen sich vergleichsweise schnell verifizieren.
Wahlweise ist als Bedingung zur Erzeugung des Secure Object eine erfolgreiche Verifizierung einer kryptographischen Signatur oder/ und eines Zertifikats vorgesehen, d.h. nur unter der Bedingung, dass in einer Bereitstel- lungs-Phase der Provisionierung die Signatur oder/ und das Zertifikat erfolgreich verifiziert wird (und ggf. falls weitere Bedingungen erfüllt sind), wird das Secure Object erzeugt und in den NVM ausgegeben. Die Verifizierung einer Signatur ist zeitaufwendiger als die Verifizierung eines
Hashwerts, MAC, Prüf summe, etc..
Erfindungsgemäß wird weiter ein Verfahren zur Provisionierung eines Ap- pliance angegeben. Das Appliance umfasst eine Microcontroller- Anordnung, die wiederum eine Micro-Controller-Unit MCU, eine TE-Validator, eine TE- Implementor und einen nicht-flüchtigen Speicher (NVM), der für die TE- Validator schreibbar und für die TE-Implementor lesbar ist, umfasst, in einer Bereitstellungs-Phase der Provisionierung:
- Bereitstellen von Provisionierungsdaten zur Provisionierung der MCU von einem Server an die TE-Validator; ggf. zudem Abspeichern der Provisionierungsdaten in der MCU (insbesondere im nicht-volatilen Speicher), um sie zur nachfolgenden Erzeugung des Secure Object zur Verfügung zu haben;
- durch die TE-Validator, Durchführen eines ersten Authentisierungsvor- gangs, in welchem die Provisionierungsdaten authentisiert werden, und im Fall erfolgreicher Authentisierung der Provisionierungsdaten, Erzeugen eines Secure Object, das einen in den Provisionierungsdaten enthaltenen Pay- loacl und ein aus den Provisionierungsdaten ermitteltes Validierungs- Element umf asst, und Abspeichern des erzeugten Secure Object im nicht- volatilen Speicher, wobei in dem Secure Object:
die Payload eingerichtet ist, durch die TE-Implementor ausgeführt zu werden, wobei durch eine Ausführung der Payload eine Umsetzung der Provisionierung in der MCU bewirkt wird; und
das Validierungs-Element eine Authentisierung der Provisionierungsdaten durch die TE-Implementor mittels eines zweiten, vom ersten unterschiedlichen, Authentisierungsvorgangs ermöglicht.
Nun ist die MCU in einem Zustand, in welchem eine Fertigstellung der Provisionierung durch die TE-Implementor möglich ist, d.h. insbesondere ohne die TE-Validator, und nur noch mit dem vorzugsweise weniger komplexen zweiten Authentisierungsvorgang.
In einer Implementierungs-Phase, die der Bereitstellungs-Phase nachfolgt, sind wahlweise folgende Schritte vorgesehen:
- durch die TE-Implementor, Anstoßen des Implementierens der Provisionierungsdaten;
- durch die TE-Implementor, Auslesen des Secure Object aus dem nicht- volatilen Speicher, und, mittels des ausgelesenen Secure Object, Durchführen des zweiten, vom ersten unterschiedlichen, Authentisierungsvorgangs, um die Provisionierungsdaten zu authentisieren;
- im Fall erfolgreicher Authentisierung im zweiten Authentisierungsvor- gang, Implementieren der Payload in die MCU, um die Provisionierung in der MCU umzusetzen.
Kurze Beschreibung der Zeichnungen Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigen:
Fig. 1 eine Microcontroller- Anordnung (Chip Package) mit einer MCU, die eine TE-Validator und eine TE-Implementor umfasst, sowie mit einem persistenten Datenspeicher NVM, nach einer Ausführungsform der Erfindung;
Fig. 2 eine Detailansicht des Geräts mit Microcontroller- Anordnung (Chip Package) aus Fig. 1, mit Detail-Darstellung der Bestandteile TE- Validator, TE-Implementor und persistenter Datenspeicher NVM;
Fig. 3 ein Ablaufschema für den Aufbau der Vertrauensbeziehung und dem Austausch bzw. Vereinbarung der Schlüssel
Fig. 4 ein Ablaufschema zum Boot- Vorgang wenn keine Fehler auftreten;
Fig. 5 ein Ablaufschema zum Boot- Vorgang, wenn der TE-Implementor den Provisionierungsdaten nicht vertrauen kann.
Fig. 6 ein Ablaufschema zum ersten Authentisierungs-Vorgang, in dem die TE-Validator die Provisionierungsdaten prüft und aus den Provisionierungsdaten das Secure Object erzeugt.
Detaillierte Beschreibung
Ein Appliance in einem Provisiönierungs-System gemäß einer in Fig. 1 dargestellten Ausführungsform der Erfindung wird realisiert durch das Zusammenwirken der folgenden innerhalb des Appliance (d.h. des technischen Geräts) integrierten Komponenten:
• TE-Validator: Eine sichere Umgebung zur Prüfung von Provisionierungsdaten, die von Autoritäten des Eco-Systems produziert werden. Die Provisionierungsdaten kommen im allgemeinen von einem oder mehreren Trusted Service Managern (TSMs)
• TE-Implementor: eine sichere Umgebung mit Logik zur Implementierung/Verarbeitung von Provisionierungsdaten, insbesondere der Payload. Die Implementierung bedeutet Personalisierung, Einrichtung von Credentials, Freischaltung von Ressourcen, Features etc..
• NVM: ein nicht-volatiler (persistenter, nicht-flüchtiger) Speicher auf dem Appliance. Das NVM ist für die TE-Implementor lesbar und für die TE-Validator schreibbar. Das NVM kann als externe Komponente ausgeführt sein.
• ROM: ein unveränderbarer Speicher (der Inhalt kann nicht verändert werden) in dem Appliance. Dieser Speicher ist ebenfalls für die TE- Implementor zugreifbar.
· NWd: die normale Umgebung, von der keine Sicherheitsanforderungen erwartet werden. Dies ist die Umgebung in der die Betriebssoftware ausgeführt wird, einschließlich des Kernels des Betriebssystems. Über diese Komponente wird die Kommunikation zwischen den anderen Komponenten realisiert.
Ferner umfasst das Provisionierungs-System ein Eco-System, das Provisio- nierungsdaten generiert:
• TSM: externer Server, der Provisionierungsdaten erzeugt (oder von einem Daten-Erzeugungs-Server bezieht) und an das Appliance be- reitstellt. Das Eco-System kann mehrere TSMs umfassen, die unterschiedliche Autoritäten repräsentieren.
Fig. 2 zeigt ein Provisionierungs-System umfassend ein Appliance und einen exterenen Server TSM, die physisch über das Internet miteinander
verbunden sind, gemäß einer Ausführungsform der Erfindung. Innerhalb des Appliance wird die Vetrauensbeziehung zwischen der TE-Implementor und der TE-Validator durch einen kryptographisch abgesicherten
Schlüsselaustausch dargestellt. Initial muss die TE-Implementor die folgenden Schlüssel besitzen:
Name Typ Beschreibung
PK.Root Öffentlicher Der öffentliche Schlüssel des Issuers der TE- Schlüssel Validator. Diese Schlüssel kann in der TE selbst liegen, oder aber im ROM-Bereich der Appliance, der der TE zugänglich ist. Es muss sichergestellt sein, dass der PK.Root nicht ausgetauscht werden kann
K.SO Symmetrischer Der Schlüssel zur Absicherung des Secure
Schlüssel Objects. Der Schlüssel kann zum Beispiel durch eine PUF (Physical uncloneable Function), durch„Fuses" oder durch Key- Injection bei der Produktion erzeugt werden.
Nonce Shared Secret, Die Nonce ist kein echter Schlüssel, sondern optional ein einmaliger Wert. Die Nonce dient nur dazu, Replay Angriffe auf das Secure Object zu verhindern; bei jedem Neu- Aufbau der Vertrauensbeziehung wird eine neue Nonce generiert und somit werden alle bestehenden Secure-Objects automatisch ungültig. Die Nonce kann eine geringere Bit-Länge als Schlüssel haben. Dadurch kann die Belastung der TE-Implementor reduziert werden. Die Nonce muss in der TE-Implementor gespeichert oder erzeugt werden
Die TE-Validator besitzt die folgenden Schlüssel
Name Type Beschreibung SK.Val Privater Der private Teil des Schlüsselpaars speziSchlüssel fisch für die TE-Validator. Das Schlüsselpaar wird durch den Issuer generiert und in die TE-Validator eingebracht.
PK.Val Öffentlicher Der öffentliche Teil des Schlüsselpaars speSchlüssel zifisch für die TE-Validator.
Cert.Val Zertifikat Das Zertifikat enthält den öffentlichen
Schlüssel PK.Val und die Signatur. Die Signatur wird mittels des privaten Schlüssels (SK.Root) des Issuer s der TE-Validator erzeugt
Fig. 3 zeigt den Aufbau einer Vertrauensbeziehung zwischen einer TE- Validator und einer TE-Implementor, in einer Setup-Phase vor der eigentlichen Provisionierung. Der Aufbau der Vertrauensbeziehung erfolgt in der Setup-Phase, die einmalig stattfinden kann. In dieser Phase übergibt die TE-Validator das Zertifikat Cert. Val = Cert.TE2 an die TE-Implementor. Die TE-Implementor prüft das Zertifikat anhand des öffentlichen Schlüssels PK.Root, der im ROM der Appliance gespeichert ist. Diesem Schlüssel kann vertraut werden, da das ROM nicht änderbar ist. Wenn das Zertifikat akzeptiert wird, erzeugt die TE-Implementor eine Nonce und sendet diese sowie den K.SO an die TE-Validator.
1.0: Authenticate(Cert. Val = Cert.TE2)
Die TE-Validator sendet das Zertifikat Cert. Val = Cert.TE2 an die TE- Implementor. Das Zeritifkat beinhaltet den öffentlichen Schlüssel der TE und ist signiert mit dem privaten Schlüssel des Issuers (SK.Root)
1.1: Read: PK.Root Die TE-Implementor liest den öffentlichen Schlüssel PK.Root des Issuers aus dem ROM des Chips.
1.2 Verify(Cert.TE2, PK.Root): OK
Die TE-Implementor prüft die Signatur des Zertifikats Cert-TE2 mittels des öffentlichen Schlüssels P Root. Wenn die Verifikation erfolgreich ist, vertraut die TE-Implementor dem Zertifikat und dem darin enthaltenen öffentlichen Schlüssel der TE-Validator.
1.3 Generate(): nonce
Die TE-Implementor erzeugt einen einmaligen Wert (Nonce). Dies kann z.B. durch einen Zufallsgenerator erfolgen.
1.4: Save(nonce)
Die (optionale) Nonce wird intern in der TE-Implementor gespeichert. Die Nonce dient dem Replay-Schutz.
1.5: Enc[PK.TE2](nonce, K.SO)
Die TE-Implementor verschlüsselt die Nonce und den eigenen Schlüssel K.SO mit dem öffentlichen Schlüssel aus dem Zertifikat Cert.TE2. Das Kryptogramm wird an die TE-Validator gegeben.
Die folgenden Varianten sind möglich:
· Der Schlüssel K.SO ist ein symmetrischer Schlüssel, der in der TE- Implementor generiert oder gespeichert ist. Die Herausgabe dieses Schlüssels an die TE-Validator stellt keine Sicherheitsrisiko dar, da die beiden TEs in der selben Appliance sind, sich gegenseitig vertrauen und sowieso duaerhaft gebunden werden sollen.
· Der Schlüssel K.SO kann auch ein asymmetrischer Schlüssel sein, wobei der private Teil bei der TE-Validator („writer", dem Erzeuger des SO) und der öffentliche Teil in der TE-Implementor liegen soll. Insbesondere kann dazu das Schlüsselpaar SK.TE2 und PK.TE2 verwendet werden. Die TE-Implementor muss dazu den öffentlichen Teil intern speichern. • Es kann auch ein hybrides Verfahren verwendet werden. Dabei wird das Secure Object durch einen symmetrischen Schlüssel K.SO verschlüsselt, der durch den Erzeuger (TE-Validator) generiert wird. Der K.SO selbst wird mit dem privaten Schlüssel SK.TE2 gewrappt. Sowohl der gewrappte Schlüssel als auch das Secure Object werden im NVM hinerlegt und sind für die TE-Implementor lesbar.
Das Secure Object beinhaltet, in bevorzugter Ausführung:
• Die (optionale) Nonce,
· Die„Payload" aus den Provisionierungsdaten,
• Ein Validierungs-Element, z.B. eine Prüfsumme, oder einen Key- Check-Value oder MAC etc..
Die Nonce ist optional. Die Nonce dient nur dem Replay-Schutz und ermöglicht es, bereits ausgestellte Secure Objects zu invalidieren. In manchen Szenarien ist dies jedoch nicht erforderlich (z.B. weil invalidierte Secure Objecte zuverlässlich gelöscht werden können) bzw. sogar nicht gewünscht, etwa wenn alle jemals ausgestellten Secure Objects gültig bleiben sollen. Ein mögliches Anwendungsszenario könnte sein, dass dynamisch beim Boot- Vorgang zwischen verschiedenen Konfigurationen (z.B. Test und Produktion) umgeschaltet werden soll. Die Nonce erfordert eine non-volatile Speichermöglichkeit in der TE-Implementor.
Die„Payload", z.B. ein feature enable pattern, wird unverändert aus den Provisionierungsdaten übernommen, so wie sie vom TSM generiert wurden.
Das Validierungs-Element (z.B. Prüfsumme) stellt sicher, dass der Speicher im NVM auch wirklich ein Secure Object enthält. Das Validierungs-Element kann und soll sehr einfach zu berechnen sein, damit die TE-Implementor nicht belastet wird, wie z.B. für eine Prüfsumme der Fall ist. Aber natürlich kann die Prüfsumme auch durch einen Hash oder MAC ersetzt werden, obwohl dies für den zugrundeliegenden Anwendungsfall häufig zu teuer sein wird. Als weitere Variante kann auch nur ein konstanter Key-Check- Value eingesetzt werden. Dies ist ein statischer Wert, der zwischen TE-
Validator und TE-Implementor vereinbart ist. Die TE-Implementor wird das Secure Object nur akzeptieren, wenn sie nach der Entschlüsselung den vereinbarten Wert im Key-Check- Value vorfindet. Fig. 4 zeigt ein Ablauf diagramm über eine Boot-Phase einer MCU, die der Setup-Phase nachfolgt, im Fall eines erfolgreichen Boot- Vorgangs, mit erfolgreicher Verifizierung des Secure Object.
Fig. 5 zeigt das Fig. 4 entsprechende Ablauf diagramm für eine fehlerhafte, nicht erfolgreiche Verifizierung des Secure Object.
In der Boot-Phase spielt die TE-Implementor die Payload aus den Provisio- nierungsdaten in die MCU ein, um die Provisionierung der MCU
umzusetzen. Dazu verwendet die TE-Implementor ausschließlich das Secure Object SO.
1.0 Starten des Boot- Vorgangs ,,Boot()"
1.1 Lesen ,,read()" des Secure Object SO. Die TE-Implementor liest das Secure-Object aus dem NVM.
1.2 Entschlüsseln„Dec" des verschlüsselt abgelegten Secure Object und Extrahieren des Nonce und der eigentlich wirkfähigen Payload der
Provisionierungsdaten sowie Verifizieren des Secure Object.
1.3 Verifizieren„Verify" des Nonce, hier mit Erfolg„OK".
1.4 Implementieren des Payload, dargestellt durch Anweisung„Activate". Die Prüfung der Nonce ist optional. Wenn sowohl Secure Object als auch die Nonce erfolgreich verifiziert werden, werden die Provisionierungsdaten durch Aktivieren„Activate" des Payload in der MCU des Appliance implementiert.
Fig. 6 zeigt ein Ablauf diagramm über den ersten Validierungsvorgang in der Bereitstellungs-Phase, bei dem die TE- Validator im Erfolgsfall das Secure Object erzeugt. Voraussetzung ist, dass die TE- Validator und die TE- Implementor in einer der bereits dargestellten Weisen, z.B. gemäß Fig. 3, die Vertrauensbeziehung aufgebaut haben.
1.0 Starten des Validierungsvorgangs
1.1 RequestProvisioning(dev-id): ProvisioningPackage
Die Provisionierungsdaten, hier vorliegend in Form eines Provisio ing Package, werden vom externen Server (TSM) angefragt.
1.2 Verify (ProvisioningPackage)
Die Provisionierungsdaten (Provisioning Package) werden durch die TE- Validator geprüft. Im dargestellten Szenario verläuft die Prüfung positiv und die Provisionierungsdaten werden akzeptiert.
1.3 Enc[K.TEl] (nonce, ProvisioningPackage.payload):SO
Der TE- Validator erzeugt das Secure Object unter Verwendung des gemeinsamen Schlüssels K.TE1; dieser Schlüssel wurde im Zuge des Aufbaus der Vertrauensbeziehung mit der TE-Implementor ausgetauscht beziehungsweise abgeleitet.
1.4 Write(SO)
Die TE- Validator speichert das erzeugte Secure Object SO im nicht-volatilen Speicher NVM. Der Speicherort ist vorab mit der TE-Implementor per Konvention vereinbart.
1.5 bootO Die TE-Validator leitet einen Re-Boot der Appliance ein, um den Provisionie- rungsmodus zu verlassen und die neu eingespielte Provisionierung wirksam werden zu lassen, z.B. mit dem in Fig. 4, 5 gezeigten Verfahren. Wenn das Secure Object oder/ und der Nonce ungültig ist (Fig. 5), verweigert der TE-Implementor die Provisionierung. Der Boot- Vorgang wird abgebrochen und die Appliance wird in einen Fail-safe Modus versetzt werden. Andere Fehlerfall-Behandlungen als Abbruch sind auch möglich. Die Erfindung umfasst den Fall dass die TE-Validator die Validierung von Provisiorüerungsdaten für mehrere TE-Implementor übernimmt. In diesem Szenario baut die TE-Validator eine bilaterale Trustbeziehung mit jeder zu versorgenden TE-Implementor auf. Nach der Prüfung der Provisionierungs- daten erzeugt die TE-Validator für jede TE-Implementor jeweils ein speziali- siertes Secure Object.

Claims

P a t e n t a n s p r ü c h e
1. Appliance umfassend eine Microcontroller- Anordnung umfassend eine Micro-ControUer-Unit MCU, eine TE-Validator, umfassend eine oder einge- richtet zur Aufnahme einer Validierungs-Funktionalität, eine TE-
Implementor, umfassend eine oder eingerichtet zur Aufnahme einer Implementierungs-Funktionalität, und einen nicht-flüchtigen Speicher (NVM), der für die TE-Validator schreibbar und für die TE-Implementor lesbar ist.
2. Appliance nach Anspruch 1, wobei:
- in der MCU, mindestens ein provisionierbares Objekt eingerichtet ist, das durch die Implementierungs-Funktionalität der TE-Implementor provisio- nierbar ist; und
- im nicht-volatilen Speicher (NVM) ein Secure Object abgespeichert ist, das einen in den Provisionierungsdaten enthaltenen Payload und ein aus den
Provisionierungsdaten ermitteltes Validierungs-Element umfasst, wobei: die Payload eingerichtet ist, durch die TE-Implementor ausgeführt zu werden, wobei durch eine Ausführung der Payload eine Umsetzung der Provisionierung in der MCU bewirkt wird; und
— das Validierungs-Element mittels eines ersten Authentisierungsvor- gangs der Authentisierung der Provisionierungsdaten durch die Validierungs-Funktionalität der TE-Validator erzeugt worden ist und eine Authentisierung der Provisionierungsdaten durch die TE-Implementor mittels eines zweiten, vom ersten unterschiedlichen, Authentisierungsvorgangs ermög- licht.
3. Appliance nach Anspruch 2, wobei der zweite Authentisierungsvorgang kürzer dauert als der erste Authentisierungsvorgang.
4. Appliance nach Anspruch 2 oder 3, wobei als provisionierbares Objekt eines der folgenden, oder mehrere davon, vorgesehen ist: eine Hardware- Komponente der MCU, insbesondere ein Prozessor-Core, ein Speicher, insbesondere ROM, RAM, EEPROM oder Flash, ein Coprozessor, insbesondere Crypto-Coprozessor, eine Schnittstelle, insbesondere UART-Schnittstelle.
5. Appliance nach einem der Ansprüche 1 bis 4, wobei die TE-Validator und die TE-Implementor über kryptographische Schlüssel verfügen, mit welchem die TE-Implementor die Authentizität der TE-Validator prüfen kann, und mit welchen im Fall dass im nicht-flüchtigen Speicher (NVM) ein Secure Ob- ject abgespeichert ist, die TE-Implementor die Authentizität des Secure Ob- ject prüfen kann.
6. Appliance nach einem der Ansprüche 1 bis 5, wobei die TE-Validator als auf Software-Ebene gesicherte Umgebung gestaltet ist, insbesondere als Trusted Execution Environment oder als Teilfunktionalität der MCU in ei- nem sicheren Betriebsmodus, oder als von der MCU gesondertes Secure Element, und wobei die die Validierungs-Funktionalität als Validierungs- Software gestaltet ist, insbesondere Validierungs- Applikation, insbesondere Validierungs- Applet.
7. Appliance nach einem der Ansprüche 1 bis 6, wobei die TE-Implementor als sichere Hardware in der MCU implementiert und die Implementierungs- Funktionalität als Hardware zur Konfigurierung der MCU gestaltet ist.
8. Appliance nach einem der Ansprüche 1 bis 7, wobei der nicht-volatile Speicher (NVM) entweder in der MCU oder in einer von der MCU gesonderten integrierten Schaltungs- Anordnung implementiert ist.
9. Appliance nach einem der Ansprüche 1 bis 8, gestaltet als eines der Folgenden: Regelungsgerät, insbesondere Steuerungsgerät, Messgerät oder kombiniertes Steuerungs- und Messgerät, für eine Industrieanlage; Chipset für ein Mobilfunk-Endgerät; M2M-Modul für eine Industrieanlage; Automo- tive M2M-Modul.
10. Appliance nach einem der Ansprüche 1 bis 9, wobei das Secure Object als Validierungs-Element für den zweiten Authentisierungsvorgang eines oder mehrere der folgenden umfasst: eine Prüf summe, eine kryptographische Prüfsumme, einen Hashwert, einen Message Authentication Code, jeweils gebildet unter Verwendung der Provisionierungsdaten.
11. Verfahren zur Provisionierung eines Appliance umfassend eine
Microcontroller- Anordnung umfassend eine Micro-Controller-Unit MCU, eine TE-Validator, eine TE-Implementor und einen nicht-flüchtigen Speicher (NVM), der für die TE-Validator schreibbar und für die TE-Implementor lesbar ist, und eingerichtet nach einen der Ansprüche 1 bis 10, das Verfahren umfassend die Schritte, in einer Bereitstellungs-Phase der Provisionierung:
- Bereitstellen von Provisionierungsdaten zur Provisionierung der MCU von einem Server an die TE-Validator;
- durch die TE-Validator, Durchführen eines ersten Authentisierungsvor- gangs, in welchem die Provisionierungsdaten authentisiert werden, und im Fall erfolgreicher Authentisierung der Provisionierungsdaten, Erzeugen eines Secure Object, das einen in den Provisionierungsdaten enthaltenen Pay- load und ein aus den Provisionierungsdaten ermitteltes Validierungs- Element umfasst, und Abspeichern des erzeugten Secure Object im nicht- volatilen Speicher, wobei in dem Secure Object:
die Payload eingerichtet ist, durch die TE-Implementor ausgeführt zu werden, wobei durch eine Ausführung der Payload eine Umsetzung der Provisionierung in der MCU bewirkt wird; und
das Validierungs-Element eine Authentisierung der Provisionie- rungsdaten durch die TE-Implementor mittels eines zweiten, vom ersten un- terschiedlichen, Authentisierungsvorgangs ermöglicht.
12. Verfahren nach Anspruch 11, weiter umfassend die Schritte, in einer der Bereitstellungs-Phase nachfolgenden Implementierungs-Phase:
- durch die TE-Implementor, Anstoßen des Implementierens der Provisionie- rungsdaten;
- durch die TE-Implementor, Auslesen des Secure Object aus dem nicht- volatilen Speicher (NVM) und, mittels des ausgelesenen Secure Object, Durchführen des zweiten, vom ersten unterschiedlichen, Authentisierungsvorgangs, um die Provisionierungsdaten zu authentisieren;
- im Fall erfolgreicher Authentisierung im zweiten Authentisierungsvor- gang, Implementieren der Payload in die MCU, um die Provisionierung in der MCU umzusetzen.
PCT/EP2016/002174 2015-12-23 2016-12-22 Validierung und ausführung von provisionierungsdaten auf appliances WO2017108192A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102015016750.2 2015-12-23
DE102015016750.2A DE102015016750A1 (de) 2015-12-23 2015-12-23 Validierung und Ausführung von Provisionierungsdaten auf Appliances

Publications (1)

Publication Number Publication Date
WO2017108192A1 true WO2017108192A1 (de) 2017-06-29

Family

ID=57860781

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/002174 WO2017108192A1 (de) 2015-12-23 2016-12-22 Validierung und ausführung von provisionierungsdaten auf appliances

Country Status (2)

Country Link
DE (1) DE102015016750A1 (de)
WO (1) WO2017108192A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11775694B2 (en) 2022-01-05 2023-10-03 International Business Machines Corporation Validating and securing non-volatile memory

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3651046A1 (de) * 2018-11-07 2020-05-13 Siemens Aktiengesellschaft Verfahren, client, überwachungseinheit und alarmierungseinheit zur sicheren nutzung einer geschützten ausführungsumgebung

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080082828A1 (en) * 2006-09-29 2008-04-03 Infineon Technologies Ag Circuit arrangement and method for starting up a circuit arrangement
WO2011047276A2 (en) * 2009-10-15 2011-04-21 Interdigital Patent Holdings, Inc. Registration and credential roll-out for accessing a subscription-based service

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100058317A1 (en) * 2008-09-02 2010-03-04 Vasco Data Security, Inc. Method for provisioning trusted software to an electronic device
EP2814277A1 (de) * 2009-04-15 2014-12-17 Interdigital Patent Holdings, Inc. Validierung und/oder Authentifizierung einer Vorrichtung zur Kommunikation mit einem Netzwerk

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080082828A1 (en) * 2006-09-29 2008-04-03 Infineon Technologies Ag Circuit arrangement and method for starting up a circuit arrangement
WO2011047276A2 (en) * 2009-10-15 2011-04-21 Interdigital Patent Holdings, Inc. Registration and credential roll-out for accessing a subscription-based service

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11775694B2 (en) 2022-01-05 2023-10-03 International Business Machines Corporation Validating and securing non-volatile memory

Also Published As

Publication number Publication date
DE102015016750A1 (de) 2017-06-29

Similar Documents

Publication Publication Date Title
EP3574625B1 (de) Verfahren zum durchführen einer authentifizierung
EP2727277B1 (de) System zur sicheren übertragung von daten und verfahren
DE102015214267A1 (de) Verfahren und System zum Erzeugen eines sicheren Kommunikationskanals für Endgeräte
DE102015209108A1 (de) Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
DE102011051498A1 (de) Gesicherter Zugriff auf Daten in einem Gerät
DE102013227184A1 (de) Verfahren zur Absicherung eines Systems-on-a-Chip
DE112008001436T5 (de) Sichere Kommunikation
DE102009036179A1 (de) Verfahren zur Ausstellung eines digitalen Zertifikats durch eine Zertifizierungsstelle, Anordnung zur Durchführung des Verfahrens und Rechnersystem einer Zertifizierungsstelle
DE102021127624A1 (de) Sichere bereitstellung der identität des basisboard-management-controllers einer plattform
WO2016113154A1 (de) Verfahren zum lesen von attributen aus einem id-token
DE112010004580T5 (de) Sichere Pin-Verwaltung einer für Benutzer vertrauenswürdigen Einheit
EP3337085B1 (de) Nachladen kryptographischer programminstruktionen
EP3465513B1 (de) Nutzerauthentifizierung mittels eines id-tokens
EP3271855B1 (de) Verfahren zur erzeugung eines zertifikats für einen sicherheitstoken
EP2434424B1 (de) Verfahren zur Erhöhung der Sicherheit von sicherheitsrelevanten Online-Diensten
WO2017108192A1 (de) Validierung und ausführung von provisionierungsdaten auf appliances
EP3373545A1 (de) Sicherheitseinheit insbesondere ein für iot-gerät und verfahren zur ausführung einer oder mehrerer applikationen zum gesicherten datenaustausch mit einem oder mehrere web-dienste bereitstellenden servern
EP3244331B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3407242A1 (de) Personalisieren eines halbleiterelements
EP3130165B1 (de) Bereitstellen einer virtuellen verbindung zum übertragen von anwendungsdateneinheiten
DE102015208176A1 (de) Gerät und Verfahren zur Autorisierung eines privaten kryptographischen Schlüssels in einem Gerät
DE102015016637B4 (de) Micro-Controller Unit MCU mit selektiv konfigurierbaren Komponenten
WO2023025642A1 (de) Sicheres betreiben einer industriellen steuerungsvorrichtung zusammen mit einem ai-modul
DE102014019407A1 (de) Verfahren zur Freischaltung eines Zugriffs auf in einem Gerät geschützt gespeicherte Daten und Anordnung zur Durchführung des Verfahrens
EP2531983A1 (de) Komplettierung portabler datenträger

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: 16829068

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: 16829068

Country of ref document: EP

Kind code of ref document: A1