Method and industrial device for secure firmware update
By extending the DICE architecture and utilizing temporary key protection and re-encryption, the challenges of security and integrity during firmware updates for industrial equipment are addressed. This ensures that the equipment can still use encryption and security functions normally after the update, achieving efficient and secure firmware updates.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-28
- Publication Date
- 2026-03-27
AI Technical Summary
In the existing technology, the firmware update process of industrial equipment cannot efficiently ensure both information technology security and firmware update integrity at the same time, which may result in the equipment being unable to use encryption and security functions after the update.
The approach employs an extension of the DICE architecture to protect assets by temporarily using a second key and re-encrypting them after firmware updates. This ensures the derivability of the key hierarchy and an authenticated update process, using either symmetric or asymmetric keys for encryption and signing operations.
It enables the protection of asset security during firmware updates, ensuring that devices can continue to use encryption and security features after the update, and maintaining a high level of information technology security.
Smart Images
Figure CN121753027A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present invention relates to a method for a secure firmware update from a first firmware to a second firmware and to an industrial device. BACKGROUND
[0002] Information technology security, in particular cyber security in resource-constrained industrial devices, for example embedded devices or Internet of Things devices, is constantly being improved. Modern architectures are constantly evolving to improve the security of such industrial devices. An important component of an industrial device is the installed software, in particular the firmware that controls the mode of operation of the industrial device. The integrity, authenticity and authenticity of the installed firmware is an important requirement. This can be achieved by binding the protection properties of the asset of the industrial device to firmware that is evaluated as trustworthy, in particular derived from firmware that is evaluated as trustworthy. Thus, an improved security, for example for secure storage or secure communication, can be achieved with the aid of symmetric and / or asymmetric keys bound to the firmware. The keys can additionally be derived from a secret of the device individual here.
[0003] The binding of the secret to the executed firmware makes it difficult for an attacker to manipulate the firmware or to properly exploit the manipulated firmware. Because if an attacker manipulates the firmware, a further, i.e. invalid, secret will be derived to fulfill the protection properties. However, from the invalid secret now different keys are generated with which the encryption and security functions in the industrial device cannot be successfully used. It can thus be confirmed that the device is not trustworthy.
[0004] However, it must be possible to perform automatic firmware updates in the industrial device on a regular basis. With the aid of the firmware updates, for example, security holes, program errors and defects are repaired.
[0005] It is known to perform a firmware update and subsequently to re-bind the security properties of the industrial device to the current firmware. However, this is not efficient.
[0006] The challenge therefore remains in the industrial device to implement a firmware update on the one hand and to ensure a high level of information technology security at the same time. SUMMARY
[0007] It is therefore an object of the present invention to provide a method for a secure firmware update with which the asset can be securely protected at the time of the firmware update. It is a further object of the present invention to provide an industrial device with which the method can be performed.
[0008] The object of the present invention is achieved with a method having the features specified in claim 1 and with an industrial device having the features specified in claim 10. Preferred refinements of the invention are specified in the dependent claims, the following description and the figures.
[0009] In the method for updating an industrial device from a first firmware to a second firmware according to the application, an asset related to the first firmware is protected by a first key, wherein the asset is temporarily protected by a second key related to the hardware of the industrial device, and the first firmware is subsequently replaced by the second firmware and re-encrypted by means of the second key, so that the asset is protected by a third key related to the second firmware.
[0010] Advantageously, the method according to the application extends the DICE architecture, from which the derivation of stable and unstable keys is basically known. By means of DICE it can be ensured that the key hierarchy on the device can be reproduced only if the firmware has not changed. The method according to the application now additionally advantageously opens up the possibility of a firmware update, in which the firmware is changed obligatorily, whereby the key hierarchy itself is lost. The method steps of the method according to the application, however, extend the DICE concept in such a way that both the derivability feature of the key hierarchy and the possibility of an authenticated firmware update exist by means of the temporary protection of the key hierarchy by the second key within the framework of the firmware update.
[0011] In a preferred refinement of the method according to the application, the asset is protected by means of the second key, so that the asset is encrypted by means of the second key.
[0012] In the method according to the application, the asset is preferably protected by means of the second key, so that the asset is protected by means of the first key and the first key is protected by means of the second key. In the refinement of the application, the asset can be protected in a certain way by means of a key chain.
[0013] Preferably in the method according to the application, protection by means of the first and / or second and / or third key is effected in such a way that encryption by means of the first and / or second and / or third key, respectively, is carried out.
[0014] Alternatively or additionally and likewise preferably, in the method according to the application, protection by means of the first and / or second and / or third key is effected in such a way that signing by means of the first and / or second and / or third key is carried out.
[0015] In the method according to the application, suitably the first key and / or the second key and / or the third key is an asymmetric key.
[0016] Alternatively or additionally, in the method according to the application, the first key and / or the second key and / or the third key is a symmetric key.
[0017] In the method according to the application, suitably the first key and the third key are asymmetric keys, 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 application, the first key and the third key and preferably also the second key are symmetric keys, respectively.
[0019] The industrial device according to the application constitutes a device for carrying out the method according to the application, as described before, for updating an industrial device from a first firmware secure firmware to a second firmware. BRIEF DESCRIPTION OF DRAWINGS
[0020] The application is explained in more detail below on the basis of the embodiments shown in the drawings.
[0021] wherein: Figure 1 a first embodiment of a method for updating an industrial device from a first firmware secure firmware to a second firmware is shown schematically in a schematic diagram, Figure 2 a second embodiment of a method for updating an industrial device from a first firmware secure firmware to a second firmware is shown schematically in a schematic diagram, Figure 3 a third embodiment of a method for updating an industrial device from a first firmware secure firmware to a second firmware is shown schematically in a schematic diagram, and Figure 4 a fourth embodiment of a method for updating an industrial device from a first firmware secure firmware to a second firmware is shown schematically in a schematic diagram. DETAILED DESCRIPTION
[0022] In the embodiments shown, the following structure of a key hierarchy in the industrial device is used: In the embodiments shown, the key derivation chain is always based on a secret in the form of a hardware secret GG which is in a ROM memory. The hardware secret GG is configured during creation of the industrial device and cannot be changed. The hardware secret GG guarantees the uniqueness of the keys derived from the hardware secret GG.
[0023] In the Open-DICE configuration file, two different key hierarchies are specified. In a first key hierarchy, the key derivation is related to the firmware status of the firmware respectively installed on the industrial device. In this case, the key hierarchy is unstable and changes with the installation of new firmware.
[0024] In a second key hierarchy which is different from the first key hierarchy, key derivation parameters are used which are independent of the current firmware version. In this case, the key hierarchy is stable and always creates the same keys. That is, the second key hierarchy also creates the same keys for different firmware installations.
[0025] The two key hierarchies mentioned previously are calculated and established during start-up of the industrial device, respectively. Each step in the start-up chain that occurs during start-up of the industrial device takes an output secret from the respective previous start-up level and creates a new secret as output for the next level. Each level can use the respective secret to generate a symmetric or asymmetric key.
[0026] The two key hierarchies are used jointly in the illustrated embodiment, respectively.
[0027] Here, symmetric or asymmetric keys are used in the respective embodiment, respectively.
[0028] First, an embodiment of a symmetric key is set out: The illustrated embodiment describes an industrial device, respectively, in which an asset A is protected in normal operation, respectively. For this purpose, a DERIV first symmetric key k1 is derived directly from a first volatile secret s1, which protects the asset A by symmetrically encrypting the asset A. Here, the first volatile secret s1 is derived from a first firmware FW1 of the industrial device. No secure storage is provided for the first volatile secret s1 or the first symmetric key k1. Thus, the first volatile secret s1 as well as the first symmetric key k1 change with a change of the first firmware FW1 and can satisfy the protection properties of the asset A. As Figure 1 This serves to protect the first firmware FW1 from manipulation attacks or to identify manipulations of the first firmware FW1, as described in the
[0029] Now, when a firmware update from the first firmware FW1 to a second firmware FW2 is to be made, the two embodiments of the concept are distinguished: In Figure 1The concept of the first embodiment is illustrated in Fig. 1. In normal operation using the first firmware FW1, the protection properties are created by means of the first symmetric key k1 derived DERIV from the first unstable secret s1. If a firmware update is to be made, the stable secret s2 is used to derive DERIV the temporary second symmetric key k2. Thus, the protection properties with the first symmetric key k1 can be applied in the sense of the unprotected operation UNP, which for example includes decryption by means of the first symmetric key k1 and an integrity check by means of a cryptographic checksum. Subsequently, the protection operation PROT using the second symmetric key k2 can be applied, i.e. encryption using the second symmetric key k2 and generation of a cryptographic checksum. After the firmware update has been installed to the second firmware FW2, the new unstable secret s3 is derived DERIV from the second firmware FW2. From the second unstable secret s3, the new third symmetric key k3 is derived DERIV. This time, the protection properties with the temporary second symmetric key k2 are applied in the sense of the unprotected operation UNP, i.e. decryption by means of the second symmetric key k2 and an integrity check of the asset A by means of a cryptographic checksum. Since, as mentioned before, the stable secret is independent of the firmware change from the first firmware FW1 to the second firmware FW2. The protection operation PROT can subsequently be applied by means of the third symmetric key k3, i.e. encryption of the asset A and generation of a cryptographic checksum.
[0030] Another embodiment using symmetric keys is illustrated in Figure 2 In normal operation using the first firmware FW1, the protection properties of the asset A are created by means of the first symmetric key k1 derived DERIV from the first stable secret s1. If a firmware update to the second firmware FW2 is to be made, the stable secret s2 of the hardware of the industrial device is used and from it the temporary second symmetric key k2 is derived DERIV. Subsequently, the first symmetric key k1 is encrypted by means of the temporary second symmetric key k2 and securely stored in the key store STORk1. After the firmware update has been installed to the second firmware FW2, the new unstable secret s3 can be derived DERIV from the second firmware FW2. From it, the new third symmetric key k3 is derived DERIV. Thus, the stored first symmetric key k1 can be decrypted by means of the temporary second symmetric key k2, since the second symmetric key k2 is derived from the stable secret s2 and does not change after the firmware update to the firmware FW2. Finally, the protection properties with the first symmetric key k1 can be applied in the sense of the unprotected operation UNP, for example decryption by means of the first symmetric key k1 and an integrity check of the asset A by means of a cryptographic checksum. Subsequently, the protection operation PROT can be re-applied by means of the third symmetric key k3, for example encryption by means of the third symmetric key and generation of a cryptographic checksum.
[0031] As a variant of the described embodiments, the presented method can be extended for updating any number of symmetric keys. However, in the described second embodiment, only one temporary second symmetric key k2 is required for encrypting all existing keys that derive DERIV from one or more volatile secrets. For this reason, the described first embodiment results in a higher number of protection PROT and unprotection UNP operations compared to the second embodiment, which in turn results in lower performance. On the other hand, the second embodiment requires secure temporary storage for the encryption keys that are composed of volatile secrets, i.e. for a number of encryption keys similar to the first symmetric key kl.
[0032] The following describes embodiments of asymmetric keys: In normal operation, an asymmetric key pair with a first private key skl and a first public key pkl is directly derived DERIV from a first volatile secret sl. No secure storage is provided for the first volatile secret sl or for the first private key skl and the first public key pkl. Thus, the first volatile secret sl as well as the first private key skl and the first public key pkl change with any change of the first firmware FW1 to the second firmware FW2 installed on the industrial device. Protection PROT and unprotection UNP operations cannot be successfully performed anymore. As in the previously described embodiments, this serves to protect the running first firmware FW1 against manipulation attacks. Typically, the public key pkl is certified by a certification authority (also referred to as CA).
[0033] When a firmware update is to be performed, again two embodiments are distinguished for the described concept: In a first of the described embodiments, as shown in Figure 3 In normal operation of the first firmware FW1, an asymmetric protection feature is created based on a first key pair with a first private key skl and a first public key pkl, which is derived DERIV from a first volatile secret sl, as shown in Fig. 1 1. If a firmware update to the firmware FW2 is to be performed, a temporary new key pair with a second private key sk2 and a second public key pk2 is derived using the stable secret s2. First, the second public key pk2 is signed by means of the first private key skl. The signed second public key pk2 is stored in the key store STORpk2 in the industrial device for subsequent verification. Thus, a certification chain is created, since the first public key pkl is certified by a certification authority. Alternatively, in other not specifically shown embodiments, the new second public key pk2 can be certified accordingly by a certification authority. A certificate including the first public key is stored in the key store STORpkl of the industrial device.
[0034] A new firmware update can now be installed to the second firmware FW2. After successful installation, a new second volatile secret s3 can be derived DERIV from the second firmware FW2. Naturally, the first volatile secret s1 and in turn the first private key skl can no longer be derived DERIV. From the second volatile secret s3 a new key pair with a third private key sk3 and a third public key pk3 is generated. The third public key pk3 is then signed with the second private key sk2 and stored in the key store STORpk3. The authentication chain is thereby extended. Alternatively, the third public key pk3 can now also be signed by a public certification authority.
[0035] Another embodiment using asymmetric keys is shown in Figure 4 In normal operation by means of the first firmware FW1, an asymmetric protected feature is created on the basis of a first key pair with a first private key skl and a first public key pkl, which is derived DERIV from the first volatile secret s1. A certificate including the first public key is stored in the key store STORpkl of the industrial device.
[0036] If a firmware update to the second firmware FW2 is to be made, the stable secret s2 is used to derive DERIV a unique temporary symmetric key k2. Subsequently, the first private key skl is encrypted with the symmetric key k2 and temporarily stored securely in the key store STORskl. The second firmware FW2 can now be installed. After successful installation, a new second volatile secret s3 can be derived DERIV from the second firmware FW2. The first volatile secret s1 can no longer be derived DERIV. From the second volatile secret s3 a new key pair with a third private key sk3 and a third public key pk3 is generated. In the embodiment, sk3 and pk3 are themselves the second private key and the second public key, but in order to be consistent with the previous embodiment, the respective designations are retained and the symmetric key k2 is to some extent considered the second key, so that the designations sk3 and pk3 are used as the third private key and the third public key. First, the stored first private key skl can be decrypted with the symmetric key k2, since the symmetric key k2 is derived DERIV from the stable secret and does 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 the key store STORpk3. Alternatively, the third public key can now also be signed by a public certification authority.
[0037] In other embodiments not specifically shown, both of the two previously described embodiments can be extended for updating an arbitrary number of asymmetric key pairs. However, for a firmware update made with the embodiment shown in Figure 4 Figure 4 The embodiments shown in Figure 3 The embodiments shown in Figure 3 The embodiments shown in require more storage space to securely store the plurality of signed public keys, i.e. the plurality of signed second public keys pk2, during the firmware update.
Claims
1. A method for updating an industrial device from a first firmware (FW1) security firmware to a second firmware (FW2), wherein an asset (A) is protected by a first key (kl; skl) associated with the first firmware (FW1) (DERIV), wherein the asset (A) is temporarily protected by a second key (k2; sk2) associated with the hardware of the industrial device (DERIV), and subsequently the first firmware (FW2) is replaced by the second firmware (FW2) and re-encrypted by means of the second key (k2; sk2), such that the asset is protected by a third key (k3; sk3) associated with the second firmware (FW2) (DERIV).
2. The method according to any one of the preceding claims, wherein the asset (A) is protected by means of the second key (k3; sk3) such that the asset (A) is encrypted by means of the second key (k2; sk2).
3. The method according to any one of the preceding claims, wherein the asset (A) is protected by means of the second key (k2; sk2), such that the asset (A) is protected by means of the first key (kl; skl) and the first key (kl; skl) is protected by means of the second key (k2; sk2).
4. The method according to any one of the preceding claims, wherein protection is provided by means of the first key (kl; skl) and / or the second key (k2; sk2) and / or the third key (k3; sk3) by means of encryption performed by means of the first key (kl; skl) and / or the second key (k2; sk2) and / or the third key (k3; sk3).
5. The method according to any one of the preceding claims, wherein protection is provided by means of the first key (skl) and / or the second key (sk2) and / or the third key (sk3) by means of signing by means of the first key (skl) and / or the second key (sk2) and / or the third key (sk3).
6. The method according to any one of the preceding claims, wherein the first key (sk1) and / or the second key (sk2) and / or the third key (sk3) are asymmetric keys.
7. The method according to any one of the preceding claims, wherein the first key (k1) and / or the second key (k2) and / or the third key (k3) are symmetric keys.
8. The method according to any one of the preceding claims, wherein the first key (sk1) and the third key (sk3) are asymmetric keys respectively, and the second key is an asymmetric key (sk2) or a symmetric key (k2).
9. The method according to any one of the preceding claims, wherein the first key (k1) and the third key (k3) and preferably the second key (k2) are symmetric keys.
10. An industrial apparatus configured to perform the method according to any one of the preceding claims.