Password flexibility

Abstract

A method for updating a device, comprising: receiving, by the device, a common one-time signature key; receiving, by the apparatus, a secret encryption key; receiving an encrypted update package and a signature from an update provider; validating the signature using the common one-time signature key; decrypting the encrypted update package using the secret encryption key; and updating the device using the decrypted update package.

Description

Technical Field

[0001] Various exemplary embodiments disclosed herein relate to cryptographic flexibility. Background Art

[0002] The field of quantum computing has recently seen significant progress, with significantly increased attention focused on designing and implementing cryptographic schemes that are resistant to attacks from sufficiently powerful quantum computers. These worldwide efforts have led to the development of a number of candidate schemes based on mathematical assumptions that are believed to avoid some of the cryptanalytic speedups that occur when using quantum computing. These secure post-quantum cryptography (PQC) schemes are generally much less mature than today's widely deployed cryptography, such as ECC and RSA, and as a result, these candidate PQC schemes do not achieve the same level of confidence (in terms of their security) as existing classical algorithms. Summary of the Invention

[0003] A summary of various exemplary embodiments is presented below.

[0004] Various embodiments relate to a method for updating a device, comprising: receiving a public one-time signing key by the device; receiving a secret encryption key by the device; receiving an encrypted update package and a signature from an update provider; verifying the signature using the public one-time signing key; decrypting the encrypted update package using the secret encryption key; and updating the device using the decrypted update package.

[0005] Various embodiments are described, additionally including: provisioning a secret seed to a device; and reserving code space in the device for generating a key using the secret seed.

[0006] Various embodiments are described, additionally including: provisioning code to run a one-time signature verification in a device.

[0007] Various additional embodiments relate to a method for updating a device by an update provider, comprising: sending a public one-time signing key by the update provider to the device; sending a secret encryption key by the update provider to the device; encrypting an update package using the secret encryption key; generating a signature of the encrypted update package using the secret one-time signing key; and sending the encrypted update package and the signature to the device.

[0008] Various additional embodiments relate to a method for updating a device, comprising: receiving, by the device, a first public one-time signature key and a second public one-time signature key; receiving, by the device, a secret encryption key; receiving an update mode message and a first signature; verifying the first signature using the first one-time signature key; receiving an encrypted update package and a second signature from an update provider; verifying the second signature using the second public one-time signature key; decrypting the encrypted update package using the secret encryption key; and updating the device using the decrypted update package.

[0009] Various embodiments are described, additionally including receiving code from an update provider to run a one-time signature verification.

[0010] Various additional embodiments relate to a method for updating a device by an update provider, comprising: sending a first public one-time signature key and a second public one-time signature key to the device; sending a secret encryption key to the device; generating a first signature of an update mode message using a first secret one-time signature key corresponding to the first public one-time signature key; sending the update mode message and the first signature to the device; encrypting an update package using the secret encryption key; generating a second signature of the encrypted update package using a second secret one-time signature key corresponding to the second public one-time signature key; and sending the encrypted update package and the signature to the device.

[0011] Various additional embodiments relate to a method for requesting a certificate by an updated device, comprising: receiving a public certification center signing key by the updated device; receiving a secret one-time signing key by the device; generating a new updated device secret key and public key; generating a signing request for the new updated device public key; generating a first signature for the signing request using the secret one-time signing key; sending the signing request and the first signature to a certification center; and receiving a certificate from the certification center, the certificate including the signature of the certificate.

[0012] Various embodiments are described, additionally including: provisioning a secret seed to a device; and reserving code space in the device for generating a key using the secret seed.

[0013] Various embodiments are described, additionally including: provisioning code to run a one-time signature verification in a device.

[0014] Various embodiments are described in which the first signature is based on a secret certification authority signing key.

[0015] Various additional embodiments relate to a method for generating a certificate for an updated device, comprising: sending a public certification center signing key to the updated device; sending a secret one-time signing key to the updated device; receiving a certificate request for the new updated device public key and a first signature for the certificate request from the device, wherein the first signature is based on the secret one-time signing key; verifying the first signature and the certificate request; generating a certificate for the new updated device public key using the secret certification center signing key corresponding to the public certification center signing key, the certificate including a signature of the certificate; and sending the certificate and the second signature to the updated device.

