Authenticated firmware transmittal upgrade system

Abstract

The invention relates to a method of uploading firmware (FW) to a device comprising an end node (EN), applying an authentication tag (AT) to the firmware released, the releasing and end node side share a digital key, and utilize an identical MAC-algorithm for calculating a message authentication tag (AT), utilized by the end node device (EN) for authenticating the firmware received. A MAC algorithm (THAMC) included secure token (INT) calculates the message authentication tag (AT) in the end node (EN), the token (INT) incorporating a unique identity (TID), and the method further comprising a secure identity management system (CS) for authenticating an identity (ID) of end node devices, and an end node configuration management module (CMS) releasing firmware to an end node (EN) upon receipt of an identity authentication (IDAUR) of the end node (EN) from the secure identity management system (CS).

Description

AUTHENTICATED FIRMWARE TRANSMITTAL UPGRADE SYSTEMTECHNICAL FIELD

[0001] The present invention relates to a device, system and method for device (or asset) firmware (henceforth FW) upgrade using a method of authentication.BACKGROUND ART

[0002] Contemporary devices like industrial equipment and consumer goods very often come with an electronic component involving firmware, which over time is often desired to be upgraded, or at least modified, e.g. for adaptation or coping with matters like changed circumstances or desire to change functionality of the device. A practice of so-called upgrading firmware using wireless or connected electronic communication is commonly known.

[0003] In general it may be said that manufacturers typically want to update equipment in the field with new and / or updated firmware. In fact, this may even be set as mandatory for security updates within certain legislations, e.g. in the EU. However, it in practice appears to be difficult to make sure that every piece of equipment is effectively updated, and that the correct firmware version is installed on each.

[0004] The practice of firmware-upgrade is up to now very often performed in so called distribution mode, preferably using a public-private key signature, with a static public key, also known as the “Bob and Alice method”. One of supposedly various problems associated with the known practice of firmware upgrading is that the supplier is unable to see, i.e. notice, which FW version is installed on any given end node. Also, this known practice comes with a single point of failure, in that a single FW signature hack potentially breaches all associated end-nodes. For instance, an older (e.g. weak), modified or corrupted FW version may be rolled out using this hacked method, for example by using a stolen valid signature key.

[0005] One state of the art manner of securely updating FW, commonly known as FOTA, brief for “firmware over the air” may be known from Wikipedia publication “Over-the-air update” of 13 Aug. 2023 at https: / / en.wikipedia.org / wiki / Over-the-air update. In view of the aspect of vulnerability, the publication for example remarks that FW related manufacturers have responded by instituting vulnerability disclosure programs (a.k.a. bugbounty programs). It also discloses that attack vectors specific to OTA updates include "spoofing, tampering, repudiation attacks, information leakage, denial-of-service, replay attacks, and privilege escalation attacks”. Another overview for firmware upgrade technologies, including “over the air” (OTA), is provided by the “embeddedinn”- publication “secure firmware upgrade for embedded systems” by Vysakh P. Pillai, of 2017, at https: / / embeddedinn.com / articles / tutorial / Secure-Firmware-upgrade-for-embedded- systems / . It defines a secure firmware upgrade as “the ability to ensure E2E credibility and integrity of update software downloaded into a device."

[0006] While various other FW upgrade practices might still exist, these are generally felt to be unsatisfactory, i.e. this is an insufficiently controlled topic in contemporary industry, in particular in industrial equipment.

[0007] In general it may thus be concluded from present day practice that FW downloads are mostly done in so-called distribution mode described above, i.e. the FW, in fact software, is sent to all customers, i.e. to all end nodes in the same way, using a publicprivate key signature with an often static public key, while thirdly the supplier is unable to see which FW version is installed on end nodes. As mentioned, this known method typically departs from a centralized architecture and disadvantageously feature a single point of failure (a single FW signature hack potentially breaches all nodes). There is also no guarantee that when a correct FW update is received, it is actually installed on an end node. Incidentally, in view of terminology it is remarked that where a server might upload a message or trigger indicating that a certain FW version is made available, the initiative to action may be at the end node or end node device side, which end node then downloads the firmware as made available by a server.

[0008] In the practice of FW updating, many types of defending or risk mitigating measures can be encountered, but in fact none of these measures avails to create a fully satisfactorily procedure. Rather, various types of partial solutions may be encountered and, depending on the liking of a user, one is more favorable than another.

[0009] It is at this point remarked that part of the insight underlying the present invention is that a known end node authentication system, e.g. disclosed by patent publication WO2021240445, may be used for improving control over present day FW upgrades. The known authentication system features a central server and a unique hardware token, or at least a unique secure token or technical equivalent.

[0010] The present invention recognizes that this system may, when additionally provided with among others an adapted authentication method, be used for this purpose of improved FW upgrade control. Hence, that the existing methodology and hardware may be used for realizing a FW upgrade system which is considered to have considerably further-reaching controll than the up to now generally applied FW upgrade method, in the so called distribution mode or as disclosed in e.g. the article “Secure firmware upgrade for embedded systems’", written by Vysakh P Pillai and introduced above.

[0011] As to the above-cited End Node authentication solution WO2021240445, it is remarked that while this prior art publication method solves an end node authentication problem, it does not deal with FW upgrade. Yet the present invention recognizes that it may be utilized in the desired improvement of the known existing FW upgrade method. Since the authentication document is silent as to the FW upgrade method topic, WO2021240445 neither discloses nor teaches anything related to any embedded FW authentication method, nor does it suggest so. Even where this system of WO2021240445 may, in accordance with the presently to be proposed invention for the purpose of controlling FW upgrades, be extended with a so-called customer configuration management system, the latter system may in principle be run on the in this method of WO2021240445 already available server hardware, while also on the end node side in principle no additional hardware is required to be added.

[0012] Typical existing ways of updating firmware, as for example disclosed in EP3772008A1, rely on a public key infrastructure (PKI). These methods include a public key signature on the firmware itself to guarantee its integrity and authenticity, which ultimately needs to be verified using a root certificate installed in and trusted by the receiving device. Moreover, as discussed in EP3772008A1, the receiving device may be authenticated using its device certificate. Upon manufacturing the receiving device may have been issued a digital birth certificate, which needs to be replaced at various times throughout its lifecycle.

[0013] These steps - both incorporating the proper root certificate(s) as well as replacing the device certificate - introduce security threats to the receiving device that need to be mitigated. Especially for resource-constrained devices this can be impractical and / or uneconomical.BRIEF SUMMARY OF THE INVENTION

[0014] The current invention addresses these concerns by relying on a secure, immutable hardware token that during production is already provided with an immutable and unique identity and (symmetric) authentication means. This hardware token is embedded into the receiving device. The symmetric nature of the authentication can be leveraged to both authenticate the receiving device, as well as verifying the authenticity of the received firmware.

[0015] The present invention seeks to provide at least one solution in this field which addresses the existing problem, at least inconvenience of lack of sufficient control to a significant extend, by proposing a new method to generate a (temporary) authentication tag, somewhat corresponding to the cryptographic key as known from the so-called Bob-and Allice method, based on a mutual authentication result.

[0016] Within an idea underlying the present invention, a new manner of updating firmware ideally ensures that firmware comes from a trusted source, i.e. the device can authenticate source of received data or FW, may authentically report successful download back to the source, is compatible with standard public-key based SW signature, preferably can be encrypted by a device-specific key, and moreover preferably will enable fine-grained firmware configuration management.

[0017] In a first aspect according to the invention, a method for authenticating a first firmware at an end node device with respect to a second firmware at a network is disclosed. The end node device comprises at least one end node in the network. The method preferably comprises generating by the end node device a first hash value of the first firmware, generating by the end node device a first authentication tag from the first hash value, using a token hash-based message authentication code, THMAC, algorithm that belongs to the end node device and uses an end node device-specific symmetric key. Furthermore, the method comprises generating by the network a second hash value of the second firmware, generating by the network a second authentication tag from the second hash value, using a server hash-based message authentication code, SHMAC, algorithm that corresponds to a unique identity of the end node device and uses the same end node device-specific symmetric key. Finally, determining whether the first and second authentication tag are identical, thereby authenticating the first firmware with respect to the second firmware.

[0018] In an embodiment of the first aspect, the THMAC algorithm is comprised within an immutable token in the end node device, wherein the immutable token further comprises the unique identity of the end node device, and the symmetric key used by the THMAC algorithm, preferably wherein the immutable token is a hardcoded integrated circuit, IC, more preferably wherein the immutable token is a hardcoded integrated circuit, IC, without non-volatile memory.

[0019] In an embodiment of the first aspect, the method further comprises: receiving at the end node device the first firmware and the second authentication tag from the network, wherein the first firmware is a transmitted copy of the second firmware from the network to the end node device, wherein the step of determining whether first and second authentication tag are identical is performed at the end node device, thus authenticating the first firmware received at the end node device.

[0020] In an embodiment of the first aspect, the step of determining further comprises generating an authentication result, which comprises information as to whether or not the firmware received at the end node device was authenticated; and wherein the method further comprises: transmitting from the end node device to the network the authentication result.

