Method for secure firmware updating, and industrial device

Abstract

In the method for the secure firmware updating of an industrial device from first firmware to second firmware, a first key depending on the first firmware protects an asset, wherein the asset is temporarily protected by a second key depending on hardware of the industrial device and subsequently the first firmware is replaced by the second firmware and re-encrypted by means of the second key, so that the asset is protected by a third key depending on the second firmware.

Description

[0001] Description

[0002] Secure firmware update procedure and industrial device

[0003] The invention relates to a method for secure firmware updates from a first firmware to a second firmware and an industrial device.

[0004] IT security, and particularly cybersecurity, in resource-constrained industrial devices, such as embedded devices or IoT devices, is constantly being improved. Modern architectures are constantly being developed to increase the security of such industrial devices. An important component of industrial devices is the installed software, particularly the firmware, which controls the functionality of the industrial device. The integrity, originality, and authenticity of the installed firmware is an important requirement. This can be achieved by binding asset protection properties for the industrial device to the trusted firmware, or in particular by deriving them from the trusted firmware.Consequently, enhanced security can be achieved with symmetric and / or asymmetric keys bound to this firmware, for example, for secure storage or secure communication. The keys can also be derived from a device-specific secret.

[0005] Binding the secrets to the running firmware makes it more difficult for an attacker to tamper with the firmware or to appropriately use tampered firmware. This is because if an attacker were to tamper with the firmware, other, invalid, secrets would be derived to fulfill the protection properties. Invalid secrets, however, result in other keys with which the cryptography and security functionalities in the industrial device cannot be successfully used. This can be used to determine that the device is not trustworthy. However, it must be possible to carry out automatic firmware updates on a regular basis in industrial devices. Firmware updates are used to fix security gaps, bugs, and errors, for example.

[0006] It is known to perform firmware updates and subsequently rebind the security features of the industrial device to the current firmware. However, this is not efficient.

[0007] The challenge remains to enable firmware updates in industrial devices while at the same time ensuring a high level of IT security.

[0008] It is therefore an object of the invention to provide a method for secure firmware updates, with which an asset can be securely protected during a firmware update. It is also an object of the invention to provide an industrial device with which the method can be carried out.

[0009] This object of the invention is achieved by a method having the features specified in claim 1 and by an industrial device having the features specified in claim 10. Preferred developments of the invention are specified in the associated subclaims, the following description and the drawing.

[0010] In the method according to the invention for the secure firmware update of an industrial device from a first firmware to a second firmware, a first key which depends on the first firmware protects an asset, wherein the asset is temporarily protected with a second key which depends on hardware of the industrial device and subsequently the first firmware is replaced by the second firmware and re-encrypted using the second key, such that the asset is protected with a third key which depends on the second firmware. Advantageously, the method according to the invention extends the DICE architecture, from which the derivation of stable and unstable keys is fundamentally known. With DICE it can be ensured that a key hierarchy can only be reproduced on a device if the firmware has not been changed.The method according to the invention now also advantageously opens up the possibility of firmware updates, in which the firmware is inevitably changed and the key hierarchy itself would thus be lost. However, the method steps of the method according to the invention extend the DICE concept to the extent that both the properties of derivability of the key hierarchy and the possibility of authenticated firmware updates exist, in which the key hierarchy is temporarily protected with the second key during the firmware update.

[0011] In a preferred development of the method according to the invention, the asset is protected with the second key in such a way that the asset is encrypted with the second key.

[0012] In the method according to the invention, the asset is preferably protected with the second key in such a way that the asset is protected with the first key and the first key is protected with the second key. In this development of the invention, the asset can be protected, so to speak, by means of a chain of keys.

[0013] In the method according to the invention, protection is preferably provided by means of the first and / or second and / or third key by encrypting with the first and / or second and / or third key.

[0014] Alternatively or additionally and also preferably, in the method according to the invention, protection is provided by means of the first and / or second and / or third key by signing by means of the first and / or second and / or third key.

[0015] In the method according to the invention, the first key and / or second key and / or third key is expediently an asymmetric key.

[0016] Alternatively or additionally, in the method according to the invention, the first key and / or second key and / or third key is a symmetric key.