[0016] The foregoing has been a fairly general overview of the features and technical advantages of the examples disclosed herein so that the following specific embodiments may be better understood. Additional features and advantages will be described hereinafter. The disclosed concepts and specific examples may be readily used as a basis for modifying or designing other structures for carrying out the same purpose of the present disclosure. Such equivalent constructions do not depart from the scope of the appended claims. The characteristics of the concepts disclosed herein (both their organization and method of operation) together with the associated advantages will be better understood from the following description when considered in conjunction with the accompanying drawings. Each of the figures is provided for the purpose of illustration and description and is not intended to limit the boundaries of the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order that the above-described features of the present disclosure may be understood in detail, a more particular description, briefly summarized above, may be made by reference to various aspects, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings illustrate only certain typical aspects of the present disclosure and, therefore, should not be considered as limiting the scope of the present disclosure, as the description may admit of other equally effective aspects. The same reference numerals in different figures may identify the same or similar elements.

[0018] Figure 1 The impact of the update mechanism on the device to be updated and the overall process of a one-time critical update are shown.

[0019] Figure 2 A secondary update system and method is shown.

[0020] Figure 3 Describes the process of attesting and requesting certification for new keys or credentials.

[0021] Figure 4 Shown for implementing Figure 1-3 An exemplary hardware diagram of the updater system described in . DETAILED DESCRIPTION

[0022] Various aspects of the present disclosure are described more fully below with reference to the accompanying drawings. However, the present disclosure can be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout the present disclosure. In fact, these aspects are provided so that the present disclosure will be thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. Based on the teachings herein, those skilled in the art will understand that the scope of the present disclosure is intended to cover any aspect of the disclosure disclosed herein, whether implemented independently of or in combination with any other aspect of the disclosure. For example, any number of aspects set forth herein may be used to implement an apparatus or practice a method. In addition, the scope of the present disclosure is intended to cover such an apparatus or method practiced using other structures, functionalities, or structures and functionalities in addition to or different from the various aspects of the disclosure set forth herein. It should be understood that any aspect of the disclosure disclosed herein may be embodied by one or more elements of the claims.

[0023] Several aspects of cryptographic systems and methods will now be presented with reference to various devices and techniques. These devices and techniques will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as "elements"). These elements can be implemented using hardware, software, or a combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0024] The field of quantum computing has recently seen significant progress, with significantly increased attention being paid to designing and implementing cryptographic schemes that are resistant to attacks from sufficiently powerful quantum computers. This worldwide effort has led to the development of a number of candidate schemes based on mathematical assumptions that are believed to avoid some of the cryptanalytic speedups that occur when using quantum computing. These secure post-quantum cryptography (PQC) schemes are generally much less mature than today's widely deployed cryptography, such as ECC (elliptic curve cryptography) and RSA (Rivest-Shamir-Adelson), and therefore these candidate PQC schemes do not achieve the same level of confidence (in terms of their security) as existing classical algorithms.

[0025] Deploying post-quantum cryptography is fraught with challenges: increased memory / bandwidth requirements for the schemes, a lack of drop-in replacements for some protocols, and difficulty ensuring backward compatibility, to name a few. The relative lack of confidence in the security of PQC schemes means that many vendors may want to develop contingency plans in the event that one or more of these new schemes suffers a new breakthrough in cryptanalysis.

[0026] In this disclosure, a method for securely executing a critical update procedure is described in which one or more cryptographic algorithms, including the cryptographic algorithms supporting the update procedure itself, are replaced in a manner that incurs low overhead in terms of storage and bandwidth through the use of one-time signatures. To augment this process, several additional elements are described that can optionally be used with the present invention to smooth the transition process, including increasing flexibility by enabling multiple critical updates, certifying newly generated keys, directing the critical update mechanism to securely load data into non-volatile memory, and thwarting advanced attackers who attempt to compromise the device before the update is provided.

[0027] Recent significant advances in quantum computing have accelerated the search for PQC schemes, which consist of cryptographic algorithms that run on classical computers but are believed to remain secure even in the presence of an adversary with access to a quantum computer. This demand is driven by interest from standardization bodies, such as the National Institute of Standards and Technology (NIST)'s call for proposals for new public-key cryptography standards. The first selection process for new cryptographic standards has concluded, and the lattice-based schemes Kyber, Dilithium, and FALCON, as well as the hash-based scheme SPHINCS+, have been selected by NIST as future standards for post-quantum cryptography. Stateful hash-based schemes XMSS and LMS, along with their multi-tree variants, were previously standardized by NIST.

[0028] In addition to the standardized or selected schemes, the code-based schemes BIKE, HQC, and classic McEliece remain candidates for selection by NIST for future PQC algorithms.

[0029] The migration from quantum-vulnerable cryptography, such as ECC / RSA, to PQC is driving a growing awareness of the benefits of cryptographic agility, broadly defined as ensuring that cryptographic algorithms and protocols can be promptly replaced with other functionally equivalent components. The systems and methods described herein are motivated by the potential need to replace vulnerable current cryptographic schemes or vulnerable PQC schemes, but can be used to update any cryptographic component based on the system's urgent functional needs. Specifically, they ensure the integrity (and, if necessary, confidentiality) of code updates to replace cryptographic component algorithms in a very timely manner, thereby reducing the potential attack window for capable adversaries.

