Electronic data processing device

Abstract

According to one embodiment, an electronic data processing device is described, the electronic data processing device having: a memory configured to store program code for encryption of a cryptographic algorithm; a cryptographic processor unit having a secure processor, an interface to a memory, an internal volatile memory, and a cryptographic function unit; a data processing unit having an interface to the cryptographic processor unit; and path selection circuitry configured to, in a configured state, provide a first data path between the memory via the cryptographic function unit to an internal volatile memory of the cryptographic processor unit, and interrupting the first data path and providing a second data path between the secure processor and the internal volatile memory and the cryptographic function unit in the execution state.

Description

Technical Field

[0001] Embodiments collectively relate to an electronic data processing device. Background Art

[0002] An electronic data processing device that processes secure data, such as cryptographic keys, should be protected from attackers gaining access to the secure data. Since protection from attacks is complex, there is the possibility of providing only a specially protected part of the data processing device, a so-called secure enclave, which works with secure data. A secure enclave represents a domain of system resources surrounded by a continuous secure area, in which the system resources are protected from physical and / or logical attacks from outside the domain (unsecure areas). However, in many applications, it is desirable to transfer data to the secure enclave from outside the secure enclave (and thus from an unsecure or at least (with respect to certain attacks) less secure area) (e.g. for updating a cryptographic algorithm to be executed by the secure enclave or a key used by the secure enclave), which may jeopardize the security of the secure enclave. A desirable methodological approach is to ensure the security of the secure enclave in this context as well. Summary of the invention

[0003] According to one embodiment, an electronic data processing device is provided, the electronic data processing device having: a memory configured to store encrypted program code for a cryptographic algorithm; a cryptographic processor unit having a security processor, an interface to the memory, an internal volatile memory and a cryptographic function unit; a data processing unit having an interface to the cryptographic processor unit, wherein the cryptographic processor unit is configured to,

[0004] - in a configuration state, receiving an encrypted program code from a memory, decrypting the encrypted program code by means of a cryptographic function unit, verifying the integrity and / or authenticity of the decrypted program code, and storing the decrypted program code in an internal volatile memory;

[0005] - in an execution state, executing the decrypted program code by means of the security processor and at least partly by means of the cryptographic function unit; and

[0006] A path selection circuit device is configured to provide a first data path between the memory via the cryptographic function unit to the internal volatile memory of the cryptographic processor unit in a configuration state, and to interrupt the first data path and provide a second data path between the security processor and the internal volatile memory and the cryptographic function unit in an execution state. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The drawings do not depict actual size relationships, but should be used to illustrate the principles of different embodiments. Different embodiments are described below with reference to the following drawings.

[0008] Figure 1 An electronic data processing device is shown.

[0009] Figure 2 A state diagram is shown for securely and authenticated loading of data for one or more algorithms of a cryptographic protocol into secure enclave memory and executing program code in the secure enclave.

[0010] Figure 3 The secure enclave is shown in greater detail and illustrates its communication with a data processing unit, one or more memories, and one or more peripheral devices.

[0011] Figure 4 The architecture of a secure enclave is shown according to one embodiment.

[0012] Figure 5 An electronic data processing device according to one embodiment is shown. DETAILED DESCRIPTION

[0013] The following detailed description relates to the accompanying drawings, which show details and embodiments. The embodiments are described in detail so that those skilled in the art can implement the invention. Other embodiments are also feasible, and changes can be made to the embodiments in terms of structure, logic and electricity without departing from the subject matter of the present invention. Different embodiments are not necessarily mutually exclusive, but different embodiments can be combined with each other to produce new embodiments. Within the scope of this specification, the terms "connect", "connect" and "couple" are used to describe direct and indirect connections, direct or indirect connections and direct or indirect couplings.

[0014] Figure 1 An electronic data processing device 100 is shown which has, in particular, a secure enclave (SE) 101 .

[0015] The data processing device 100 may be a security controller, such as an ECU (electronic control unit) in a vehicle, or may be a chip card with any form factor. However, the data processing device may also be a computer (or part thereof), a smartphone, a tablet, etc.

[0016] The data processing device 100 further has a memory 102 , a data processing unit 103 (or a plurality of data processing units) and one or more peripheral devices 104 .

[0017] The secure enclave 101 can be viewed as a set of system resources that work in the same security domain and share the protection of a unique common continuous security perimeter. The secure enclave 101 implements a cryptographic processor unit.

[0018] For example, the secure enclave 101 encapsulates confidential data, such as confidentiality keys (relative to other components 102, 103, 104, such as trust roots, encryption and signing keys), and provides algorithms for cryptographic protocols using the confidential data (such as the keys) to the data processing unit 103. This includes, for example, unilateral or mutual authentication protocols, signature creation such as ECDSA (Elliptic Curve Digital Signature Algorithm), key derivation or encapsulation, etc. The secure enclave 101 can also control the state and behavior of the system in which the secure enclave is embedded, that is, the data processing device 100, in that the secure enclave activates or deactivates security functions provided by the system.

