METHOD AND SECURE ELEMENT FOR PROOFING A TRUSTWORTHY ELECTRONIC ASSEMBLY

Description

[0001] The present invention relates to a method for proving trustworthy electronics, in particular electronic assemblies and hardware components, as well as a secure element for proving the trustworthiness of an electronic assembly, in particular with trustworthy electronics, preferably with applications, for critical infrastructures.

[0002] For manufacturers of embedded systems, the development and provision of trustworthy electronics with applications for critical infrastructures is of utmost importance. Electronics used in "digital factories" or highly automated processes are particularly expected to be highly reliable and available. This applies particularly to critical infrastructures such as medical technology, transportation technology, or food production. These infrastructures place particular demands on the trustworthiness of devices, production technology, and device technology. Trust is based on the certifiability and verifiability of the devices, as well as their electronic assemblies and (hardware) components.In globalized production chains, traceability of the trustworthiness of electronic components is particularly important throughout all processes, such as production (split manufacturing) and commissioning by manufacturers, system integrators, and operators of these components. In principle, practical tracking of trusted products in transnational goods exchanges, for example, at customs stations, is also suitable for verifying a certificate of origin, which can be retrieved digitally. Documents US 2012 / 131334 and US 2011 / 296201 represent the state of the art.

[0003] The present invention is based on the object of proposing a method and a device with which robust and reliable proof of the trustworthiness of an electronic assembly can be provided. This object is achieved by a method having the features of claim 1 and by a secure element having the features of claim 11.

[0004] According to a first aspect, the invention relates to a method for proving a trustworthy electronic assembly with a CPU, a bus interface and a secure element, which comprises a proof of origin and which has a record memory with a target state value of the assembly.The method comprises the following steps: determining an actual state value of an actual state of the assembly, optionally saving the actual state in a record in the record memory, optionally checking and optionally determining whether the assembly has a secure element with proof of origin, reading the target state value from the record memory, whereby the target state value represents a target state of the assembly, checking the secure element for authenticity by checking the proof of origin of the secure element, processing the actual state value and the target state value and / or comparing the target state and the actual state and evaluating and deciding whether the actual state is similar to, compatible with, or corresponds to the target state to such an extent that a trust criterion is met. The actual state and the target state of the assembly represent the composition of the assembly and its parts and components.If the states are identical, the assembly corresponds to the original state during production or initial commissioning and includes the components and parts that were originally installed. Similarity of states can occur if a predetermined number of components are identical or have the same properties or characteristics.

[0005] For example, the assembly could be trusted, meaning the specified trust criterion is met, if 70% of the components are identical (e.g., identical serial number), whereby certain components of the assembly must fall into this 70% group. Sufficient compatibility can be present if, for example, at least 40% of the components are identical and another 50% have the same properties, e.g., electrical properties or current flow during boot, etc., whereby it can be specified that certain components must be identical. These trust criteria can be specified by the manufacturer or commissioning engineer of the assembly, or by the user of the assembly to prevent subsequent modifications or tampering.

[0006] The target state value can include dynamic data of a component or assembly, such as a voltage and current curve when the component or assembly is booted or started,

[0007] The target state value may also include static data of the assembly and / or a component, such as the serial number, the production date, a production batch or series, current or voltage values, clock frequencies or similar parameters that describe and characterize the component.

[0008] The target state value can also include cryptographic operations with IP elements distributed across the module. These include, for example, keys, physical unclonable functions (PUFs), and physical obfuscated keys (POKs).

[0009] The actual state values ​​correlate with the target state values. The values ​​or parameters stored as target state values ​​are therefore queried. The determination can include receiving the actual state value of the assembly, a component of the assembly, or an external component. A component could be, for example, a sensor, a memory, an SD card, a CPU, an SoC (System on Chip), or an IP with a unique ID (identity) or key, or similar. Sensors, processors, and processing units can also be queried to determine the actual state values. The actual state value can also include static data of a component, as listed above, for example, the serial number, production date, production batch or series, current or voltage values, clock frequencies, keys, physical unclonable functions, physical obfuscated keys, or similar parameters that describe and characterize the component.

[0010] Processing the actual state value and the target state value can involve converting or reading individual values ​​or parameters from the state values. It can be queried whether certain parameters or components are currently present in the assembly and were also present at the time of the defined target state. If necessary, individual parameters can be processed or combined with cryptographic keys or other verifications before a decision can be made regarding the trustworthiness of the assembly. In a simple embodiment, the target state or target state value can be compared with the actual state or actual state value.

[0011] The confidence criterion is defined as an evaluation algorithm that compares a number of actual values ​​(actual state values) with a number of target values ​​(target state values). In a simple implementation, equality is checked, i.e., each actual value is compared with the corresponding target value; if they are equal, the confidence criterion is met. The evaluation algorithm can also be performed by an AI unit. In this case, the target state consists of the previously determined parameters of a previously defined AI algorithm. The evaluation algorithm can also consist of a data series obtained as the actual state with supplemented error correction data to allow for a tolerable deviation.

[0012] The trust criterion is considered met if a predetermined number of values ​​or parameters of the actual state exactly or partially match the target state, i.e., if there is agreement between the actual state values ​​and the corresponding, in other words, corresponding, target state values. The values ​​or parameters can also result in or include a standardized measure between 0 and 1 in a weighted form. This must then be equal to or greater than a predetermined threshold. The values ​​or parameters can be transmitted individually or collectively as a key for encrypting a "challenge." The aggregation of values ​​can optionally take place outside the verification unit. The aggregation of values ​​can preferably also be performed using an AI unit (artificial intelligence unit) on which, for example, neural networks, Petri nets, hidden Markov models, or similar are implemented.The summary of values ​​can also be transmitted as data, which is optionally encrypted.

[0013] The evaluation algorithm can also be based on a weighted and standardized assessment of several values ​​and parameters of the current state, representing a measure of the agreement between the target and actual state [0..1], and the trust definition can be determined by a threshold value. The authenticity of the secure element is verified by checking the proof of origin of the secure element. This verification can include querying whether a proof of origin is present or whether the proof of origin has a specific form, such as a certificate. Further verifications of the authenticity of the secure element can be provided, for example, verifying the certificate of origin using a public key infrastructure (PKI) or verifying the presence of a private key in the secure element.

[0014] The method according to the invention can be initiated and triggered by a CPU or processing unit or processor unit and can run at least partially in the CPU or processing unit. Alternatively, the method can also run or be initiated at least partially in a hardware component, for example in an FPGA with an additionally generated secure processor. In these cases, during the process run, it is queried and checked whether a secure element is present on the module and whether it has a proof of origin. If the method is executed in a secure element, this process step can be omitted or reduced to determining and checking whether a proof of origin is present.

[0015] The method according to the invention has the advantage that it can be determined in a simple, fast, reliable, and robust manner whether the assembly corresponds to a target state and whether the assembly or components have been unchanged since production. The method can rule out the possibility that parts of the assembly have been modified, components replaced, or that parts of the components are not or no longer original. This requires that the assembly has a secure element that provides security or authenticity verification (proof of origin) and a record memory in which at least target state values ​​of a target state are stored at the end of production or, preferably, in a (secure) commissioning phase.

[0016] The invention further enables a secure, trustworthy, and tamper-proof value chain from the semiconductor manufacturer through the electronic assembly manufacturers to the completion of ready-to-use products. This preferably includes, in addition to the verification from the production records (target state values), also the proof of origin for individual components of the assembly (semiconductor system components) with identities that can preferably be derived and verified locally during initial commissioning, preferably using keys stored in the secure element, signed fingerprints or hash values, and certificates of origin. In particular, the integration of hardware and software focused on trustworthiness is enabled by the invention. The design of the records of trust at the local system level for the design and monitoring of system integrity is a preferred implementation.

[0017] The preferably cryptographic "linking" of all ID features results in the composition (creation) of a new, immutable identity of the module, which represents the trusted, digital identity upon initial commissioning of the hardware logic and, preferably, the software. This, together with a previously generated proof of origin or certificate, serves as independent proof of authenticity in subsequent commissioning phases.

