Patent Description:
Applications, also known as Apps, which may be installed and updated independently of a basic software system, such as known from for example mobile phones or tablet computers, may also be supported on industrial devices (also known as App-enabled Field Device, App-enabled Edge Cloud). For certain reasons, for example performance, power consumption, real-time behavior and key management, it may be advantageous to use a so-called "Hardware App". A Hardware App (HW App) may be loaded into a reconfigurable digital chip, digital circuit or digital module, for example a Field-Programmable Gate Array (FPGA), a Complex Programmable Logic Device (CPLD), an Application Specific Integrated Circuit (ASIC) with embedded FPGA or CPLD, or a System on a Chip (SoC) with embedded FPGA or CPLD. A Hardware App may partially define the configuration of the digital chip or module, also known as Partial Reconfiguration. A HW App may generally be operated stand alone, or may be operated as part of an "App Bundle" comprising Software App and Hardware App and their configuration parameters. The concept of HW Apps may be utilized in order to outsource computation-intensive tasks to hardware. HW Apps may also perform cryptographic operations in which the underlying key may be better protected from being compromised by malicious software than in a pure software-based solution. However, communication of the Hardware App with entities outside the Hardware App, for example the assigned Software App components of an App Bundle or another Hardware App of another App Bundle or memory outside the reconfigurable digital chip or module, may be compromised.

Patent documents <CIT>, <CIT> and <CIT> and a publication <NPL> disclose teachings relevant to the technical field of the application.

Therefore, there is a need in the art for protecting external communication 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 for 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 an aspect, a method for key management in a field-programmable integrated part of an integrated circuit is provided. The integrated circuit may comprise for example a Field-Programmable Gate Array (FPGA), a Complex Programmable Logic Device (CPLD), an Application Specific Integrated Circuit (ASIC) with embedded FPGA or CPLD, or a System on a Chip (SoC) with embedded FPGA or CPLD. According to the method, a hardware configuration for the field-programmable integrated part is loaded into the field-programmable integrated part. The hardware configuration may be considered as a Hardware App, which is loaded into the field-programmable integrated part, for example for providing computation-intensive tasks. The hardware configuration includes a key derivation functionality. The key derivation functionality may comprise a key agreement functionality. A cryptographic key is derived based on information provided in the field-programmable integrated part using the key derivation functionality. The key derivation functionality may comprise a functionality implemented in the field-programmable integrated part and relying on information provided in the integrated circuit, for example secret and/or unique information which cannot be read out from outside the integrated circuit. The key derivation and agreement functionality may comprise for example a Diffie-Hellmann key agreement method, also called Diffie-Hellmann key exchange method. The Diffie-Hellman key agreement (DH) is a method of securely exchanging cryptographic keys over a public (not protected) channel. By implementing the key derivation functionality in the field-programmable integrated part using information provided in the integrated circuit, the derived keys are bound to the hardware and it may be assured that the key exchange is bound to the hardware, e.g. performed at least partially by the hardware logic.

According to an embodiment, the hardware configuration includes a control functionality for controlling operation of an application implemented by the field-programmable integrated part using the cryptographic key. In particular, a control functionality for controlling communication of an application implemented by the field-programmable integrated part may use the cryptographic key for protecting data communicated between the field-programmable integrated part and an entity outside the field-programmable integrated part. The entity outside the field-programmable integrated part may comprise for example a Software App assigned to the Hardware App and executed by a processor coupled to the integrated circuit. Additionally, or as an alternative, the entity outside the field-programmable integrated part may comprise a memory for storing information of the field-programmable integrated part, or the entity outside the field-programmable integrated part may comprise a further field-programmable integrated part of the integrated circuit.