[0021] In an embodiment of the first aspect, the second firmware is encrypted by the network using an ephemeral key outputted by the SHMAC algorithm before transmission to the end node device, and wherein the encrypted first firmware is decrypted by the end node device using the same ephemeral key outputted by the THMAC algorithm, wherein preferably the SHMAC and THMAC algorithm generate the ephemeral key based on the hash value of the second and first firmware respectively; and wherein in the case that the network transmits the encrypted first firmware, the network also transmits to the end node device the hash value of the second firmware.

[0022] In an embodiment of the first aspect, the end node device determines whether the hash value of the second firmware received from the network and the hash value of the decrypted first firmware match.

[0023] In an embodiment of the first aspect, the method further comprises: generating a number-used-once, nonce, at the network; transmitting the nonce from the network to the end node device (CED), wherein the step of generating the first hash by the end node deviceis done based on the received nonce and the first firmware and wherein the step of generating the second hash by the network is done based on the nonce and the second firmware; transmitting the first authentication tag (AT) from the end node device (CED) to the network; wherein the second firmware corresponds to a firmware registered for the end node device; wherein the step of determining whether first and second authentication tag are identical is performed at the network, thus authenticating the firmware registered for the end node device.

[0024] In an embodiment of the first aspect, the end node device is furthermore authenticated by the network, using the following steps: outputting an identity (ID) from the end node device (CED) to the network, uniquely identifying the end node device (CED), preferably an immutable identity, more preferably an immutable and unique token identity code; verifying by the network whether the identity (ID) is valid; receiving, by the end node device (CED), a identification challenge word (CW) from the network, if the network has verified that the identity (ID) is valid; calculating by the end node device (CED) an identification authentication tag (AT) using the THMAC algorithm, based on the challenge word (CW); outputting the identification authentication tag (AT) to the network; determining the integrity and validity of the identification authentication tag (AT).

[0025] In an embodiment of the first aspect, the integrity and validity of the authentication tag (AT) is determined using the identity (ID) and the SHMAC algorithm of the network corresponding to the identity (ID), wherein preferably the challenge word (CW) is used as input to the SHMAC algorithm to generate a control authentication tag, which is compared with the identification authentication tag received from the end node device; and more preferably wherein the challenge word (CW) is a number-used-once, nonce.

[0026] In an embodiment of the first aspect, before the identity (ID) is outputted to the network, the firmware upload is initiated by the network, preferably by receiving at the end node device an identity request (RID) from the network; or wherein the authentication of the end node device is initiated by the end node device.

[0027] In an embodiment of the first aspect, the firmware that is sent to the end node device is targeted to the end node device (CED) such that a version or content of the firmware received is dependent on the identity (ID) transmitted from the end node device to the network.

[0028] In an embodiment of the first aspect, the network has a private key part of a publicprivate key pair, wherein the corresponding public key is comprised in the end node device, and wherein the network digitally signs one or more messages sent to the end node device with the private key; and the end node device checks whether the signature of the network is correct by using the public key.

[0029] In an embodiment of the first aspect, the network comprises a central server, and a configuration management system, wherein the central server (CS) is used for identifying and authenticating identities (ID) and wherein configuration management server (CMS) for registering and releasing firmware (FW), preferably wherein the central server and configuration management server are separate entities, more preferably wherein the central server is related to one or more clients and wherein the configuration management server is related to one or multiple end node devices of a particular client.

[0030] In an embodiment of the first aspect, the firmware registered for the end node device is a firmware which the network has previously transmitted to the end node device and which the network has registered as being the firmware which is installed on the end node device, preferably wherein the firmware registered for the end node device is registered together with the identity obtained from the method according to the first aspect, more preferably wherein the registration is at the configuration management system according to the first aspect, more preferably: wherein the step of determining whether the first and second authentication tag are identical provides a verification outcome; transmitting the verification outcome to the configuration management system and if the verification is successful, registering at the configuration management system a version of the firmware installed on the end node device together with the identity of the end node device.

[0031] In a second aspect according to the invention, an end node device (CED) providing an end node of a network is disclosed. The device comprising: processing hardware (MCU) for executing certain functionality of the device and / or the end node (EN); an end node token (INT) comprising an electronically readable, preferably immutable unique identity (TID), a token hash-based message authentication code, THMAC, algorithm and a symmetric key used by the THMAC algorithm, preferably wherein the end node token is a hardcoded integrated circuit, IC, more preferably wherein the immutable token is ahardcoded integrated circuit, IC, without non-volatile memory; a memory comprising firmware; wherein the end node device is configured to communicate with the network using the end node, in particular wherein the THMAC algorithm is used for calculating a message authentication tag (AT) to be communicated by the end node (EN), the end node token (INT) arranged for performing said calculation, in particular for identifying and authenticating firmware versions, preferably in accordance with any of the preceding claims.

[0032] Furthermore, preferably a system that can securely send targeted firmware updates to individual, i.e. identified pieces of equipment, or even individual electronic modules thereof is introduced. The new system in the idea of the present invention can also keep track of which firmware version was sent, preferably installed on which equipment or component thereof. Thus, the present invention at least ideally sets forth a new way to securely target firmware updates to specific devices, as well as the feature of remotely verifying the installed FW version, with the device reporting back upon success.

[0033] The presently proposed method and system sets forth a huge step in efforts of industry to more effectively deal with “sold” machines, in that control may be taken and hence well based guarantee may be provided in case of damage or spare parts, both at “off enterprise” sold equipment and at second hand sold machine.

[0034] The invention is defined by the appended claims.

[0035] The present invention thus relates to a method of uploading firmware to a device comprising an end node, receiving the firmware from a firmware distributing or releasing system, the method applying an authentication tag, i.e. what perhaps otherwise might have been known as an encrypted signature, to the firmware released and to be uploaded to the device, in which method the releasing side and the end node side share a digital key, with the releasing side and the end node device utilizing an identical message authentication code algorithm for calculating a message authentication tag, utilized by the end node device for authenticating the firmware received, the method further comprising a MAC algorithm, for calculating the message authentication tag, included in the end node device, the token further incorporating a unique identity of the end node, the method further comprising a secure identity management system implemented for authenticating a secure identity of end node devices, and an end node configurationmanagement system releasing firmware to an end node upon receipt of an identity authentication of the end node from the secure identity management system.

[0036] It is remarked that the present invention in fact enables FW Management. After all, targeted FW is sent to a specific module, and the thus downloaded FW cannot be reused on another module. Also, FW management according to the presently proposed solution generates a secure verification that the FW has been received correctly and installed. The FW Management of the present invention is further featured in that it may perform runtime checks to verify the correct FW is currently stored locally. Also, the FW management is compatible with existing security measures such as FW signature and FW encryption. In the latter respect FW encryption can in the new method be targeted to specific modules, i.e. enables targeted encryption as opposed to the known so-called broadcast encryption.

[0037] The present invention a somewhat elaborated version may further relate to the same in which the message authentication code algorithm is a hash-based message authentication code, a hash of the to be uploaded firmware forming a basis for calculating the authentication tag, in particular with the token identity being used for determining the key used in the hash. Also, the firmware upload may be initiated by either one of the end node device and the configuration management module. The new method of uploading may be described as a targeted upload, i.e. the firmware version or content of upload being determined or modified in dependence of the end node identity.

[0038] Yet further, the present invention may favorably be worked out in that the firmware version as present on the end node is determined by the configuration management system, the latter system generating and providing a time stamp to the end node, the end node using this time stamp and its installed firmware to calculate and provide a response word to the identity management system, the identity management system further being provided with a challenge word by the configuration management system, calculated, preferably using a hash algorithm, on the basis of said generated time stamp and the firmware registered in relation to the end node identity, and the identity management system determining the conformance of said challenge word and said response word and outputting the result to the configuration management system. Given advantages of this technology it is or may also be applied independently.

[0039] Hence the invention encompasses a method for assessing installed firmware version in a device, in which the device comprises at least one end node, related to, andoperating with, a particular firmware, the method involving identifying and authenticating the identity of the end node, the end node thereto provided with a preferably immutable unique identity code, the method thereto further involving an identity management system for identifying and authenticating said end node, in which the method further involves a configuration management system, registering the end node identity, and the firmware installed, at least dispatched to the end node with said identity, in which the firmware version as present on the end node is determined by the configuration management system, the latter system generating and providing a time stamp to the end node, the end node using this time stamp and its installed firmware to calculate and provide a response word to the identity management system, the identity management system further being provided with a challenge word by the configuration management system, calculated, preferably using a hash algorithm, on the basis of said generated time stamp and the firmware registered in relation to the end node identity, and the identity management system determining the conformance of said challenge word and said response word and outputting the result to the configuration management system.

[0040] It is remarked that the firmware upload is dependent on a preceding exchange step between end node device and the end node configuration management module. Where any information or authentication would by the end node or end node device be required from the central server, it should be noticed that the central server is as it were unknown to the end node. Hence any such notwithstanding nominated communication between and end node and a central server could in the present set up at best be mentioned as an indirect communication.

