阅读说明：本技术 集成电路中的密钥管理 (Key management in integrated circuits ) 是由 H·阿绍尔 R·福尔克 C·P·费斯特 S·弗里斯 A·马夫顿 H·苏舍克 T·泽西格 于 2020-02-14 设计创作，主要内容包括：本申请涉及一种用于集成电路(40)的现场可编程集成部分(42)中的密钥管理的方法。根据该方法,用于现场可编程集成部分(42)的硬件配置(51)被加载到现场可编程集成部分(42)中。硬件配置(51)包括密钥导出功能(45)。此外,使用密钥导出功能(45),基于在现场可编程集成部分(42)中所提供的信息来导出加密密钥。(The application relates to a method for key management in a field programmable integrated part (42) of an integrated circuit (40). According to the method, a hardware configuration (51) for the field programmable integration part (42) is loaded into the field programmable integration part (42). The hardware configuration (51) includes a key derivation function (45). Further, an encryption key is derived based on information provided in the field programmable integration portion (42) using a key derivation function (45).)

1. A method for key management in a field programmable integration portion (42) of an integrated circuit (40), the method comprising:

-loading (60) a hardware configuration (51) for the field programmable integration part (42) into the field programmable integration part (42), wherein the hardware configuration (51) comprises a key derivation function (45), and

-deriving (61) an encryption key based on information provided in the field programmable integration part (42) using the key derivation function (45).

2. The method of claim 1, wherein the hardware configuration (51) includes a control function for controlling operation of an application implemented by the field programmable integration portion (42) using the encryption key.

3. The method according to claim 1 or claim 2, wherein the information provided in the field programmable integration portion (42) comprises at least one of:

-a hardware application identifier comprised in the hardware configuration (51) loaded into the field programmable integration part (42),

-a hardware identifier included in the field programmable integration part (42) and uniquely identifying the field programmable integration part (42),

-a hardware system key provided by an application executed by logic (41) coupled to the field programmable integration part (42),

-a part of a bitstream of the hardware configuration (51),

-a fingerprint of a bitstream of said hardware configuration (51), an

-secret system parameters comprised in the field programmable integration part (42).

4. The method of any of the preceding claims, further comprising:

-performing an encryption operation in the field programmable integration part (42) using the derived encryption key.

5. The method of any one of the preceding claims, wherein deriving the encryption key comprises applying a hash function to information provided in the field programmable integration portion (42).

6. The method of any of the preceding claims, further comprising:

-generating (67) encrypted data in the field programmable integration part (42) using the encryption key, an

-transmitting (85) the encrypted data to a memory (50) remote from the field programmable integration part (42).

7. The method of any of the preceding claims, further comprising:

-receiving (86) encrypted data from a memory (50) remote from the field programmable integration part (42), and

-decrypting (68) the encrypted data using the encryption key in the field programmable integration part (42).

8. The method of any of the preceding claims, wherein the field programmable integration portion (42) represents a first field programmable integration portion (42) of the integrated circuit (40), the method further comprising:

-loading a further hardware configuration into a second field programmable integration part (43) of the integrated circuit (40), wherein the further hardware configuration comprises a further key derivation function (47),

-deriving a further encryption key by the further key derivation function (47) based on further information provided in the second field programmable integration part (43).

9. The method of claim 8, further comprising:

-generating (61), in the first field programmable integration part (42) and the second field programmable integration part (43), a session key for protecting messages communicated between the first field programmable integration part (42) and the second field programmable integration part (43) using a key agreement protocol.

10. The method of claim 9, wherein the session key comprises at least one of:

-a first direction session key for protecting messages passed from the first field programmable integrated part (42) to the second field programmable integrated part (43), and

-a second direction session key for protecting messages passed from the second field programmable integration part (43) to the first field programmable integration part (42).

11. The method of claim 9 or claim 10, further comprising at least one of:

-protecting messages of the key agreement protocol transferred from the first field programmable integrated part (42) to the second field programmable integrated part (43) using the encryption key, and

-using the further encryption key to protect messages of the key agreement protocol passed from the second field programmable integration part (43) to the first field programmable integration part (42).

12. The method according to any of claims 9-11, wherein the protection message comprises at least one of:

-encrypting the message in a first step,

-decrypting the message, and

-protecting the integrity of said message.

13. A system comprising a field programmable integration part (42) of an integrated circuit (40), wherein the field programmable integration part (42) is configured to

Loading a hardware configuration (51) for the field programmable integration part (42) into the field programmable integration part (42), wherein the hardware configuration (51) comprises a key derivation function (45) that enables the field programmable integration part (42) to perform the key derivation function, and

deriving, by the key derivation function (45), an encryption key based on information provided in the field programmable integration portion (42).