According to various examples, the information provided in the field-programmable integrated part comprises at least one of a hardware application identifier, a hardware identifier, a hardware system key, a part of a bitstream of the hardware configuration, a fingerprint of the bitstream of the hardware configuration, and a secret system parameter. The hardware application identifier (HW-App-ID) may be integrated in the hardware configuration loaded into the field-programmable integrated part. The hardware application identifier may be assigned when installing the hardware configuration in the field-programmable integrated part or may be part of the hardware configuration. The hardware identifier, for example a hardware serial number (HW-SN) may be comprised in the field-programmable integrated part. The hardware identifier may uniquely identify the field-programmable integrated part. The hardware identifier may be secret such that it cannot be read out from outside of the field-programmable integrated part. The hardware system key (HW-SK) may be provided by an application associated to the hardware configuration, for example a logic of the integrated circuit for downloading the hardware configuration and initiating operation of the downloaded hardware configuration. The hardware system key may be secret. The part of the bitstream of the hardware configuration and the fingerprint of the bitstream of the hardware configuration both rely on data constituting the hardware configuration and may therefore be considered as hardware configuration bitstream related key information (HW-BK). The part of the bitstream of the hardware configuration may comprise a specific part of the bitstream of the hardware configuration loaded into the field-programmable integrated part. The fingerprint of the bitstream of the hardware configuration may be generated for example using a hash function, for example SHA256. The secret system parameter (HW-SP) may be comprised in the integrated circuit and may be accessible from the field-programmable integrated part only. Using the above listed information provides a binding of the derived cryptographic key to the Hardware App and the integrated circuit hardware.

According to further embodiments, a cryptographic operation is performed in the field-programmable integrated part using the derived cryptographic key. For example, the derived cryptographic key may be used for deriving further direction specific cryptographic keys for corresponding communication connections of the Hardware App with an entity outside the field-programmable integrated part. The direction specific cryptographic keys may be derived using a Diffie Hellman secret, established when performing the Diffie Hellman protocol as the key agreement functionality. Based on the direction specific keys, further security service specific keys may be derived, for example separate keys for integrity protection and confidentiality.

In various examples, deriving the cryptographic key comprises applying a hash function on the information provided in the field-programmable integrated part, for example a hash key derivation function (HKDF), a keyed hash function like a hash-based message authentication code (HMAC) using a cryptographic hash function like secure hash algorithm, for example SHA256, or a symmetric algorithm in MAC mode, for example according to the advanced encryption standard (e.g. AES-<NUM>-GMAC).

In further examples, the derived cryptographic key may be used in connection with storing data of the field-programmable integrated part in a memory outside the field-programmable integrated part 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, encrypted data may be generated in the field-programmable integrated part using the cryptographic key and the encrypted data may be transmitted to the memory remote from the field-programmable integrated part. Likewise, encrypted data may be received from the memory remote from the field-programmable integrated part, and the encrypted data may be decrypted in the field-programmable integrated part using the cryptographic key. As the cryptographic key relies on hardware specific and/or Hardware App specific parameters and is provided in the field-programmable integrated part only, decrypting the encrypted data of the field-programmable integrated part outside the field-programmable integrated part may be reliably prohibited.

According to a further embodiment, the hardware configuration is loaded into a first field-programmable integrated part of the integrated circuit, and a further hardware configuration is loaded into a second field-programmable integrated part of the integrated circuit. The second field-programmable integrated part may be separated from the first field-programmable integrated part. However, the first field-programmable integrated part and the second field-programmable integrated part may be arranged in a same entity or in different entities of the integrated circuit. For example, the first field-programmable integrated part and the second field-programmable integrated part may be arranged in a same field-programmable gate array or in different field-programmable gate arrays. The further hardware configuration includes a further key derivation functionality. A further cryptographic key is derived by the further key derivation functionality based on further information provided in the second field-programmable integrated part. The further information provided in the second field-programmable integrated part may comprise information which is different from the information provided in the first field-programmable integrated part, for example a different hardware application identifier of the further hardware configuration, and a different part or fingerprint of a bitstream of the further hardware configuration. However, the further information provided in the second field-programmable integrated part may comprise information which is the same as the information provided in the first field-programmable integrated part, for example the hardware identifier, the secret system parameter and the hardware system key. Thus, the key derivation functionality and the further key derivation functionality may rely on at least partially the same secret information, for example the hardware identifier and the hardware system key, thus sharing a secret.