[0017] In the method according to the invention, the first key and the third key are expediently an asymmetric key and the second key is preferably an asymmetric key or alternatively and likewise preferably a symmetric key.

[0018] Alternatively and likewise preferably, in the method according to the invention the first key and the third key and preferably also the second key are each a symmetric key.

[0019] The industrial device according to the invention is designed to carry out a method according to the invention for a secure firmware update from a first firmware to a second firmware as described above.

[0020] The invention is explained in more detail below with reference to an embodiment shown in the drawing.

[0021] It shows :

[0022] Fig. 1 shows a first exemplary embodiment of a method for securely updating the firmware of an industrial device from a first firmware to a second firmware, schematically in a diagrammatic representation. Fig. 2 shows a second exemplary embodiment of a method for securely updating the firmware of an industrial device from a first firmware to a second firmware, schematically in a diagrammatic representation.

[0023] Fig. 3 shows a third exemplary embodiment of a method for the secure firmware update of an industrial device from a first firmware to a second firmware schematically in a diagrammatic representation, and

[0024] Fig. 4 shows a fourth exemplary embodiment of a method for the secure firmware update of an industrial device from a first firmware to a second firmware schematically in a diagrammatic representation.

[0025] In the illustrated examples, the structure of key hierarchies in industrial devices explained below is used:

[0026] In the illustrated embodiments, the key derivation chains are always based on a secret in the form of a hardware secret GG, which is located in ROM memory. This hardware secret GG is configured during the creation of the industrial device and cannot be changed. This hardware secret GG guarantees the uniqueness of the keys derived from this hardware secret GG.

[0027] The Open-DICE profile specifies two different key hierarchies. In a first key hierarchy, key derivation depends on the firmware status of the firmware installed on the industrial device. In this case, the key hierarchy is unstable and changes with new firmware installations. In a second key hierarchy, which is different from the first key hierarchy, key derivation parameters are used that are independent of the current firmware version. In this case, the key hierarchy is stable and always creates the same keys. This means that this second key hierarchy also creates the same keys for different firmware installations.

[0028] The two previously mentioned key hierarchies are each calculated and established during boot of the industrial device. Each step in a boot chain established during boot of the industrial device receives an output secret from the previous boot level and creates a new secret as output for the next level. Each level can use the respective secrets to generate symmetric or asymmetric keys.

[0029] These two key hierarchies are used together in the illustrated examples.

[0030] In each of the embodiments, either symmetric or asymmetric keys are used.

[0031] First, examples for symmetric keys are explained:

[0032] The illustrated embodiments each describe industrial devices in which an asset A is protected during normal operation. For this purpose, a symmetric first key kl is derived directly from a first unstable secret sl DERIV, which protects the asset A by symmetrically encrypting the asset A. The first unstable secret sl is derived from a first firmware FW1 of the industrial device DERIV. No secure storage is provided for the first unstable secret sl or the first symmetric key kl. Therefore, the first unstable secret sl and the first symmetric key kl would change with each change to the first firmware FW1 and the protection properties of the assets A cannot be met. As described in Figure 1, this serves to protect the first firmware FW1 from tampering attacks or to detect tampering with the first firmware FW1.

[0033] If a firmware update from the first firmware FW1 to a second firmware FW2 is imminent, we distinguish between 2 examples for this concept:

[0034] The concept of the first embodiment is shown in Fig. 1. During normal operation with the first firmware FW1, the protection properties are created with the first symmetric key kl, which is derived DERIV from the first unstable secret sl. If the firmware update is imminent, a stable secret s2 is used to derive DERIV from the temporary second symmetric key k2. Consequently, the protection properties can be applied with the first symmetric key kl in the sense of a deprotection operation UNP, which includes, for example, decryption with the first symmetric key kl and a check of the integrity using a cryptographic checksum. Subsequently, a protection operation PROT can be applied with the second symmetric key k2, i.e., encryption with the second symmetric key k2 and generation of a cryptographic checksum.After installing the firmware update on a second firmware FW2, a second unstable secret s3 is derived from the second firmware FW2 DERIV . A new third symmetric key k3 is derived from the second unstable secret s3 DERIV . This time the protection properties are applied with the temporary second symmetric key k2 in the sense of a deprotection operation UNP , i.e. decryption using the second symmetric key k2 and a check of the integrity of asset A using a cryptographic checksum . This is because, as explained above, the stable secret is independent of the change in firmware from the first firmware FW1 to the second firmware FW2 . Subsequently, a protection operation PROT can be applied with the third symmetric key k3, i.e. encryption of asset A and generation of a cryptographic checksum .