14. The system of claim 13, wherein the system (20) is configured to perform the method of any one of claims 1-12.

15. A hardware configuration for a field programmable integration part (42) of an integrated circuit (40), which hardware configuration can be loaded into the field programmable integration part (42), wherein the hardware configuration (51) causes the field programmable integration part (42) to perform the method for key management according to any one of claims 1 to 12.

Technical Field

The invention relates to a method for key management in an integrated circuit, in particular in a field programmable integrated part of an integrated circuit. The field programmable integrated part may comprise a field programmable integrated circuit comprised in a system on chip (SoC), or the field programmable integrated part may be part of a field programmable integrated circuit comprising a further integrated circuit, such as a processing unit or a further field programmable integrated part.

Background

Applications, also known as apps, which can be installed and updated independently of the basic software system, such as are known from e.g. mobile phones or tablet computers, can also be supported on industrial devices (also known as App-enabled field devices, App-enabled edge clouds). For some reasons, such as performance, power consumption, real-time behavior and key management, it may be advantageous to use a so-called "hardware App". The hardware app (hw app) may be loaded into a reconfigurable digital chip, digital circuit or digital module, such as a Field Programmable Gate Array (FPGA), a Complex Programmable Logic Device (CPLD), an Application Specific Integrated Circuit (ASIC) with an embedded FPGA or CPLD, or a system on a chip (SoC) with an embedded FPGA or CPLD. The hardware App may define in part the configuration of the digital chip or module, also referred to as partial reconfiguration. The HW App may be operated independently, or may be operated as part of an "App Bundle" that includes both the software App and the hardware App and their configuration parameters. The concept of a HW App can be utilized to outsource compute-intensive tasks to hardware. The HW App may also perform cryptographic operations in which the base key may be better protected from malware than in a purely software-based solution.

However, communication of the hardware App with entities external to the hardware App, such as an allocated software App component of an App bundle or another hardware App of another App bundle or memory external to a reconfigurable digital chip or module, may be compromised.

Disclosure of Invention

Therefore, there is a need in the art to protect external communications of a hardware App.

According to the present invention, this object is achieved by a method for key management in a field programmable integrated part of an integrated circuit, a system comprising a field programmable integrated part of an integrated circuit, and a hardware configuration of a field programmable integrated part of an integrated circuit as defined in the independent claims. The dependent claims define embodiments of the invention.

According to one aspect, a method is provided for key management in a field programmable integration portion of an integrated circuit. The integrated circuit may include, for example, a Field Programmable Gate Array (FPGA), a Complex Programmable Logic Device (CPLD), an Application Specific Integrated Circuit (ASIC) with an embedded FPGA or CPLD, or a system on a chip (SoC) with an embedded FPGA or CPLD. According to the method, a hardware configuration for a field programmable integration part is loaded into the field programmable integration part. The hardware configuration may be thought of as a hardware App that is loaded into a field programmable integration portion, for example, to provide compute intensive tasks. The hardware configuration includes a key derivation function. The key derivation function may include a key agreement function. The encryption key is derived based on information provided in the field programmable integration portion using a key derivation function. The key derivation function may include a function implemented in the field programmable integrated portion and dependent on information provided in the integrated circuit, such as secret and/or unique information that cannot be read from outside the integrated circuit. The key derivation and negotiation functions may include, for example, Diffie-Hellman key negotiation methods, also known as Diffie-Hellman key exchange methods. Diffie-Hellman key agreement (DH) is a method of securely exchanging keys over a public (unprotected) channel. By implementing the key derivation function in the field programmable integration part using information provided in the integrated circuit, the derived keys are bound to the hardware and it can be ensured that the key exchange is bound to the hardware, e.g. at least partly performed by hardware logic.

According to one embodiment, the hardware configuration includes a control function for controlling operation of an application program implemented by the field programmable integration portion using the encryption key. In particular, a control function for controlling communication of an application implemented by the field programmable integration portion may use an encryption key to protect data communicated between the field programmable integration portion and an entity external to the field programmable integration portion. Entities external to the field programmable integrated portion may include, for example, a software App assigned to a hardware App and executed by a processor coupled to the integrated circuit. Additionally, or alternatively, the entity external to the field programmable integration portion may include a memory for storing information of the field programmable integration portion, or the entity external to the field programmable integration portion may include another field programmable integration portion of the integrated circuit.