[0018] The method's flexibility in application is advantageous. It can be used in small assemblies with limited system resources as well as in multiprocessor systems. To prevent the unauthorized replacement of semiconductor components, recording multiple components with a corresponding number of stored characteristics can increase the amount of verifiable record data and thus protect against counterfeiting. Preferably, it can be planned or determined during production how safety-critical manufacturing steps, including the recording of record data (target state values), are to be implemented and coordinated with other components, such as software-related ones.

[0019] If reference samples of an assembly are available, the degree of automation in production can be advantageously implemented even in a relatively uncertain production environment. For example, the use of assembly self-tests could contribute to this and reduce manufacturing costs without compromising the desired reliability.

[0020] In a further aspect, the invention relates to a secure element for proving the trustworthiness of an electronic assembly, wherein the secure element comprises a control unit, a record memory, a secure memory, and an optional interface. The record memory comprises a target state value of the assembly. The secure element has a public key of the proof of origin, which can be output to a requesting processing unit or CPU of the assembly. The secure memory of the secure element comprises a private key of a proof of origin. The control unit of the secure element for proving trustworthiness is configured and designed to receive and process an actual state value of the assembly, to answer a request from the processing unit as to whether a proof of origin is present in the secure element using the private key, and to read the target state value of the assembly from the record memory.The control unit is further configured and designed to process and / or compare the actual state value and the target state value and to evaluate and / or decide whether the actual state is similar to, compatible with, or corresponds to the target state to such an extent that a trust criterion is met.

[0021] A further aspect of the invention relates to an electronic assembly comprising a CPU (processing unit), a bus interface, and a memory. The assembly comprises a secure element for verifying the trustworthiness of the assembly, wherein the secure element has a control unit, a record memory, and a secure memory, and wherein the secure element is preferably configured and designed to at least partially, preferably completely, execute the above-described inventive method.

[0022] A further aspect of the invention relates to a hardware component for verifying a trustworthy electronic assembly. The hardware component has a protected security processor, a record memory, and a secure memory. The hardware component is a component of the assembly to be tested and is configured and designed to carry out the above method. For example, the hardware component can be part of a system-on-chip (SoC) of the assembly. The hardware component can also be connected to the assembly via an interface, preferably detachably connected.

[0023] Further aspects of the invention relate to a computer program and a computer program product having program code for carrying out the steps of the method when the program code is executed on a computer or a hardware component or electronic assembly, as well as a storage medium on which a computer program is stored which, when executed on a computer or a CPU, effects execution of the method described herein.

[0024] The secure element can also be implemented in a multiprocessor system, using a processor that can access a record memory with a target state value and a secure memory with a proof of origin. The secure element could also be integrated into an FPGA, for example. In these cases, verification of the proof of origin can be omitted, with the preferred method being to query whether a proof of origin exists.

[0025] Alternatively, the secure element could be implemented exclusively in software or a computer program. Thus, all functions of a secure element would be realized in software. In these cases, the software can access the necessary memory.

[0026] Preferred embodiments of the invention are described in the dependent claims. It is understood that the features mentioned above and those to be explained below can be used not only in the respective combinations specified, but also in other combinations or alone, without departing from the scope of the present invention. In particular, the method and the computer program product can be implemented according to the embodiments described for the device in the dependent claims.

[0027] In a preferred embodiment of the method according to the invention, a further step is provided which comprises authorizing and / or influencing the module whose trustworthiness is being checked. In this case, the use of the module is influenced depending on the evaluation. For example, the module can be reset so that the module or its CPU reboots. It is also possible to lock individual or all components if the evaluation is negative. A positive evaluation of trustworthiness can be a prerequisite for releasing individual components, areas or elements of the module. Likewise, a process running on the module can be influenced, for example aborted, or authorized. Branches within a process or program are possible.

[0028] Preferably, the proof of origin, or at least part of it, is stored in encrypted form in the secure element. Preferably, the proof is stored in a separate memory, preferably a protected memory, such as a secure memory. This is preferably separate from the record memory. Access restrictions may exist for the secure memory and / or the record memory; for example, the secure memory can only be read by the security processor. A rights management system can be provided that assigns the secure element special rights for the memory. The rights management system can provide write permissions only for the production process and, optionally, also for commissioning. It can optionally provide the stored elements with a note or parameter relating to the time and / or process step during production or commissioning.

[0029] In a preferred embodiment of the invention, the proof of origin may comprise an origin certificate. For example, the certificate may preferably be a key certificate, which preferably comprises several parts, of which at least one certificate part may be encrypted. The key certificate preferably comprises a public key and a private key, which is preferably specially protected or encrypted.

[0030] Preferably, verifying the proof of origin for verifying the authenticity of the secure element first comprises the step of reading the public key of the secure element, preferably from the secure memory. Preferably, this reading is authorized. If the public key is encrypted in the secure element, the public key could optionally be decrypted. One method step involves checking whether the private key corresponding to the read public key is present in the secure element. In other words, it is checked whether the key pair consisting of the private key and the public key matches. Preferably, it is checked whether the matching private key is stored in the secure memory.

[0031] If the proof of origin is preferably a key certificate with a private key and a public key, the presence of the private key in the secure element is preferably checked using further steps. First, an at least partially arbitrary data value is generated, e.g. a random value. The data value preferably has a random part and a predetermined part (e.g. the current date or any sequential number). This is sent to the secure element and there encrypted with the private key to produce a result value. After being output from the secure element, the result value is decrypted with the public key. In a further step, the result value is checked against the previously generated data value (random value). This involves a comparison of the result value and the data value. A 100% comparison is preferably carried out here.

[0032] In a preferred embodiment, the method according to the invention is executed during the process of a module. For this purpose, it can be provided that this method is initiated at certain points during the boot process. Parts of the method can be initiated and controlled by the main processor of the module or the processing unit of the module. Parts of the method can be executed by the CPU or processing unit. The processor or CPU of the module then calls the secure element to execute the process steps running there.

[0033] Preferably, the boot process of the assembly or the boot process of assembly components is influenced. Depending on the procedure executed and the result of the trust criterion check, the boot process is modified or adapted. Individual components of the assembly can be locked or initiated. The boot process can be modified so that certain assemblies or components are only called or booted if the trustworthiness of the previous components has been proven in a previous step. Software licenses that may be required in the subsequent boot process can also be locked or not released.

[0034] In a preferred embodiment, individual steps of the method according to the invention, such as the verification of actual state values ​​and target state values, are carried out for individual components of the assembly or hardware components of the assembly, and the trust criterion for this component is determined. The method is then preferably run through again, but for the next component of the assembly. The control and selection of the components can be initiated and controlled by a boot process of the assembly. This can take place depending on the verification of the trustworthiness of other assemblies or components. For this purpose, several entries are preferably stored in the record memory of the secure element, i.e. several target state values, whereby a separate target state value is preferably stored and stored for each assembly or for each hardware component of an assembly.The corresponding actual state values ​​of the individual components are stimulated, initiated and / or controlled either by the CPU of the module, another processor of a component of the module or by the secure element.

[0035] A likewise preferred embodiment of the method according to the invention provides that the method can be executed during the boot process. The method according to the invention is called at corresponding points in the boot process that are provided for this purpose. The boot process thus branches to the method according to the invention. The boot process is preferably influenced by the method according to the invention. In other words, the boot process depends on the results delivered by the method. Particularly preferably, the sequence of the boot process can be changed. For example, depending on the determined trust criterion of a component of the assembly, a different sequence or different parts of the boot process can be executed.

[0036] In a preferred embodiment of the method according to the invention, an element for proving the trustworthy production of the assembly is stored in the record memory in the form of a target state value of the assembly. Preferably, at least one element for proving the trustworthy production of a component is stored in the record memory in the form of a target state value. The elements or target state values ​​comprise information about the manufacture or processing of the assembly. They can be in the form of a data record. For example, a production location, a production time, or other production-specific parameters can be stored in the element. The element corresponds to the target state value. Information about a specific configuration in the production of the assembly is also conceivable, for example the sequence in which different components of the assembly were assembled or the equipment used for production.Preferably, the elements or target state values ​​are linked to one another. Particularly preferably, they are arranged and linked in the form of a chain, preferably appended at the end. The target state values ​​stored in the record memory then correspond to a record chain, which forms a digital identity of the electronic assembly and thus contributes to the trustworthiness of the assembly.