[0035] Another embodiment using symmetric keys is shown in Fig. 2:

[0036] During normal operation with a first firmware FW1, the protection properties of an asset A are created with the first symmetric key kl, which is derived from a first stable secret sl DERIV. If a firmware update to a second firmware FW2 is imminent, a stable secret s2 of the hardware of the industrial device is used, and from this a temporary second symmetric key k2 DERIV is derived. The first symmetric key kl is then encrypted with the temporary second symmetric key k2 and securely stored in a key store STORkl. After installation of the firmware update to the second firmware FW2, a new unstable secret s3 can be derived from the second firmware FW2 DERIV. From this, a new, third, symmetric key k3 is derived DERIV.Consequently, the stored first symmetric key kl can be decrypted with the temporary second symmetric key k2, because the second symmetric key k2 is derived from the stable secret s2 DERIV and would not change after a firmware update to the firmware FW2. Finally, the protection properties can be applied with the first symmetric key kl in the sense of a deprotection operation UNP, for example, decryption using the first symmetric key kl and checking the integrity of the asset A using a cryptographic checksum. Subsequently, a protection operation PROT can be applied again with the third symmetric key k3, for example, encryption using the third symmetric key and generation of a cryptographic checksum.

[0037] As variations of these embodiments, the presented methods can be extended to update any number of symmetric keys. In the second described embodiment, however, only a temporary second symmetric key k2 would be needed for the encryption of all existing keys derived from one or more unstable secrets DERIV. For this reason, the first described embodiment can lead to a higher number of protection PROT and deprotection operations UNP compared to the second embodiment and therefore to lower performance. On the other hand, the second embodiment requires secure caching for encrypted keys from unstable secrets, i.e. for multiple encrypted keys analogous to the first symmetric key kl.

[0038] Examples of asymmetric keys are described below:

[0039] During normal operation, an asymmetric key pair with a first private key skl and a first public key pkl is derived directly from a first unstable secret sl DERIV . No secure storage is provided for the first unstable secret sl or the first private key skl and the first public key pkl . Therefore, the first unstable secret sl as well as the first private key skl and the first public key pkl would change with each change from a first firmware FW1 installed on the industrial device to a second firmware FW2 . Protection PROT and deprotection operations UNP can then no longer be carried out successfully. As explained in the previous embodiments, this serves to protect the running first firmware FW1 from tampering attacks.Typically, the public key pkl is certified by a certification authority, also known as a Certificate Authority (CA).

[0040] If a firmware update is imminent, we again distinguish two embodiments for this concept: In a first of these embodiments, as shown in Fig. 3, during normal operation of the first firmware FW1, the asymmetric protection properties are created based on the first key pair with a first private key skl and a first public key pkl, which is derived from a first unstable secret sl. If a firmware update to a firmware FW2 is imminent, a stable secret s2 is used to derive a temporary new key pair with a second private key sk2 and a second public key pk2. First, the second public key pk2 is signed with the first private key skl. The signed second public key pk2 is stored in the industrial device in a key storage STORpk2 for subsequent verification.This creates a certification chain because the first public key pkl is certified by a certification authority. Alternatively, in other embodiments not specifically shown, the new, second public key pk2 can be certified accordingly by a certification authority. A certificate including the first public key is stored in a key storage device STORpkl of the industrial device.

[0041] The new firmware update can now be installed on the second firmware FW2. After successful installation, a new, second unstable secret s3 can be derived from the second firmware FW2. Naturally, the first unstable secret sl and thus also the first private key skl can no longer be derived. A new key pair with a third private key sk3 and a third public key pk3 is generated from the second unstable secret s3. The third public key pk3 is then signed with the second private key sk2 and stored in a key store ST0Rpk3. This extends the certification chain. Alternatively, the third public key pk3 can now also be signed by a public certification authority.