According to various examples, a session key for protecting messages communicated between the first field-programmable integrated part and the second field-programmable integrated part may be generated using a key agreement protocol in the first field-programmable integrated part and the second field-programmable integrated part. The key agreement protocol may comprise for example the Diffie Hellman key exchange protocol. Protecting messages may comprise for example providing an integrity protection and/or confidentiality of the data comprised in the messages.

The session key may comprise for example a first directional session key for protecting messages communicated from the first field-programmable integrated part to the second field-programmable integrated part. Furthermore, the session key may comprise a second directional session key for protecting messages communicated from the second field-programmable integrated part to the first field-programmable integrated part. The second directional session key may be different than the first directional session key. However, additionally or as an alternative, a single same session key may be established and used for communicating messages from the first field-programmable integrated part to the second field-programmable integrated part and vice versa.

According to a further embodiment, the messages of the key agreement protocol communicated from the first field-programmable integrated part to the second field-programmable integrated part may be protected using the cryptographic key. Likewise, the messages of the key agreement protocol communicated from the second field-programmable integrated part to the first field-programmable integrated part may be protected using the further cryptographic key. Thus, already the key agreement protocol may be protected, for example in the meaning of integrity protection, based on the cryptographic key and the further cryptographic key. In particular, the above shared secret may contribute to establish protection of the messages of the key agreement protocol.

According to various examples, protecting messages may comprise at least one of the following: encrypting the messages, decrypting the messages and protecting integrity of the messages. Encrypting and decrypting the messages may contribute to assure confidentiality.

According to a further aspect, a system comprising a field-programmable integrated part of an integrated circuit is provided. The field-programmable integrated part is configured to load a hardware configuration for the field-programmable integrated part into the field-programmable integrated part. The hardware configuration includes a key derivation functionality enabling the field-programmable integrated part to perform a key derivation function. A cryptographic key is derived by the key derivation functionality based on information provided in the field-programmable integrated part. The system may be a system on a chip (SoC) and may comprise for example an integrated circuit comprising a processor and a field-programmable integrated circuit. The system may comprise further components, for example memory and interfaces.

The system may be configured to perform the above described method and the embodiments thereof and comprises therefore the above described advantages.

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

Same reference signs in the various drawings refer to similar or identical components.

<FIG> schematically illustrates a system <NUM> comprising a processing unit <NUM>, an integrated circuit <NUM> comprising a plurality of field-programmable integrated parts <NUM> and <NUM>, and a memory <NUM>. The system <NUM> may be realized as a system on a chip (SOC), an application specific integrated circuit (ASIC), or a printed circuit board (PCB). The system <NUM> may be an embedded device, for example an embedded industrial device. The processing unit <NUM> may comprise a central processing unit (CPU) or a controller, which is configured to execute software, for example software stored in the memory <NUM>. The memory <NUM> may comprise for example a read only memory (ROM), a random access memory (RAM), and/or a flash memory. The integrated circuit <NUM> may be realized as a field-programmable gate array (FPGA) or any other kind of programmable logic, for example a complex programmable logic device (CPLD) or an ASIC with embedded FPGA or CPLD.

Apart from the software which may be executed by the processing unit <NUM>, the memory <NUM> may provide a hardware configuration <NUM> which may be loaded into the field-programmable integrated parts <NUM> or <NUM>. In particular, for each field-programmable integrated part <NUM> and <NUM> a corresponding hardware configuration <NUM> may be provided. The hardware configuration <NUM> may be considered as a hardware application, a so-called Hardware App (HW-App). The Hardware App may be part of an App Bundle comprising the Hardware App, one or more corresponding Software Apps, and additional configuration- / meta-data for the hardware and software components. Thus, reference sign <NUM> may also refer to an App Bundle comprising a package of a Hardware App and a Software App. For each field-programmable integrated part <NUM>, <NUM> a corresponding App Bundle <NUM> may be provided in the memory <NUM>.