[0037] A particular embodiment of the method or of the secure element can provide that, based on a successful check of the trustworthiness of the assembly or the trustworthiness of a component of the assembly, a new element is created for the record memory. This element is then stored in the record memory, preferably with a link to existing elements or entries in the record memory. New elements are therefore linked to existing elements. Particularly preferably, this linking also takes place in the form of a chain, for example in the form of a record chain. Preferably, the new elements are added to the end of the chain, wherein particularly preferably no elements can be inserted between existing elements. It is conceivable that new elements are added to existing elements in the form of a branch.

[0038] Preferably, the record store therefore contains not only target state values, but also other elements that can be added during the trustworthiness check of the assembly or a component of the assembly. In this way, it can be proven at a later point in time that the trustworthiness of the assembly existed at a previous point in time, i.e. in the past. Thus, the record store contains not only entries (records) created during production, but preferably also entries created at a later point in time. In addition to entries resulting from the trustworthiness check during operation of the assembly, entries can also be created during the initial commissioning of the assembly.

[0039] Previously generated entries or elements in the record memory of the secure element are then equated with the target state values ​​and are also referred to as target state values ​​in the context of this invention.

[0040] By updating the record chain or link chain in the record memory, records of trust are updated, the first element of which is preferably the proof of origin, i.e., the proof of authenticity, of the secure element. This has the advantage that, at any time during the operation of an assembly, it is possible to trace when and which trusted components and parts were installed, and when trustworthiness existed during commissioning and / or operation. Trustworthiness can preferably extend not only to components of the assembly, but also to installed and implemented firmware or software for individual components of the assembly.

[0041] In a preferred embodiment of the method according to the invention, the target state values ​​comprise a plurality of features of the assembly or a plurality of features of components. In the simplest case, the features can preferably be, for example, a serial number, a production date, a production batch, an assembly, or the like. Furthermore, they can be voltage or current values, specific clock frequencies or clock rates, software version statuses at specific times, production sites or locations or dates, maintenance or repair information, or the like. For example, a feature could also be a maximum power requirement when booting up the assembly or in a specific operating state. The list of features provided here is not intended to be exhaustive. Other features are also conceivable.

[0042] In a preferred embodiment of the secure element, the target state values ​​in the record memory can be cryptographically secured, for example, they can be encrypted. Preferably, several target state values ​​or several entries are arranged in a sequence in the record memory, whereby the sequence or chaining must particularly preferably take place in a specified order. Preferably, the series of entries begins with a link or reference to the authenticity or proof of origin of the secure element. The link or a representation value for the link or a representation value for the proof of authenticity of the secure element can be stored in the record memory, preferably encrypted. This can preferably be the first entry in the records of trust or the series of elements or state values ​​stored in the record memory.When multiple target state values ​​are arranged in a specified sequence, the term "target state value" also includes values ​​or entries in the record memory that were not generated during production and contain production-specific data or parameters. Rather, specific values ​​generated during commissioning of the assembly can also be stored as target state values. A subsequent reliability check during operation can also be stored in the record memory in the form of a "target state value."

[0043] A special embodiment of the secure element provides for a weighted assessment of the actual state value and the target state value to be carried out to demonstrate trustworthiness. The actual state values ​​and target state values ​​can be values ​​of the assembly or components of the assembly. The target state values ​​can each include not only production data, but also data from previous checks or commissioning (initial commissioning). A weighted assessment can stipulate that the trustworthiness of individual components can be lower and that a high rating only needs to be given for special or unique components. The same applies to the assessment of the trustworthiness of the assembly. Here, a distinction can be made between a comparison or alignment between current actual state values ​​and target state values ​​during production orto target condition values ​​from previous inspections, which can be incorporated with a lower rating. The evaluation of the condition values ​​can be performed within the secure element itself. Likewise, the evaluation can preferably be performed by other components of the assembly.

[0044] In a preferred embodiment, the secure element has an interface to exchange data, entries in the secure memory and / or the record memory, intermediate results, or instantaneous values ​​with external components, i.e., components on the assembly or components outside the assembly, for processing. This preferably provides the option of outsourcing at least one process step of the inventive method for proving trustworthiness to a component of the assembly. The data exchanged with the component is particularly preferably encrypted and authentic. In a particularly preferred embodiment, communication with the component via the interface only occurs if the component has a secure engine that can execute security functions in a protected area within the component.The secure engine is preferably a (co-)processor unit that is not easily accessible from the outside and / or whose program processed by the secure engine is specially protected. Security features in this context mean that the secure element has been developed and produced in a tamper-proof manner and is protected against known attack methods. Furthermore, the security level of the secure element should correspond to the current state of the art and be certified according to a standard, such as EAL.

[0045] A similarly preferred embodiment of the secure element provides an interface for exchanging data with an external component that is secured at least by security features. The component does not need to have a secure engine as defined in the description for the secure element. Security features in this context include, for example, data integrity, data authenticity, data encryption, or even protection of a key against manipulation. The term "component secured by security features" refers to a component that, for example, has a cryptographic key or a unique ID that cannot be read, can preferably be repeatedly generated by physical conditions, or is present or stored in an obfuscated manner using special methods.

[0046] A "Chain of Records" platform, which, based on an embedded trust anchor (secure element), supports both a trustworthy production chain and the secure commissioning of semiconductor components and assemblies of a specific hardware platform (device), is preferably employed and used within the scope of the invention. The trustworthiness of the hardware platform or electronic assembly consists of a secure element (SE, so-called root of trust) and other, non-clonable identity features. A backend system is also preferably used, which can support the rollout of the necessary security services during manufacturing or production, as well as other services in the lifecycle management of a product. This can be a higher-level authority that grants authorizations to specific manufacturers who manufacture and install trustworthy components or install them.produce a trustworthy assembly. Backend systems for supporting and maintaining the Records of Trust can preferably be, for example, remote Certificate Authorities (CAs) and certificate management systems, as well as authorization systems for rights management.

[0047] Based on a previously proven trustworthy hardware platform (e.g. an embedded system), equipped with a preferably embedded secure element (trust anchor SE) and further, preferably complementary non-clonable identities of semiconductor components or hardware components, the invention also includes possibilities for a trustworthy interlinking of hardware and software during initial commissioning.

[0048] This includes both the commissioning of configurable logic in an FPGA and the secure booting or bootstrapping of firmware or software (OS) through consistent application of the "Chain of Records" platform. This can apply to all safety-critical processes that an assembly with hardware manufacturing records must undergo until commissioning. At the end of commissioning, the records can be stored seamlessly and tamper-proof as commissioning records together with the manufacturing records in an embedded secure element (anchor of trust). In later phases of product lifecycle management, the secure element (SE) and the records of trust can be queried directly and at any time for the purposes of digital proof of origin and integrity. They thus represent a digital identity of the electronic assembly or electronic device.

[0049] Supporting the integrity of open source operating systems using the Secure Element is another possible application. To maintain and maintain the trustworthiness of all security-relevant processes, such as network and system integration, the Secure Element serves as a permanent, continuously expandable anchor of trust.

[0050] Mechanisms or methods that can ensure trustworthiness protection from the moment of initial operation are a preferred area of ​​application of the invention. This can also include maintaining system integrity, such as the protection of intellectual property, which can extend to both partially reconfigurable hardware logic and firmware and software worthy of protection as carriers of intellectual property.

[0051] The inventive approach to creating trustworthiness for an electronic hardware component or assembly is based on the use of chained records of trust throughout the entire product lifecycle. The records of trust are stored in the secure element, preferably in the record memory, and can be read from the secure element at any time. Thus, the assembly can be cryptographically verified on-site for authenticity and trustworthiness.

[0052] Building blocks and components of the Chain of Records include, on the one hand, hardware-specific features, which are preferably present as a target state value, particularly preferably summarized in a "hardware fingerprint," representing a unique feature of a specific hardware unit or electronic assembly. On the other hand, a control instruction for a multi-stage verified boot process could be a component of the Records of Trust. A manufacturer could be able to create such a hardware fingerprint, e.g., as a new element, new entry, or as a new target state value, in the record memory of the secure element. Such an entry could trigger a fingerprint check, whereby the check result, in conjunction with the secure element, can influence or interrupt the further boot process. This can include both a check for equality or similarity with respect to a reference assembly, as well as a check for uniqueness.

