Method for cryptographically processing data

Abstract

In a method for cryptographically processing data which are exchanged between a first unit and a control unit, a derived key is used in this process, which is derived from a secret key and an identifier. The exchanged data are encrypted using the derived key, and the exchanged data are encrypted in a tool chain, which provides the identifier.

Claims

1. A method for providing secure data communication within components of a motor vehicle, comprising: receiving, by processing circuitry and from a tester, data to be encrypted; deriving, by the processing circuitry, a derived key from (a) a secret key that is stored in a storage location of the motor vehicle, the storage location being locally accessible to a control unit of the motor vehicle and (b) an identifier; the processing circuitry encrypting the data received from the tester using the derived key; the processing circuitry encapsulating the encrypted data and the identifier in a container; and the processing circuitry outputting the container to the control unit of the motor vehicle, based on which the control unit is configured to: obtain the data by: deriving the derived key from (a) the secret key that is stored in the storage location of the motor vehicle and (b) the identifier included in the container; and decrypting the encrypted data included in the container using the derived key; and process the decrypted data for testing for errors in the processing by the control unit of the decrypted data.

2. The method as recited in claim 1, wherein the encryption is performed using a tool chain, which provides the identifier.

3. The method as recited in claim 2, wherein a random number serves as the identifier.

4. The method as recited in claim 3, wherein the derivation is performed using a public key infrastructure, which provides the secret key.

5. The method as recited in claim 3, further comprising the control unit performing the decrypting in response to receipt of the encrypted data.

6. The method as recited in claim 5, wherein the encrypted data are decrypted in a hardware security module of the control unit.

7. A data-exchange system within a motor vehicle for providing secure data communication, comprising: processing circuitry configured to: derive a derived key from (a) a secret key that is stored in a storage location of the motor vehicle, the storage location being locally accessible to a control unit of the motor vehicle and (b) an identifier; encrypt data received by the processing circuitry from a tester, wherein the encryption is performed using the derived key; encapsulate the encrypted data and the identifier in a container; and output the container to the control unit of the motor vehicle, based on which the control unit is configured to: obtain the data by: deriving the derived key from (a) the secret key that is stored in the storage location of the motor vehicle and (b) the identifier included in the container; and decrypting the encrypted data included in the container using the derived key; and process the decrypted data for testing for errors in the processing by the control unit of the decrypted data.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 shows a trust pyramid.

(2) FIG. 2 shows functions of an HSM in a schematic representation.

(3) FIG. 3 shows the configuration of one embodiment of the HSM in a schematic representation.

(4) FIG. 4 shows an encryption of a software container according to the related art.

(5) FIG. 5 shows one possible specific embodiment of the introduced method.

DETAILED DESCRIPTION OF THE INVENTION

(6) The present invention is schematically shown in the drawings based on specific embodiments and is described in greater detail hereafter with reference to the drawings.

(7) To trust an IT system to the effect that it always operates as is expected, it is necessary to consecutively trust all layers which are integrated in order to create a trustworthy IT system.

(8) FIG. 1 shows a trust pyramid for a typical IT system. This pyramid is denoted overall by reference numeral 10 and includes a layer for an organizational security 12, a layer for a system security 14, a layer for a hardware security 16, a layer for a software security 18, and a topmost layer for trust 20.

(9) To be able to trust the entire IT system, it is necessary that each layer is able to trust in the effective security of the layer underneath, without being able to directly verify this. This means, for example, that a perfect software and hardware security approach may prove useless as a result of a weak security system design underneath. Moreover, it may be that a possible weakness in the system design is not detected or prevented by the upper hardware and software layers.

(10) In contrast to typical back and IT systems, the hardware layer of embedded systems is often exposed to physical attacks, which influence hardware or software functions through physical means, for example manipulate a flash memory or deactivate alarm functions. One approach for making such physical attacks more difficult is to use in particular manipulation-protected hardware security modules (HSM), as they are shown in FIG. 2, for example. Such an HSM protects important information, for example personal identification numbers (PIN), secure keys and critical operations, for example a PIN verification, a data encryption, for example through strong physical shielding.

(11) The following illustrates how an HSM may be designed and what functions the same may be able to carry out to improve the security of an embedded system.

(12) FIG. 2 shows the core functions of a typical hardware security module. The illustration shows a software layer 30 and a hardware layer 32, which is protected against unauthorized accesses.

(13) Software layer 30 includes a number of applications 34, of which three are shown here. In addition, an operating system 36 is provided. Hardware layer 32 includes embedded standard hardware 38 and a hardware security module (HSM) 40. In this HSM 40, a first block 42 for interfaces and control, a second block 44 for secure encryption functions, a third block 46 for secure functions, and a secure memory 48 are provided.

(14) Secure memory 48 is a small, non-volatile data memory, for example having a capacity of several kilobytes, within the manipulation-protected HSM 40 to prevent a non-authorized read-out, a manipulation or a deletion of critical information, such as of cryptographic keys, cryptographic certificates or authentication data, for example PINs or passwords. Secure memory 48 of HSM 40 furthermore contains all HSM configuration information, for example information about the owner of HSM 40 or access authorizations to secured internal units.

(15) Second block 44 for secure encryption functions contains cryptographic algorithms which are used for data encryption and decryption, for example AES or 3DES, data integrity enhancement, for example MAC or HMAC, data origin verification, for example by using digital signature algorithms, such as RSA or ECC, and all associated cryptographic activities, such as key generation, key verification.