[0019] The secure enclave 101 may contain, for example, cryptographic primitives such as block ciphers (AES...), hash functions (SHA-2, SHA-3...), AEAD schemes (ASCON...), acceleration modules for elliptic curves and RSA, hardware implementations of post-quantum algorithms (Kyber, Dilithium...), and software implementations of different algorithms for different protocols. Such software implementations of algorithms may run on a dedicated processor or a programmable state machine embedded in the secure enclave 101. The idea of ​​the paradigm of processing with the aid of the secure enclave may be that confidential data never leaves the secure enclave, and all calculations with such confidential data also occur within the secure enclave 101, so that confidential data never experience an "external" system domain, i.e. a domain outside the secure domain of the secure enclave. The implementation of the secure enclave generally provides a higher degree of hardware security mechanisms and attack sensors than the system domain. In Figure 1 In the example of , (one or more) data processing units 103, memory 102 and peripheral devices 104 belong to the system domain which is generally considered to be unsecure. The secure enclave is isolated relative to the system domain so that even if an attacker gains control over the system domain or is able to read code and data from the system domain, the data in the SE is not compromised. In addition to keys, useful data worth protecting and code worth protecting (such as implementing a dedicated algorithm that should remain confidential) can belong to the data.

[0020] exist Figure 1 The data path is referred to as ICT-X, where ICT-X stands for "interconnect to X".

[0021] In practice, the following requirements are typically required to implement a (desirable) secure enclave:

[0022] ●Confidential data (e.g. keys, certificates, algorithms, ...) must be loaded into the secure enclave.

[0023] Typically, the information must be chip-individualized. For example, not every security application allows on-chip key generation or implements a hardware PUF (Physically Uncloneable Function) in a secure enclave to provide chip-individualized keys (or chip-individualized key material, i.e., key information).

[0024] Flexibility in the algorithms used by the secure enclave is typically required, i.e. after the hardware is manufactured and used, it should be feasible to change the algorithms (and thus e.g. the supported protocols) multiple times:

[0025] The reason for this may be,

[0026] o providing security upgrades (after manufacturing and personalization, i.e., for example "on site"),

[0027] o Cost savings, e.g. providing different algorithms for different markets: In this case, for example, the same hardware is used for multiple markets and application-specific (e.g. market-specific) algorithms are inserted into the secure enclave. This is more cost-effective than implementing all algorithms and selecting only the required algorithms on site.

[0028] ● Requirements regarding flexibility, such as in algorithms, may also exist with regard to confidential data (such as keys, etc.), ie such data may be changed as may be required by the application.

[0029] ●If the secure enclave 101 does not have (or has insufficient) its own (i.e., internal) non-volatile memory (NVM), but only has (sufficient) volatile memory, the (if necessary chip-individualized) algorithms and / or confidential data must be loaded from the system domain into the volatile memory (i.e., typically RAM) of the secure enclave.

[0030] What all these requirements have in common is that the algorithms and confidential data that should be loaded into the secure enclave must be trusted, private and protected in terms of their integrity (and correspondingly resistant to logical attacks (LA) according to the system requirements and in many cases also to physical attacks (PA) on the side of the system domain).

[0031] One possibility for ensuring this is to extend the higher security level required for the secure enclave to the entire system including all hardware and software, for example by using a security controller for the entire system. However, such security controllers then often lack the computing power and memory size as well as the communication interfaces required for many IoT (Internet of Things) or high-end applications.

[0032] According to different implementations, a method is provided that can achieve the above requirements (in terms of flexibility and security).

[0033] As in Figure 1 As shown in , the secure enclave includes an internal memory 105 (MEM), hereinafter referred to as SE memory 105. The SE memory 105 includes volatile memory, but may also include non-volatile memory (i.e., the SE memory 105 may be implemented by a memory device having different memory areas (e.g., chips) implemented by means of different memory technologies). As described above, the secure enclave is connected to the data processing unit 103 (PU) via a data path ICT-SE and to the memory 102 (external to the secure enclave) via a data path ICT-MS. The data paths ICT-SE and ICT-MS do not necessarily need to be implemented by separate connections, but may also be implemented by means of a single (common) connection.

[0034] In order to implement a specific (cryptographic) protocol, public data, private keys and executable code that must be downloaded from memory 102 (which can be regarded as the memory of data processing unit 103 and is therefore also referred to as PU memory 102 below for better distinction) to SE memory 105 are combined into a binary object (BO).