[0053] The embedding of the hardware fingerprint in conjunction with a multi-stage verified boot process into the records of trust already existing from the production of the components within the manufacturing process, together with an extension of the trustworthiness (trusts) to the operational phase in the form of protected firmware and software, creates a completely new, holistic verification system for the trustworthiness of electronic systems and assemblies.

[0054] To ensure the trustworthy commissioning of an electronic assembly (HW platform) and its integrity, individual process or method steps that are successively tested for trustworthiness are required. The invention provides that, as outlined above, a digitally signed production history is already present in the secure element (trust anchor SE), characterized by the storage of production-relevant process steps, data, serial numbers, or QA verifications, preferably in the form of one or more records (elements or entries) in the record memory. These records can be verified during the ongoing commissioning process or during the operational phase, preferably using cryptographic functions of the secure element, but also outside the secure element. For example, the creation of a fingerprint could also take place in a special boot layer of an FPGA.This can then be encrypted or transmitted to the secure element via a protected connection and verified. During initialization of the hardware platform or assembly, ID characteristics, which may be based on hardware fingerprints of individual components, are verified and, depending on the result, used to authorize subsequent steps in the hardware initialization and / or boot process. The same procedure can also be applied to the application of fingerprints of hardware logic, firmware (FW), and software (SW). The prerequisite for the process proposed here is that, prior to a largely fully automated electronics production process, so-called production records or P-records are stored for the purpose of recording hardware-related test parameters, preferably in the record memory of the secure element. These P-records serve as target state values.If component characteristics are available in the form of electrical or other parameters, trustworthiness can also be verifiably derived using decision criteria from locally implemented AI (artificial intelligence) procedures. The procedure and the required measures and components are explained in detail using examples:

[0055] In a preferred embodiment, a digital identity can be created at the hardware platform level using intelligent functions in the secure element, preferably through the design of hardware fingerprinting methods, for example by integrating UID semiconductor technologies, e.g. using physically obfuscated keys (POKs), and by binding them to unique ID features, i.e., unambiguous identity features of individual components or the assembly. These cost-effective semiconductor circuits, some of which have limited resource constraints and limited cryptographic functions, can enable unique, cryptographic authentication of the POK by the SE via a computer bus and represent a forgery-proof feature of a semiconductor component. Authenticity can be verified on-site, without establishing an external network connection, using the secure element and the records stored there.

[0056] The creation of Records of Trust and certificate management are located at the very beginning of the production chain with the creation of Records of Trust. Proof of origin of the secure element, preferably in the form of a key certificate, is another important component in establishing trustworthiness.

[0057] The invention is described and explained in more detail below using selected embodiments in conjunction with the accompanying drawings. They show: Figure 1 shows a schematic drawing of an assembly whose trustworthiness is to be proven; Figure 2 shows a secure element for proving the trustworthiness of an assembly; Figure 3 shows an example of the relationship between the manufacturing process and the target state value; Figure 4 shows a secure element in connection with the manufacturing process; Figure 5 shows an exemplary structure of a record from a record memory of the secure element; Figure 6 shows a schematic representation of a boot process of an assembly with partial proof of trustworthiness; Figure 7 shows a schematic representation of another part of a boot process with proof of trustworthiness; Figure 8 shows another schematic representation of another boot process with a secure element; and Figure 9 shows a schematic representation of the method according to the invention.

[0058] Figure 1shows an electronic assembly 100 with typical hardware components and parts. The assembly 100 comprises a processing unit or CPU 110, an operational memory 120 in which data can be temporarily stored for processing, and a non-volatile memory 130 in which values ​​can be stored that are still present in the memory even after the assembly is switched off. The assembly 100 further comprises a computer bus interface 140, optionally a logic component, e.g., a reconfigurable logical gate array, preferably an FPGA (field programmable gate array) 150, and a communications controller 160. Furthermore, the assembly 100 can have a UID unit and a PUF unit 170. In addition, the assembly can comprise further components 180, such as a digital-to-analog converter 190 or other typical processing components, e.g., sensors.

[0059] A central component of the electronic assembly 100 is a secure element 200, which is used to prove the trustworthiness of the assembly 100. The secure element 200 is the central element in which security features are stored and which performs a verification of stored data or features with current data or features of the assembly 100 in a secured area that is not accessible or only accessible to a limited extent from the outside. Access to the secure element 200 is partially only possible after authorization and by authorized units or programs.

[0060] Figure 2shows the secure element 200 in detail. It comprises a control unit 210, a secure memory 220 in which a proof of origin 222 is stored, a record memory 230 with one or preferably several records 232, and a communication interface 240 for data exchange with components of the assembly 100, in particular for data exchange with the CPU 110 or with the FPGA 150.

[0061] The control unit 210 comprises a processor unit 212, which may include an optional co-processor (not shown), and a boot process engine 214, as well as preferably an optional AI engine 216 (artificial intelligence unit, AI engine). The control unit 210 may preferably include a random number generator (RNG) 215 for generating random or quasi-random numbers, and optionally a time generator or a clock. The control unit 210 has an actual memory 218 and a target memory 219, wherein the two volatile memories 218, 219 are configured for temporarily storing data, data sets, state values, or records. The processor 212 controls the processing processes and the method for proving the trustworthiness of the assembly 100, optionally with the aid of the co-processor and / or the AI ​​engine 216.If this verification is performed, for example, when booting the module 100, a boot control can additionally be performed using the boot process engine 214 or boot-specific parameters can be read from the record memory 230.

[0062] In the secure memory 220, the proof of origin 222 can be present in the form of a certificate of origin 223, e.g., as a key certificate. The certificate of origin 223 can comprise a public key 224 and a private key 226, wherein preferably at least the private key 226 of a proof of origin 222 of the secure element 200 is stored in the memory.

[0063] The record memory 230 preferably comprises a plurality of records 232, of which at least one record 232 is a production record or P-record 234, in which specific data of a target state, so-called target state values ​​235, are stored during the manufacture of the assembly 100, authorized by the manufacturer. The P-records 234 are preferably immutable. Alternatively, one or more records 232 can store not only production-specific features in the form of target state values, but also include specific values ​​during initial commissioning. For example, current or voltage curves when switching on or booting the assembly 100 can be stored in these IB records 236.

[0064] In addition, the records 232 can also be B-records 238, in which boot configurations or boot process sequences can be stored. Finally, it is possible for one or more records 232 to be implemented as BP records 239, which preferably include the results of a boot process during the use of the module 100. These BP records 239 can be written to the record memory 230 by the boot process engine 214 during a boot process or after a boot process of the module 100. Preferably, parts of the proof of origin 222, preferably the origin certificate 223 and / or the public key 224, can also be located at the beginning of the record memory 230. In this case, the origin certificate 223 is not stored in the secure memory.

[0065] Figure 3shows part of an authorized manufacturing process with which a chain of records of trust can be implemented. A first manufacturer 251 produces an electronic component, for example, an FPGA 150, which is mounted on a module 100. The module 100 includes a secure element 200 with a secure memory 230, as described above.

[0066] After the manufacturer 251 has installed the trustworthy FPGA 150 on the assembly 100 during its manufacturing process, production-specific process data and preferably characteristic feature data are stored in the secure element 200. Process data and features are written to the record memory 230 in the form of P-records 234. These P-records include target state values ​​235 that characterize the trustworthy FPGA 150 as it was installed on the assembly 100 during trustworthy production. The target state values ​​235 in the P-record 234 can include a serial number, a production date, a production location, the designation and serial number of the production machine, or other data. This also includes current or voltage values, for example, at an operating point, clock frequencies, or the like.It is also possible that several state values ​​are combined into one fingerprint and then the fingerprint is stored alternatively or additionally in P-Record 234.

[0067] In the further trusted manufacturing process, the same manufacturer 251 or another manufacturer 252 can install another component on the assembly 100. This component can be, for example, a UID-PUF unit 170 or a sensor. The characteristic values ​​of the UID unit or sensor are in turn stored in the record memory 230 of the secure element 200 of the assembly 100. This is again done in the form of a record 232. During this production step, the current target state values ​​235 are also stored as a P-record 234 and thus characterize the currently installed component. Preferably, the new records 232 are appended to the existing records in the record memory 230 and concatenated or linked to each other. For example, it is possible for a hash value of the previous record 232 to be stored in the subsequent record 232 of the new component (UID-PUF unit 170).

