METHOD FOR ESTABLISHING A SECURE DATA COMMUNICATION FOR A PROCESSING DEVICE AND A TRUST MODULE FOR GENERATING A CRYPTOGRAPHIC KEY AND A FIELD DEVICE

Abstract

A method for establishing a secure data communication based on a cryptographic key is provided. The method includes submitting a cryptographic key request to a trust module. A digital signature is verified based on a public key assigned to the processing device. An internal cryptographic key is generated based on the public key assigned to the processing device and a secret key assigned to the trust module. The cryptographic key is generated based on the internal cryptographic key and a key identifier of the processing device. The cryptographic key is encrypted using the public key assigned to the processing device. The encrypted cryptographic key is transmitted to the processing device. The trust module is implemented as a stateless Lambda trust anchor.

Claims

1. A method for establishing a secure data communication for a processing device based on a cryptographic key, the method comprising: submitting a cryptographic key request to a trust module, the cryptographic key request including a key identifier provided by the processing device and the cryptographic key request being protected by a digital signature of the processing device; verifying, at the trust module, the digital signature based on a public key assigned to the processing device; generating, at the trust module, an internal cryptographic key based on the public key assigned to the processing device and a secret key assigned to the trust module; generating, at the trust module, the cryptographic key based on the internal cryptographic key and the key identifier provided by the processing device; encrypting, at the trust module, the cryptographic key using the public key assigned to the processing device; and transmitting the encrypted cryptographic key to the processing device; wherein the trust module is implemented as a stateless Lambda trust anchor.

2. The method of claim 1, further comprising: decrypting, at the processing device, the encrypted cryptographic key using a secret key assigned to the processing device; and establishing a secure data communication between the processing device and another device using the cryptographic key.

3. The method of claim 1, wherein the public key assigned to the processing device is submitted to the trust module as a part of the digital signature or as a raw key or by referencing the public key.

4. The method of claim 1, further comprising: generating the internal cryptographic key using a key derivation function, wherein the key derivation function maps the public key assigned to the processing device and the secret key assigned to the trust module to the internal cryptographic key.

5. The method of claim 1, further comprising: generating, the internal cryptographic key using a key generation function at which a public-private key pair is generated based on a primary seed.

6. The method of claim 1, further comprising: generating the cryptographic key using a key derivation function, wherein the key derivation function maps the internal cryptographic key and the key identifier of the processing device to the cryptographic key.

7. The method of claim 1, further comprising: decrypting, by the secret key that is assigned to the trust module, a data structure that is transmitted as a part of the cryptographic key request from the processing device to the trust module, such that a decrypted key is obtained out of the data structure, wherein the decrypted key is used for a cryptographic operation of the trust module.

8. The method of claim 1, further comprising: submitting, the cryptographic key request from the processing device to the trust module via an authenticated communication channel.

9. The method of claim 1, further comprising: storing the generated internal cryptographic key in a volatile storage unit.

10. The method of claim 1, further comprising: storing the generated internal cryptographic key in a non-volatile storage unit.

11. The method of claim 1, wherein the trust module is formed as a crypto controller, as a hardware security module implemented on a security chip, within a separated execution environment as a Trusted Execution Environment, or as an Intel Software Guard Extension.

12. In a non-transitory computer-readable storage medium that stores instructions executable by at least one computer to establish a secure data communication for a processing device based on a cryptographic key, the instructions comprising: submitting a cryptographic key request to a trust module, the cryptographic key request including a key identifier provided by the processing device and the cryptographic key request being protected by a digital signature of the processing device; verifying, at the trust module, the digital signature based on a public key assigned to the processing device; generating, at the trust module, an internal cryptographic key based on the public key assigned to the processing device and a secret key assigned to the trust module; generating, at the trust module, the cryptographic key based on the internal cryptographic key and the key identifier provided by the processing device; encrypting, at the trust module, the cryptographic key using the public key assigned to the processing device; and transmitting the encrypted cryptographic key to the processing device, wherein the trust module is implemented as a stateless Lambda trust anchor.

13. A trust module for generating a cryptographic key for establishing a secure data communication with a processing device, the trust module comprising: an input unit configured to receive a cryptographic key request from the processing device, wherein the cryptographic key request includes a key identifier provided by the processing device, and wherein the cryptographic key request is protected by a digital signature of the processing device; a verification unit configured to verify the digital signature based on a public key assigned to the processing device; a first key generation unit configured to generate an internal cryptographic key based on the public key assigned to the processing device and a secret key assigned to the trust module; a second key generation unit configured to generate the cryptographic key based on the internal cryptographic key and the key identifier provided by the processing device; an encryption unit configured to encrypt the cryptographic key using the public key assigned to the processing device; and an output unit configured to transmit the encrypted cryptographic key to the processing device, wherein the trust module is implemented as a stateless Lambda trust anchor.