[0041] In yet a further development of the present invention, the firmware upload depends on the use of a unique, so-called Ephemeral Key, independently generated by the identity management server and the end node token, based on the unique identity of the end node, preferably with the firmware uniquely encrypted in transit to the device using said ephemeral key. Further, firmware to be uploaded may be provided with a digitally encrypting signature, provided by either the end node identity management system, or by the configuration management module.

[0042] In particular as may be preferred in case of expensive or sensitive environments or equipment, the method in an even further development of the concept, performs a tripleauthentication check in relation to a device, involving the signature of the firmware to be uploaded, a response word in view of the identity code as based on hardware processing in the end node token, and a challenge word based on a firmware -hash, preferably with the firmware uniquely encrypted in transit to the device.

[0043] An unexpected firmware upload feature may in the present invention be that an end node is provided with a micro controller unit, executing steps of the Firmware upload method, the response words of this method being calculated by the token of an end node. The presently proposed method typically may involve a separate server for identifying and authenticating identities and a separate end node configuration management server for registering and releasing firmware, while an end node configuration management module or server involves a firmware database, a hash module (HSH) and an end node identity register. The identity management system typically involves an identity registering database and a message authentication code module, and an end node typically avails of a build in hard coded unique identity and a key, in particular as part of a token.

[0044] As a yet further security measure, the present invention may involve a procedure step involving executing an, as it were final or double, check whether the entire procedure has been executed with the correct end node, the step involving a response word to be received at an end node from the configuration management system, in the end node re-used as challenge or input to the end node identity token, the latter generating a second response word, which is output to the configuration management system, the latter either requesting a conformance check to the central server, determining a conformance between the response word as dispatched to the end node and the second response word as received by the configuration management system from the end node, or performing this check on the basis of a response word emitted by the central server to the management system and a response word emitted to the end node for performing so called verification test, the configuration management system on the basis of this similarity check outputting a so- called all checks passed assessment.

[0045] Within the same subject, the present invention also claims a system for uploading firmware, in particular for executing a method of uploading firmware as described in the preceding, the system comprising one or more devices, each with at least one end node, and a central server electronically registering identities of said at least one end node and set upfor identifying and authenticating any end node, utilizing e.g. web-based electronic communication means, an end node provided with firmware and electronic micro processing hardware for executing certain functionality of the end node, as well as with means enabling electronic communication with a the central system, the system further comprising a configuration management system registering end node identities in conjunction with information on installed firmware in dependence of the end node identity, the system set up for uploading firmware in a targeted manner, the configuration management arranged for transmitting a challenge to an end node and for receiving a response word or authentication tag from the end node, the management system arranged to communicate said response to the central server, the latter, on the basis of the thus received response arranged for communicating an authentication test result to the configuration management system, the latter preferably set up to release a firmware version to the targeted end node, in dependence of the thus identified and authenticated end node.

[0046] The latter remark of system components being independent part of the present invention also holds for a device comprising one or more end nodes, with at least one end node provided with a preferably immutable, unique identification token, the end node provided with firmware and electronic micro processing hardware for executing certain functionality of the end node, and an end node token comprising an electronically readable, preferably immutable unique identity, the end node set up for enabling electronic communication with a remote controller, the end node, in particular the end node token further provided with a so called MAC- or machine authenticating code algorithm, for calculating a message authentication tag to be communicated by the end node, the end node token arranged for performing said calculation, in particular for identifying and authenticating firmware versions, more in particular in accordance with any of the preceding claims. The end node token may herein be arranged for performing both a message authentication code (MAC) verification and an identification function, thereto comprises a MAC, is arranged for releasing a unique ID or identity code, in particular for identification of the end node, and for calculating a response word or authentication tag when provided with a challenge word, in particular thereinrelying on cooperation with a central server having registered the key used in relation to said identity for said MAC.

[0047] Aspects and embodiments of the invention are further described in the following description of example embodiments and in the claims.BRIEF INDICATION OF FIGURES

[0048] FIG. 1 A provides an example of typical, state of the art FW uploading method, as published by above cited 2017 article “Secure firmware upgrade for embedded systems;”

[0049] FIG. IB sets forth a method not or hardly used in the firmware upload field for message or firmware approach using a symmetric type of encryption, i.e. sender and receiver using the same key and the same deciphering algorithm, ensuring the authenticity of a message that is transmitted from A to B, assuming they share a common cryptographic key;

[0050] FIG. 2A schematically sets forth a known system for authenticating remote hardware, i.e. a customer end node, using a cloud-based control or authentication platform and a customer configuration management system for authenticating the end node, in particular where the end node is configured with an electronically readable, preferably immutable, more preferably hardcoded identity (ID-) token;

[0051] FIG. 2B sets forth a system and method featuring a firmware authentication process in accordance with the invention, for authenticating and identity token comprising end node, for receiving firmware released by an end node configuration management module CMS upon receipt of confirmation of authenticity of an end node identity incorporated or included in a customer end node device, thus the new firmware is downloaded and authenticated, the CS calculates the AT, this is appended and sent together to the end node. The end node repeats the calculation and checks that the AT is correct;

[0052] FIG.’s 3 A, 3B and 3C represent a firmware authentication process optionally applying the method extension of a digital encrypting signature provided by either end node identity management system CS as in FIG 3 A, or by the end node configuration management system or module CMS as in FIG. 3B, while FIG. 3C representing an elaboration in which the hash module is incorporated in the token rather than in the MCU of the end node;

[0053] FIG.’s 4 A and 4B represents the FW authentication system of FIG. 3 enhanced by a system of encryption adapted for the FW upgrade in accordance with the present invention;

[0054] FIG.’s 5 A and 5B represent the FW authentication system of the preceding FIG. 3 and 4, enhanced by a combined system of hardware and firmware authentication of end node devices;

[0055] FIG. 6 represents a further development of the invention in the form of a firmware FW verification and installation method feature; while FIG. 7 by the same token as in FIG. 6 represents a possible runtime verification method feature as may be applied for installed FW verification independently of any intention towards uploading.DESCRIPTION OF EMBODIMENTS

[0056] The features and advantages of the invention will be appreciated upon reference to the following example embodiments, described by way of example only, with reference to the accompanying schematic drawings in which corresponding reference symbols indicate corresponding parts.

[0057] Furthermore, in the present context a FW signature check is understood as a standard measure to sign FW and check signature upon receipt. In the same sense FW encryption is understood to encompass encrypted transport of FW. A so-called targeted FW update here means that the FW version sent out, can only be installed on the specific module it is sent to. FW version control and configuration management here implies that a module reports back that FW was received correctly. In an elaborated version it may also mean that it is installed correctly. FW version verification here implies that a module can be interrogated about which FW is locally present, and in an elaborated version if it is installed.

[0058] FIG. 1 A sets forth an example of generally encountered practice, by way of a diagram as published in the article “Secure firmware upgrade for embedded systems”, written by Vysakh P Pillai, introduced above, and illustrates a typical and generic method of uploading FW, in particular a firmware blob. In this respect the Wikipedia article “Binary blob”, retrievable at https: / / en.wikipedia.org / wiki / Binary blob, indicates that the term blob was initially used to describe a collection of binary data stored as a single entity.

[0059] FIG. 1 A indicates that in order to sign a firmware blob, a hash of the blob is computed using a hashing algorithm which is then encrypted using a signer’s signing (private) key. In this prior art publication, the mentioned encrypted hash is called thesignature. A signature can be verified using the signer’s public key, available in the signing certificate, to get back the expected hash of the blob.

[0060] To verify authenticity of firmware, a hash of the received firmware blob is computed using a hashing algorithm and its signature is checked with respect to the decrypted signature received together with the firmware blob. They will match only if contents of the firmware blob are intact as signed. In this respect it is further mentioned that a “ digital signature refers to a digital equivalent of hand written signature that can verify the authenticity of a document. From a digital signatures perspective, the document by itself will be in clear test and not encrypted” Also, the publication mentions that digital signatures depart from the two cryptographic capabilities of an ability to create a non- reversible (one-way) and unique message digest (Hash), and an ability to implement public key cryptography that can ensure authenticity of a signing certificate. In the latter respect, the signer certificate will contain info / details including signer' s public key and signature algorithm and hash function to be used, and signer certificate will be signed by a trusted root certificate authority (CA) that authenticates the holder and integrity of the signer certificate.

[0061] In FIG. 1 A the FW to be uploaded to a device is indicated in the upper box “Firmware blob” of the left hand side column of blocks, representing an instance of the device manufacturer, while the device that will download the new FW, also represented by upper most box, is represented at the right hand side. The method, at both sides departs from the availability of Hashing means, represented in the second box “Hashing Algo”, from a Signer Private key available at the device manufacturer as represented by the Left hand side column of boxes, at the lower most box “Signer Private Key”, and conversely at the device or right hand side a public key represented by lowermost box “Signer Public Key”.

[0062] Transmission of the FW to be downloaded, a method step represented by the arrow in between the columns is dependent on the availability of a so-called signature, represented by a left hand side box “Signature”, which receives its input from an encryption process represented in the third box “Encrypt”, which encrypts the Hash generated by the second box on the basis of the FW to be downloaded, using the private key as available in the lowermost box. This signature is then transmitted in conjunction if not combined with the FW to the device. At the device side the signature received in combination with the FW is compared with a signature generated in the process step represented by the third box from above “Decrypt”, using a hash generated by the hashing algorithm on the left side of thefigure using a public key available at the device, inputted by the process step of the lowermost box “Signer Public Key”. The comparison step indicated by the box “Compare” at the right-hand side of the third box “Decrypt” compares the decrypted signature received with the generated signature of the firmware blob. If the comparison succeeds, the authenticity of the FW received is accepted.