[0042] Another embodiment using asymmetric keys is shown in Fig. 4. In normal operation, the asymmetric protection properties are created using a first firmware FW1 based on a first key pair comprising a first private key skl and a first public key pkl, which is derived from a first unstable secret sl. A certificate including the first public key is stored in a key memory STORpkl of the industrial device.

[0043] If a firmware update to a second firmware FW2 is imminent, a stable secret s2 is used to derive a single temporary symmetric key k2. The first private key skl is then encrypted with the symmetric key k2 and securely stored in a key store STORskl. The second firmware FW2 can now be installed. After successful installation, a new second unstable secret s3 can be derived from the second firmware FW2. The first unstable secret sl can now no longer be derived. A new key pair with a third private key sk3 and a third public key pk3 is generated from the second unstable secret s3.In this embodiment, sk3 and pk3 individually represent a second private key and a second public key, but for consistency with the previous embodiment, a corresponding designation is retained and the symmetric key k2 is counted as the second key, so that the designation of sk3 and pk3 as third private key and third public key is used. First, the stored first private key skl can be decrypted with the symmetric key k2 because the symmetric key k2 is derived from the stable secret DERIV and would not change after the firmware update to the second firmware FW2. Finally, the third public key pk3 is signed with the second private key sk2. The signed third public key pk3 is stored in a key store STORpk3.Alternatively, the third public key can now also be signed by a public certification authority.

[0044] In further embodiments not specifically shown, both of the previously described embodiments can be expanded to update any number of asymmetric keys. However, only a single symmetric key k2 is required for a firmware update with the embodiment shown in Fig. 4, regardless of the number of asymmetric key pairs present. Therefore, the embodiment shown in Fig. 3 can lead to a higher number of operations for asymmetric protection properties compared to the embodiment shown in Fig. 4 and thus to lower performance. In addition, the embodiment shown in Fig. 3 requires more memory space for securely storing multiple signed public keys during the firmware update, i.e., multiple signed second public keys pk2.

Claims

Patent claims 1. Method for the secure firmware update of an industrial device from a first firmware (FW1) to a second firmware (FW2), in which a first key (kl; skl) dependent (DERIV) on the first firmware (FW1) protects an asset (A), wherein the asset (A) is temporarily protected with a second key (k2; sk2) dependent (DERIV) on a hardware of the industrial device and subsequently the first firmware (FW2) is replaced by the second firmware (FW2) and is re-encrypted by means of the second key (k2; sk2), so that the asset is protected with a third key (k3; sk3) dependent (DERIV) on the second firmware (FW2).

2. Method according to one of the preceding claims, in which the asset (A) is protected with the second key (k3; sk3) in such a way that the asset (A) is encrypted with the second key (k2; sk2).

3. Method according to one of the preceding claims, in which the asset (A) is protected with the second key (k2; sk2) in such a way that the asset (A) is protected with the first key (kl; skl) and the first key (kl; skl) is protected with the second key (k2; sk2).

4. Method according to one of the preceding claims, in which protection is provided by means of the first (kl; skl) and / or second (k2; sk2) and / or third key (k3; sk3) by encrypting with the first (kl; skl) and / or second (k2; sk2) and / or third key (k3; sk3).

5. Method according to one of the preceding claims, in which protection is provided by means of the first (skl) and / or second (sk2) and / or third key (sk3) by signing by means of the first (skl) and / or second (sk2) and / or third key (sk3).

6. Method according to one of the preceding claims, in which the first key (skl) and / or second key (sk2) and / or third key (sk3) is an asymmetric key.

7. Method according to one of the preceding claims, in which the first key (k1) and / or second key (k2) and / or third key (k3) is a symmetric key.

8. Method according to one of the preceding claims, in which the first key (skl) and the third key (sk3) is an asymmetric key and the second key is an asymmetric key (sk2) or a symmetric key (k2).

9. Method according to one of the preceding claims, in which the first key (kl) and the third key (k3) and preferably also the second key (k2) is a symmetric key.

10. Industrial device designed to carry out a method according to one of the preceding claims.

Images