[0030] The number of PQC schemes under consideration for deployment is substantial compared to past NIST standardization efforts and drives the need for cryptographic flexibility in the design of new secure systems and devices. A specific difficulty with flexibility and migration to post-quantum cryptography relates to the risk of disruption or significant improvements in the cryptanalysis of deployed schemes. This is illustrated by the recent disruptions of the Rainbow digital signature scheme and the SIKE key encapsulation mechanism: both were candidates for late-stage NIST selection. It is crucial to prepare for the eventual disruption of schemes in use and to design mechanisms that allow vulnerable devices and processes to recover from or securely update or replace a disrupted cryptographic scheme with a non-vulnerable one.

[0031] A key challenge with this mechanism for embedded / field devices is that cryptography (specifically digital signatures) is the cornerstone of the security of any update. Therefore, if the cryptographic scheme used to verify the integrity (and potentially confidentiality) of the update is itself vulnerable, this challenge becomes a "chicken and egg" problem: if the cryptographic scheme the device has been programmed to use is vulnerable, how can we update the device to use a non-vulnerable cryptographic scheme? Beyond this primary challenge, many questions remain, such as, if the device's cryptographic keys or the scheme it was programmed to use are compromised, how can the device prove that any newly generated keys can be used with a non-vulnerable scheme? How can a user detect not only if a key has been compromised, but also if the device has been compromised (meaning that an attacker has managed to gain control of the device before a security update is deployed to patch any vulnerabilities)? The update system and method described herein aims to address the primary challenge of maintaining security without relying on vulnerable cryptography, while also addressing some of the additional challenges of cryptographically agile transitions.

[0032] The goal of the updater system and method is to allow a device to be updated after its implemented cryptographic scheme has been compromised. Updates in this specific context will be referred to as critical updates. The updated system and method described herein perform such critical updates without using the device's conventional update mechanism, which relies on vulnerable cryptography. The disclosed update system and method only marginally impacts the footprint of the update mechanism on the device.

[0033] The updater system and method are based on the following features.

[0034] The use of a one-time signature (OTS) to perform a one-time critical update is proposed and described. The first benefit of this method is its small footprint on the device. Only a 56-byte OTS public key and a small code size are provided on the device to perform the verification of the signature of the critical update. The verification mainly consists of calling hash functions, which are already implemented on the device in many cases. The second benefit is that it relies on the security of hash functions that are not known to be vulnerable to quantum computers. This first feature authenticates and protects the integrity of the update. In addition, thanks to this feature, a new OTS public key can be sent and signed as part of the update. Therefore, it is possible to reuse a very simple OTS signature scheme without the need to implement a fully mature hash-based signature algorithm.

[0035] The use of symmetric keys, provisioned on the device, to encrypt and decrypt one-time critical updates is proposed and described. In standard scenarios, asymmetric key establishment is preferred for encrypted updates. However, in the specific case of critical updates, to avoid man-in-the-middle attacks or sending update packages in clear text, it is recommended to rely on symmetric keys reserved solely for this purpose. Similarly, a smaller footprint, such as a 32-byte key, and a symmetric encryption algorithm, such as the Advanced Encryption Standard (AES), are often already present on the device.