[0063] While the method of FIG. 1 A discloses a generally accepted model of a basic standard for FW upload, the present invention proposes to radically, i.e. against prejudice or contrary to what is deemed advisory, deviate from this model by adopting a model much closer to the so called symmetric key approach, represented by FIG. IB, as published by the Wikipedia topic “Message authentication code” on https: / / en.wikipedia.org / wiki / Message authentication code.

[0064] While not known for its application in firmware upgrade, this method of encrypting is indicated to be used in the finance industry. This method uses a type of symmetric encryption, where sender and receiver of a message to be transmitted in between use the same key and the same deciphering algorithm, and is referred to as MAC, short for Message Authentication Code.

[0065] The non-repudiation feature is in such set-ups at one side or party provided by having the copy of the identical key in a hardware security module. In the example of FIG. IB, “the sender of a message runs it through a MAC algorithm to produce a MAC data tag, with the term tag as it were corresponding to the term signature as is applicable in the method according to FIG. 1 A. The message and the MAC tag are then sent to the receiver. The receiver in turn runs the message portion of the transmission through the same MAC algorithm using the same key, producing a second MAC data tag. The receiver then compares the first MAC tag received in the transmission to the second generated MAC tag. If they are identical, - question represented at the right bottom side of the figure - the receiver can safely assume that the message was not altered or tampered with during transmission (data integrity)”. In this system, “to allow the receiver to be able to detect replay attacks, the message must contain data that assures that this same message can only be sent once, e.g. a time stamp, a sequence number or by use of a one-time MAC.” This prevents an attacker to record the message and play it back at a later time, producing the same result as the original sender.

[0066] The present invention proposes to adopt above exchange system for use as or in a FW update method, amongst others by using hash-based message authentication code or HMAC, instead of MAC as indicated in FIG. IB.

[0067] In FIG. 2 a simplified schematic diagram as proposed by the present invention is shown, of an exchange of messages in conjunction with an authentication procedure between an end node EN (right side) and a central server CS (on the left side), typically a cloud based so-called platform, wherein the central server CS is provided with challengeresponse control functionality server hash-based message authentication code SHMAC.

[0068] Further different from the prior art symmetric key system of FIG. IB, the present invention proposes a model involving a customer configuration management system CMS, recording the configuration of each individual end node EN. Typically, this may be the configuration of a device sold and to be serviced by a producer, so that the end node EN is a participant to the FW upgrade system as proposed by the present invention. This configuration management system CMS, which often takes the form of a server, provided within the set-up of the present invention, is typically maintained under responsibility by the device-producer, such devices here denoted as end node EN.

[0069] A configuration management system CMS for firmware updates is a specialized system component designed to manage, automate, and monitor the distribution and application of firmware updates across devices. It ensures that devices maintain consistent firmware versions, comply with security policies, and minimize downtime during updates. Its key functionalities may include centralized management of firmware files for easy deployment to multiple devices, tracking firmware versions and maintaining a record of updates for each device, automating firmware updates and scheduling them to minimize operational disruptions, verifying that updates are compatible with the targeted devices before deployment, providing the ability to revert to a previous firmware version in case of errors or issues, and offering real-time monitoring of update processes and generating reports on update success or failures.

[0070] The end node EN typically includes an embedded, integrated circuit, comprising micro controller unit (MCU) functionality, which latter, in conjunction with an end node token identity TID and / or a token hash-based message authentication code THMAC, upon request respectively, outputs an identity code ID to the central server CS, receives achallenge message or word CW from the central server CS, and outputs a response message or response word, also called an authentication tag AT to the central server CS.

[0071] Such request may be performed by the configuration management system CMS, which initiates an ID control of the end node by outputting an identity request RID to the end node EN, and which may receive from the central server CS an authentication check result IDAUR. In this novel set-up, the end node EN receives a challenge by the challenge message or challenge word CW from the central server CS, and generates the response AT to the challenge.

[0072] The end node EN may be any kind of device or item or asset which it is desired to identify and / or authenticate. The configuration management system CMS typically is set up to manage configurations of a single customer only, and may be either controlled by a customer to the identification and authentication system or platform central server CS, or may be controlled as a service to such customer, in conjunction with the platform service central server CS.

[0073] At its core, the end node device comprises at least one end node (EN), which represents the functional unit responsible for processing data, executing firmware, and interacting with the environment or connected systems. The device may be equipped with embedded processing capabilities, such as a microcontroller unit (MCU), to manage its operations efficiently. These operations often include executing firmware, handling secure communications, and authenticating updates or commands.

[0074] The end node device connects to the network, enabling it to interact with centralized systems like the identity management central server (CS) and the configuration management system (CMS). The CS plays a pivotal role in ensuring the security and authenticity of the device by managing cryptographic keys and performing critical authentication tasks. For instance, when firmware updates are distributed, the CS generates a server-side hash-based message authentication code (SHMAC) using a symmetric key shared with the end node device.

[0075] The CMS may operate as the orchestration layer, responsible for managing and distributing firmware, configurations, and updates across the network. It may ensure that the correct firmware versions are deployed to specific devices based on their unique identities and requirements. The CMS works in tandem with the CS to maintain a secure updatepipeline. After the end node device verifies the firmware using its token hash-based message authentication code (THMAC) algorithm, it communicates the verification outcome back to the CMS, confirming the successful installation of the firmware.

[0076] This interconnected architecture allows the end node device to operate securely within a distributed network. The CS ensures authentication and trust, while the CMS provides configuration and update management. The end node device itself acts as a secure endpoint, safeguarding its integrity through hardware-level protections, such as an immutable token storing cryptographic keys and algorithms. This design ensures that each component of the system works cohesively, providing robust security, streamlined operations, and scalability for applications like loT, industrial automation, and distributed control systems.

[0077] In the present invention it is believed that at least part of potentially various complaints or regarded shortcomings in know methods of FW-upgrade may be solved, i.e. may now be controlled in an improved manner according to the presently invented firmware authentication system. In the present invention, various levels of security may be incorporated, in practice depending on non-technical factors like the economic value or strategic interest of the FW or the end-node enhanced thereby. In standard configuration the end-node EN or FW thereof may hold a public key signature, e.g. provided by the firmware provider, which key can be monitored using the central server CS.

[0078] In an improved embodiment such public key signature may be defined over the firmware itself, so that an indication is attained that the public key and the firmware belong together. Yet further, the present proposal towards improved FW upgrade and authentication further involves the use of a secure and unique identification token (TID). Such a unique and secure identification token may be in the form of a hardcoded token, e.g. as known by patent publication WO2021240445, which latter discloses a centralized code handling platform for verifying the ID of an immutable, hard coded identification token. This prior art publication solves an end node authentication problem, however does not deal with FW upgrade. Since the document is silent as to this latter topic, it neither discloses nor teaches anything related to any embedded FW authentication, nor does it suggest so.

[0079] While other secure identification tokens may be used, the above cited hardcoded token is preferred over e.g. so-called secure elements, trusted execution environments ormicrocontrollers in that apart from an FW signature check as described in the preceding, other desired or preferred functionalities may not or not optimally or easily be present or performed. Such additional functions according to the present invention encompass FW encryption, targeted FW upgrade, FW version control & configuration management, and FW version verification. Other advantages of the cited hardcoded identification token encompass reduced complexity of implementation and resistance to physical tampering. A particular advantage of the present invention moreover holds that it offers both, i.e. combined authentication of firmware FW and hardware, i.e. of end node EN.

[0080] The present invention extends this known concept by providing an authentication step, as among others illustrated in FIG. 2A, in communication between the central server CS and the end node EN. An end node EN refers to the logical endpoint in a network, representing the source or destination of data, while an end node device CED is the physical hardware that fulfills this role, such as a computer, smartphone, or loT sensor. In this respect the new system holds, or alternatively is extended with a so-called configuration management system CMS, which may be triggered to dispatch, i.e. electronically communicate, in manner described in above cited prior publication, an identity request RID. In a configuration according to the present invention, the end node EN, utilizing electronic circuitry MCU with micro control unit functionality, typically embedded, yet at least accessible and useable by the end node EN, is configured to respond to this request or trigger, by sending out a signal ID, holding the unique ID-code of an embedded ID token TID to the central server CS, which latter verifies in the known manner if the identity code ID is valid or not. If valid, the central server CS, i.e. a challenge-response circuit thereof, emits a challenge word CW to the end node EN, the latter in this invention thereto configured with a challenge-response token hash-based message authentication code THMAC, which latter is configured to calculate the correct response AT, which is then emitted by the processing unit MCU to the central server CS.