According to various examples, the information provided in the field programmable integration portion includes at least one of a hardware application identifier, a hardware system key, a portion of a hardware configured bitstream, a fingerprint of the hardware configured bitstream, and a secret system parameter. The hardware application identifier (HW-App-ID) may be integrated in a hardware configuration loaded into the field programmable integration portion. The hardware application identifier may be assigned when installing the hardware configuration in the field programmable integration portion, or may be part of the hardware configuration. A hardware identifier, such as a hardware serial number (HW-SN), may be included in the field programmable integration portion. The hardware identifier may uniquely identify the field programmable integration portion. The hardware identifier may be secret such that the hardware identifier cannot be read from outside the field programmable integration portion. The hardware system key (HW-SK) may be provided by an application associated with the hardware configuration, such as logic of an integrated circuit used to download the hardware configuration and initiate operation of the downloaded hardware configuration. The hardware system key may be secret. Both the portion of the hardware configured bitstream and the fingerprint of the hardware configured bitstream depend on the data that make up the hardware configuration and, therefore, may be considered hardware configuration bitstream dependent key information (HW-BK). The portion of the hardware configured bitstream may include a particular portion of the hardware configured bitstream loaded into the field programmable integration portion. The fingerprint of the hardware configured bitstream may be generated, for example, using a hash function, such as SHA 256. The secret system parameters (HW-SP) may be included in the integrated circuit and may be accessible only from the field programmable integration part. The binding of the derived encryption key to the hardware App and integrated circuit hardware is provided using the information listed above.

According to a further embodiment, the encryption operation is performed in the field programmable integration part using the derived encryption key. For example, the derived encryption key may be used to derive further direction-specific encryption keys for corresponding communication connections of the hardware App with entities external to the field programmable integration portion. The direction-specific encryption key may be derived using a Diffie Hellman secret established when a Diffie Hellman protocol is executed as a key agreement function. Based on the direction-specific key, further security service-specific keys may be derived, e.g. separate keys for integrity protection and confidentiality.

In various examples, deriving the encryption key includes applying a hash function, such as a Hash Key Derivation Function (HKDF), such as a keyed hash function based on a Hashed Message Authentication Code (HMAC) using a cryptographic hash function, such as a secure hash algorithm, e.g., SHA256, or a symmetric algorithm in MAC mode, e.g., according to an advanced encryption standard, such as AES-128-GMAC, to information provided in the field programmable integration portion.

In further examples, the derived encryption key may be used in connection with storing data of the field programmable integration portion in a memory external to the field programmable integration portion and retrieving the data from the memory. The memory may comprise, for example, a (non-volatile) flash memory or a (volatile) Random Access Memory (RAM). For example, the encryption key may be used to generate encrypted data in the field programmable integration portion and the encrypted data may be transmitted to a memory remote from the field programmable integration portion. Likewise, the encrypted data may be received from a memory remote from the field programmable integration portion, and the encrypted data may be decrypted in the field programmable integration portion using the encryption key. Since the encryption key depends on the hardware-specific parameters and/or the hardware App-specific parameters and is only provided in the field programmable integrated part, decryption of encrypted data of the field programmable integrated part outside the field programmable integrated part can be reliably disabled.

According to further embodiments, the hardware configuration is loaded into a first field programmable integration portion of the integrated circuit and the further hardware configuration is loaded into a second field programmable integration portion of the integrated circuit. The second field programmable integration portion may be separate from the first field programmable integration portion. However, the first field programmable integration portion and the second field programmable integration portion may be arranged in the same entity or in different entities of the integrated circuit. For example, the first field programmable integration part and the second field programmable integration part may be arranged in the same field programmable gate array or in different field programmable gate arrays. The further hardware configuration comprises a further key derivation function. The further encryption key is derived by a further key derivation function based on further information provided in the second field programmable integration part. The further information provided in the second field programmable integration portion may comprise different information than the information provided in the first field programmable integration portion, such as a different hardware application identifier for the further hardware configuration and a different portion or fingerprint of a bitstream for the further hardware configuration. However, the further information provided in the second field programmable integration part may comprise the same information as provided in the first field programmable integration part, such as a hardware identifier, secret system parameters and a hardware system key. Thus, the key derivation function and the further key derivation function may rely at least partly on the same secret information, e.g. the hardware identifier and the hardware system key, to share the secret.

According to various examples, a session key for protecting messages communicated between a first field programmable integration portion and a second field programmable integration portion may be generated in the first field programmable integration portion and the second field programmable integration portion using a key agreement protocol. The key agreement protocol may include, for example, the Diffie Hellman key exchange protocol. Protecting a message may include, for example, providing integrity protection and/or confidentiality for data included in the message.

The session key may comprise, for example, a first direction session key for protecting messages passed from the first field programmable integration portion to the second field programmable integration portion. Further, the session key may include a second direction session key for protecting messages passed from the second field programmable integration portion to the first field programmable integration portion. The second direction session key may be different from the first direction session key. However, additionally or alternatively, a single same session key may be established and used to pass messages from a first field programmable integration portion to a second field programmable integration portion and vice versa.