[0036] The two previous features can be combined into a single mechanism or used independently of each other. Signatures are generally critical for secure updates (for original entity authentication and data integrity), but the second feature can be omitted if confidentiality of the update is not required. Other extensions and options for the two previous features are discussed later in this disclosure. Ultimately, once the updater system and mechanism described in this disclosure are executed to deploy updates, the derivation of new secret key material for the replacement scheme can be performed according to the seed updater described in U.S. patent application No. 18 / 183,310, entitled "METHOD FOR POST-QUANTURN SECURE IN-THE-FIELDTRUST PROVISION," filed on March 14, 2023 (the '310 application), the contents of which are incorporated herein by reference for all purposes. To make the transition to the replacement algorithm smoother, three additional mechanisms for the one-time signing process for critical updates are further described below.

[0037] First, once a device generates new keys for a replacement scenario, it needs to certify these new keys. By certifying these keys by linking them to the device's identity, the relevant certification authority (CA) can generate a certificate for the device's new keys. Thanks to another feature of the present invention, this can be achieved by once again leveraging the OTS. The device can be provisioned with an OTS secret key, which serves the sole purpose of certifying its new keys after a key update. The device will request a certificate from the CA, which is later used to communicate with other devices or services when authenticating the device.

[0038] Second, the one-time signed code used in the critical update process can be used as a building block for authenticating the loading of data into non-volatile memory during the manufacturing process. The idea is to use a stateful hash-based signature scheme such as LMS to authenticate the loaded data, which uses the LM-OTS component for critical updates as a subroutine (this can be done similarly for XMSS and its subroutine WOTS).

[0039] The third described feature of the present disclosure involves detecting compromised devices between the interruption of the cryptographic scheme in use and the deployment of a critical update. The idea is to use a tamper-resistant, monotonically increasing counter to track update versions. Even if an adversary has compromised the signing key used to authenticate device updates, the adversary cannot compromise the counter, so any unauthorized software update will advance the counter, and any subsequent critical updates will be rejected.

[0040] Figure 1 The impact of the update mechanism on the device to be updated and the overall process of a one-time critical update are shown. Figure 1 Shown is a device 105 and an update provider (UP) 110. SK and PK refer to a secret key and a public key, respectively. Figure 1Starting at the top, standard update keys 115 include a key pair (UP.SK.Sig, UP.PK.Sig) for standard updates or updates before enabling critical update mode. Multiple key pairs can be used for hybrid post-quantum cryptography purposes, i.e., combining two or more schemes, typically one traditional scheme and one post-quantum secure scheme. To keep the description of the updater system and method simple and clear, only one key pair (UP.SK.Sig, UP.PK.Sig) is included and referenced, but additional key pairs may be used. The key pair (UP.SK.Sig, UP.PK.Sig) can be ECC, RSA, Dilithium, LMS, XMSS, or SPHINCS+ keys, or any other public key cryptography protocol keys, including non-PQC and PQC protocols. The secret key D.SK.Kex is also provisioned in the device 105, and the public key D.PK.Kex is held by the update provider 110. The corresponding key pair (D.SK.Kex, D.PK.Kex) can be ECC, RSA, or Kyber keys, or any other public key cryptography protocol key, including non-PQC and PQC protocols. This key pair is used to perform key establishment to derive a shared symmetric key to encrypt the update.

[0041] Next, the previously mentioned seed updater mechanism proposed in the '310 application can be used to supply additional secret seeds to the device to derive keying material for any new cryptographic scheme that the device is updated to use at some point. Other methods for thus updating keying material can also be used. In addition, some code space is reserved for key generation. Note that these seeds can be used to derive keying material for more than one scheme, for example by using a key derivation function or an extensible output function with appropriate labeling and domain separation.

[0042] Next, Figure 1The required settings for key update mode 125 are shown. UP 110 generates an OTS key pair (UP.CU.SK.OTS, UP.CU.PK.OTS) which will be used for the purpose of a one-time key update. The public key UP.CU.PK.OTS and the OTS verification code are provisioned on the device 105 to verify the signature of the key update. One option for implementing this OTS is to use the Leighton-Micali One-Time Signature (LM-OTS) described in RFC 8554 of the IRTF. In this example, UP.CU.PK.OTS comprises 56 bytes, but using other key formats or schemes may result in different key sizes. The verification code has very little impact on the device because it utilizes a hash algorithm already present on the device 105 and simply calculates a checksum and hash chain. The symmetric encryption key D.CU.SK.ENC is provisioned on the device 105 to decrypt the update. This key D.CU.SK.ENC can be the same for all devices, or unique for each device, or diversified depending on device family, user, or other aspects (ie, the same key is used for a particular group, but the key is different for each group).

[0043] When a critical update is required to replace a vulnerable cryptographic scheme with a non-vulnerable one 130, the update provider 110 first encrypts the update package using the same symmetric key D.CU.SK.ENC as on the target device. The command to enable one-time critical update mode, along with the update package, is then signed using the OTS secret key UP.CU.SK.OTS. This is done to authenticate the update mode command (which initiates a critical update for the target device), as the device would not want to enter this mode if prompted from an illegitimate source. Finally, once the device receives the update mode indication and the update, the first step in the critical update mechanism is to verify the signature using UP.CU.PK.OTS. Only if the signature is verified does the critical update process continue, and the update package is decrypted using D.CU.SK.ENC; otherwise, the device aborts the update.

[0044] Depending on which update schemes are implemented on the device and the specific reason for a future critical update, the exact replacement cipher scheme may be difficult to predict. Consequently, more time may be required to create the update code. In this case, the device will most likely need to perform any updates without using vulnerable cryptography. Furthermore, it may be beneficial to prompt the device to stop using any vulnerable cryptography for critical applications. This choice is left to the device owner.

[0045] The updated system and mechanism disclosed herein can handle the previous situation by performing a two-level update. This requires provisioning two OTS public keys. The OTS2 first public key is used to authenticate a dedicated system message to enable critical update mode and disable any updates that use vulnerable cryptographic schemes, and the second public key is used to authenticate the final valid update package. Figure 2 A two-level update system and method is shown. Likewise, the steps taken after the device has received the command are up to the device owner and are outside the scope of this disclosure.

[0046] To simplify the previous description and diagrams, a single one-time update or a two-level process was considered. These proposed mechanisms can be extended to accommodate multiple updates. Because the present disclosure deals with the specific case of critical updates, it is expected that the number of such updates will be small. Considering the goal to handle m such updates, since the OTS secret key can only sign a single message, the previous mechanism can be extended by supplying m UP.CU.PK.OTS keys to the device. This corresponds to 56m bytes for the public verification key, but the same code impact as the case of only a single update. Note that although 56-byte keys are used for illustration, keys of other sizes can also be used.

[0047] Another option to avoid supplying all OTS public keys is to build a small hash tree with m leaves (for example, to accommodate m = 8 critical updates, a small hash tree of height h = 3 can be built). This allows signing m updates while only supplying a single 56-byte public key. However, this increases the size of the update signature and the complexity and code size of its verification. m = 8 OTS keys can be used to sign both the command to enable critical mode and the update package.

[0048] Naturally, devices that already implement hash-based signatures for standard updates can simply use the same hash tree. In this ID, we are primarily concerned with devices that do not implement full-fledged hash-based signatures such as LMS, XMSS, or SPHINCS+, or if standard updates do not use hash-based signatures due to, for example, statefulness, impossibility of key backup, overhead issues, or any other practical or technical reasons.

[0049] First, the update provider 210 generates two OTS secret keys, UP.CU.SK.OTS1 and UP.CU.SK.OTS2, and then provisions the corresponding public keys, UP.CU.PK.OTS1 and UP.CU.PK.OTS2, on the device 205. The symmetric secret key D.CU.SK.ENC is also provisioned on the device 205 and the update provider 210. Code to run OTS authentication is also provisioned on the device 205.

[0050] Next, at 220, critical mode is enabled and the use of any vulnerable cryptography for updates is disabled. The update provider generates a signature, Signature1, using the secret key UP.CU.SK.OTS1. At 230, the update provider 210 sends an update mode command and Signature1 to the device 205. The device 205 uses Signature1 and the key UP.CU.PK.OTS1 from the update provider 210 to verify receipt of the update mode command.

[0051] Once Signature1 is verified, the critical update is installed at 225. Update Provider 210 prepares the update package, EncPackage, by encrypting it using the secret key UP.CU.SK.ENC. Update Provider 210 also generates Signature2 using the encrypted package, EncPackage, and the secret key UP.CU.SK.OTS2. At 235, Update Provider 210 sends the encrypted package, EncPackage, and Signature2 to Device 205. Device 205 verifies Signature2 using the public key UP.CU.PK.OTS2. Device 205 then decrypts EncPackage using the secret key D.CU.SK.ENC to produce Package, which is then installed on Device 205.

[0052] Next, we describe a mechanism for refreshing the symmetric encryption key D.CU.SK.ENC. This is useful if you don't want to reuse the same symmetric key for all critical updates. This refresh involves deriving a new symmetric key from D.CU.SK.ENC and a random secret value r encrypted with the first update using a function F, as follows:

[0053] D.CU.SK.ENC=F(D.CU.SK.ENC,r).

[0054] This new key overwrites the previous D.CU.SK.ENC. Function F requires efficient computation (F) and is difficult to invert (F -1 ), which means that good candidates for use are hash functions such as SHA-2 and SHA-3, and key derivation functions such as HKDF, but other one-way functions that can be calculated within the processing constraints of the device can also be used. This solution provides forward secrecy of updates. If the current D.CU.SK.ENC key is recovered by an attacker, the confidentiality of previous updates is maintained due to the one-way property of the function.

[0055] This mechanism introduces operational challenges when updates are delivered "offline" (meaning they are broadcast or published somewhere for devices to retrieve). In this case, the server entity providing updates cannot ensure that all devices have received the critical update before broadcasting / publishing the next update package, which in turn means the server cannot be certain that all devices have moved on from the previous value of D.CU.SK.ENC. The solution is for each update package to include not only the required r value but also all previous values ​​of r that have been used. Any device can then perform the correct number of iterations of F with the appropriate r value to obtain the most recent symmetric key.

[0056] Next, we'll describe how to authenticate the new credentials. As already mentioned, the seed updater mechanism can be used to generate secret keying material for the replacement scheme. However, for compliance or other reasons, the device may need to randomly generate its own keys for the replacement scheme. In this case, the device needs to distribute its new public key and prove to the server and other devices in its network that it is, in fact, the same device as before (but with a new key). To prevent impersonation attacks, this can be done using an authentication mechanism, where a secure environment generates a cryptographic signature of certain device details (including its identifier).

[0057] In the event that this signature scheme has become vulnerable, it is possible to securely transmit an authentication request using the provisioned symmetric key D.CU.SK.ENC to sign the new public key: the server will then respond with a certificate for the new public key. The problem here is that this only works if the update provider is the same entity that signed the operational credentials (or the credential signing entity is trusted by these symmetric keys).

[0058] An alternative approach is for the device to sign a new public key (and device identifier, etc.) using a one-time signature scheme, thereby proving new credentials in a secure manner. This option requires that the appropriate server entity holds a one-time public key associated with the OTS signing key. If this option is enabled, this OTS signing key can be derived from a single seed, as described above. Figure 3 Describes the process of proving and requesting certificates for new keys or credentials. This mechanism can have a single seed used to derive OTS secret keys and symmetric keys.

[0059] At 315, the Certificate Authority public key may be updated on the device during a critical update. Device 305 has the public key CA.PK of Certificate Authority 310 provisioned therein. Certificate Authority 310 stores its secret key CA.SK. At 320, the Seed Updater provisions the seed for key generation and reserves code space on device 205. Next, at 325, the OTS secret key D.NCA.SK.OTS and code to run the OTS signing process are provisioned on device 205. The public key D.NCA.PK.OTS is also provided to Certificate Authority 310.

[0060] At 330, a critical one-time update is enabled, and device 305 generates new keys. Furthermore, device 305 creates a signed certificate request for its new credentials using secret key D.NCA.SK.OTS, proving its identity. At 340, device 305 sends the request and signature to authentication center 310. At 335, authentication center 310 verifies the identity and status of the device, then creates a certificate for device 305 certifying its new public key. At 345, authentication center 310 sends certificate D.Cert to device 305.

[0061] Initial NVM loading in manufacturing with post-quantum security will now be described. The same update mechanism described above for critical updates can also be used for the initial non-volatile memory (NVM) initialization of a device during manufacturing. At this point, the device contains only valid immutable read-only memory (ROM) contents, which, in addition to basic functionality, also holds a limited-time signature verification scheme, load / update code, and initial verification and decryption keys. In many currently deployed solutions, this integrity check is performed using symmetric cryptography or traditional digital signature algorithms such as ECDSA (where the encryption key or ECDSA verification key is loaded into ROM). In the first case, compromise of one device allows the adversary to load arbitrary software into all devices (sharing a symmetric key), and in the second case, the program is vulnerable in the presence of a quantum computer. To avoid these two drawbacks, integrity protection can be provided by a hash-based signature scheme, for which a one-time signature subcomponent is already installed in the critical update module: for example, if LM-OTS and WOTS are respectively in the critical update module, the OS load can be signed with LMS or XMSS. In addition to conservative post-quantum security, the benefit of this approach is a reduction in ROM code size compared to separate signature verification algorithms for OS loading and critical updates. Asymmetric signatures will be used to authenticate the (initial) loader and for integrity protection of the loaded content. Confidentiality protection will be retained in the symmetric cryptography. After the initial content is loaded, the initial immutable key can be exchanged with the key loaded in the modifiable (RAM / NVM) memory and can be changed multiple times within a single loader.

[0062] Detecting compromise during the critical update loading process will now be described. The critical update concept is described as a mechanism for replacing schemes disrupted by new cryptanalytic attacks or the invention of sufficiently powerful quantum computers, which makes it possible for a device to be compromised by an adversary between the breakthrough and deployment of a critical update. Thus, such an adversary who can disrupt existing update cryptography (specifically, by calculating a secret signing key from a public verification key) can gain full access to the device by installing its own software or firmware update. This makes it important to be able to detect the loading of such unauthorized updates whenever possible, and simply abort the update process if such an update is detected.

[0063] One approach to detecting updates is to store a tamper-proof, monotonically increasing counter that captures which update version the device currently holds. The counter itself can be stored in fuses, while the code for this mechanism can be in ROM: this way, an adversary (even one with access to the cryptographic keying material for the update mechanism) cannot restore this counter to its previous value. When a critical update is loaded, if the counter value is higher than the value that the update initiator has declared, the device will not install the critical update and will report this failure to the system manager so that the device can be marked as compromised and removed from use. Instead of a counter, the device can also provide more detailed feedback, including, for example, a hash of its current software version and update history, as long as this information cannot be forged by an adversary who has gained control of the device. This flexible / modular approach can be used to provide an indication of a device's post-quantum readiness.

[0064] Figure 4 Shown for implementing Figure 1-3 4. Exemplary hardware diagram 400 of the updater system described in . Exemplary hardware 400 may correspond to device 105, 205, 305, update provider 110, 210, or certification authority 310. As shown, device 400 includes a processor 420, memory 430, user interface 440, network interface 450, and storage device 460 interconnected via one or more system buses 410. It should be understood that in some aspects, Figure 4 The diagram is abstracted and the actual organization of the components of apparatus 400 may be more complex than shown.

[0065] Processor 420 can be any hardware device capable of executing instructions stored in memory 430 or storage device 460 or otherwise processing data. Thus, the processor can include a microprocessor, a microcontroller, a graphics processing unit (GPU), a neural network processor, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or other similar devices. The processor can be a secure processor or include a secure processing portion or core that is tamper-resistant.

[0066] Memory 430 may include various memories, such as L1, L2, or L3 cache or system memory. Thus, memory 430 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read-only memory (ROM), or other similar memory devices. Furthermore, some or all of the memory may be secure memory with limited authorized access and tamper-resistant.

[0067] The user interface 440 may include one or more devices to enable communication with a user, such as an administrator. For example, the user interface 440 may include a display, a touch interface, a mouse, and / or a keyboard for receiving user commands. In some embodiments, the user interface 440 may include a command line interface or a graphical user interface that may be presented to a remote terminal via the network interface 450.

[0068] The network interface 450 may include one or more devices for enabling communication with other hardware devices. For example, the network interface 450 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol or other communication protocols (including wireless protocols). In addition, the network interface 450 may implement a TCP / IP stack for communicating according to the TCP / IP protocol. Various alternative or additional hardware or configurations for the network interface 450 will be apparent.

[0069] Storage device 460 may include one or more machine-readable storage media, such as read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, or similar storage media. In various embodiments, storage device 460 may store instructions for execution by processor 420 or data that processor 420 can operate on. For example, storage device 460 may store a basic operating system and application software 461 for controlling various basic operations of hardware 400. Storage device 462 may include instructions for implementing the functions of the updater system described herein.

[0070] It will be apparent that various information described as being stored in storage device 460 may additionally or alternatively be stored in memory 430. In this regard, memory 430 may also be considered to constitute "storage," and storage device 460 may be considered to be "memory." Various other arrangements will be apparent. Additionally, both memory 430 and storage device 460 may be considered to be "non-transitory machine-readable media." As used herein, the term "non-transitory" will be understood to exclude transitory signals and to include all forms of storage, including both volatile and non-volatile memory.

[0071] The system bus 410 allows communications between the processor 420 , memory 430 , user interface 440 , storage device 460 , and network interface 450 .

[0072] Although host device 400 is shown as including one of each described component, in various embodiments, various components may be repeated. For example, processor 420 may include multiple microprocessors configured to independently execute the methods described herein, or configured to execute steps or subroutines of the methods described herein, such that the multiple processors collaborate to implement the functionality described herein. Additionally, when device 400 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, processor 420 may include a first processor in a first server and a second processor in a second server.

[0073] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the aspects to the precise forms disclosed. Modifications and variations may be made in light of the above disclosure, or may be acquired from practice of the various aspects.

[0074] As used herein, the term "component" is intended to be broadly construed as hardware, firmware, and / or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, and / or a combination of hardware and software.

[0075] As used herein, satisfying a threshold value may refer to a value being greater than a threshold value, greater than or equal to a threshold value, less than a threshold value, less than or equal to a threshold value, equal to a threshold value, not equal to a threshold value, and so forth, depending on the context. It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, and / or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the aspects. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code—it being understood that software and hardware may be designed to implement the systems and / or methods based, at least in part, on the description herein.

[0076] As used herein, the term "non-transitory machine-readable storage medium" will be understood to exclude transitory propagating signals but to include all forms of volatile and non-volatile memory. When software is implemented on a processor, the combination of software and processor becomes a specific special-purpose machine.

[0077] Because the data processing to implement the embodiments described herein is largely comprised of electronic components and circuits known to those skilled in the art, circuit details will not be explained to any greater extent than deemed necessary as described above in order to understand and appreciate the basic concepts of the aspects described herein and in order not to obscure or detract from the teachings of the aspects described herein.

[0078] Unless otherwise stated, terms such as "first" and "second" are used to arbitrarily distinguish between the elements these terms describe. Therefore, these terms are not necessarily intended to indicate a temporal or other prioritization of such elements.

[0079] Those skilled in the art will appreciate that any block diagrams herein represent conceptual views of illustrative hardware embodying the principles of various aspects.

[0080] While each of the embodiments is described above in terms of its structural arrangement, it should be understood that the aspects also encompass the associated methods of using the above-described embodiments.

[0081] Unless otherwise indicated, all numbers used in this specification and claims expressing parameter values ​​and the like should be understood as being modified in all cases by the term "about". Therefore, unless otherwise indicated, the numerical parameters set forth in this specification and the appended claims are approximate values, which may vary depending on the desired properties that the embodiments of the present disclosure attempt to obtain. As used herein, "about" may be understood by one of ordinary skill in the art and may vary to some extent depending on the context in which it is used. If there is a use of a term that is unclear to one of ordinary skill in the art, "about" may mean up to ±10% of the particular term, taking into account the context in which the term is used.

[0082] Although specific combinations of features are described in the claims and / or disclosed in this specification, these combinations are not intended to limit the disclosure of each aspect. In fact, many of these features can be combined in a manner not specifically described in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of each aspect includes each dependent claim in combination with each other claim in the claim set. The phrase "at least one" mentioned in the list of items refers to any combination of these items, including single members. As an example, "at least one of the following: a, b or c" is intended to cover a, b, c, ab, ac, bc and abc, as well as any combination of multiples of the same element (for example, aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc and ccc, or any other arrangement of a, b and c).

[0083] Unless so explicitly described, none of the elements, actions, or instructions used herein should be construed as critical or essential. Also, as used herein, the article "a" is intended to include one or more items and can be used interchangeably with "one or more." Furthermore, as used herein, the terms "set" and "group" are intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, etc.) and can be used interchangeably with "one or more." Where only one item is intended, the phrase "only one" or similar language is used. Also, as used herein, the term "having" or similar terms are intended to be open-ended terms. Furthermore, unless otherwise explicitly stated, the phrase "based on" is intended to mean "based at least in part on."