[0035] Multiple BOs can be stored in the PU memory 103 to support different protocols. A mechanism is proposed to protect the privacy and integrity of BOs. For example, BOs are stored in the PU memory 102 under the protection of AEAD (Authenticated Encryption with Associated Data). AEAD enables the protection of privacy and integrity in one step. Privacy and integrity can also be verified separately. This means that the privacy of each BO is protected by encryption, and the integrity and authenticity are protected by checksums. And BOs can (optionally) contain associated data.

[0036] Figure 2State diagram 200 is shown for securely and authenticated loading of data (including program code) for one or more algorithms of cryptographic methods, such as protocols (eg encryption, authentication, . . . ) into SE memory 105 and execution of the program code in the SE.

[0037] The state diagram 200 includes five states 201 to 205. The operations respectively performed in the states and the transitions between the states are implemented and controlled by a state machine (e.g., FSM (Finite State Machine)) implemented in the secure enclave 101. The SE is controlled via instructions (hardware signals), in particular by the data processing unit 103.

[0038] The first four states are also considered sub-states of the setup state 206 (or “configure” state or “prepare” state) that follows the execute state 205 .

[0039] When the data processing device 100 (or at least the secure enclave 101 ) starts up, the secure enclave 101 is in an initial state 201 (first state) or “empty” state, ie no BO is installed in the SE memory 105 .

[0040] The data processing unit 103 can trigger the loading of the BO in order to install and finally execute in the secure enclave 101 the program code of one or more algorithms for the desired method (e.g. protocol). To this end, the data processing unit sends a "key loading" instruction to the secure enclave (via the ICT-SE). This puts the SE into a second state (key loading state) 202 in such a way that the data processing unit expects the transmission of the key modifier (via the ICT-SE) necessary to decrypt the BO. If the data processing unit receives the key modifier, the secure enclave can derive the authentication key K-AUTH from the key modifier K-MOD and the root key (Root-Secret) K-ROOT available inside the (SE):

[0041] K-AUTH=kderiv(K-MOD,K-ROOT).

[0042] K-ROOT may be a key generated, for example, by the secure enclave's PUF (physical unclonable functions), or a key introduced into the secure enclave 101 during the personalization phase.

[0043] The data processing unit 103 then sends an "install" command to the secure enclave 101, which places the secure enclave in a third state (installed state) 203. The data processing unit 103 then transmits data, such as AEAD-protected BO (or BO protected with respect to privacy and integrity by means of other mechanisms), i.e., AEAD (BO), to the SE memory 105 via the ICT-MS (or ICT-SE if there is only one connection). The encrypted data is decrypted by an AEAD module (usually a cryptographic processor unit; AEAD is used here as an example) containing the SE (which can be a hardware module or software). The AEAD (BO) data contains a check value (usually after the last data word). After receiving the data, the AEAD module of the secure enclave 101 checks, based on the check value, whether the BO is authentic. If this is not the case, the secure enclave 101 transitions to a secure state, for example, clears the BO from its memory and changes to the initialized state 201 (or a separate error state). If the authentication check of the BO succeeds, the secure enclave transitions to a fourth state (ready state or standby state) 204 and prepares to execute the program code of one or more algorithms for the protocol contained in the BO.

[0044] If the data processing unit 103 then sends protocol-specific input data to the secure enclave 101, for example via the IC-SE or a separate communication data buffer, and the secure enclave starts executing one or more algorithms by means of an execution instruction to the secure enclave 101, the secure enclave 101 transitions to the fifth state 205 (execution state) and executes one or more algorithms.

[0045] After execution of one or more algorithms for the protocol is complete, the secure enclave 101 returns to the fourth state 204 (standby) and waits for a restart ( Figure 2 Path A in ). Alternative path B transitions to the second state (load keys), so that other BOs can be loaded, for example, according to other protocols or continuations of said protocols. Path C unloads the BO and returns to the empty state 201. Which path the secure enclave 101 takes, i.e., which state the secure enclave transitions to, can be determined by the configuration of the secure enclave, the content of the installed BOs, and / or the instructions of the data processing unit 103.

[0046] The internal architecture of secure enclave 101 is described in more detail below, particularly with respect to the AEAD module.

[0047] Figure 3The secure enclave 301 (corresponding to the secure enclave 101) is shown in more detail, and illustrates the communication of the secure enclave with a data processing unit 303 (corresponding to the data processing unit 103), one or more memories 302 (corresponding to the memories 102), and one or more peripheral devices 304 (corresponding to the one or more peripheral devices 104).