The processing unit <NUM> may execute an operating system (OS) <NUM> including a kernel and application software in a user space <NUM> thus providing a basic software system. In the user space <NUM>, Software Apps <NUM> and <NUM> of the aforementioned App Bundles may be executed. Each Software App <NUM>, <NUM> may include program code <NUM> and <NUM>, respectively. The program code <NUM>, <NUM> of each Software App <NUM>, <NUM> may be configured to download the associated Hardware App into the integrated circuit <NUM> and to communicate with the associated Hardware App. For downloading the Hardware App into the integrated circuit <NUM>, a reconfiguration and update manager (RUM) <NUM> may be provided, which is configured to communicate with a partial reconfiguration (PR) logic <NUM> provided in the integrated circuit <NUM>.

The integrated circuit <NUM> comprises the field-programmable integrated parts <NUM> and <NUM> and the partial reconfiguration (PR) logic <NUM>. The partial reconfiguration logic <NUM> may receive the hardware configurations for the field-programmable integrated parts <NUM> and <NUM> from the reconfiguration and update manager <NUM>, configure the field-programmable integrated parts of <NUM> and <NUM> with the corresponding hardware configurations, and initiate operation of the field-programmable integrated parts <NUM> and <NUM> using the corresponding hardware configurations. The integrated circuit <NUM> may comprise any number of field-programmable integrated parts, for example one or two field-programmable integrated parts or more than two field-programmable integrated parts, for example three to ten or even in excess of ten.

The partial reconfiguration logic <NUM> may comprise a hardware system key (HW-SK), which may be accessible by the field-programmable integrated parts <NUM>, <NUM> or which may be included in the hardware configuration by the partial reconfiguration logic <NUM> during loading the hardware configuration in the corresponding field-programmable integrated part <NUM>, <NUM>. The hardware system key may not be accessible from outside the integrated circuit <NUM> and may therefore be considered as a secret key.

The integrated circuit <NUM> may furthermore provide a hardware identifier, for example a hardware serial number (HW-SN). The hardware serial number may be accessible by or included in the field-programmable integrated parts <NUM>, <NUM>. Furthermore, the integrated circuit <NUM> may provide a secret system parameter (HW-SP) which is accessible by the field-programmable integrated parts, but not accessible from outside the integrated circuit <NUM>. The hardware system key, the hardware serial number and the system parameter may thus be considered as hardware related information referred to by reference sign <NUM> in <FIG>.

The hardware configurations loaded into the field-programmable integrated parts <NUM> and <NUM> may each comprise a corresponding evaluation part <NUM> and <NUM>, respectively, which realizes a functionality for deriving cryptographic keys based on for example the hardware related information <NUM>. The evaluation parts <NUM> and <NUM> may additionally consider hardware configuration related information for deriving cryptographic keys. The hardware configuration related information may comprise for example a hardware application identifier (HW-App-ID) <NUM> and <NUM>, which is assigned to the corresponding hardware configuration and uniquely identifies the hardware configuration. The hardware configuration related information may furthermore comprise for example key information related to the bitstream of the hardware configuration (HW-BK). For example, a fingerprint of the bitstream of the hardware configuration may be generated either by the Software App <NUM>, <NUM>, related to the Hardware App, the RUM <NUM>, or the reconfiguration logic <NUM> during loading the hardware configuration into the integrated circuit <NUM>, or a specific part of the bitstream of the hardware configuration may be defined either by the Software App <NUM>, <NUM>, the RUM <NUM>, or the reconfiguration logic <NUM> during loading the hardware configuration into the integrated circuit <NUM>. The bitstream related key information is indicated in <FIG> by reference signs <NUM> and <NUM>, respectively. The fingerprint or the specific part of the bitstream may be considered by the evaluation parts <NUM> and <NUM>, respectively, when deriving cryptographic keys.