[0068] Figure 4shows the secure element 200 in detail in relation to the manufacturing process. Above a dashed line 245, individual manufacturers 250 of individual hardware components or parts of the assembly 100 are shown. For example, a manufacturer 251 can write and save a P-record 234 into the record memory 230. Writing to the record memory occurs during the manufacturing process and is authorized. For this purpose, it can be provided that only authorized manufacturers 250 are authorized to write target state values ​​235 into the records 232 and are authorized by a higher-level authority 260, for example, within the framework of a chain-of-trust system. The authorized authority 260 can be part of a chain-of-trust collaboration platform system.

[0069] A manufacturer 250 can write multiple data records to a P-record 234. Alternatively, a manufacturer can also create multiple P-records 234. It is conceivable, for example, that a first manufacturer 251 stores data from an FPGA 150 or other gate array in a P-record. This can be, for example, the serial number of the FPGA 150, production date, production location, manufacturer, clock frequency, or similar values. A second manufacturer 252 writes target state values ​​235 to another P-record 234. The second manufacturer 252 can, for example, be the manufacturer of a second component 180, for example the non-volatile memory 130, and writes the second record 232 with the target state values ​​235 that characterize this memory 130. Here, too, multiple P-records 234 can be created. Alternatively, multiple target state values ​​can also be stored in one record.The two P-records 234, which was described by manufacturer 251, and 234, which was described by manufacturer 252, are preferably linked to each other, particularly preferably in the form of a sequence or chain. In this way, linked records of trust are formed in the record memory.

[0070] At the end of the manufacturing process, a manufacturer 254 can perform an initial commissioning of the assembly 100 and write a commissioning entry in the form of an IB record 236 into the record memory 230. The IB record 236 is appended to the chain of records 232. For example, boot sequences or startup configurations can be stored here, which are then preferably made available in the boot process engine 214 of the control unit 210 and processed therein.

[0071] The record memory 230 can optionally include a proof of origin 222 or parts of a proof of origin 222 of the secure element 200. For example, a public key (public key 224) and a certificate of origin 223 can be stored in the form of a record 232 at the beginning of the concatenated records. This assumes that the proof of origin 222 is stored in the form of a public key 224 and a private key 226. The private key 226 is stored in the secure memory 220 and can only be read by the processor unit 212. The public key 224 and the private key 226 are used to verify the authenticity of the secure element 200. This is done in the manner described above.

[0072] During the boot process of the electronic platform, the current status of a component can be transmitted from the CPU 110 of the module 100 to the secure element 200 via a data channel 280, which is preferably secured. For example, the trustworthiness of the non-volatile memory 130 can be checked. For this purpose, specific features or data are read from the non-volatile memory 130 by the CPU 110 and transmitted via the data channel 280 to the communication interface 240 of the secure element 200. An actual state value 233 is temporarily stored in the actual memory 218. The processor 212 reads the corresponding values ​​from the associated record 232 or the P-record 234 for the non-volatile memory 130 and temporarily stores them in the target memory 219. The state values ​​are checked, for example, compared, by the processor unit 212 to determine whether a trust criterion is met.This could be achieved, for example, by a simple target-actual value comparison or a weighted and standardized comparison of the actual state values ​​and the target state values. Alternatively, the processor can also commission the AI ​​engine 216 for the verification process, so that part of the verification process is carried out, for example, based on neural networks or other AI algorithms in the AI ​​engine 216. Instead of comparing the target and actual values, fingerprints can be evaluated and correlated, with the target state values ​​then being stored as a fingerprint in the records 232. A fingerprint is an intelligent combination of several hardware features of the electronic assembly to form an overall state value. The fingerprint as the actual state value of a component 180 could also be recorded outside of the secure element 200, e.g., by the CPU 110 or the FPGA 150.

[0073] Additionally, before processing the state values, it can be checked whether the secure element 200 has a specific proof of origin. For this purpose, the processor unit 212 of the secure element 200 can read the private key 226 from the secure memory 220. The processor 212 determines the associated public key 224 and then compares it with the public key 224 stored in the record memory 230.

[0074] After successfully processing the status values ​​and assessing whether a decision criterion is met, the processor unit 212 can transmit a corresponding command via the communication interface 240 through the data channel 280 to the CPU 110 or processing unit of the module 100. Alternatively, the processor unit 212 can transmit the result of the trustworthiness decision to the boot process engine 214. This can preferably write a BP record 239 to the record memory 230 and append it to the existing records 232 in the form of a new record 232. In a further step, the boot process engine 214 can then transmit a boot sequence command to the CPU 110 of the module based on the check. This also takes place via the communication interface 240 and the preferably secure data channel 280.In this way, for example, the boot process of module 100 can be controlled, influenced, modified, and possibly even aborted depending on the trustworthiness check performed in secure element 200. Additionally, secure element 200 can preferably include manufacturer certificates 227 from one or more manufacturers 250, which are preferably stored in a certificate store 228. Certificate store 228 is preferably a separate store.

[0075] Figure 5 showsAn example structure of a record 232. A record 232 consists of a data set (record data) 420 and a signature (record signature) 410. A unique value is generated across all elements of the data set 420 using an algorithm. A hash function is preferably used for this purpose. This then results in a hash value 422 that uniquely represents the data set 420. Using the hash value 422 of the data set 420, a signature 414 is subsequently generated, which requires a manufacturer certificate 227, preferably in the form of a private key 226, of the record creator. In the example, the creators are individual manufacturers 250, 251. The public key 224 belonging to the private key 226 is part of the manufacturer certificate 227, which is also stored in the secure element 200. This manufacturer certificate 227 can be used to cryptographically validate the signature 414.This ensures that the record 232 was signed by the manufacturer 250, who owns the private key 226 of the manufacturer certificate 227. To identify this manufacturer certificate 227, each record 232 in the data set 420 contains a certificate ID 430 (as a reference certificate), which is also contained in the manufacturer certificate 227.

[0076] A possible concatenation of records 232 is achieved by forming a hash value 422 over an entire record 232, which hash value is particularly preferably included in the subsequent record 232 as data value 412 (Hash-RID-1). To support this method, a record 232 in the data set 420 includes a record ID 400, a value that is particularly preferably strictly monotonically increasing.

[0077] Further optional elements in record 420 of a record 232 are not listed exhaustively below.

[0078] A Type 424 element identifies different record types or types, for example, IB Record 236, B Record 238, BP Record 239. Additional types are possible. Options 426, for example, indicate that the process data 440 is encrypted or that only authorized access is permitted. The Creator 427 element can include the manufacturer name or an abbreviation for the manufacturer 250 as a supplement to the Certificate ID 430. Product Name 432 designates the name of an electronic assembly 100. The Process Step 434 element is an identification (ID) for a precise designation of a specific process step.

[0079] Timestamp 436 includes the date and time of the process step 434 performed. The result element 438 specifies the result in more detail. For example, the result can be "good" or "bad" or described in another more precise way. Process data 440 is data dependent on type 424 and preferably includes data such as process parameters, configuration parameters, target state values ​​235, process lists of a trusted boot process, or similar data.

[0080] Figure 6 shows a schematic part of a boot process of a trusted assembly, during which the proof of trustworthiness is also carried out using a secure element 200.

[0081] After a power-on reset (POR) or power-on process 300, the CPU 110 of the module 100 executes a BIOS program 310 in a step S1. After initializing a computer bus, the BIOS 310 checks in a step S2 whether a secure element 200 is present on the module 100. For this purpose, the authenticity of the secure element is verified by querying and applying a proof of origin 222 in the secure element 200, preferably by checking the origin certificate 223 with the public key 224 in the proof against the trusted certificate chain to a known root certificate of the manufacturer's system. In addition, the presence of the associated private key can also be checked using the challenge-response method. In a step S3, it is checked whether the proof of authenticity has been provided by the secure element 200.If this fails, the BIOS program branches in step S4 to a program module (subroutine) 320, in which restrictions such as a reset, i.e., a power reset, are executed. Alternatively, the secure element 200 could directly trigger a reset of the module if the trustworthiness fails.