According to a further embodiment, messages of a key agreement protocol passed from a first field programmable integration part to a second field programmable integration part may be protected using an encryption key. Likewise, messages of the key agreement protocol passed from the second field programmable integration part to the first field programmable integration part may be protected using further encryption keys. Thus, the key agreement protocol may already be protected based on the encryption key and the further encryption key, e.g. in the sense of integrity protection. In particular, the above shared secret may help establish protection of messages of a key agreement protocol.

According to various examples, the protection message may include at least one of: encrypt messages, decrypt messages, and protect the integrity of messages. Encrypting and decrypting messages can help ensure confidentiality.

According to a further aspect, a system is provided that includes a field programmable integration portion of an integrated circuit. The field programmable integration portion is configured to load a hardware configuration for the field programmable integration portion into the field programmable integration portion. The hardware configuration includes a key derivation function that enables the field programmable integration portion to perform the key derivation function. The encryption key is derived by the key derivation function based on information provided in the field programmable integration portion. The system may be a system on a chip (SoC) and may include, for example, an integrated circuit including a processor and a field programmable integrated circuit. The system may include other components, such as a memory and an interface.

The system may be configured to perform the method described above and embodiments thereof, and thus include the advantages described above.

Another aspect relates to a hardware configuration for a field programmable integration portion of an integrated circuit. The hardware configuration may be loaded into the field programmable integration portion. The hardware configuration causes the field programmable integration portion to perform the method for key management. The method for key management may comprise the method described above and embodiments thereof.

It is to be understood that the features mentioned above and those yet to be explained below can be used not only in the respective combinations indicated, but also in other combinations or alone, without leaving the scope of the present invention.

Drawings

Fig. 1 schematically illustrates a system according to an embodiment.

Fig. 2 schematically illustrates a flow diagram of a method according to various examples.

Fig. 3 schematically illustrates a flow chart of a method according to a further example.

Fig. 4 schematically illustrates a flow chart of a method according to a further example.

Detailed Description

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be understood that the following description of the embodiments should not be taken in a limiting sense. The scope of the present invention is not intended to be limited by the embodiments or drawings described below, which are to be understood as merely illustrative.

The figures are to be regarded as schematic representations and elements illustrated in the figures are not necessarily shown to scale. Rather, various elements are shown so that their function and general purpose will become apparent to those skilled in the art. Any connection or coupling between functional blocks, devices, components or other physical or functional units shown in the figures or described herein may also be implemented by an indirect connection or coupling. Functional blocks may be implemented in hardware, firmware, software, or a combination thereof. The same reference numbers in different drawings identify similar or identical elements.

Fig. 1 schematically illustrates a system 20 including a processing unit 30, an integrated circuit 40 including a plurality of field programmable integrated portions 42 and 43, and a memory 50. System 20 may be implemented as a system on a chip (SOC), an Application Specific Integrated Circuit (ASIC), or a Printed Circuit Board (PCB). The system 20 may be an embedded device, such as an embedded industrial device. The processing unit 30 may include a Central Processing Unit (CPU) or controller configured to execute software, such as software stored in the memory 50. The memory 50 may include, for example, Read Only Memory (ROM), Random Access Memory (RAM), and/or flash memory. Integrated circuit 40 may be implemented as a Field Programmable Gate Array (FPGA) or any other kind of programmable logic, such as a Complex Programmable Logic Device (CPLD) or an ASIC with an embedded FPGA or CPLD.

In addition to software executable by the processing unit 30, the memory 50 may provide a hardware configuration 51 that may be loaded into the field programmable integration portion 42 or 43. In particular, for each field programmable integration part 42 and 43, a corresponding hardware configuration 51 may be provided. The hardware configuration 51 may be considered as a hardware application, a so-called hardware App (HW-App). The hardware App may be part of an App bundle that includes the hardware App, one or more corresponding software apps, and additional configuration/metadata for the hardware and software components. Thus, reference numeral 51 may also refer to an App bundle package that includes a package (package) of a hardware App and a software App. For each field programmable integration portion 42, 43, a corresponding App bundle 51 may be provided in memory 50.

The processing unit 30 may execute an Operating System (OS) 32 including a kernel and application software in a user space 31, thereby providing a basic software system. In the user space 31, the software apps 34 and 35 of the aforementioned App bundle may be executed. Each software App 34, 35 may include program code 36 and 38, respectively. The program code 36, 38 of each software App 34, 35 may be configured to download and communicate with an associated hardware App into the integrated circuit 40. To download the hardware App into the integrated circuit 40, a Reconfiguration and Update Manager (RUM) 33 may be provided, which is configured to communicate with Partial Reconfiguration (PR) logic 41 provided in the integrated circuit 40.