[0048] As mentioned above, Figure 3 The hardware architecture of the secure enclave 301, in particular the architecture of the secure enclave 301, enables algorithms, for example in the form of executable program codes with confidentiality (both are also collectively referred to below as data to be protected) to be downloaded from the system domain to the (at least partially) volatile internal memory 305 of the secure enclave 301. For the data to be protected, their authenticity, privacy and integrity should generally be ensured.

[0049] For this purpose, the secure enclave 301 includes an AEAD module 306 as mentioned above. The AEAD module 306 is, for example, Figure 1 As shown in FIG. 1 , via the interfaces provided for this purpose (ICT-SE and ICT-MS) or as shown in FIG. Figure 3 In the example, the AEAD module 306, the memory 302 and the data processing unit 303 are connected via the PU-BUS 307, and the PU-BUS connects the AEAD module 306, the memory 302 and the data processing unit 303 to each other.

[0050] Because in Figure 3 In the example of , the AEAD module 306 is provided for loading program code (or data to be protected in general) into the internal memory 305, so the AEAD module is also referred to as a loading AEAD module 306. The loading AEAD module 306 thus provides a mechanism for loading data (especially program code) from the system domain into the internal memory 305 of the secure enclave 301, as well as mechanisms for authentication (A), authenticated encryption (AE) and / or authenticated encryption with associated data (AEAD).

[0051] Optionally, it can be provided that the data verified and decrypted by the load AEAD module 306 (regarding authenticity and integrity) are re-encrypted by the memory encryption / decryption unit (MED) 312 before being stored in the internal memory 305. As mentioned above, the internal memory has non-volatile memories (e.g. EEPROM or ReRAM memories) in addition to volatile memories (e.g. RAM memories).

[0052] Furthermore, a communication interface 308 is provided (also implemented here via a P-BUS 307) for communication between the data processing unit 303 and a secure processor (e.g., a controller of a secure enclave (SE CTRL)) 309. The communication interface is used, for example, to send inputs (e.g., input values ​​for algorithms) from the data processing unit 303 to the secure enclave 301, and to send results of the execution of algorithms (e.g., cryptographic calculations) from the secure enclave 301 to the data processing unit 303.

[0053] Within the secure enclave 301, an internal memory 305 (which, as mentioned, can also be composed of multiple memories of different types) contains program code executed on the secure processor 309 as well as confidential data (such as key materials) and other data. In addition, a plurality of peripheral devices (PER) 310, 311 are provided in the secure enclave 301, which are connected to the secure processor 309 via an internal bus system (SE BUS) 313, which in the example also connects the secure processor 309 to the internal memory 305. For example, the peripheral devices 310, 311 include a plurality of cryptographic accelerators, such as cryptographic accelerators for symmetric algorithms (AES, DES, ...), hash functions (SHA, ...) and asymmetric cryptography (RSA, ECC, ...) in order to support different protocols, such as one-sided or mutual authentication, signature generation or verification, message authentication, key stream generation, message authentication code calculation and other common cryptographic services.

[0054] Some of the services require components that are also necessary for loading program code from memory 302 into internal memory 305 by means of AEAD, such as functionality also provided by load AEAD module 306. Figure 3 4. A peripheral device (PER-AEAD) 311 is shown in FIG. 4, which has basically the same function as the module (LOAD AEAD) 306 for downloading program code.

[0055] According to various embodiments, a method is provided that enables the use of only a single AEAD module (instead of the load AEAD module 306 and the PER AEAD module 311 ) without compromising flexibility and security, thereby significantly saving chip area and costs.

[0056] It should be noted that simply reusing the AEAD module 306 for use by the secure processor 309 (without other measures, as described below) would violate the secure enclave paradigm because it could, for example, open a direct path from the insecure system domain to the internal memory 305 or to confidential keys and data within the AEAD module 306.

[0057] Figure 4 Shown corresponding to Figure 3 The architecture of the invention has a secure enclave 401, a data processing unit 403, one or more memories 402 and one or more peripheral devices 404, with the following difference: instead of two AEAD modules 306, 311, only one AEAD module 406 is provided (usually a cryptographic function unit, which provides cryptographic functions such as authentication, integrity checking and decryption, but does not necessarily work according to AEAD (but for example has no "associated data")), which is connected to the secure enclave 401 so that it can be safely used in the setup state 206 to download data (especially program code) from the system domain to the secure enclave 401, and then in the execution state 205 for one or more algorithms executed in the secure enclave 401 (for example for the calculation of cryptographic services). Figure 4 , solid lines, dotted lines, and dash-dot lines represent data paths, and dashed lines represent control paths.

[0058] Path selection circuits 414 , 415 (or “gate” circuits, for example in the form of multiplexers) controlled by control unit 416 determine which data path or paths are open in a state and which data path or paths are closed in the state.