Claims

1. A method for updating a device, characterized in that include: receiving, by the device, a public one-time signature key; receiving, by the device, a secret encryption key; receiving an encrypted update package and signature from an update provider; verifying the signature using the public one-time signature key; decrypting the encrypted update package using the secret encryption key; as well as The device is updated using the decrypted update package.

2. The method according to claim 1, characterized in that Also includes: supplying a secret seed to the device; and Code space is reserved in the device for key generation using the secret seed.

3. The method according to claim 1, characterized in that Also includes: Code is provisioned to run a one-time signature verification in the device.

4. A method for updating a device by an update provider, characterized in that include: sending, by the update provider, a public one-time signing key to the device; sending, by the update provider, a secret encryption key to the device; encrypting the update package using the secret encryption key; generating a signature for the encrypted update package using a secret one-time signing key; as well as The encrypted update package and the signature are sent to the device.

5. A method for updating a device, characterized in that include: receiving, by the apparatus, a first public one-time signature key and a second public one-time signature key; receiving, by the device, a secret encryption key; receiving an update mode message and a first signature; verifying the first signature using the first public one-time signature key; receiving an encrypted update package and a second signature from an update provider; verifying the second signature using the second public one-time signature key; decrypting the encrypted update package using the secret encryption key; as well as The device is updated using the decrypted update package.