In general, the Hardware Apps operated in the field-programmable integrated parts <NUM>, <NUM> may use the above described hardware configuration related information <NUM>, <NUM>, <NUM>, <NUM> and hardware related information <NUM> during a key management with another entity. As described above, this information may be derived directly by the hardware application from its environment or it may be provided by the software application associated to the hardware application. In particular, this information may be used when deriving keys for authentication and key agreement. This may bind the negotiated keys to the corresponding hardware application and thus to the corresponding hardware. This may assure that the key agreement is performed indeed in the specific hardware, for example via the hardware related information <NUM>, which is available to the Hardware Apps. This may be used in protecting the communication between two Hardware Apps. Protection may comprise confidentiality and integrity protection of messages exchanged between the Hardware Apps. In addition, this may be used for encrypting data of a Hardware App which is to be stored outside the Hardware App, for example in the memory <NUM>.

In addition, Hardware Apps may use information available in the hardware for key management for the negotiation of session keys. The information in the hardware may be bound to the hardware or the Hardware App in order to have a unique assignment.

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

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

Various examples for operating the system <NUM> will be described in the following with reference to <FIG>.

<FIG> shows method steps performed in the field-programmable integrated part <NUM> by a corresponding Hardware App and method steps performed in the field-programmable integrated part <NUM> by a corresponding Hardware App. In this example, the non-authenticated Diffie Hellman key agreement is performed. The hardware application is authenticated by use of derived keys after the Diffie Hellman key agreement.

In detail, in block <NUM>, the hardware configuration for the field-programmable integrated part <NUM> is loaded into the field-programmable integrated part <NUM>. The hardware configuration may be stored in the memory <NUM> from which it is downloaded via the reconfiguration and update manager <NUM> and the partial reconfiguration logic <NUM> into the field-programmable integrated part <NUM>. The hardware configuration includes the above described evaluation part <NUM> which will be named the following also key derivation functionality <NUM>.

In block <NUM>, operation of the hardware configuration in the field-programmable integrated part <NUM> causes that a cryptographic key is derived based on the information in the field-programmable integrated part <NUM> using the key derivation functionality <NUM>. The information may comprise at least one of the above described hardware configuration related information and hardware related information <NUM>, i.e. the hardware identifier, the hardware system key, the secret system parameter, the bitstream related key information, and the hardware application identifier. The cryptographic key may furthermore be derived based on Diffie Hellman system parameters. The thus derived cryptographic key is specific for the Hardware App of the field-programmable integrated part <NUM> and will therefore in the following be referred to as HW-App-Key1. In addition to HW-App-Key1, a public Diffie Hellman key (DH-HWA1-public) and a private Diffie Hellman key (DH-HWA1-private) may be generated to be applied in a later step in a Diffie Hellman key agreement protocol.

Likewise, in block <NUM>, the hardware configuration for the field-programmable integrated part <NUM> is loaded into the field-programmable integrated part <NUM>, for example from the memory <NUM> via the reconfiguration and update manager <NUM> and the partial reconfiguration logic <NUM>. The hardware configuration for the field-programmable integrated part <NUM> comprises also a key derivation functionality in the evaluation part <NUM>.

In block <NUM>, operation of the hardware configuration in the field-programmable integrated part <NUM> causes that a cryptographic key is derived based on information in the field-programmable integrated part <NUM> using the key derivation functionality <NUM>. The information may comprise at least one of the above described hardware configuration related information and hardware related information <NUM>, i.e. the hardware identifier, the hardware system key, the secret system parameter, the bitstream related key information, and the hardware application identifier. The cryptographic key may furthermore be derived based on Diffie Hellman system parameters. The thus derived cryptographic key is specific for the Hardware App of the field-programmable integrated part <NUM> and will therefore in the following be referred to as HW-App-Key2. In addition to HW-App-Key2, a public Diffie Hellman key (DH-HWA2-public) and a private Diffie Hellman key (DH-HWA2-private) may be generated to be applied in a Diffie Hellman key agreement protocol in a later step.