[0082] If the verification is successful, the BIOS program continues, with a component to be verified—in this example, an FPGA 150—being initialized in step S5. The FPGA 150 preferably comprises a security processor with a computer bus connection. After initializing the FPGA 150, a (preferably secured) connection to the secure element 200 is established in step S6. The application of the proof of origin can subsequently also be performed at this point. The actual state value 233 of the FPGA 150 is then transmitted to the secure element 200. The secure element 200 checks the actual state value 233 with a corresponding target state value 235 stored in the secure element. This takes place in the control unit 210 of the secure element 200. If the result, whether the component or the FPGA 150 is trustworthy, i.e. the actual state value is evaluated positively, the execution of the program continues.

[0083] In a step S7, a decision is made as to how the process continues depending on the result of the trustworthiness check of the FPGA 150. If the trustworthiness of the FPGA 150 is negative, the program module 320 is called S8, which can, for example, generate an error message or execute a reset or power reset. The subsequent booting of the operating system could be prevented, or licensed programs that should be started on the electronic assembly cannot be executed normally due to a lack of a license. It is also conceivable that a program reference can be called that triggers another process in the program module 320, which was determined, for example, by a control program according to the processing of the records in the secure element 200. Such a process can, for example, include a loading process of reconfigurable logic to initiate a reconfiguration of the FPGA 150.

[0084] If the comparison in step S7 is positive, the process continues. As shown here using the example of checking a UID PUF unit 170, other components can be checked and verified in a similar manner.

[0085] After completing the verification of further components or elements, a boot process of an operating system (OS) 330 is initiated in a further step S10. Here, too, the secure element 200 can be called in a step S11 to perform a verification, for example, to compare a software version with a stored target state value of a software version or to check or query licenses.

[0086] The boot process continues in the same pattern and includes the comparison or verified call of a licensed application program 340, whereby the secure element 200 is again accessed. If, in one of the previous steps in the boot control phase, an actual state value 233 was not considered trustworthy according to the target state value 235 in the secure element 200, thereby implementing a license restriction within the secure element 200, the affected licensed application program 340 cannot start. If the trustworthiness criterion has been met, the required licenses are available in the secure element 200 and enable the application program to start normally.

[0087] Further steps after the procedure described here can be executed in the boot process. They are indicated by the dashed objects in Figure 6 indicated.

[0088] Figure 7shows an example of part of a boot process of a module 100 whose trustworthiness is to be checked.

[0089] In a first optional step S21, a platform or electronic assembly 100 with its CPU 110 starts the loading process of a BIOS when switched on in order to initialize the hardware components and parts of the assembly 100 and to make them available on an internal computer bus for further commissioning steps by the operating system.

[0090] In a second step S22, the secure element 200, as the central trust anchor of the assembly 100, initializes the computer bus interface in order to be able to communicate with the components and parts 180 of the assembly 100 connected to it. For simplicity, it is assumed that an exchange of information with other parts 180 can be established via the computer bus after the initialization phase has been completed.

[0091] In a next step S23, an internal process in the secure element 200, a so-called boot-checking program, is started. This process reads marked P-records 234 in sequential order (or selected differently) from the record memory 230 and optionally decrypts them.

[0092] The read-out data may, for example, be target values ​​of the electronic assembly 100 with respect to the preferred or expected sequence of boot processes, which were determined at the end of a development process as typical target values ​​of this electronic assembly.

[0093] A read P-Record 234 may also contain data previously generated by authorized manufacturers during a manufacturing and / or testing process of the assembly and written to the P-Record 234. This can be important data from the manufacturing processes, but also values ​​of individual parts or components that are determined in tests and commissioning procedures and then authorized to be written to a P-Record 234 as a target value (target state value).

[0094] Optionally, the linked records of trust, consisting of the P-records 234, are now fully or partially cryptographically validated. For this purpose, manufacturer certificates 227 are preferably checked to determine whether they belong to a hierarchical public key infrastructure (PKI), for example, a manufacturer association. In addition, the signature of the P-records 234 is preferably validated with the public key of the manufacturer certificate.

[0095] In a further step S24, the P-records 234 are selected for monitoring the trusted boot process.

[0096] According to step S25, a communication channel is established between the secure element 200 and the selected component 180, provided the component is in an active state. The actual values ​​(actual state values ​​233) of the selected component are read via this channel. These can be, for example, a UID or a securely transmitted fingerprint of the component.

[0097] In a further step S26, the target state value 235 of a component from a P-record 234 is related to the actual state value 233 read out in step S25 and evaluated.

[0098] In a subsequent step S27, an evaluation algorithm determines whether a successful result was achieved. Depending on the result of a comparison or analysis operation, a subsequent process is then initiated. If an expected, positive result is not received, the internal process interrupts a further course of the boot process specified by a record, or the internal process does not release resources required for the further course. Additionally, a boot control process record (BP record 239) can optionally be added to the record memory 230.

[0099] In a specific case, for example, the fingerprint read from a component would not match the stored fingerprint of a P-record. According to the flowchart, this is, for example, the exit to step S29, which returns to the beginning of the reset state or the power-on-reset state (POR state). Alternatively, further restrictions can be provided in step S29, such as no permission to execute the next boot level (No Flash enabling to load next Boot Level), no permission to load or execute target software (No license enabling for target software), or no delivery of an encryption key (No delivery of decryption key).

[0100] If the comparison in step S27 is positive, the further course of the boot processes can be continued under the control of a boot checking program (BCP, Boot Control Process).

[0101] According to the sequence control, a next step S28 in the boot process is preferably only initiated when the previous boot process or boot sub-process has been successfully completed. For this purpose, the boot-checking program optionally sends a message to the last active component of the module or to the processing unit 110 or the FPGA 150 that the component status query was successfully checked and that program flow control is released for initializing the next program section. In other words, the further sequence of boot processes proceeds "freely" until a next checkpoint in the sequence at which, for example, another component, after initialization by the driver and preferably establishment of a communication channel, can be queried for the trustworthiness (authenticity) of the hardware.

[0102] In Figure 8The verification of a hardware feature based on the target state values ​​235 in a record of trust is shown as an example.

[0103] The CPU 110 of the electronic assembly executes the start program and checks the availability of a secure element 200. After an optional check of the proof of origin 222, the CPU 110 reads a preferably existing B-record, which contains a list of the hardware features of the assembly to be checked, i.e., the components to be checked. The hardware feature to be checked first in the sequence, i.e., the next component of the assembly 100, is the UID unit 170 in this example. To do this, the secure element 200 generates a random data sequence, preferably with an appended timestamp, in the RNG unit 215 (Random Number Generator). This data sequence is transmitted to the UID unit 170 via the computer bus with the support of the CPU 110.

[0104] The UID unit 171 uses cryptographic functions in a UID co-processor 172 and encrypts the data sequence with a key UIDi taken from the UID memory 173. The UID memory 173 could also consist of a physical unclonable function.

[0105] The encrypted data is transferred back to the secure element 200 via the computer bus (transfer response) and decrypted there by the processor unit 212 of the secure element 200. The UID key used for decryption is read as a target state value from the IB record 236, which belongs to the tested UID unit and was stored in the record memory 230 during the initial commissioning of the module.

[0106] The evaluation algorithm in the co-processor of the secure element 200 checks the result of the decryption of the response for equality with the challenge that was encrypted and sent to the UID unit 170. This then serves as proof that the UIDs in the IB record of the setpoint memory (record memory 230) and the UIDi used in the UID memory 173 of the UID unit 170 are identical.

[0107] If the two are equal, the check is successful, and thus no restrictions are applied by the secure element 200, and the response is transmitted back to the CPU 110. The CPU 110 can proceed with the next check.

[0108] If the values ​​are inconsistent, the check fails and the secure element can impose restrictions on the further boot process of the device or assembly, for example a system reset or the blocking of memory resources or operating licenses.

[0109] Figure 9shows the basic sequence of the method according to the invention for proving a trustworthy electronic assembly 100 with a CPU 110, a bus interface and a secure element 200. The secure element has a record memory 230 with a target state value 235 of the assembly 100 or of components of the assembly and a proof of origin 222, which is preferably stored in a secure memory 220.