[0081] The server in response evaluates the validity of the response word AT in view of the identity code ID provided, and is configured to output a verification outcome AR to the configuration management system CMS. The verification outcome on which signal AR is based is in the context of the present invention is taken as an authentication result of the identity of the end node or alternatively put, of identification token TID identity code read out result which had been output in the form of signal or code ID.

[0082] In the present invention, the management system CMS may in return release a firmware modification for upload to the end node EN. In contrast to many known distribution systems, the firmware release is performed in a controlled manner, in that the management systems CMS may record and specifically keep track of and control which firmware modification has been released and updated for each separate end node EN specifically and may hence offer individual firmware modification uploads per end node EN.

[0083] In the above set-up, with an immutable identification token TID included in the end node EN, it may be known and verified that the two belong together, i.e. in accordance with intention of the end node EN owner and recorded in the configuration management system CMS. The certainty hereof, as already enhanced by the presence of the immutable identification token TID, is in an embodiment of the invention further elevated by hashing using the token hash-based message authentication code THMAC module, i.e. in conjunction with the immutable end node identity TID. This measure further raises certainty of the authenticity of the end node identity TID, in fact in that by using the specific THMAC module, the authenticity of TID is or may be proven. The present invention hence unexpectedly not only applies a form of authentication for raising security of firmware modifications at dispatching or releasing the same to a customer electronic device EED incorporating and end node EN for this purpose, but in fact also uses such authentication technique “the other way round” as it were, i.e. applied in the other direction than normally used, starting at the end node. Where normally the signature or signature token of a customer end node device would generate a response that is checked, i.e. automatically verified at and by the server, now the check is performed on and by the device CED, where the central server CS in a previous step would send said response to the end node device via the configuration management system CMS.

[0084] FIG. 2A is primarily directed to illustrating hardware, at least identity ID authentication in the present invention. Such authentication can be triggered by either the management system CMS or by the device or end node EN, typically automated. The depicted scheme clarifies the verification of the unique end node ID as secured in token TID, based on a challenge / response procedure with symmetrical authentication, known per se.

[0085] The outcome IDAUR of an identity authentication verification by the identity management central server CS is transferred to the customer or end node configuration management system CMS. In fact, though not graphically represented here, the configuration management system CMS utilizes this outcome for releasing or not releasing a FW modification download for the end node EN. In this representation, the authentication request RID is performed by the configuration management system CMS, in particular an ID control section IDC thereof, which request is addressed to the end node EN for interrogating the identification token TID thereof. The latter releases its value ID to the identity management central server CS, which by its hash based message authentication module SHMAC releases a control word CW to a token hash-based message authentication code THMAC of the end node EN, which in turn releases, i.e. transmits a reply word AT to the identity central server CS, which uses this reply word for thus verifying the authenticity of the provided end node ID. In this exemplary set up, the device MCU acts as transmission controller: no processing or decision taking is required for hardware, at least secure identity authentication.

[0086] THMAC (Token HMAC) refers to an HMAC (Hash-Based Message Authentication Code) that is tied to a specific token or secure element. It typically resides within the end node device and may be hardware-protected to ensure security against tampering. It is used to generate or verify authentication data (e.g., response words or signatures) in the firmware authentication process. The THMAC might utilize a challenge word (CW) to produce a response word (AT) unique to the end node device.

[0087] A secure and efficient method for authenticating firmware can be obtained by leveraging a THMAC algorithm embedded within an immutable token in the end node device. This design ensures that the core cryptographic functionalities are securely encapsulated within hardware that cannot be altered or tampered with. Preferably, the immutable token includes not only the THMAC algorithm but also the unique identity of the end node device and the symmetric key required for the algorithm. This integration ensures that the authentication process is both device-specific and resistant to external interference.

[0088] The use of a hardcoded integrated circuit (IC) as the immutable token further enhances security. Such an IC is designed to be physically immutable, meaning its configuration cannot be modified after manufacturing. This property ensures that thecryptographic components, including the symmetric key and the unique identity, remain consistent and tamper-proof throughout the device's lifecycle. More preferably, the IC is implemented without non-volatile memory, which eliminates the risk of unauthorized overwriting or extraction of sensitive data, further fortifying the security posture of the end node device.

[0089] By embedding the THMAC algorithm and its supporting components within a secure hardware element, the method addresses key vulnerabilities commonly associated with software-based cryptographic implementations. For instance, the absence of nonvolatile memory ensures that critical data cannot be retrieved or compromised even under advanced attack scenarios. This makes the method particularly suitable for applications requiring high-security standards, such as in loT devices, industrial control systems, and other environments where firmware integrity is paramount.

[0090] Moreover, the hardcoded IC approach optimizes the balance between performance and security. Since the THMAC algorithm operates directly within a dedicated hardware token, the computational overhead is minimized, allowing the end node device to perform authentication tasks efficiently.

[0091] SHMAC (Server HMAC) refers to an HMAC operation that is performed on the network side, often by the identity management central server (CS). The network uses a shared secret or device-specific key to compute its version of the authentication data. In some systems, the SHMAC might be used to generate the server-side response word (AT) that is transmitted to the end node for verification.

[0092] The symmetric key used by the SHMAC algorithm preferably is identical to the symmetric key utilized by the THMAC algorithm in the end node device. This shared use of the symmetric key establishes a cryptographic link between the server and the end node device, ensuring that both entities can perform secure and consistent HMAC operations. By using the same key, the SHMAC performed by the server and the THMAC performed by the end node device can independently generate authentication tags that are directly comparable, enabling mutual validation of firmware versions.

[0093] This shared-key mechanism allows the SHMAC algorithm to compute an authentication tag for a firmware version based on a hash generated on the server side, whilethe THMAC algorithm computes a corresponding tag from the same firmware hash on the end node side. When the firmware version and hash are consistent between the server and the end node device, the authentication tags produced by SHMAC and THMAC will match, confirming that the firmware has not been tampered with during transfer and is authentic to the intended version. This capability provides a robust mechanism for firmware authentication, as it ensures the integrity of firmware across both the server and device domains.

[0094] Additionally, the shared symmetric key creates a secure, trusted environment for firmware validation without the need to exchange sensitive keys during operation. Preferably, this setup avoids potential vulnerabilities associated with key distribution by embedding the symmetric key within secure hardware, such as the immutable token in the end node device and the secure cryptographic module in the server. This design guarantees that only authorized devices and servers possessing the shared key can successfully verify firmware versions, further strengthening the authentication process.

[0095] By allowing the SHMAC and THMAC algorithms to confirm firmware versions from each other, the system establishes a bi-directional verification framework. This approach is particularly beneficial in distributed systems, where ensuring synchronized firmware states across multiple devices is critical. The ability of SHMAC and THMAC to verify firmware versions using a shared key reduces the risk of mismatched or unauthorized firmware updates, thereby enhancing overall system reliability and security.

[0096] The network, such as the identity management central server (CS), is designed to securely store and manage multiple SHMACs, each associated with a unique symmetric key for use with individual end node devices. This architecture enables the central server CS to maintain device-specific keys, ensuring that the firmware authentication process is uniquely tailored to each device in the network. By associating each SHMAC with a specific device, the system ensures that only the correct symmetric key is used when generating the serverside authentication tag (AT) for a particular device. The network may know which symmetric key to use by looking up the identity received from the specific end node device.

[0097] Preferably, this multi-key setup allows the CS to securely handle large-scale networks with numerous devices, each requiring its own symmetric key for THMAC and SHMAC operations. During the authentication process, the CS selects the appropriateSHMAC based on the unique identity of the end node device, ensuring that the server-side HMAC computation aligns with the device-specific THMAC calculation. This ensures that the authentication tags generated by both the server and the device are derived from the same symmetric key.

[0098] The storage and management of multiple symmetric keys by the CS also enhance the system's overall security. Each symmetric key is uniquely tied to an individual device, meaning that compromising a key associated with one device does not impact the integrity of other devices in the network. Preferably, the CS employs secure storage mechanisms, such as hardware security modules (HSMs), to protect the symmetric keys from unauthorized access or tampering.

[0099] The ability to store and use device-specific keys reinforces trust in the authentication process, as it guarantees that only authorized devices with matching THMAC and SHMAC keys can successfully confirm firmware versions.

[0100] FIG. 3 A is primarily directed to illustrating the firmware FW Authentication procedure according to the present invention. Herein, the customer, i.e. the configuration management system CMS generates a hash, typically but not limited to 256 bit, from the firmware FW to be released, and this will be used as a challenge word CW for the identity central server CS, i.e. in fact in the form of an inverse authentication. Advantageously this hash needs to be generated only once, since it is the same for all devices EN serviced by the server CMS. The reply or response word AT though, generated by the identity management central server CS, is device-specific. The identity management central server CS thus uses a device specific C / R-key, using the authenticated device ID. It should further be noted that the challenge word CW and the response word AT are unique for each firmware FW version.