[0059] In the setup state 206 (or at least a substate of the setup state that requires a path from the system domain through the AEAD module 406 to the internal memory 405), the control unit 416 controls the path selection circuits 414, 415 so that the AEAD module 406 is connected to the data processing unit 403 and the internal memory 405 (optionally via the memory encryption / decryption unit 412). This means that the path from the data processing unit 403 via the first path selection circuit 414, the AEAD module 406, the second path selection circuit 415 and, if necessary, the memory encryption / decryption unit 412 to the internal memory 405 (i.e., in particular, the transition between the paths represented by the solid line and the dotted line) is open in the setup state 206.

[0060] As described above, in the setup state 206, the AEAD module 406 performs data decryption, authentication, and integrity checking (check value, e.g., hash checking or checksum checking). However, the data path between the security processor 409 and the internal memory 405 (i.e., the transition between the paths indicated by the dashed line and the dotted line) is instead blocked (i.e., blocked) in the setup state 206 (or at least the sub-state of the setup state that requires the path from the system domain through the AEAD module 406 to the internal memory 405). Because the security processor 409 is generally trusted, the blocking is optional.

[0061] In the execution state 205, the required data (especially program code) is installed in the internal memory 405, so that one or more corresponding algorithms can now be executed by the security processor 409. In order to enable the security processor 409 to use the AEAD module 406 for this purpose, the control unit 416 controls the path selection circuits 414, 415 so that in the execution state 205, the path from the system domain via the first path selection circuit 414 to the AEAD module 406 (i.e., the transition between the paths represented by the solid line and the dotted line at the first path selection circuit 414) is blocked, while the path from the security processor 409 to the AEAD module 406 or to the internal memory 405 (i.e., in particular, the transition between the paths represented by the dot-dash line and the dotted line at the first path selection circuit 414 and the transition between the paths represented by the dot-dash line and the solid line and the dotted line at the second path selection circuit 415) is open. When the security processor 409 has its own connection to the internal memory 405 (e.g., via the SE bus 413), in the execution state 205, the connection from the security processor 409 via the second path selection circuit (i.e., the transition between the paths represented by the solid line and the dotted line at the second path selection circuit 415) can also be blocked.

[0062] The path selection circuits 414, 415 together form a path selection circuit arrangement.

[0063] In order to meet the security requirements for the secure enclave 401, different implementations are proposed:

[0064] • The secure enclave 401 controls state transitions between its states (not the "unsecure" data processing unit 403, which can nonetheless indirectly trigger state transitions via instructions).

[0065] ● In the setup state, a one-way connection is established: data processing unit 403->AEAD module 406->

[0066] The internal memory 405 is used so that the data from the system domain can be decrypted and verified by the AEAD module 406 and stored in the internal memory 405. In addition, the path from the security processor 409 to the AEAD module 406 is blocked (for example, the control signal c for the path selection circuits 414, 415 is "on").

[0067] ●In the execution state, the path from the system domain (e.g., from PU-BUS 407) to the internal memory 405 is blocked by the path selection circuits 414, 415, and the security processor 409 can use the now open data path to the AEAD module 406 to feed data into the AEAD module 406 and call the result of the calculation (e.g., the control signal c for the path selection circuits 414, 415 is "off").

[0068] In various embodiments, the transition between the execution state 205 and the setup state 206 is security critical, since the AEAD module 406 implements a state-dependent cryptographic algorithm and thus contains keys and plaintext data. Therefore, the transition between use by the secure domain and the non-secure domain may leak confidential keys and / or plaintext data of the non-secure domain. Therefore, according to various embodiments, the control unit (CTRL) 416 ensures (e.g. by means of the control signal d) that the current keys and data in the AEAD module 406 are deleted when changing domains, i.e. when switching the path selection circuits 414, 415. This can be achieved by overwriting the keys or data with constant or random values, or by ensuring that the keys or data are always overwritten with the corresponding new keys or new data before starting an operation.

[0069] In summary, according to various embodiments, an electronic data processing device is provided, such as Figure 5 Shown in.

[0070] Figure 5 An electronic data processing device 500 according to one embodiment is shown.

[0071] The electronic data processing device 500 has a (e.g. non-secure "first") memory 502 configured to store encrypted program code for a cryptographic algorithm (e.g. together with application-specific data such as keys, identifications, certificates) (i.e. the program code is stored in an encrypted manner).

[0072] The electronic data processing device 500 further has a cryptographic processor unit 501 with an internal (eg secure “second”) volatile memory 504 , an interface to the (first) memory 502 , a security processor 505 and a cryptographic function unit 506 .

[0073] The electronic data processing device 500 also has a data processing unit 503 with an interface to the cryptographic processor unit 501 .

[0074] The cryptographic processor unit 501 is configured to,