[0110] In a first step S31, an actual state value 233 of the actual state of the assembly is determined. This can be done, for example, by reading characteristics of individual components or parts or using sensors. In a further step S32, an optional check and determination is performed to determine whether the assembly has a secure element 200 with proof of origin 222.

[0111] A further step S33 provides for reading the target state value 235 from the record memory 230, wherein the target state value 235 corresponds to a target state of the assembly 100, e.g., at the time of production.

[0112] A further step S34 comprises checking the secure element 200 for authenticity by checking its proof of origin 220. A step S35 comprises processing the actual state 233 and the desired state 235 and / or a comparison of the two states.

[0113] An evaluation and decision as to whether the actual state is similar or compatible with the target state to the extent that a trust criterion is met, or whether the two states match, takes place in step S36. An optional further step S37 provides for influencing or authorizing the use of the module. Alternatively or additionally, the authorization or influencing of a process performed by the module can occur depending on the evaluation performed in step S36.

[0114] The method described here may provide for individual process steps to be executed in a different order. Furthermore, individual steps or some of the specified steps may be executed multiple times.

[0115] Alternatively and additionally, individual method steps can be applied not only to the assembly 100, but also to components or parts of the assembly 100. Thus, it has proven useful to check the actual state of individual components or elements of the assembly to determine the actual state of the assembly. The method is applied equivalently to the individual components. The actual state of the assembly 100 is then determined by repeatedly querying individual components and their actual states. The actual states of the components or parts or components are each checked and compared with stored target state values ​​in the record memory 230. The trustworthiness of the assembly can be assessed by checking several individual components for trustworthiness, thus resulting in an overall picture of the trustworthiness of the assembly.The weighting of individual component assessments can be based on their safety relevance. A 100% review and assessment can be specified for individual components. The trustworthiness review can encompass not only components and parts, but also firmware or software.

[0116] The invention is summarized below: The invention describes a method for verifying the trustworthiness of a hardware component or assembly, preferably throughout the entire product life cycle. The verification can be provided locally, at least in part, at any time, partly through a cryptographic verification of the data records stored in a secure element and partly through a collection of system-specific properties (e.g., the hardware fingerprint of a component), which are compared exactly or in a weighted manner with the properties stored in a secure element and finally assessed, e.g., by a threshold value or a yes / no decision.

[0117] The aforementioned stored data records can consist of proof of authenticity, for example a preferably cryptographic chain of trust (e.g. PKI) or of (cryptographic) proof of production steps of the hardware component carried out by trustworthy manufacturers.

[0118] On the one hand, providing proof serves to verify whether a hardware component or assembly is trustworthy; however, it can also directly influence the use of the hardware or assembly's operability. This occurs, for example, in the context of a "trusted boot process," which can only be performed if the proof of trustworthiness described above can be provided. In a preferred embodiment, this is achieved by ensuring that a key required to decrypt a boot image is only available after a check described above.

[0119] In another embodiment, the release of non-volatile memory, which may contain a boot image, can only be used after a check as described above. In another embodiment, the hardware component or assembly can be automatically reset if the check fails. In another embodiment, authenticity can also be verified via a data connection to a server.

[0120] The invention also relates to a method for securely booting a system, wherein a method for proving a trustworthy hardware component is carried out. The invention also relates to a method for proving a trustworthy electronic assembly, wherein at least one element for cryptographic proof of origin is stored in a secure element located on the assembly and / or the verification of a system-specific property of the hardware component influences and / or authorizes the boot process and / or a weighted evaluation of a cryptographic proof of origin or the system-specific properties of the hardware component or assembly can influence and / or authorize the boot process and / or a weighted evaluation is carried out partially or completely in a secure element, preferably instead of in a main processor (CPU) of the assembly and / or the expected,weighted value from the system-specific properties is stored in a secure element and / or at least one element for proving the trustworthy production of an assembly or hardware component is present and / or at least one data record influences the boot process and / or a data record for proving the trustworthy production is stored in a secure element located on the hardware component. Definitions:

[0121] System on Chip (SoC) refers to a system of components that typically also includes one or more control units with corresponding peripherals. All components are housed in a usually miniaturized unit, e.g., in the form of a package (SiP system-in-package).

[0122] A secure element (SE) is typically a protected chip with a control unit (CPU), a non-volatile record memory, and a secure memory. It preferably includes, among other things, a cryptographic coprocessor (secure engine) for securely executing cryptographic functions and typical embedded controller components such as interrupt controller RAM, flash, and interfaces.

[0123] An electronic assembly is a firmly assembled unit of a few to many electronic, analog and digital components that are controlled by one or more CPUs or controllers that can use typical components such as volatile and non-volatile memory, interface elements and additional components or systems on chip (SoCs) as well as a secure element.

[0124] A target state value of an electronic assembly comprises one or more individual target values ​​that can be statically read or determined, dynamically recorded over time, or generated through a cryptographic operation. Determination is preferably also carried out using sensors, SoCs, or special components with various options for generating a digital identity. Target state values ​​in the broader sense can also be state values ​​or results that have already been stored in the Records of Trust as a record in the secure element as part of an optionally distributed production process.

[0125] A record (in the record store) refers to a coherent data set whose content is integer and which has preferably been cryptographically signed by an authorized entity. Data records of a record include, for example, information, status values, and user data about the electronic assembly, its components, and its entire life cycle. The resulting records are preferably linked in a meaningful order to form a chain, the beginning of which is the first production step and, optionally, a proof of origin, and the end of which could contain data on decommissioning. This chain is called a record of trust. The chain can have branching and reintegration branches.

[0126] To demonstrate trustworthiness, records containing data on the target state of the electronic assembly, optionally also in different operating states, are primarily stored. The connection of the records into a chain is preferably established using cryptographic functions such as a hash value.

[0127] A cryptographic signature is typically created using a secret, asymmetric key, which is owned, for example, by an authorized machine, computer, person, authority, or certification authority (creator). The associated public key, along with a cryptographically signed creator certificate, is preferably stored on the secure element or on the electronic assembly. This allows the record chain to be verified at any time regarding data integrity and the authenticity of the record creator, provided the creator certificates were created in a hierarchical public key infrastructure. The records of trust created from records and a proof of origin thus contribute to the trustworthiness of an electronic assembly and establish a digital identity. The proof of origin is preferably the first element in the chain.

[0128] A proof of origin of a secure element (222) consists of an origin certificate (224) and a private key (226). The origin certificate is preferably the beginning of the records of trust. The origin certificate can be followed by all other types of records, linked by a cryptographic function.

[0129] The source certificate contains the public key (226), data about the secure element, e.g., a serial number, and preferably other elements typical for certificate management, such as the manufacturer reference, certificate ID, creation date, and expiration date. The certificate is signed with a creator certificate or the private key associated with the creator certificate.

[0130] The originator certificate, like the records, is part of a hierarchical public key infrastructure, which allows all participating certificates in a hierarchical structure to be traced back to a root certificate, thus proving that the secure element is part of a PKI structure of a manufacturer consortium and is therefore trustworthy. Each participating manufacturer in the consortium can be identified by its certificate.

[0131] The PKI infrastructure can be hosted in public CAs or on the manufacturer's side of the electronic assembly or in an association or network of trusted manufacturers.

[0132] A security processor or secure engine comprises at least a CPU, a protected memory addressable only by the CPU, and a protected record memory addressable only by the CPU. However, they have no proof of origin in a secure memory.

[0133] The desired state, actual state, and state of a component or hardware component include data and information about the configuration, structure, design, etc. of the (hardware) component and / or the properties and characteristics of the component or system-specific properties, such as power consumption, temperature, waste heat, clock speeds, processing frequencies, etc. The same applies to the states of an assembly. These can be composed of the states of the parts or components and can be weighted.

[0134] authorize means enabling a further step in the boot process, e.g. by providing a key and by enabling further components such as programs or memory areas.

[0135] The target state value comprises unique data or information about a hardware component that is generated or already available during the manufacturing process. The target state value can be a data set and stored, for example, as a so-called P-record as interpretable information, e.g., in the record memory, with storage preferably occurring during the manufacturing process. The target state value can include proof of origin in the form of hash values, a unique ID, a PUF, a POK, or a PKI (Public Key Infrastructure). The target state value or at least parts of the contained data can be encrypted.