14. The trust module of claim 13, further comprising a control device configured to: decrypt the encrypted cryptographic key using a secret key assigned to the processing device; and establish a secure data communication between the processing device and another device using the cryptographic key.

15. The trust module of claim 13, wherein the trust module is implemented in a cloud backend of a Function-as-a-service-Cloud-Infrastructure and is configured to generate a client-specific key in dependence of a requesting client.

16. A field device comprising: a programmable hardware unit comprising a trust module for generating a cryptographic key for establishing a secure data communication with a processing device, the trust module comprising: an input unit configured to receive a cryptographic key request from the processing device, wherein the cryptographic key request includes a key identifier provided by the processing device, and wherein the cryptographic key request is protected by a digital signature of the processing device; a verification unit configured to verify the digital signature based on a public key assigned to the processing device; a first key generation unit configured to generate an internal cryptographic key based on the public key assigned to the processing device and a secret key assigned to the trust module; a second key generation unit configured to generate the cryptographic key based on the internal cryptographic key and the key identifier provided by the processing device; an encryption unit configured to encrypt the cryptographic key using the public key assigned to the processing device; and an output unit configured to transmit the encrypted cryptographic key to the processing device, wherein the trust module is implemented as a stateless Lambda trust anchor; and the processing device comprising at least an application, wherein the field device is configured to establish a secure data communication for the application based on a cryptographic key obtained by a cryptographic key request from the trust module.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0078] FIG. 1 shows a flow chart illustrating acts of a method for establishing a secure data communication for a processing device according to an embodiment;

[0079] FIG. 2 shows a block diagram of a trust module for generating a cryptographic key according to an embodiment; and

[0080] FIG. 3 shows a block diagram of a field device according to an embodiment including the trust module according to FIG. 2 and a processing device.

DETAILED DESCRIPTION

[0081] In the figures, like reference numerals designate like or functionally equivalent elements, unless otherwise indicated.

[0082] By referring to FIGS. 1, 2, and 3, operation of a trust module LTAF is described. This includes a control process as illustrated in FIG. 1 and a field device FD shown in FIG. 3, in which in a first embodiment, the LTAF is executed.

[0083] In FIG. 3, a block diagram of a field device FD according to a first embodiment is shown. The field device FD includes a processing device CPU including an application App, a second application App2, and an operating system 30. Further, the field device FD includes a programmable hardware unit FPGA that includes a stateless trust module LTAF. The field device FD in FIG. 3 is implemented as a System-on-a-chip (SoC).

[0084] A cryptographic request getKey is transmitted from the output 28 of the application App to the input 26 of the trust module LTAF if the application App wants to receive a cryptographic key KD from the trust module LTAF. The trust module LTAF is configured to generate the cryptographic key KD in response to the cryptographic request getKey for the application App. The second application App2 is also configured to transmit a cryptographic request getKey to the trust module LTAF. Further, for operating the processing device CPU and the applications App, App2, an operating system 30 is integrated on the processing device 30.

[0085] The generated cryptographic key KD is encrypted in order to generate an encrypted cryptographic key Enc(KD). The encrypted cryptographic key Enc(KD) is transmitted from an output 27 of the trust module LTAF to an input 29 of the application App. Then, the application App is configured to decrypt the encrypted cryptographic key Enc(KD). In addition, the application App is configured to establish a secure data communication between the processing device CPU and another device based on the cryptographic key KD received from the trust module LTAF.

[0086] FIG. 1 shows a flow chart illustrating acts of a method for establishing a secure data communication for a processing device CPU based on a cryptographic key KD.

[0087] Further, the trust module LTAF in FIG. 2 includes the following parts: an input unit 20, a verification unit 21, a first key generation unit 22, a second key generation unit 23, an encryption unit 24, and an output unit 25. The elements cooperatively execute the acts shown in FIG. 1 (e.g., acts S101 to S106).

[0088] In FIG. 2, the input unit 20 of the trust module LTAF is configured to receive at an input 26 a cryptographic key request getKey from a processing device CPU, where the cryptographic key request getKey includes a key identifier devP of the processing device CPU and is protected by a digital signature sig of the processing device CPU.