[0101] In order to determine a hash from the firmware, first a cryptographic hash function is selected. Commonly used hash functions include SHA-256, SHA-3, or other algorithms. The choice of hash function depends on the security requirements and the desired resistance to collisions and pre-image attacks. Next, the firmware is prepared. The firmware, typically a binary file, is read into memory. It may need to be normalized or pre-processed if specific metadata or formatting should be excluded from the hash computation (e.g., dynamic configuration fields or non-critical padding). Next, the firmware is processed. The firmwarebinary may be fed into the hash function in chunks, especially if it is large. The hash function processes the binary data either in one go or incrementally, updating an internal state with each chunk. Finally, the final hash value is computed. Once the entire firmware binary has been processed, the hash function produces a fixed-length output (e.g., 256 bits for SHA-256). This hash value is deterministic, meaning the same firmware input will always produce the same hash. The computed hash may be stored or sent to a central server for storage.

[0102] With respect to a firmware FW authentication check in device, it may be noted that in the present invention the same FW hash operation as at the customer source or management system CMS, generates the challenge-word CW. The challenge word CW authentication uses the HMAC token THMAC as present in the end node. This may according to preference involve the same token TID as used for previous, i.e. along FIG. 2 described hardware authentication, i.e. challenge / response methodology. Yet, with the authentication systematic now reversed, the end node EN, utilizing the embedded processing functionality MCU, the from system CS received response word AT and the response word AT provided by the token THMAC are provided to and compared in a AT check module CAT. Its verification outcome ACP is by the end node EN, typically by the micro-processing functionality MCU thereof, provided to the configuration management system CMS, as a successful firmware FW installation. When all check as executed in and by the end node EN, i.e. including the hash check on the new firmware NAT are reported positive, the Customer CMS knows, i.e. registers the specific FW version downloaded to, i.e. installed on a particular end node device EN with specific ID.

[0103] In this new set up, a two-step process may thus be identified: the hardware token authentication and the sending of new firmware NFW utilizing an ID specific response word AT. It may thus be concluded that the customer database and management system CMS and the identity management central server CS now know and verified the token ID. Hence the customer system CMS now knows the unique ID of the device, which may be a part, e.g. a PCB of a machine, that contains the token. In sending the firmware FW and ID-specific response word AT, the device EN thus checks the firmware FW authenticity and reports back to system CMS after successful FW installation.

[0104] FIG. 3B and 3C represent respective variants of an elaboration of the preceding method as a firmware FW authentication with signature verification. In the FIG. 3B variantthe signature is provided by the ID management system CS, upon configuration management system CMS generated and provision of a hash SWH from the firmware FW to be provided. This will be used as a challenge word CW for the identity management central server CS inverse authentication, i.e. for generating a response word AT. The identity management central server CS in the case of FIG. 3B or CMS in the case of the FIG. 3C variant also generates a unique signature on the response word AT. This may be performed using a Standard public-private key system. If the firmware FW should also be signed, this can be done by Customer instead. Subsequently, the end node device EN, performs a double authentication check in device, i.e. on the signature and on the response word AT, based on hardware processing in the token, using challenge word CW equal to FW-hash. These verifications are executed in the device processing functionality or unit MCU and in the hardware HMAC in token. The value of presence of a signature being that it provides additional anti-hacking security.

[0105] FIG. 4A and 4B FW relate to authentication with encryption, optionally with either an identity management system central server CS provided signature SSIG, or with a configuration management system CMS provided signature CSIG respectively. In this further elaborated, novel set-up, the customer, i.e. the configuration management system CMS, typically generates a hash from the new firmware FW to be uploaded to the end node device EN. Preferably the new firmware is encrypted using an encryption key EK. Also, the hash is or will be used as a challenge word CW for the identity management central server CS in the inverse implemented manner of authentication, wherein in this instance the central server CS in return generates a response word AT. Additionally, the identity management central server CS may also generate a unique signature SGN, to be added on or to the response word AT. Otherwise the thus elaborated method preferably utilizes a standard public-private key. If the to be uploaded firmware FW should also be signed, this can be done by either the identity management system CS, or by the customer configuration management CMS instead.

[0106] Yet further to the elaboration in FIG. 4A and 4B, the identity management central server CS and the end node token TID may according to a further aspect of the invention jointly generate a unique Ephemeral Key EK. A such generated ephemeral key EK is different for every firmware version FW to be uploaded, since in fact being a hash, andunique for every token or end node EN, i.e. for every different device part, which incidentally in itself in turn also may be regarded a device.

[0107] An advantage with this latter elaboration is that no special or complex or expensive key storage is required for the generated ephemeral Key EK in a device: a new key EK is generated for each challenge word CW that will be received. With this added feature, the firmware upload according to the present invention hence avails of a triple authentication check in a device, and therefor is particularly suited for highly sensitive equipment. It is remarked that the signature related response word AT is here based on hardware-, at least secure code- processing in the token THMAC, while the challenge word CW is based on a hash of the received firmware FW. In this respect the firmware FW is in this embodiment uniquely encrypted in transit to device EN. Also in this embodiment, all verification is done in device micro-processing unit or other local micro-processing functionality MCU, except for the secure or hardware HMAC, which is executed by an algorithm incorporated in the token.

[0108] Yet a further elaboration of the invention, illustrated along FIG. 5A and FIG. 5B relate to firmware FW authentication integration. While the operation of the invented method is in analogy and at least largely the same as in FIGs 4, the firmware hash FH and the encryption service ES performed by the identity management central server CS differ through an additional firmware streaming interface between the ID management central server CS and the configuration server CMS. Such a set-up has the advantage to prevent the ephemeral Key EK from coming outside the secure environment of the identity management central server CS, thereby further increasing safety, or security of the targeted secure firmware upload.

[0109] Correspondingly to the preceding, the end node side EN comprises a so-called next Generation Token IC TICD, adapted to comprise an integrated decryption algorithm. Here the corresponding advantage is present, viz. that the ephemeral key EK does not leave the IC. A further advantage of this system and method set-up is that it reduces complexity in the configuration management system CMS for hash and encryption. It is further remarked that the identity management central server CS and the Token decryption integration can be implemented independently in a system of the present invention.

[0110] FIG 6 illustrates yet a further elaboration in which an uploaded firmware NFW verification takes place in a collaboration or exchange, also denotable as firmwareconfirmation verification, between the end node device EN and the configuration management server CMS. In this verification the firmware version reported to be actually installed is compared to the firmware version registered at server CMS as released for dispatch to the end node EN. The server CMS is hereto equipped or provided with an additional element CAT2 for executing this check on similarity of reported and registered firmware version. Such a verification may be performed with all of the in the preceding described elaborations of this invention and establishes an additional authentication step, executed by the end node device EN. This step compromises treating AT as a new challenge word and submitting it to the token hash-based message authentication code THMAC module, whereupon the result AT2 is transmitted to the server CMS. The authentication may be checked by the identity management central server CS, preferably based on a precalculation thereof as further foreseen in the present invention. This new feature especially provides the additional guarantee that the firmware FW was actually processed by the target device EN. The identity management central server CS checks that AT2 matches, thus proving the firmware FW presence on the target device EN.

[0111] FIG. 7 sets forth an optional elaboration of the invention with having the token TID further extended, i.e. implemented with the capability of performing a hash in the token. This feature of the invention makes certain attacks harder. In particular an attacker now has to store the complete original firmware and not just its hash, which makes any attack, not only more elaborated, but also more complicated and requires more resources. In this option, the method and system of the present invention is extended in accordance with features as represented in FIG. 7, with the end node EN producing a hash from a timestamp TS received from the configuration server CMS, the result of which is by the end node token HMAC module used to generate a response word AT to be supplied to the identity central server CS for indicating the validity of the end node EN installed firmware FW to the configuration server CMS. The identity central server CS, thereto in the preceding, i.e. with the creation of a timestamp TS by the configuration server, receives a hash CW from the configuration central server CS of this timestamp and the firmware FW to be released, as well as a signal ID representing the device ID as registered in relation to device hardware DHW and device firmware DFW. It is remarked that while technologies as applied in accordance with the figures 6 and 7 may be related, the method of FIG. 7 elaborates on the issuing of a time stamp since the authentication step is not instantly linked to a firmwareupload, and prevents e.g. the use of any earlier responses in the system as might have been intercepted unfaithfully.

[0112] In a summary on authentication of hardware HW and firmware according to the proposal by the present invention, the present solution offers combined hardware and firmware authentication of end-node devices. Also, the hardware authentication provides a unique, authenticated identity ID of the device to be modified with uploaded firmware. The firmware FW authentication indicates which software version has been installed on each specific device (ID), i.e. establishes a far reaching controlled procedure in this respect. The controlled upgrade, at least modification of firmware FW can be performed remotely from the device, yet controlled. Rather than in known firmware upgrade methods with upgrade performed in distribution mode, upgrades in the present method may be performed in a device per device operation and at selected times. In an additionally secured version, an encryption option may be implemented, using a unique ephemeral key EK feature to increase security during upload of the firmware dispatched by a device configuration management server.