Integrated circuit 40 includes field programmable integration portions 42 and 43 and Partial Reconfiguration (PR) logic 41. The portion reconfiguration logic 41 may receive the hardware configuration for the field programmable integration portions 42 and 43 from the reconfiguration and update manager 33, configure the field programmable integration portions 42 and 43 with the corresponding hardware configuration, and initiate operation of the field programmable integration portions 42 and 43 using the corresponding hardware configuration. Integrated circuit 40 may include any number of field programmable integrated portions, such as one or two field programmable integrated portions or more than two field programmable integrated portions, such as three to ten or even more than ten.

The partial reconfiguration logic 41 may comprise a hardware system key (HW-SK) that may be accessible by the field programmable integration portions 42, 43, or that may be included in the hardware configuration by the partial reconfiguration logic 41 during loading of the hardware configuration into the corresponding field programmable integration portions 42, 43. The hardware system key may not be accessible from outside integrated circuit 40 and may therefore be considered a secret key.

The integrated circuit 40 may furthermore provide a hardware identifier, for example a hardware serial number (HW-SN). The hardware serial number may be accessible by the field programmable integration portion 42, 43 or may be included in the field programmable integration portion 42, 43. Furthermore, integrated circuit 40 may provide secret system parameters (HW-SP) that are accessible by the field programmable integrated portion but are not accessible from outside integrated circuit 40. Accordingly, the hardware system key, the hardware serial number, and the system parameter may be considered as hardware-related information denoted by reference numeral 44 in fig. 1.

The hardware configurations loaded into the field programmable integration portions 42 and 43 may each comprise a corresponding evaluation portion 45 and 47, respectively, which implements the functionality for deriving an encryption key based on, for example, the hardware-related information 44. The evaluation portions 45 and 47 may additionally consider hardware configuration-related information for deriving the encryption key. The hardware configuration related information may include, for example, hardware application identifiers (HW-App-IDs) 46 and 48 that are assigned to and uniquely identify corresponding hardware configurations. The hardware configuration related information may furthermore comprise, for example, key information (HW-BK) related to the bit stream of the hardware configuration. For example, a fingerprint of a hardware configuration's bitstream may be generated by a software App 34, 35, RUM 33, or reconfiguration logic 41 associated with the hardware App during loading of the hardware configuration into integrated circuit 40, or a particular portion of the hardware configuration's bitstream may be defined by a software App 34, 35, RUM 33, or reconfiguration logic 41 during loading of the hardware configuration into integrated circuit 40. The key information related to the bitstream is indicated in fig. 1 by reference numerals 37 and 39, respectively. The evaluation portions 45 and 47 may take into account specific portions of the bitstream or fingerprints, respectively, when deriving the encryption key.

In general, the hardware App operated in the field programmable integration part 42, 43 may use the above-described hardware configuration related information 37, 39, 46, 48 and hardware related information 44 during key management with another entity. As described above, this information may be derived directly by the hardware application from its environment, or the information may be provided by a software application associated with the hardware application. This information may be used, inter alia, in deriving keys for authentication and key agreement. This may bind the negotiated key to the corresponding hardware application and thus to the corresponding hardware. This may ensure that key agreement is indeed performed in specific hardware, e.g. via hardware-related information 44 available to the hardware App. This can be used in securing communications between two hardware apps. Protection may include confidentiality and integrity protection of information exchanged between hardware apps. Furthermore, this can be used to encrypt data of the hardware App, which data should be stored outside the hardware App, for example in the memory 50.

In addition, the hardware App may use information available in the hardware for key management to negotiate session keys. Information in the hardware may be bound to the hardware or hardware App in order to have a unique assignment.

For example, the hardware application derives the hardware application specific key based on one or more of the above-described information, i.e., a combination of the hardware configuration related information and the hardware related information. For example, a hash function may be computed based on a combination of the information described above. Furthermore, key derivation functions like HKDF or PBKDF2, or keyed hash functions like HMAC-SHA256, or symmetric algorithms like AES-128-GMAC may be used. For example, a hardware system key may be used and applied to some or all of the other information.

The hardware application specific key so derived may be used in key establishment using a key agreement protocol like Diffie Hellman, e.g. generating a shared known Diffie Hellman secret. Based on the Diffie Hellman secret thus derived, further keys may be derived, e.g. direction specific keys for a corresponding connection of the hardware application with another entity.

Various examples for operating the system 20 will be described below with reference to fig. 2-4.