Next, according to the Diffie Hellman key agreement protocol, a Diffie Hellman request <NUM> may be transmitted from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM>. The Diffie Hellman request message <NUM> may comprise for example at least one of the hardware application identifier of the field-programmable integrated part <NUM> (HW-App-ID1), the DH-HWA1-public, and a first nonce generated by the field-programmable integrated part <NUM>.

The field-programmable integrated part <NUM> may transmit a Diffie Hellman response message <NUM> to the field-programmable integrated part <NUM>. Diffie Hellman response message <NUM> may comprise for example at least one of the hardware application identifier of the field-programmable integrated part <NUM> (HW-App-ID2), the DH-HWA2-public, and a second nonce generated by the field-programmable integrated part <NUM>.

In block <NUM> the field-programmable integrated part <NUM> may determine a Diffie Hellman secret (DH-S) according to the Diffie Hellman key agreement protocol and the information provided in the response from the field-programmable integrated part <NUM>. Based on the hardware application identifier (HW-App-ID1) transmitted as part of the Diffie Hellman key agreement protocol, the field-programmable integrated part <NUM> may derive the HW-App-Key2 of the field-programmable integrated part <NUM>. Furthermore, the field-programmable integrated part <NUM> may derive direction specific session keys. For example, based on the Diffie Hellman secret and HW-App-Key1, a direction specific session key SK-HWA1 for a communication from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM> may be derived. Furthermore, based on the Diffie Hellman key agreement protocol, the hardware related information, for example the hardware system parameter (HW-SP), and the derived HW-App-Key2 of the field-programmable integrated part <NUM>, a direction specific session key SK-HWA2 for a communication from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM> may be derived.

Likewise, in block <NUM> the field-programmable integrated part <NUM> may determine the Diffie Hellman secret (DH-S) according to the Diffie Hellman key agreement protocol and the information provided in the request from the field-programmable integrated part <NUM>. Based on the hardware application identifier (HW-App-ID2) transmitted as part of the Diffie Hellman key agreement protocol, the field-programmable integrated part <NUM> may derive the HW-App-Key1 of the field-programmable integrated part <NUM>. Furthermore, the field-programmable integrated part <NUM> may derive direction specific session keys. For example, based on the Diffie Hellman secret and HW-App-Key2, a direction specific session key SK-HWA2 for the communication from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM> may be derived. Furthermore, based on the Diffie Hellman secret, the hardware related information, for example the hardware system parameter (HW-SP), and the derived HW-App-Key1 of the field-programmable integrated part <NUM>, the direction specific session key SK-HWA1 for the communication from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM> may be derived.

Thus, the field-programmable integrated part <NUM> and the field-programmable integrated part <NUM> 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-HWA2.

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

For example, a request <NUM> including an integrity check value (IVC) using the session key SK-HWA1 may be transmitted from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM>. In block <NUM>, the field-programmable integrated part <NUM> may verify the ICV using the calculated SK-HWA1. Likewise, the field-programmable integrated part <NUM> may transmit a response <NUM> including an integrity check value (IVC) using the session key SK-HWA2 to the field-programmable integrated part <NUM>. In block <NUM> the field-programmable integrated part <NUM> may verify the received ICV using the calculated SK-HWA2.

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

A further example is shown in <FIG>. In this example, the derived keys HW-App-Key1 and HW-App-Key2 are used for protecting the Diffie Hellman key agreement protocol.

In blocks <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> the same operations are performed as described above in connection with <FIG>. Therefore, these blocks will not be explained in detail in the following for reasons of brevity.

In block <NUM>, the hardware configuration for the field-programmable integrated part <NUM> is loaded into the field-programmable integrated part <NUM>. In block <NUM>, operation of the hardware configuration in the field-programmable integrated part <NUM> causes that the cryptographic key HW-App-Key1 is derived based on information in the field-programmable integrated part <NUM> using the key derivation functionality <NUM>. In addition to HW-App-Key1, the public Diffie Hellman key (DH-HWA1-public) and the private Diffie Hellman key (DH-HWA1-private) may be generated to be applied in a Diffie Hellman key agreement protocol.