(16) Secure functions in third block 46 include all protected functions which are not directly assigned to a cryptographic method, HSM 40 serving as a physically protected trust anchor. This may be, for example, a physically protected clock signal, an internal random number generator, a bootstrap protection mechanism, or some critical application function, for example to implement a secure dongle.

(17) First block 42 for interfaces and control includes the internal HSM logic which implements the HSM communication with the outside world and manages the operation of all internal base components, as they are mentioned above.

(18) All functional base components of hardware security module 40, as is described above, are surrounded by a continuous physical boundary, which prevents internal data and processes from being tapped, copied or emulated, or manipulated. This could cause an unauthorized user to be able to use or compromise internal secrets. The cryptographic boundary is usually implemented with algorithmic and physical time slot countermeasures having dedicated access protection means, for example a special shield or coatings, to enable a side channel resistance, an access notice, an access resistance, or an access response.

(19) It is described hereafter how HSM 40 is able to improve the security of an embedded product approach:

(20) HSM 40 protects critical information, for example identities, signature keys or keys, through the physical shield, which may not be bypassed by a software susceptibility.

(21) HSM 40 may help detect, weaken or ward powerful point of interest (POI) attackers in that effective side channel resistance and access protection barriers are implemented, which, among other things, have strong access restrictions, even for authorized users. For example, some pieces of information are always exclusively kept within HSM 40.

(22) HSM 40 may accelerate security mechanisms in which certain acceleration circuits are used.

(23) HSM 40 may be used to reduce security costs in that highly optimized specialized circuits are added, for example for a standardized cryptography.

(24) A possible configuration of the HSM is shown in FIG. 3. It shows HSM 70 which is embedded in an environment. The illustration shows a main central processing unit 72, a system bus 74, a RAM component 76 having an area to be used jointly, and a test program 78 or debugger having associated hardware 80 and interface 82, which in turn includes a register 84. The illustration furthermore shows a memory chip 86 for flash code having a data area 88 and a secure area 90, in which secure core data are contained.

(25) An interface 100 to test program 78, a secure processing core 102, a secure RAM component 104, a random generator 106, for example a TRNG or PRNG, and keys 108, for example AES, are provided in HSM 70.

(26) In the introduced method, already present mechanisms detecting a manipulation, for example using real time track data (RTDD), or when memory limits are exceeded, for example with the aid of MPU, hypervisor and run time limits, may be evaluated by the HSM, such as with the aid of a watchdog, operating system, and based thereon, if necessary, the deactivation of functions or switch to substitute functions may be derived.

(27) It is established via the MPU, for example, whether the function leaves the memory area assigned to it. As an alternative or in addition, the watchdog may be used to establish whether the function violates the requirements in regard to the run time. A close connection exists between the operating system of the main processing core and the HSM, i.e., the HSM may provide the operating system at regular intervals with the piece of information whether a function is allowed to be carried out.

(28) The existing security infrastructure is used to activate new performance features. With this concept, subsequent programming of the new features is possible. It should be noted that previously the features to be activated have already been onboard. Should a subsequently installed app not function correctly, it is possible to switch back to the previous software again.

(29) FIG. 4 shows a method for encrypting a software container according to the related art. The software container may be exchanged between a tester and a control unit. Initially, a software container 120 is present in which data are stored unencrypted. These data are encrypted 124 using a secret key 122, so that container 126 having encrypted data is obtained. This container is transmitted together with the secret key to a control unit 128, which includes an area 130, the so-called customer block (CB), in which the secret key is stored.

(30) Due to the fact that the secret key suitable for decryption, which is comparatively unprotected, is also transmitted in addition to the encrypted data, this method is not secure.

(31) One specific embodiment of the described method is shown in FIG. 5. In the illustration, the creation of an encrypted software container is described at the top, denoted by arrow 140, and the decryption of the software container is described at the bottom, denoted by arrow 200.

(32) In the method for encrypting, a so-called public key infrastructure (PKI) 150 and a tool environment 152, which is here also referred to as a tool chain, are used. PKI 150 is a system which is able to issue, distribute and check digital certificates.

(33) A secret key 160, which in this embodiment is a symmetric key, is stored in PKI 150. In PKI 150, a further secret key 164, which is subsequently referred to as derived key 164, is derived from secret key 160. This takes place using secret key 160 and a random number 166, which in this case is the identifier which is generated in tool chain 152 and transmitted to PKI 150 in a step 170.

(34) This derived secret key 164 is transmitted in a further step 172 by PKI 150 to tool chain 152. Tool chain 152 is provided with a software container 162, in which data or software is/are stored, whereupon tool chain 152 encrypts the data using the derived secret key 164. Thereupon, tool chain 152 deletes the derived secret key 164. Subsequently, in a step 176, tool chain 152 creates an encrypted container 180 including encrypted data 182 and an area 184 in which random number 166 is stored.

(35) The illustration at the bottom, denoted by arrow 200, shows the use of an HSM 202 during the decryption in conjunction with an area 204, which herein was already referred to as CB.

(36) Initially, a programming software requests a derivation of secret key 160 with random number 166 from HSM 202, in which secret key 160 is stored. For this purpose, in a first step 210, random number 166 is transmitted from area 204 into HSM 202. HSM 202 derives the derived secret key 164 therefrom.

(37) Furthermore, the programming software in a further step 212 transfers the encrypted software container to HSM 202 for decryption. HSM 202 then decrypts the software container using the derived secret key 164.

(38) It is of significance that no secret key has to be transmitted along with the transmission, but only an identifier, for example a random number, which alone is not sufficient for an unauthorized attacker to decrypt the transmitted data.