[0113] Thus, in the present invention firmware FW updates are performed within a combination of a hardware or device EN unique identity ID as securely stored at the device EN in an identification token TID, e.g. in the form of an immutable hard coded identity value, and an identity management central server CS and a method and system implementing identity establishment, i.e. readout as well as authentication thereof. Herein a firmware FW status may be registered in a configuration management system CMS, typically registering device configurations with end nodes EN such as a replacement parts on a machine registered on the basis of a therein incorporated specific IC, securely establishing a unique identity, e.g. by way of a secure element or a hard coded identity value. In such a system and method a challenge of targeted hardware HW and firmware FW to be uploaded or as present on the hardware HW, i.e. on the specific end node EN, is based on a hash of both the concerned firmware FW and the concerned end node identity ID. In such a targeted update with firmware FW that is specific to the targeted hardware or end node EN, a confirmation may be achieved by a configuration management server CMS that the right, i.e. correct version of firmware FW has been uploaded. In advance of or after upload of a firmware version FW, confirmation may be achieved by the confirmation management system CMS which FW is present, i.e. implemented on the end node EN.Additionally a timestamp TS may be used to do update and check firmware version FW at the end node EN.

[0114] The determination step in the described firmware authentication method provides distinct workflows depending on whether the comparison occurs on the device (end node) or the network side, with each serving a specific use case for verifying firmware integrity and alignment. This dual-path approach ensures flexibility and reliability in different operational scenarios, adapting to whether the firmware originates from the network or the device.

[0115] Device-side determination may occur when the end node has received firmware, either through an update process or other communication from the network. In this case, the end node validates the firmware locally before installation or execution. The end node generates a first hash value from the received firmware and processes it through its token hash-based message authentication code (THMAC) algorithm, using a device-specific symmetric key, to produce the first authentication tag. Simultaneously, the network generates a second authentication tag using the server hash-based message authentication code (SHMAC) algorithm for the same firmware.

[0116] The second authentication tag is sent from the network to the end node, allowing the device to perform the comparison. If the two authentication tags match, the firmware is verified as authentic and unaltered, permitting secure installation or activation. This approach ensures that the end node operates only with validated firmware, offering a secure, autonomous method for handling updates while reducing reliance on external validation.

[0117] Network-side determination may be employed when the network needs to confirm the firmware currently installed on the end node device with respect to its own records or expectations. This is critical for ensuring system-wide consistency, particularly in scenarios where the network maintains a registry of firmware versions assigned to each device.

[0118] In this workflow, the end node generates a first authentication tag using its THMAC algorithm, based on the hash of the installed firmware, and sends this tag to the central server (CS). The network, using its registration of the expected firmware for the device, generates a second hash value and processes it through its SHMAC algorithm to produce a second authentication tag. The CS then compares the received first authentication tag from the end node with the internally computed second authentication tag. In this case anonce may be used together with the firmware to create a hash value, the nonce for example generated by the network, e.g. the CMS.

[0119] A match confirms that the end node’ s firmware aligns with the network’ s registered firmware version, verifying that the device is running authorized software. If there is a mismatch, the network may flag the device for remediation, initiate a reinstallation of the correct firmware, or take other corrective actions.

[0120] This dual-determination framework provides flexibility and robustness for firmware authentication across different operational contexts. Device-side determination ensures immediate validation of received firmware, allowing end nodes to independently confirm authenticity before installation. On the other hand, network-side determination centralizes firmware management, enabling the network to maintain a comprehensive and synchronized view of firmware states across all devices, essential for large-scale deployments.

[0121] The use of identical symmetric keys for both THMAC and SHMAC operations ensures consistency and security in both workflows. By tailoring the determination step to the specific context — firmware reception on the device side or firmware registration on the network side — the system achieves a seamless balance between localized security at the device level and centralized control within the network. This approach enhances trust, integrity, and scalability in firmware management for distributed systems.

[0122] Modifications to the embodiments described above may be made to the structures and techniques described herein without departing from the spirit and scope of the invention. Accordingly, although specific embodiments have been described, these are examples only and are not limiting upon the scope of the invention.CLAUSES1. A method of uploading firmware (FW) to a device (CED) comprising at least one end node (EN), receiving the firmware (FW) from a firmware distributing or releasing system (CMS), the method applying an authentication tag (AT) to the firmware released (FW) and to be uploaded to the device, in which method the releasing side and the end node side share a digital key, with the releasing side (CMS) and the end node (EN) or the end node device (CED) utilizing an identical message authentication code algorithm for calculating a message authentication tag (AT), utilized by the end node (EN) or end node device (CED) for authenticating the firmware (FW) received, the method further comprising a machine authenticating code, MAC, algorithm (THMAC), for calculating the message authentication tag (AT), included in the end node (EN) or end node device (CED), the token further incorporating a unique identity (TID) of the end node (EN) or end node device (CED), the method further comprising a secure identity management system (CS) implemented for authenticating a secure identity (TID) of an end node (EN), and an end node configuration management system (CMS) releasing firmware to an end node (EN) upon receipt of an identity authentication (IDAUR) of the end node (EN) from the secure identity management system (CS).2. Method according to clause 1, in which the message authentication code algorithm is a hash-based message authentication code (HMAC), a hash of the to be uploaded firmware (FW) forming a basis for calculating the authentication tag (AT), in particular with the token identity (TID) being used for determining the key used in the hash.3. Method according to either one of clause 1 and 2, in which a firmware upload may be initiated by either one of the end node device (EN) and the configuration management module (CMS).4. Method in accordance with either one of clauses 1 to 3, in which the method of uploading is a targeted upload, the firmware version (FW) or content of upload being determined or modified in dependence of the end node identity (TID).5. Method in accordance with any one of the preceding clauses, in which the firmware version as present on the end node (EN) is determined by the configuration management system (CMS), the latter system generating and providing a time stamp (TS) to the end node (EN), the end node (EN) using this time stamp (TS) and its installed firmware to calculate and provide a response word (AT) to the identity management system (CS), the identity management system (CS) further being provided with a challenge word (CW) by the configuration management system (CMS), calculated, preferably using a hash algorithm, on the basis of said generated time stamp (TS) and the firmware registered in relation to the end node (EN) identity, and the identity management system (CS) determining the conformance of said challenge word (CW) and said response word (AT) and outputting the result to the configuration management system (CMS).6. Method for assessing installed firmware version in a device (CED), in which the device comprises at least one end node (EN), related to, and operating with, a particular firmware (FW), the method involving identifying and authenticating the identity of the end node (EN), the end node thereto provided with a preferably immutable unique identity code (TID), the method thereto further involving an identity management system (CS) for identifying and authenticating said end node (EN), in which the method further involves a configuration management system (CMS), registering the end node identity (TID), and the firmware installed, at least dispatched to the end node (EN) with said identity (TID), in which the firmware version as present on the end node (EN) is determined by the configuration management system (CMS), the latter system generating and providing a time stamp (TS) to the end node (EN), the end node (EN) using this time stamp (TS) and its installed firmware to calculate and provide a response word (AT) to the identity management system (CS), the identity management system (CS) further being provided with a challenge word (CW) by the configuration management system (CMS), calculated, preferably using a hash algorithm, on the basis of said generated time stamp (TS) and the firmware registered in relation to the end node (EN) identity, and the identity management system (CS) determining the conformance of said challenge word (CW) and said response word (AT) and outputting the result to the configuration management system (CMS).7. Method in accordance with any one of the preceding clauses in which, the firmware upload is dependent on a preceding exchange step between end node device (EN) and the end node configuration management module (CMS).8. Method in accordance with any one of the preceding clauses in which the firmware upload depends on a unique Ephemeral Key (EK), independently generated by the identity management server (CS) and the end node token (TID), based on the unique identity (ID) of the end node (EN), preferably with the firmware (FW) uniquely encrypted in transit to the device using said ephemeral key (EK).9. Method in accordance with any one of the preceding clauses in which firmware to be uploaded is provided with a digitally encrypting signature (SIG), provided by either the end node identity management system (CS), or by the configuration management module (CMS).10. Method in accordance with any one of the preceding clauses in which the method performs a triple authentication check in relation to a device, involving the signature (SIG) of the firmware to be uploaded, a response word (AT) in view of the identity code (TID) as based on hardware processing in the end node token, and a challenge word (CW) based on a firmware (FW) -hash, preferably with the firmware (FW) uniquely encrypted in transit to the device.11. Method in accordance with any one of the preceding clauses, in which an end node (EN) is provided with a micro controller unit (MCU), executing steps of the Firmware upload method, the response words of this method being calculated by the token (THMAC) of an end node (EN).12. Method in accordance with any one of the preceding clauses, in which the method involves a separate server (CS) for identifying and authenticating identities (ID) and a separate end node configuration management server (CMS) for registering and releasing firmware (FW).13. Method in accordance with any one of the preceding clauses in which the end node configuration management module or server (CMS) involves a firmware (FW) database, a hash module (HSH) and an end node identity (ID) register.14. Method in accordance with any one of the preceding clauses, in which the identity management system (CS) involves an identity registering database and a message authentication code module (SHMAC).15. Method in accordance with any one of the preceding clauses, in which an end node (EN) avails of a build in hard coded unique identity (TID) and a key (THMAC), in particular as part of a token.16. Method in accordance with any one of the preceding clauses, in which a procedure step involves executing an, as it were final or double, check whether the entire procedure has been executed with the correct end node (EN), the step involving a response word (AT) to be received at an end node (EN) from the configuration management system (CMS), in the end node (EN) re-used as challenge or input to the end node identity token (INT), the latter generating a second response word (AT2), which is output to the configuration management system (CMS), the latter either requesting a conformance check to the central server (CS), determining a conformance between the response word (AT) as dispatched to the end node (EN) and the second response word (AT2) as received by the configuration management system (CMS) from the end node (EN), or performing this check on the basis of a response word (AT2) emitted by the central server (CS) to the management system (CMS) and a response word (AT) emitted to the end node (EN) for performing so called verification test, the configuration management system on the basis of this similarity check outputting a so- called all checks passed (ACP) assessment.17. A system for uploading firmware, in particular for executing a method of uploading firmware a in accordance with any of the preceding clauses, the system comprising one or more devices, each with at least one end node (EN), and a central server (CS) electronically registering identities of said at least one end node (EN) and set up for identifying andauthenticating any end node (EN), utilizing e.g. web-based electronic communication means, an end node (EN) provided with firmware (FW) and electronic micro processing hardware (MCU) for executing certain functionality of the end node (EN), as well as with means enabling electronic communication with a the central system (CS), the system further comprising a configuration management system (CMS) registering end node identities in conjunction with information on installed firmware in dependence of the end node identity, the system set up for uploading firmware in a targeted manner, the configuration management arranged for transmitting a challenge (CW) to an end node (EN) and for receiving a response word or authentication tag (AT) from the end node, the management system (CMS) arranged to communicate said response (AT) to the central server (CS), the latter, on the basis of the thus received response (AT) arranged for communicating an authentication test result to the configuration management system (CMS), the latter preferably set up to release a firmware version to the targeted end node, in dependence of the thus identified and authenticated end node (EN).18. A device (CED) comprising one or more end nodes (EN), with at least one end node provided with a preferably immutable, unique identification token (INT), the end node (EN) and / or the device (CED) provided with firmware (FW) and electronic micro processing hardware (MCU) for executing certain functionality of the device and / or the end node (EN), and an end node token (INT) comprising an electronically readable, preferably immutable unique identity (TID), the end node set up for enabling electronic communication with a remote controller, the end node (EN), in particular the end node token (INT) further provided with a so called MAC- or token hash-based message authentication code algorithm (THMAC), for calculating a message authentication tag (AT) to be communicated by the end node (EN), the end node token (INT) arranged for performing said calculation, in particular for identifying and authenticating firmware versions, more in particular in accordance with any of the preceding clauses.19. A device (CED) in accordance with the preceding clause, in which the end node token (INT) is arranged for performing both a machine authenticating code, MAC, and an identification function, thereto comprises a MAC (THMAC), is arranged for releasing a unique ID code (TID), in particular for identification of the end node, and for calculating a response word or authentication tag (AT) when provided with a challenge word (CW), in particular therein relying on direct or indirect cooperation with a central server (CS) having registered the THMAC function used by the end node token (INT) with said identity (TID).