[0075] - in the configuration state, receiving an encrypted program code from the memory, decrypting the encrypted program code by means of the cryptographic function unit 506, verifying the integrity and / or authenticity of the decrypted program code, and storing the decrypted program code in the internal volatile memory 504;

[0076] In the execution state, the decrypted program code is executed by means of the security processor 505 and at least partially by means of the cryptographic function unit 506 .

[0077] The electronic data processing device 500 (e.g., the cryptographic processor unit 501) also has a path selection circuit device 507, which is configured to provide a first data path from the (first) memory 502 via the cryptographic function unit 506 to the internal volatile memory 504 of the cryptographic processor unit 501 in a configuration state, and to interrupt the first data path in an execution state and provide a second data path between the security processor 505 and the internal volatile memory 504 and the cryptographic function unit 506.

[0078] According to different embodiments, a cryptographic processor unit (e.g., a secure enclave or a portion of a secure enclave) provides multiple paths that enable the use of the cryptographic processor unit 501 not only when installing program code on the cryptographic processor unit 501 but also when executing the program code without compromising security.

[0079] The cryptographic processor unit may be a secure enclave (or at least a part thereof) implemented at least partially in hardware, e.g. as part of a system, such as a microcontroller or microprocessor system, having a plurality of (other) hardware components (the hardware components e.g. implementing a memory and a data processing unit (e.g. a processor)).

[0080] Various embodiments are described below.

[0081] Embodiment 1 is an electronic data processing device, the electronic data processing device having: a memory, the memory configured to store encrypted program code for a cryptographic algorithm; a cryptographic processor unit, the cryptographic processor unit having a security processor, an interface to the memory, an internal volatile memory and a cryptographic function unit; a data processing unit, the data processing unit having an interface to the cryptographic processor unit, wherein the cryptographic processor unit is configured to,

[0082] - in a configuration state, receiving the encrypted program code from the memory, decrypting the encrypted program code by means of the cryptographic function unit, verifying the integrity and / or authenticity of the decrypted program code, and storing the decrypted program code in the internal volatile memory;

[0083] - in an execution state, executing the decrypted program code by means of the security processor and at least partly by means of the cryptographic function unit; and

[0084] A path selection circuit device is configured to provide a first data path between the memory via the cryptographic function unit to the internal volatile memory of the cryptographic processor unit in the configuration state, and to interrupt the first data path and provide a second data path between the security processor and the internal volatile memory and the cryptographic function unit in the execution state.

[0085] Embodiment 2 is the electronic data processing apparatus according to embodiment 1, wherein the path selection circuit device is configured to interrupt the second data path in the configuration state.

[0086] Embodiment 3 is an electronic data processing device according to embodiment 1 or 2, wherein the security processor does not have read access and write access to the internal volatile memory in the configuration state.

[0087] Embodiment 4 is the electronic data processing device of any one of embodiments 1 to 3, wherein the first data path is unidirectional.

[0088] Embodiment 5 is an electronic data processing device according to any one of embodiments 1 to 4, wherein the security processor does not access the cryptographic function unit in the configuration state.

[0089] Embodiment 6 is an electronic data processing device according to any one of embodiments 1 to 4, wherein the data processing unit does not access the internal volatile memory of the cryptographic function unit and the cryptographic processor unit in the execution state.

[0090] Embodiment 7 is an electronic data processing device according to any one of Embodiments 1 to 6, wherein the path selection circuit device has a first path selection circuit, and the first path selection circuit is configured to establish a connection between the data processing unit and the cryptographic function unit in the configuration state and block the connection in the execution state.

[0091] Embodiment 8 is an electronic data processing device according to embodiment 7, wherein the path selection circuit device has a second path selection circuit, and the second path selection circuit is configured to establish a connection between the security processor and the cryptographic function unit in the execution state and block the connection in the configuration state.

[0092] Embodiment 9 is an electronic data processing device according to embodiment 8, wherein the path selection circuit device is configured to establish a connection between the cryptographic function unit and the internal volatile memory in the execution state.

[0093] Embodiment 10 is an electronic data processing device according to any one of Embodiments 1 to 9, wherein the memory is configured to store a check value of the decrypted program code, and the cryptographic processor unit is configured to verify the integrity and / or authenticity of the decrypted program code based on the check value.

[0094] Embodiment 11 is an electronic data processing device according to any one of embodiments 1 to 10, wherein the cryptographic function unit is an authenticated encryption module or an authenticated encryption module with associated data.

[0095] Embodiment 12 is an electronic data processing device according to any one of Embodiments 1 to 11, wherein the cryptographic processor unit belongs to a first area of ​​the data processing device, and the first area is more strongly protected against physical attacks than a second area to which the data processing unit and the memory belong.