Fig. 2 shows the method steps performed by the corresponding hardware App in the field programmable integrated part 42 and the method steps performed by the corresponding hardware App in the field programmable integrated part 43. In this example, unauthenticated Diffie Hellman key agreement is performed. The hardware application authenticates by using the derived key after Diffie Hellman key agreement.

In detail, in block 60, the hardware configuration for the field programmable integration portion 42 is loaded into the field programmable integration portion 42. The hardware configuration may be stored in memory 50 from which it is downloaded into the field programmable integration portion 42 via the reconfiguration and update manager 33 and the partial reconfiguration logic 41. The hardware configuration comprises the above described evaluation portion 45, which will also be named key derivation function 45 in the following.

In block 61, operation of the hardware configuration in the field programmable integration portion 42 causes the encryption key to be derived based on information in the field programmable integration portion 42 using the key derivation function 45. The information may include the hardware configuration related information and the hardware related information 44 described above, i.e., at least one of a hardware identifier, a hardware system key, secret system parameters, bitstream related key information, and a hardware application identifier. The encryption key may furthermore be derived based on Diffie Hellman system parameters. The encryption Key so derived is specific to the hardware App of the field programmable integrated portion 42 and will therefore be referred to in the art as a HW-App-Key 1. In addition to the HW-App-Key1, a public Diffie Hellman Key (DH-HWA 1-public) and a private Diffie Hellman Key (DH-HWA 1-private) may be generated for application in later steps in the Diffie Hellman Key agreement protocol.

Likewise, in block 70, the hardware configuration for the field programmable integration portion 43 is loaded into the field programmable integration portion 43 from the memory 50, for example, via the reconfiguration and update manager 33 and the partial reconfiguration logic 41. The hardware configuration for the field programmable integration portion 43 also includes a key derivation function in the evaluation portion 47.

In block 71, operation of the hardware configuration in the field programmable integration portion 43 causes the encryption key to be derived based on information in the field programmable integration portion 43 using the key derivation function 47. The information may include the hardware configuration related information and the hardware related information 44 described above, i.e., at least one of a hardware identifier, a hardware system key, secret system parameters, bitstream related key information, and a hardware application identifier. The encryption key may furthermore be derived based on Diffie Hellman system parameters. The encryption Key thus derived is specific to the hardware App of the field programmable integrated part 43 and will therefore be referred to hereinafter as HW-App-Key 2. In addition to the HW-App-Key2, a public Diffie Hellman Key (DH-HWA 2-public) and a private Diffie Hellman Key (DH-HWA 2-private) may be generated for application in later steps in the Diffie Hellman Key Agreement protocol.

Next, a Diffie Hellman request 80 may be transmitted from the field programmable integration portion 42 to the field programmable integration portion 43 according to a Diffie Hellman key agreement protocol. The Diffie Hellman request message 80 may include, for example, at least one of a hardware application identifier (HW-App-ID 1) of the field programmable integration portion 42, a DH-HWA1-public, and a first random number (nonce) generated by the field programmable integration portion 42.

The field programmable integration portion 43 may transmit a Diffie Hellman response message 81 to the field programmable integration portion 42. The Diffie Hellman response message 81 may include, for example, at least one of a hardware application identifier (HW-App-ID 2) of the field programmable integration portion 43, a DH-HWA2-public, and a second random number generated by the field programmable integration portion 43.

In block 62, the field programmable integration portion 42 may determine a Diffie Hellman secret (DH-S) based on the Diffie Hellman key agreement protocol and information provided in the response from the field programmable integration portion 43. Based on the hardware application identifier (HW-App-ID 1) transmitted as part of the Diffie Hellman Key agreement protocol, the field programmable integration portion 42 may derive the HW-App-Key2 of the field programmable integration portion 43. In addition, the field programmable integration portion 42 may derive the direction-specific session key. For example, based on the Diffie Hellman secret and the HW-App-Key1, the direction-specific session Key SK-HWA1 for communication from the field programmable integration part 42 to the field programmable integration part 43 may be derived. Further, based on the Diffie Hellman Key agreement protocol, hardware related information, e.g. hardware system parameters (HW-SP), and the derived HW-App-Key2 of the field programmable integrated part 43, a direction specific session Key SK-HWA2 for communication from the field programmable integrated part 43 to the field programmable integrated part 42 may be derived.

Likewise, in block 72, the field programmable integration portion 43 may determine a Diffie Hellman secret (DH-S) based on the Diffie Hellman key agreement protocol and information provided in the request from the field programmable integration portion 42. The field programmable integration portion 43 may derive the HW-App-Keyl of the field programmable integration portion 42 based on a hardware application identifier (HW-App-ID 2) transmitted as part of the Diffie Hellman key agreement protocol. Further, the field programmable integration portion 43 may derive the direction-specific session key. For example, based on the Diffie Hellman secret and the HW-App-Key2, the direction-specific session Key SK-HWA2 for communication from the field programmable integration part 43 to the field programmable integration part 42 may be derived. Further, based on the Diffie Hellman secret, hardware related information, e.g. hardware system parameters (HW-SP), and the derived HW-App-Key1 of the field programmable integration part 42, a direction specific session Key SK-HWA1 for communication from the field programmable integration part 42 to the field programmable integration part 43 may be derived.