Claims

CLAIMS1. A method for authenticating a first firmware at an end node device (CED) with respect to a second firmware at a network, the end node device (CED) comprising at least one end node (EN) in the network, wherein the method comprises: generating by the end node device a first hash value of the first firmware; generating by the end node device a first authentication tag from the first hash value, using a token hash-based message authentication code, THMAC, algorithm that belongs to the end node device and uses an end node device-specific symmetric key; generating by the network a second hash value of the second firmware; generating by the network a second authentication tag from the second hash value, using a server hash-based message authentication code, SHMAC, algorithm that corresponds to a unique identity of the end node device and uses the same end node devicespecific symmetric key; determining whether the first and second authentication tag are identical, thereby authenticating the first firmware with respect to the second firmware.

2. The method of claim 1, wherein the THMAC algorithm is comprised within an immutable token in the end node device, wherein the immutable token further comprises the unique identity of the end node device, and the symmetric key used by the THMAC algorithm, preferably wherein the immutable token is a hardcoded integrated circuit, IC, more preferably wherein the immutable token is a hardcoded integrated circuit, IC, without non-volatile memory.

3. The method of claim 1 or 2, wherein the method further comprises: receiving at the end node device the first firmware and the second authentication tag from the network, wherein the first firmware is a transmitted copy of the second firmware from the network to the end node device; wherein the step of determining whether first and second authentication tag are identical is performed at the end node device, thus authenticating the first firmware received at the end node device.

4. The method of claim 3, wherein the step of determining further comprises generating an authentication result, which comprises information as to whether or not the firmware received at the end node device was authenticated; and wherein the method further comprises: transmitting from the end node device to the network the authentication result.

5. The method of claim 3 or 4, wherein the second firmware is encrypted by the network using an ephemeral key outputted by the SHMAC algorithm before transmission to the end node device, and wherein the encrypted first firmware is decrypted by the end node device using the same ephemeral key outputted by the THMAC algorithm, wherein preferably the SHMAC and THMAC algorithm generate the ephemeral key based on the hash value of the second and first firmware respectively; and wherein in the case that the network transmits the encrypted first firmware, the network also transmits to the end node device the hash value of the second firmware.

6. The method of claim 5, wherein after successful decryption of the encrypted first firmware, the end node device determines whether the hash value of the second firmware received from the network and the hash value of the decrypted first firmware match.

7. The method of any one of the preceding claims, wherein the method further comprises: generating a number-used-once, nonce, at the network; transmitting the nonce from the network to the end node device (CED), wherein the step of generating the first hash by the end node device is done based on the received nonce and the first firmware and wherein the step of generating the second hash by the network is done based on the nonce and the second firmware; transmitting the first authentication tag (AT) from the end node device (CED) to the network; wherein the second firmware corresponds to a firmware registered for the end node device;wherein the step of determining whether first and second authentication tag are identical is performed at the network, thus authenticating the firmware registered for the end node device.

8. The method of any one of the preceding claims, wherein the end node device is furthermore authenticated by the network, using the following steps: outputting an identity (ID) from the end node device (CED) to the network, uniquely identifying the end node device (CED), preferably an immutable identity, more preferably an immutable and unique token identity code; verifying by the network whether the identity (ID) is valid; receiving, by the end node device (CED), a identification challenge word (CW) from the network, if the network has verified that the identity (ID) is valid; calculating by the end node device (CED) an identification authentication tag (AT) using the THMAC algorithm, based on the challenge word (CW); outputting the identification authentication tag (AT) to the network; determining the integrity and validity of the identification authentication tag (AT).

9. The method of claim 8, wherein the integrity and validity of the authentication tag (AT) is determined using the identity (ID) and the SHMAC algorithm of the network corresponding to the identity (ID), wherein preferably the challenge word (CW) is used as input to the SHMAC algorithm to generate a control authentication tag, which is compared with the identification authentication tag received from the end node device; and more preferably wherein the challenge word (CW) is a number-used-once, nonce.

10. The method of claim 8 or 9, wherein before the identity (ID) is outputted to the network, the firmware upload is initiated by the network, preferably by receiving at the end node device an identity request (RID) from the network; or wherein the authentication of the end node device is initiated by the end node device.

11. The method of any one of claims 8-10, wherein the firmware that is sent to the end node device is targeted to the end node device (CED) such that a version or content of thefirmware received is dependent on the identity (ID) transmitted from the end node device to the network.

12. The method of any one of the preceding claims, wherein the network has a private key part of a public-private key pair, wherein the corresponding public key is comprised in the end node device, and wherein the network digitally signs one or more messages sent to the end node device with the private key; and wherein the end node device checks whether the signature of the network is correct by using the public key.

13. The method of any one of the preceding claims, wherein the network comprises a central server, and a configuration management system, wherein the central server (CS) is used for identifying and authenticating identities (ID) and wherein configuration management server (CMS) for registering and releasing firmware (FW), preferably wherein the central server and configuration management server are separate entities, more preferably wherein the central server is related to one or more clients and wherein the configuration management server is related to one or multiple end node devices of a particular client.

14. The method of claim 7, wherein the firmware registered for the end node device is a firmware which the network has previously transmitted to the end node device and which the network has registered as being the firmware which is installed on the end node device, preferably wherein the firmware registered for the end node device is registered together with the identity obtained from the method of claim 8, more preferably wherein the registration is at the configuration management system of claim 13, more preferably: wherein the step of determining whether the first and second authentication tag are identical provides a verification outcome; transmitting the verification outcome to the configuration management system and if the verification is successful, registering at the configuration management system a version of the firmware installed on the end node device together with the identity of the end node device.

15. An end node device (CED) providing an end node of a network, comprising: processing hardware (MCU) for executing certain functionality of the device and / or the end node (EN); an end node token (INT) comprising an electronically readable, preferably immutable unique identity (TID), a token hash-based message authentication code, THMAC, algorithm and a symmetric key used by the THMAC algorithm, preferably wherein the end node token is a hardcoded integrated circuit, IC, more preferably wherein the immutable token is a hardcoded integrated circuit, IC, without non-volatile memory; a memory comprising firmware; wherein the end node device is configured to communicate with the network using the end node, in particular wherein the THMAC algorithm is used for calculating a message authentication tag (AT) to be communicated by the end node (EN), the end node token (INT) arranged for performing said calculation, in particular for identifying and authenticating firmware versions, preferably in accordance with any of the preceding claims.

Images