[0096] Embodiment 13 is an electronic data processing device according to any one of embodiments 1 to 12, wherein the cryptographic processor unit is a secure enclave of the electronic data processing device.

[0097] Further embodiments 14 to 27 are described below, which can be arranged alternatively or in combination with the above-mentioned embodiments 1 to 13 (i.e., in particular, an electronic data processing device can be provided, which has the features of any one of embodiments 1 to 13 and the features of any one of embodiments 14 to 27).

[0098] Embodiment 14 is an electronic data processing device, the electronic data processing device having: a memory, the memory being configured to encrypt and store encrypted program code for a cryptographic algorithm; a cryptographic processor unit having an internal volatile memory and an interface to the memory, wherein the cryptographic processor unit is configured to transform between preset states and has a key storage area for storing first key information; a data processing unit, the data processing unit having an interface to the cryptographic processor unit, wherein the cryptographic processor unit is configured to,

[0099] - in an initial state, waiting for second key information from the data processing unit, the second key information enabling the cryptographic processor unit to derive a key for decrypting the encrypted program code by combining the first key information with the second key information;

[0100] - in a key loading state, receiving the second key information from the data processing unit;

[0101] - in an installed state, receiving the encrypted program code from the memory, decrypting the encrypted program code by means of the key, verifying the integrity and / or authenticity of the decrypted program code, and storing the decrypted program code in the internal volatile memory;

[0102] - in the execution state, executing the decrypted program code; and

[0103] - after executing the decrypted program code one or more times, clearing the decrypted program code in the internal volatile memory and returning to the initial state.

[0104] Embodiment 15 is an electronic data processing device according to embodiment 14, wherein the cryptographic processor unit is configured to, in response to a reset instruction from the data processing unit, clear the decrypted program code in the internal volatile memory and return to the initial state.

[0105] Embodiment 16 is an electronic data processing device according to Embodiment 14 or 15, wherein the cryptographic processor unit is configured to clear the decrypted program code in the internal volatile memory and return to the initial state after executing the decrypted program code in the memory a specified number of times.

[0106] Embodiment 17 is an electronic data processing device according to any one of Embodiments 14 to 16, wherein the cryptographic processor unit is configured to, after decrypting the encrypted program code and verifying the integrity and / or authenticity of the decrypted program code, transition to a ready state in the following manner: the cryptographic processor unit waits for an execution instruction from the data processing unit and transitions to the execution state in response to the execution instruction.

[0107] Embodiment 18 is an electronic data processing device according to embodiment 17, wherein the cryptographic processor unit is configured to return to the ready state after each execution of the decrypted program code.

[0108] Embodiment 19 is an electronic data processing device according to any one of Embodiments 14 to 18, wherein the cryptographic processor unit is configured to return to the installation state after executing the decrypted program code one or more times, and receive encrypted additional program code from the memory, decrypt the additional program code with the aid of another key, verify its integrity and / or authenticity, and store it in an internal volatile memory, and execute it in the execution state.

[0109] Embodiment 20 is an electronic data processing device according to any one of embodiments 14 to 19, wherein the cryptographic processor unit is a secure enclave of the electronic data processing device.

[0110] Embodiment 21 is an electronic data processing device according to any one of embodiments 14 to 20, wherein the cryptographic processor unit has a non-volatile memory with a key storage area.

[0111] Embodiment 22 is an electronic data processing device according to any one of Embodiments 14 to 21, wherein the memory is configured to store a check value of the program code, and the cryptographic processor unit is configured to verify the integrity and / or authenticity of the received program code based on the check value.

[0112] Embodiment 23 is the electronic data processing device according to any one of embodiments 14 to 22, wherein the internal volatile memory is empty in the initial state.

[0113] Embodiment 24 is an electronic data processing device according to any one of embodiments 14 to 23, wherein the first key information is a physically unclonable function value.

[0114] Embodiment 25 is an electronic data processing device according to any one of embodiments 14 to 24, wherein the second key information is a key modification value for the first key information.

[0115] Embodiment 26 is an electronic data processing device according to any one of Embodiments 14 to 25, wherein the cryptographic processor unit is configured to delete the received program code from the internal volatile memory of the cryptographic processor unit and transition to the initial state or error state if the verification of the received program code fails.

[0116] Embodiment 27 is an electronic data processing device according to any one of Embodiments 14 to 26, wherein the cryptographic processor unit belongs to a region of the data processing device that is more strongly protected against physical attacks than a region to which the data processing unit and the memory belong.

[0117] Although the present invention is particularly shown and described with reference to specific embodiments, it will be appreciated by those skilled in the art that a large number of changes may be made to the embodiments in terms of design and detail without departing from the spirit and scope of the present invention as defined by the specification. Therefore, the scope of the present invention is determined by the embodiments and is intended to include all changes that fall within the meaning and equivalent scope of the embodiments.