Likewise, in block <NUM>, the hardware configuration for the field-programmable integrated part <NUM> is loaded into the field-programmable integrated part <NUM>. In block <NUM>, operation of the hardware configuration in the field-programmable integrated part <NUM> causes that the cryptographic key HW-App-Key2 is derived based on information in the field-programmable integrated part <NUM> using the key derivation functionality <NUM>. In addition to HW-App-Key2, the public Diffie Hellman key (DH-HWA2-public) and the private Diffie Hellman key (DH-HWA2-private) may be generated to be applied in a Diffie Hellman key agreement protocol.

Next, according to the Diffie Hellman key agreement protocol, a Diffie Hellman request <NUM> may be transmitted from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM>. The Diffie Hellman request <NUM> may comprise for example at least one of the hardware application identifier of the field-programmable integrated part <NUM> (HW-App-ID1), the DH-HWA1-public, and a first nonce generated by the field-programmable integrated part <NUM>. The Diffie Hellman request <NUM> may be integrity protected using the cryptographic key HW-App-Key1. For example, an integrity check value (IVC) may be calculated based on the HW-App-Key1 and included in the request <NUM>.

In block <NUM> the field-programmable integrated part <NUM> may determine the Diffie Hellman secret (DH-S) according to the Diffie Hellman key agreement protocol and the information provided in the request <NUM> from the field-programmable integrated part <NUM>. Based on the hardware application identifier (HW-App-ID1) transmitted as part of the Diffie Hellman request message, the field-programmable integrated part <NUM> may derive the HW-App-Key1 of the field-programmable integrated part <NUM>. Based on the HW-App-Key1 the field-programmable integrated part <NUM> may verify integrity of the received request <NUM>, for example based on the integrity check value (ICV) included in the request <NUM>.

The field-programmable integrated part <NUM> may derive direction specific session keys. For example, based on the Diffie Hellman secret and HW-App-Key2, a direction specific session key SK-HWA2 for the communication from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM> may be derived. Furthermore, based on the Diffie Hellman secret, the hardware related information, for example the hardware system parameter (HW-SP), and the derived HW-App-Key1 of the field-programmable integrated part <NUM>, a direction specific session key SK-HWA1 for the communication from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM> may be derived.

The field-programmable integrated part <NUM> may transmit a Diffie Hellman response <NUM> to the field-programmable integrated part <NUM>. Diffie Hellman response <NUM> may comprise for example at least one of the hardware application identifier of the field-programmable integrated part <NUM> (HW-App-ID2), the DH-HWA2-public, and a second nonce generated by the field-programmable integrated part <NUM>. The Diffie Hellman response <NUM> may be integrity protected using the cryptographic key HW-App-Key2. For example, an integrity check value (IVC) may be calculated based on the HW-App-Key2 and included in the response <NUM>.

In block <NUM> the field-programmable integrated part <NUM> may determine the Diffie Hellman secret (DH-S) according to the Diffie Hellman key agreement protocol and the information provided in the response from the field-programmable integrated part <NUM>. Based on the hardware application identifier (HW-App-ID2) transmitted as part of the Diffie Hellman response message, the field-programmable integrated part <NUM> may derive the HW-App-Key2 of the field-programmable integrated part <NUM>. Based on the HW-App-Key1 the field-programmable integrated part <NUM> may verify integrity of the received response <NUM>, for example based on the integrity check value (ICV) included in the response <NUM>.

The field-programmable integrated part <NUM> may derive direction specific session keys. For example, based on the Diffie Hellman secret and HW-App-Key1, a direction specific session key SK-HWA1 for the communication from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM> may be derived. Furthermore, based on the Diffie Hellman secret, the hardware related information, for example the hardware system parameter (HW-SP), and the derived HW-App-Key2 of the field-programmable integrated part <NUM>, a direction specific session key SK-HWA2 for the communication from the field-programmable integrated part <NUM> to the field-programmable integrated part <NUM> may be derived.