[0089] Referring to FIG. 1, in the first act S101, the cryptographic key request getKey is submitted to the trust module LTAF (e.g., to the input 26 of the input unit 20 (see FIG. 2) of the trust module LTAF. In another embodiment, the cryptographic key request getKey is submitted from the processing device CPU to the trust module LTAF via an authenticated communication channel.

[0090] Further, in FIG. 2, the verification unit 21 is configured to verify the digital signature sig based on a public key Kpub-caller assigned to the processing device CPU. In this embodiment, the public key Kpub-caller is submitted to the trust module LTAF within the cryptographic key request getKey. In another embodiment, the public key Kpub-caller is submitted to the trust module LTAF as a part of the digital signature sig or as a raw key or by referencing the public key Kpub-caller. Next, the public key Kpub-caller is forwarded to the first key generation unit 22 (see FIG. 2).

[0091] Hence, according to act S102, the digital signature sig is verified based on the public key Kpub-caller.

[0092] In act S103 in FIG. 1, an internal cryptographic key Ki-caller is generated by the first key generation unit 22 (see FIG. 2) based on the public key Kpub-caller assigned to the processing device CPU and a secret key SK assigned to the trust module LTAF.

[0093] In this embodiment, the first key generation unit 22 of FIG. 2 is configured to generate the internal cryptographic key Ki-caller using a first key derivation function KDF1. The first key derivation function KDF1 maps the public key Kpub-caller and the secret key SK to the internal cryptographic key Ki-caller. In another embodiment, the internal cryptographic key Ki-caller is generated using a key generation function at which a public-private key pair is generated based on a primary seed. The generated internal cryptographic key Ki-caller is then forwarded to the second key generation unit 23 shown in FIG. 2.

[0094] In this embodiment, the generated internal cryptographic key Ki-caller is stored in non-volatile storage unit. The generated internal cryptographic key Ki-caller may also be stored in a volatile storage unit.

[0095] In FIG. 1, in act S104, the cryptographic key KD is generated by the second key generation unit 23 (see FIG. 2) based on the internal cryptographic key Ki-caller and the key identifier devP provided by the processing device CPU. In this embodiment, the second key generation unit 23 of FIG. 2 is configured to generate the cryptographic key KD using the second key derivation function KDF2. The second key derivation function KDF2 maps the internal cryptographic key Ki-caller and the key identifier devP provided by the processing device CPU to the cryptographic key KD. Next, the generated cryptographic key KD is transmitted to the encryption unit 24, which is shown in FIG. 2.

[0096] Further, in act S105 of FIG. 1, the cryptographic key KD is encrypted by the encryption unit 24 (see FIG. 2) using the public key Kpub-caller assigned to the processing device CPU and is then forwarded to the output unit 25 of FIG. 2.

[0097] The output unit 25 of FIG. 2 is configured to transmit the encrypted cryptographic key Enc(KD) to the processing device CPU (e.g., from the output 27 of the trust module LTAF to the input 29 (see FIG. 3) of the application App that is integrated within the processing unit CPU (see FIG. 3)). This corresponds to act S106 in FIG. 1.

[0098] In this embodiment, in a further act, the encrypted cryptographic key Enc(KD) is decrypted using a secret key Kpriv-caller assigned to the processing device CPU.

[0099] As a result, a secure data communication between the processing device CPU and another device using the cryptographic key KD obtained and generated from the trust module LTAF is established.

[0100] In another embodiment that is not shown, a data structure is decrypted by the secret key SK that is assigned to the trust module LTAF. The data structure is transmitted as a part of the cryptographic key request getKey from the processing device CPU to the trust module LTAF in order to obtain a decrypted key out of the data structure. The decrypted key is used for a cryptographic operation of the trust module LTAF.

[0101] The trust module LTAF in FIG. 2 is implemented as a stateless Lambda trust anchor. The trust module LTAF further includes a control device (not shown) that is implemented to operate the trust module LTAF according to the acts S101-S106 of FIG. 1.

[0102] In a further embodiment, the trust module LTAF is implemented in a cloud backend of a Function-as-a-service-Cloud-Infrastructure and is configured to generate a client-specific key in dependence of a requesting client.

[0103] In a further embodiment, the trust module LTAF is formed as a crypto controller, a hardware security module implemented on a security chip, within a separated execution environment as a Trusted Execution Environment (TEE), or an Intel Software Guard Extension (SGX).

[0104] The elements and features recited in the appended claims may be combined in different ways to produce new claims that likewise fall within the scope of the present invention. Thus, whereas the dependent claims appended below depend from only a single independent or dependent claim, it is to be understood that these dependent claims may, alternatively, be made to depend in the alternative from any preceding or following claim, whether independent or dependent. Such new combinations are to be understood as forming a part of the present specification.

[0105] While the present invention has been described above by reference to various embodiments, it should be understood that many changes and modifications can be made to the described embodiments. It is therefore intended that the foregoing description be regarded as illustrative rather than limiting, and that it be understood that all equivalents and/or combinations of embodiments are intended to be included in this description.