[0118] Reference numerals list

[0119] 100 Data processing equipment

[0120] 101 Safe Enclave

[0121] 102 Memory

[0122] 103 Data Processing Unit

[0123] 104 (multiple) peripheral devices

[0124] 105 Internal Memory

[0125] 200 State Diagram

[0126] 201-205 status

[0127] 301 Safe Enclave

[0128] 302 Memory

[0129] 303 Data Processing Unit

[0130] 304 Peripheral equipment

[0131] 305 Internal memory (of the secure enclave)

[0132] 306 AEAD module

[0133] 307 PU bus

[0134] 308 Communication Interface

[0135] 309 Security Processor

[0136] 310, 311 Internal peripherals (of secure enclave)

[0137] 312 Memory encryption / decryption unit

[0138] 313 Internal bus system (of the secure enclave)

[0139] 401 Secure Enclave

[0140] 402 Memory

[0141] 403 Data Processing Unit

[0142] 404 Peripheral Devices

[0143] 405 Internal storage (of secure enclave)

[0144] 406 AEAD module

[0145] 407 PU bus

[0146] 408 Communication Interface

[0147] 409 Security Processor

[0148] 410, 411 Internal peripherals (of secure enclave)

[0149] 412 Memory encryption / decryption unit

[0150] 413 Internal bus system (of the secure enclave)

[0151] 414, 415 path selection circuit

[0152] 416 Control Unit

[0153] 500 Data processing equipment

[0154] 501 Cryptographic Processor Unit

[0155] 502 Memory

[0156] 503 Data Processing Unit

[0157] 504 Internal volatile memory of the cryptographic processor unit

[0158] 505 Security Processor

[0159] 506 Cryptographic Function Unit

[0160] 507 Path Selection Device

Claims

1. An electronic data processing device, comprising: a memory configured to store encrypted program code for a cryptographic algorithm; a cryptographic processor unit having a security processor, an interface to the memory, an internal volatile memory and a cryptographic function unit; a data processing unit having an interface to the cryptographic processor unit; wherein the cryptographic processor unit is configured to: - in a configuration state, receiving the encrypted program code from the memory, decrypting the encrypted program code by means of the cryptographic function unit, verifying the integrity and / or authenticity of the decrypted program code, and storing the decrypted program code in the internal volatile memory; - in an execution state, executing the decrypted program code by means of the security processor and at least partially by means of the cryptographic function unit; as well as A path selection circuit device is configured to provide a first data path between the memory via the cryptographic function unit to the internal volatile memory of the cryptographic processor unit in the configuration state, and to interrupt the first data path and provide a second data path between the security processor and the internal volatile memory and the cryptographic function unit in the execution state.

2. The electronic data processing device according to claim 1, The path selection circuit arrangement is configured to interrupt the second data path in the configuration state.

3. An electronic data processing device according to claim 1 or 2, The security processor does not perform read access and write access to the internal volatile memory in the configuration state.

4. An electronic data processing device according to any one of claims 1 to 3, The first data path is unidirectional.

5. An electronic data processing device according to any one of claims 1 to 4, The security processor does not access the cryptographic function unit in the configuration state.

6. An electronic data processing device according to any one of claims 1 to 4, The data processing unit does not access the internal volatile memory of the cryptographic function unit and the cryptographic processor unit in the execution state.

7. An electronic data processing device according to any one of claims 1 to 6, The routing circuit arrangement has a first routing circuit which is configured to establish a connection between the data processing unit and the cryptographic function unit in the configuration state and to block the connection in the execution state.

8. The electronic data processing device according to claim 7, The routing circuit arrangement has a second routing circuit which is configured to establish a connection between the security processor and the cryptographic function unit in the execution state and to block the connection in the configuration state.

9. The electronic data processing device according to claim 8, The routing circuit arrangement is configured to establish a connection between the cryptographic function unit and the internal volatile memory in the execution state.

10. An electronic data processing device according to any one of claims 1 to 9, The memory is configured to store a check value of the decrypted program code, and the cryptographic processor unit is configured to verify the integrity and / or authenticity of the decrypted program code according to the check value.

11. An electronic data processing device according to any one of claims 1 to 10, The cryptographic function unit is an authentication encryption module or an authentication encryption module with associated data.

12. An electronic data processing device according to any one of claims 1 to 11, The cryptographic processor unit belongs to a first area of ​​the data processing device, which is more strongly protected against physical attacks than a second area to which the data processing unit and the memory belong.

13. An electronic data processing device according to any one of claims 1 to 12, Wherein the cryptographic processor unit is a secure enclave of the electronic data processing device.

Images