Messages and data may be communicated using the direction specific session keys SK-HWA1 and SK-HWA2, for example as described above in connection with request <NUM>, block <NUM>, response <NUM> and block <NUM>.

<FIG> shows a further example of deriving and using a cryptographic key in the field-programmable circuit part <NUM>.

In block <NUM>, the hardware configuration for the field-programmable integrated part <NUM> is loaded into the field-programmable integrated part <NUM>. The hardware configuration may be stored in the memory <NUM> from which it is downloaded via the reconfiguration and update manager <NUM> and the partial reconfiguration logic <NUM> into the field-programmable integrated part <NUM>. The hardware configuration includes the above described evaluation part <NUM>, i.e. the key derivation functionality.

In block <NUM>, operation of the hardware configuration in the field-programmable integrated part <NUM> causes that a cryptographic key is derived based on the information in the field-programmable integrated part <NUM> using the key derivation functionality <NUM>. The information may comprise at least one of the above described hardware configuration related information and hardware related information <NUM>, i.e. the hardware identifier, the hardware system key, the secret system parameter, the bitstream related key information, and the hardware application identifier. The thus derived cryptographic key is specific for the Hardware App of the field-programmable integrated part <NUM> and will be referred to as HW-App-Key.

In block <NUM>, data and messages provided or generated in the field-programmable circuit part <NUM>, which are to be stored in the memory <NUM>, may be integrity protected using the HW-App-Key. Additionally, or as an alternative, the data and messages may be encrypted using the HW-App-Key. Although in this example the memory <NUM> is used for storing the data and messages and the hardware configuration <NUM>, different memories may be used, for example a first memory for providing the hardware configuration <NUM> and a second memory for storing the data and messages, wherein the second memory is different from the first memory. In particular, the first and second memory may comprise separate memory devices which may be arranged inside or outside the system <NUM>.

The thus integrity protected and/or encrypted data and messages may be transmitted as indicated by reference sign <NUM> to the memory <NUM>. For example, the data and messages may be communicated from the field-programmable circuit part <NUM> to the associated Software App <NUM> and the Software App <NUM> may transmit the data and messages via the operating system <NUM> to the memory <NUM>.

At a later point in time, the field-programmable integrated part <NUM> may want to retrieve the stored data and messages. Upon request from the field-programmable integrated part <NUM>, the integrity protected and/or encrypted data and messages may be communicated from the memory <NUM> to the field-programmable integrated part <NUM> as indicated by reference sign <NUM>. For example, the data and messages may be retrieved from the memory <NUM> by the operating system <NUM> and may be communicated from the operating system <NUM> via the Software App <NUM> to the field-programmable circuit part <NUM>.

In block <NUM>, the field-programmable circuit part <NUM> may decrypt the received data and messages using the HW-App-Key. Additionally, or as an alternative, the field-programmable circuit part <NUM> may verify integrity of the received data messages using the HW-App-Key.

To sum up, keys created in the context of a Hardware App may be recognized accordingly. This enables, for example, the enforcement of security policies that take certain requirements into account when generating session keys. By binding the keys to system-specific parameters, copying a Hardware App to another hardware can be prevented, leading to a different result and being recognized by the communication partner.

Claim 1:
A method for key management in a field-programmable integrated part (<NUM>) of an integrated circuit (<NUM>), the method comprising:
- loading (<NUM>) a hardware configuration (<NUM>) for the field-programmable integrated part (<NUM>) into the field-programmable integrated part (<NUM>), wherein the hardware configuration (<NUM>) includes a key derivation functionality (<NUM>), and
- deriving (<NUM>), using the key derivation functionality (<NUM>), a cryptographic key based on information provided in the field-programmable integrated part (<NUM>), the information comprising at least one of
- a fingerprint of a bitstream of the hardware configuration (<NUM>),
- hardware related information.