6. The method according to claim 5, characterized in that Also includes: Receive code from the update provider to run a one-time signature verification.

7. A method for updating a device by an update provider, characterized in that include: sending a first public one-time signature key and a second public one-time signature key to the device; sending a secret encryption key to the device; generating a first signature for an update mode message using a first secret one-time signature key corresponding to the first public one-time signature key; sending the update mode message and the first signature to the device; encrypting the update package using the secret encryption key; generating a second signature for the encrypted update package using a second secret one-time signature key corresponding to the second public one-time signature key; as well as The encrypted update package and the second signature are sent to the device.

8. A method for requesting a certificate by an updated device, characterized in that include: receiving, by the updated device, a public certification authority signing key; receiving, by the updated device, a secret one-time signing key; generating new updated device secret and public keys; generating a signing request for the new updated device public key; generating a first signature for the signature request using the secret one-time signing key; Sending the signature request and the first signature to a certification center; as well as A certificate is received from the certification authority, the certificate including a signature of the certificate.

9. The method according to claim 8, characterized in that Also includes: supplying a secret seed to the updated device; as well as Code space is reserved in the updated device for key generation using the secret seed.

10. A method for generating a certificate for an updated device, characterized in that include: sending a public certification authority signing key to the updated device; sending a secret one-time signing key to the updated device; receiving, from the updated device, a certificate request for a new updated device public key and a first signature for the certificate request, wherein the first signature is based on the secret one-time signature key; verifying the first signature and the certificate request; generating a certificate for the new updated device public key using a secret certificate authority signing key corresponding to the public certificate authority signing key, the certificate including a second signature for the certificate; as well as The certificate and second signature are sent to the updated device.

Images