Thus, the field programmable integration portion 42 and the field programmable integration portion 43 share the Diffie Hellman secret, the hardware application-specific keys HW-App-Key1 and HW-App-Key2, and the direction-specific session keys SK-HWA1 and SK-HWA 2.

Messages and data may be communicated using direction-specific session keys.

For example, a request 82 including an integrity check value (IVC) using the session key SK-HWA1 may be transmitted from the field programmable integration portion 42 to the field programmable integration portion 43. In block 73, the field programmable integration portion 43 may verify the ICV using the calculated SK-HWA 1. Likewise, the field programmable integration portion 43 may transmit a response 83 to the field programmable integration portion 42 that includes an integrity check value (IVC) using the session key SK-HWA 2. In block 63, field programmable integration portion 42 may verify the received ICV using the calculated SK-HWA 2.

In further examples, based on the direction-specific keys SK-HWA1 and SK-HWA2, further security service-specific keys may be derived, e.g., separate keys for integrity protection and confidentiality. In a further example, instead of direction-specific keys, only one communication key may be derived, which may be used by both the field programmable integration part 42 and the field programmable integration part 43 for sending and receiving messages and data.

A further example is shown in figure 3. In this example, the derived keys HW-App-Key1 and HW-App-Key2 are used to protect the Diffie Hellman Key agreement protocol.

In blocks 60, 61, 63, 70, 71, and 73, the same operations as described above in connection with fig. 2 are performed. Therefore, for reasons of brevity, these blocks will not be explained in detail hereinafter.

In block 60, the hardware configuration for the field programmable integration portion 42 is loaded into the field programmable integration portion 42. In block 61, operation of the hardware configuration in the field programmable integration portion 42 causes the encryption Key HW-App-Key1 to be derived based on information in the field programmable integration portion 42 using the Key derivation function 45. In addition to the HW-App-Key1, a public Diffie Hellman Key (DH-HWA 1-public) and a private Diffie Hellman Key (DH-HWA 1-private) may be generated for application in the Diffie Hellman Key agreement protocol.

Likewise, in block 70, the hardware configuration for the field programmable integration portion 43 is loaded into the field programmable integration portion 43. In block 71, operation of the hardware configuration in the field programmable integration portion 43 causes the encryption Key HW-App-Key2 to be derived based on information in the field programmable integration portion 43 using the Key derivation function 47. In addition to the HW-App-Key2, a public Diffie Hellman Key (DH-HWA 2-public) and a private Diffie Hellman Key (DH-HWA 2-private) may be generated for application in the Diffie Hellman Key agreement protocol.

Next, a Diffie Hellman request 90 may be transmitted from the field programmable integration portion 42 to the field programmable integration portion 43 according to a Diffie Hellman key agreement protocol. The Diffie Hellman request 90 may include, for example, at least one of a hardware application identifier (HW-App-ID 1) of the field programmable integration portion 42, a DH-HWAl-public, and a first random number generated by the field programmable integration portion 42. The Diffie Hellman request 90 may be integrity protected using the encryption key HW-App-keyyl. For example, an integrity check value (IVC) may be calculated based on the HW-App-Key1 and included in the request 90.

In block 74, the field programmable integration portion 43 may determine a Diffie Hellman secret (DH-S) based on the Diffie Hellman key agreement protocol and information provided in the request 90 from the field programmable integration portion 42. Based on the hardware application identifier (HW-App-ID 1) transmitted as part of the Diffie Hellman request message, the field programmable integration portion 43 may derive the HW-App-Key1 of the field programmable integration portion 42. Based on the HW-App-Key1, e.g., based on an Integrity Check Value (ICV) included in the request 90, the field programmable integration portion 43 may verify the integrity of the received request 90.

The field programmable integration portion 43 may derive the direction-specific session key. For example, based on the Diffie Hellman secret and the HW-App-Key2, the direction-specific session Key SK-HWA2 for communication from the field programmable integration part 43 to the field programmable integration part 42 may be derived. Further, based on the Diffie Hellman secret, hardware related information, e.g. hardware system parameters (HW-SP), and the derived HW-App-Key1 of the field programmable integration part 42, a direction specific session Key SK-HWA1 for communication from the field programmable integration part 42 to the field programmable integration part 43 may be derived.