[0136] IB records are records that are stored in the record memory during the (initial) commissioning of the assembly. They contain target state values ​​that are different for each serial piece and must be recorded during a commissioning process and added to the record memory as IB records, e.g., UIDs of IP elements or keys of POKs or verifiable serial numbers.

[0137] BP records: Records for storing data about an at least partially executed boot process, for example, records as log files stored in the record store. They are generated, for example, during the boot process or during the trustworthiness check.

[0138] B-records include a boot configuration, information on the type and order of the hardware features to be checked, and a list of the required P-records or IB-records.

[0139] Influencemeans abort, continue, block, reset, prevent.

[0140] System-specific Properties are measured values ​​such as voltage, current, time, frequency of a hardware component or special ID for creating a non-copyable / non-clonable identity such as Physical Unclonable Functions (PUF) or Physical, obfuscated Keys (POK), Secure Elements with verifiable proof of origin.

[0141] Hardware component comprises at least one instruction execution unit.

[0142] Dataset is an optionally cryptographically secured data set that represents a trusted production step.

[0143] In the claims, the words "comprising" and "having" do not exclude the presence of further elements or steps. The undefined article "a" or "an" does not exclude the presence of a plurality. A single element or unit may perform the functions of several of the units recited in the claims. An element, unit, device, and system may be partially or completely implemented in hardware and / or software. The mere mention of some measures in several different dependent claims should not be understood to mean that a combination of these measures cannot also be advantageously used. A computer program may be stored / distributed on a non-volatile data carrier, for example, on an optical storage device or on a solid-state drive (SSD).A computer program may be distributed together with hardware and / or as part of hardware, for example, via the Internet or via wired or wireless communication systems. Reference signs in the patent claims are not to be construed as limiting.

Claims

1. Method for verifying a trusted electronic assembly (100) with a CPU (110), a bus interface and a secure element (200) with a control unit (210), wherein the secure element (200) comprises a proof of origin (222) and a record memory (230) with a target state value (235) of the assembly (100), with the following steps: Determining an actual state value (233) of an actual state of the assembly (100); Reading the target state value (235) from the record memory (230), where the target state value (235) represents a target state of the assembly (100); Checking the authenticity of the Secure element (200) by verifying the proof of origin (222) of the Secure element (200), Processing the actual state value (233) and the target state value (235) and / or comparing the target state and the actual state; evaluating and deciding in the control unit (210) of the secure element (200) whether the actual state is similar or compatible with the target state or is consistent with the target state that a trust criterion is met; and authorizing and / or influencing the use of the assembly (100) and / or any process that the assembly (100) performs in the control unit (210) of the Secure element (200) and depending on the evaluation performed.

2. The method of claim 1, characterized in that authorizing and / or influencing may include locking of the assembly (100), a locking and / or releasing of parts of the assembly (100) or components of the assembly (100), resetting the assembly (100) or cancelling the process.

3. The method of claim 1 or 2, characterized in that the proof of origin (222) in the secure element (200) comprises a serial number of the secure element and / or the proof of origin (222) is stored encrypted in the secure element (200), preferably in a secure memory (220) which is different from the record memory (230).

4. Method according to any of the preceding claims, characterized in that the proof of origin (222) includes a certificate of origin (223), which is preferably a key certificate having a public key (224) and a private key (226), wherein the verification of the proof of origin (222) for proof of authenticity of the secure element (200) includes the following steps: Reading a public key (224) of the secure element (200) from the secure memory (220), Checking whether the private key (226) belonging to the public key (224) is present in the secure element (200).

5. The method of claim 4, characterized in that the verification of the presence of the private key (224) in the secure element (200) is carried out by the further steps: Generating any data value, Sending the data value to the Secure element (200); Encrypting the data value with the private key (226) in the secure element (200), Outputting a result value from the Secure element (200), Deciphering the result value with the public key (224), Checking the result value depending on the generated data value.

6. A method according to any of the preceding claims, characterized in that the method is executed during the boot process of the assembly (100) and preferably the boot process is influenced by assembly components.

7. A method according to any of the preceding claims, characterized in that the method is executable during the boot process, wherein the boot process is preferably influenced by the method, in particular the sequence of the boot process is preferably changed.

8. A method according to any of the preceding claims, characterized in that an element is stored in the record memory (230) to prove the trustworthy production of an assembly (100) in the form of a target state value (235) of the assembly (100), wherein the element comprises information of the manufacture or processing of the assembly (100), and wherein elements are linked to each other in the record memory (230), are particularly preferably strung together in the form of a chain.

9. A method according to one of the preceding claims, characterized in that on the basis of a check of the trustworthiness of the assembly (100) a new element is created for the record memory (230) and stored in the record memory (230), wherein the new elements are preferably linked to existing elements in the record memory (230), especially preferably in the form of a chain.

10. A method according to any one of the preceding claims, characterized in that the target state value (235) comprises several features of the assembly (100), preferably the features being specific and / or characteristic parameters for the component and / or assembly (100).

11. Secure element for proving the trustworthiness of an electronic assembly (100), characterized in that the secure element (200) comprises a control unit (210), a record memory (230) and a secure memory (220), whereby the record memory (230) includes a target state value (235) of the assembly (100), the secure memory (220) comprises a private key (226) of a proof of origin (222), the secure element (200) has a public key (224) of the proof of origin (222) that can be issued to a requesting processing unit, the control unit (210) is set up and trained to demonstrate trustworthiness to: - receive and process an actual state value (233) of the assembly (100), - answer a request from the processing unit as to whether proof of origin (222) exists in the secure element (200) using the private key (226), - read the target state value (235) of the module (100) from the record memory (230), - process and / or compare the actual state value (233) and the target state value (235), - assess and / or decide whether the as-is is similar or compatible with the target state or is consistent with the expected state to the extent that a trust criterion is met; - whereby - processing and / or comparing the actual state value (233) and the target state value (235) and assessing and / or deciding whether the actual state is similar or compatible with the target state to the extent that a trust criterion is met, is done in a processor unit (212) and / or an AI engine (216) of the secure element (200).

12. Secure element according to claim 11, characterized in that the secure memory (220) is encrypted, preferably at least part of the proofs of origin (222) stored in the secure memory (220) are encrypted.

13. Secure element according to claim 11 or 12, characterized in that in the record memory (230) the target state values (235) are cryptographically secured, preferably encrypted, wherein a sequence of several target state values (235) must be done in a specified order.

14. Secure element according to any of the preceding claims 11 to 13, characterized in that the record memory (230) comprises several target state values (235) of the assembly (100) in the form of records (232).

15. Secure element according to any of the preceding claims 11 to 14, characterized in that the secure element (200) performs a weighted assessment of the actual state value (233) and the target state value (235) to prove trustworthiness, wherein the control unit preferably comprises a processor unit (212) and a boot process engine (214) and / or an AI engine (216) and the processor unit and / or the AI engine performs the verification test to prove trustworthiness.

16. Secure element according to any one of the preceding claims 11 to 14, characterized in that the target state value (235) comprises several features of the assembly (100) or a component of the assembly (100), the features being preferably specific and / or characteristic parameters for the component and / or assembly (100).

17. Secure element according to any of the preceding claims 11 to 15, characterized in that the secure element (200) has an interface to outsource at least one process step for proving trustworthiness to a component of the assembly (100), wherein preferably exchanged data is encrypted with the component and particularly preferably the component has a secure engine which can perform security functions in a protected area, or the component is secured by security features.

18. An electronic assembly (100) comprising a CPU, a bus interface and a memory, characterized in that the assembly (100) comprises a secure element (200) to prove the trustworthiness of the module (100), wherein the secure element (200) has a control unit (210), a record memory (230) and a secure memory (220), wherein the secure element (200) is formed according to one of claims 11 to 17.

19. A hardware component comprising a protected security processor for proving the trustworthiness of an electronic assembly (100), wherein the hardware component comprises a record memory (230) and a secure memory (220), characterized in that the hardware component is part of the module (100) to be verified and is configured and designed to execute the method according to any one of claims 1 to 10.

20. A computer program for executing a method according to any one of claims 1 to 10.