The field programmable integration portion 43 may transmit a Diffie Hellman response 91 to the field programmable integration portion 42. The Diffie Hellman response 91 may include, for example, at least one of a hardware application identifier (HW-App-ID 2) of the field programmable integration portion 43, a DH-HWA2-public, and a second random number generated by the field programmable integration portion 43. The Diffie Hellman response 91 may be integrity protected using the encryption Key HW-App-Key 2. For example, an integrity check value (IVC) may be calculated based on the HW-App-Key2 and included in response 91.

In block 64, the field programmable integration portion 42 may determine a Diffie Hellman secret (DH-S) based on the Diffie Hellman key agreement protocol and information provided in the response from the field programmable integration portion 43. Based on the hardware application identifier (HW-App-ID 2) transmitted as part of the Diffie Hellman response message, the field programmable integration portion 42 may derive the HW-App-Key2 of the field programmable integration portion 43. Based on the HW-App-Key1, e.g., based on an Integrity Check Value (ICV) included in the response 91, the field programmable integration portion 42 may verify the integrity of the received response 91.

The field programmable integration portion 42 may derive the direction-specific session key. For example, based on the Diffie Hellman secret and the HW-App-Key1, the direction-specific session Key SK-HWA1 for communication from the field programmable integration part 42 to the field programmable integration part 43 may be derived. Further, based on the Diffie Hellman secret, hardware related information, e.g. hardware system parameters (HW-SP), and the derived HW-App-Key2 of the field programmable integration part 43, a direction specific session Key SK-HWA2 for communication from the field programmable integration part 43 to the field programmable integration part 42 may be derived.

Messages and data may be communicated using the direction-specific session keys SK-HWA1 and SK-HWA2, e.g., as described above in connection with request 82, block 73, response 83, and block 63.

Fig. 4 shows a further example of deriving and using encryption keys in the field programmable circuit portion 42.

In block 65, the hardware configuration for the field programmable integration portion 42 is loaded into the field programmable integration portion 42. The hardware configuration may be stored in the memory 50 from which it is downloaded into the field programmable integration portion 42 via the reconfiguration and update manager 33 and the partial reconfiguration logic 41. The hardware configuration includes the above-described evaluation section 45, i.e., a key derivation function.

In block 66, operation of the hardware configuration in the field programmable integration portion 42 causes the encryption key to be derived based on information in the field programmable integration portion 42 using the key derivation function 45. The information may include the hardware configuration related information and the hardware related information 44 described above, i.e., at least one of a hardware identifier, a hardware system key, secret system parameters, bitstream related key information, and a hardware application identifier. The encryption Key so derived is specific to the hardware App of the field programmable integration portion 42 and will be referred to as the HW-App-Key.

In block 67, data and messages provided or generated in the field programmable circuit portion 42 to be stored in the memory 50 may be integrity protected using the HW-App-Key. Additionally or alternatively, data and messages may be encrypted using the HW-App-Key. Although in this example the memory 50 is used for storing data and messages as well as the hardware configuration 51, different memories may be used, for example a first memory for providing the hardware configuration 51 and a second memory for storing data and messages, wherein the second memory is different from the first memory. In particular, the first and second memories may comprise separate memory devices, which may be disposed internal or external to the system 20.

The data and messages thus integrity protected and/or encrypted may be transferred to the memory 50 as indicated by reference numeral 85. For example, data and messages may be passed from the field programmable circuit portion 42 to the associated software App 34, and the software App 34 may transmit the data and messages to the memory 50 via the operating system 32.

At a later point in time, the field programmable integration portion 42 may want to retrieve the stored data and messages. Upon request from the field programmable integration portion 42, the integrity protected and/or encrypted data and messages may be transferred from the memory 50 to the field programmable integration portion 42, as indicated by reference numeral 86. For example, data and messages may be retrieved by operating system 32 from memory 50, and may be passed from operating system 32 to field programmable circuitry portion 42 via software App 34.

In block 68, the field programmable circuit portion 42 may decrypt the received data and messages using the HW-App-Key. Additionally, or alternatively, the field programmable circuit portion 42 may use the HW-App-Key to verify the integrity of the received data message.

In summary, the keys created in the context of the hardware App can be identified accordingly. This enables, for example, the implementation of a security policy that takes into account certain requirements when generating session keys. By binding the key to system specific parameters, the hardware App can be prevented from being copied to another hardware, resulting in a different result and being recognized by the communication partner.

Although the invention has been shown and described with respect to certain preferred embodiments, equivalents and modifications will occur to others skilled in the art upon the reading and understanding of the specification. The present invention includes all such equivalents and modifications, and is limited only by the scope of the following claims.