CN118591803A - Apparatus and method for secure booting using an authorized subkey - Google Patents

Abstract

A computing device incorporates a secure boot and an authorized sub-key pair based software image verification mechanism supported by a key generator that generates the authorized sub-key pair and an image signer that generates an encrypted secure software image. The improved software image includes an authorized sub-public key, a digital signature on the authorized sub-public key generated using a basic private key, program data, a digital signature on the program data generated using an authorized sub-private key, a new revocation bit, and a digital signature on the new revocation bit generated using the basic private key. The computing device verifies the new revocation bit, updates the current revocation bit, verifies the sub-public key according to the revocation bit and the basic public key, generates a verification public key according to the sub-public key and the basic public key, and verifies the program data according to the verification public key.

Description

Apparatus and method for secure booting using an authorized subkey

Technical Field

Aspects of the disclosed embodiments relate generally to computer security, and more particularly, to secure boot techniques.

Background

Secure booting is a mechanism that aims to ensure that a computing device can only be booted by authorized and trusted software. Secure launch is a multi-level process where the currently loaded component is responsible for authenticating and loading the next component. Modern computing devices are typically manufactured using components from multiple suppliers, creating a multi-partner ecosystem. The traditional code signature technical scheme cannot be well expanded in a large multi-partner ecological system.

One conventional approach relies on a public key infrastructure (public key infrastructure, PKI) in which each partner has a signing key that can be verified using certificates. These solutions are costly to implement and maintain. PKI-based solutions also require additional entities and complexities to support the creation and distribution of certificate revocation lists to support revocation of signature authority upon partners entering and leaving a multi-partner ecosystem. PKI-based solutions may also introduce additional overhead for software image metadata.

An original equipment manufacturer (original equipment manufacturer, OEM) may provide a signature server for a partner to sign its code modules, rather than delegate the signing authority to the partner. The code signing server exposes the attack vector and requires expensive infrastructure to provide high availability for a large number of providers.

Accordingly, there is a need for improved apparatus and methods to provide lightweight code signing schemes that readily support revocation signature authority. It is therefore desirable to provide methods and apparatus that address at least some of the problems described above.

Disclosure of Invention

Aspects of the disclosed embodiments relate to apparatus and methods for providing an improved secure launch solution for a multi-partner ecosystem. Aspects of the disclosed embodiments employ a signing technique based on authorized subkey pairs to avoid the overhead of the PKI infrastructure, can authorize signing capabilities, eliminate semantic gaps associated with HSM-based techniques, and reduce the amount of metadata required in software images.

The foregoing and other implementations and advantages are obtained, according to a first aspect, by an apparatus including a processor and a memory. The memory includes a software image including a sub-public key, a digital signature on the sub-public key generated using a base private key, program data, and a digital signature on the program data generated using the sub-private key. The processor is configured to verify the software image by verifying the sub-public key based on the digital signature on the sub-public key and the base public key. The processor calculates a verification key by applying a finite set of operations to the base public key and the sub-public key, and then verifies the program data based on the digital signature on the program data and the verification public key. The basic private key and the basic public key form a public-private key pair, and the sub-private key and the verification public key form a public-private key pair. The adopted signature technical scheme is based on an authorized sub-key pair so as to avoid the expenditure of PKI infrastructure, authorize signature capability, eliminate semantic gap associated with the HSM-based technical scheme and reduce the amount of metadata required in software image.

In one possible implementation, the apparatus includes a one-time programmable memory, the software image includes a new revocation bit, and a digital signature on the new revocation bit generated using the base private key. Verifying the software image includes: verifying the new revocation bit based on the digital signature and the base public key on the new revocation bit; updating a current revocation bit according to the new revocation bit, wherein the current revocation bit is stored in the one-time programmable memory; and verifying the sub-public key according to the updated current revocation bit. The inclusion of new revocation bits in the software image provides a reliable and efficient method of distributing revocation information to computing devices. Verifying the subpublic key from the revocation bits provides a trusted way to verify the software image and ensures that the image signed using the revoked subkey is not performed.

In one possible implementation, the one-time programmable memory includes an eFuse type memory, and updating the current revocation bit includes setting unset bits in the eFuse type memory and leaving the set bits in the current revocation bit unchanged. This feature of eFuse type memory may set bits and prevent reset bits, which may ensure that the current undo bit cannot be retired to an early version of the undo bit.

In one possible implementation, the sub-public key includes a plurality of least significant bits, wherein the plurality of least significant bits form an identification of the sub-public key and the plurality of least significant bits are equal to a predetermined bit pattern. Using the LSB portion of the sub-public key as the key identification facilitates the generation and maintenance of compressed key revocation information in the form of revocation bits.

In one possible implementation, the current revocation bits form a bit vector, and the plurality of least significant bits represent an integer that identifies one bit in the bit vector. Verifying the sub-public key is based on a bit of the identification. Using a revocation bit vector, wherein each sub-public key corresponds to one bit of the bit vector, provides a simple way to maintain the revocation bits. The sub-public key may be revoked by setting only one bit in the revocation bits.

In one possible implementation, the current revocation bits comprise a bitmask. Verifying the sub-public key includes comparing the plurality of least significant bits to the bitmask. Revocation information may be encoded into a smaller number of revocation bits using a bitmask.

In one possible implementation, the current revocation bit comprises a bloom filter. Verifying the sub-public key includes testing whether the sub-public key is a member of the bloom filter. Bloom filters provide a very compact representation of the element set, and also have an additional advantage: adding members to a collection only requires setting additional bits, and does not require resetting any bits.

In one possible implementation, the one-time programmable memory includes a hash of the base public key, and the software image includes the base public key. Verifying the software image includes verifying the hash of the base public key from the base public key. The inclusion of a hash of the base public key in the one-time programmable memory (one-time programmable memory, OTP) instead of the complete base public key reduces the amount of OTP memory required.

In one possible implementation, the base public key and the base private key correspond to an elliptic curve-based public key cryptosystem (elliptic curve based public key cryptographic system, ECDSA). ECDSA is a well known and widely used cryptographic system and therefore does not require the implementation and distribution of new cryptographic algorithms for the device.

According to a second aspect, the above and other implementations and advantages are obtained by a method. In one embodiment, the method includes generating a base key pair, wherein the base key pair corresponds to an elliptic curve-based public key cryptography system (elliptic curve based public key cryptographic system, ECDSA). The method comprises the following steps: generating a sub-key pair; updating the revocation bit; distributing the sub-key pair and the revocation bit; the generating sub-key pair, updating and distributing steps are repeated one or more times. Generating the sub-key pair includes: generating a random number; calculating a sub-public key according to the random number; repeating the steps of generating a random number and calculating a sub-public key until one or more least significant bits of the sub-public key match a predetermined bit pattern; and calculating a sub-private key corresponding to the sub-public key. The method generates authorized sub-key pairs that may be distributed to partners or authorized signers in a multi-partner ecosystem.

In one possible implementation, the revoked bit includes an array of one or more bits, and the revoked sub-public key includes a plurality of least significant bits that identify one bit in the array of one or more bits. Updating the revocation bit includes setting the one bit of the array of one or more bits that corresponds to the revoked subpublic key. Using a bit array having a one-to-one correspondence with the LSB pattern of the revoked sub-public key provides a simple way to identify the revoked sub-public key and update the revocation bits.

In one possible implementation, the revocation bits form a bloom filter, and updating the revocation bits includes adding the revoked sub-public key to the bloom filter.

According to a third aspect, the above and other implementations and advantages are obtained by a method. In one embodiment, the method includes receiving a software image, wherein the software image includes: a new revocation bit, a digital signature on the new revocation bit generated using a base private key, an authorized sub-public key, a digital signature on the authorized sub-public key generated using the base private key, program data, and a digital signature on the program data generated using an authorized sub-private key. The authorized sub-private key corresponds to the authorized sub-public key. The method comprises the following steps: verifying the new revocation bit based on the digital signature and the base public key on the new revocation bit; updating the current revocation bit according to the new revocation bit; verifying the sub-public key according to the updated current revocation bit; verifying the authorized sub-public key based on the digital signature on the authorized sub-public key and the basic private key; calculating a verification public key by applying a finite group operation to the base public key and the authorized sub-public key; and verifying the program data according to the digital signature and the verification public key on the program data. The method allows a computing device to reliably verify a software image during a secure boot.

According to a fifth aspect, the above and other implementations and advantages are obtained by a computer program product. In one embodiment, the computer program product comprises a non-transitory computer readable medium having stored thereon program instructions which, when executed by a processor, cause the processor to perform a method according to the second or third aspect and possible implementations described herein.

These and other aspects, implementations, and advantages of the exemplary embodiments will become apparent from the embodiments described herein, considered in conjunction with the accompanying drawings. It is to be understood that such description and drawings are for the purpose of illustration only and are not intended as a definition of the limits of the invention; reference should be made to the appended claims for any limitation of the invention. Additional aspects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Furthermore, the aspects and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims.

Drawings

In the following detailed description of the invention, the invention will be explained in more detail with reference to exemplary embodiments shown in the drawings, wherein like references indicate like elements, and:

FIG. 1 is a block diagram of an exemplary computing device for supporting an improved secure boot process in connection with aspects of the disclosed embodiments;

FIG. 2 is a flow chart of an exemplary method for verifying a software image with new revocation information in conjunction with aspects of the disclosed embodiments;

FIG. 3 illustrates a boot loading process in a multi-partner ecosystem incorporating aspects of the disclosed embodiments;

FIG. 4 is a block diagram of an exemplary authorized sub-key generation and software image verification process incorporating aspects of the disclosed embodiments;

FIG. 5 is a block diagram of details of an exemplary authorized sub-key generation and software image verification process incorporating aspects of the disclosed embodiments;

FIG. 6 is a flow chart of an exemplary method for generating authorized sub-key pairs in connection with aspects of the disclosed embodiments;

FIG. 7 is a flow chart of an exemplary method for verifying a software image in connection with aspects of the disclosed embodiments.

Detailed Description

FIG. 1 is a block diagram of an exemplary apparatus 100 for supporting an improved secure boot process in connection with aspects of the disclosed embodiments. The exemplary device 100 of the disclosed embodiments generally includes a computing device for using an authorized subkey to ensure that the computing device 100 is only booted by authorized and trusted software components. Among other benefits, the use of authorized sub-keys may reduce image size, simplify authorization, and provide an efficient key revocation mechanism. These improvements and advantages are obtained in part by deriving and distributing authorized sub-key pairs for use in conjunction with a base key pair.

Referring to FIG. 1, in one embodiment, an exemplary computing device 100 includes a processor 102 and a memory 104. The memory 104 includes a software image 120. In one embodiment, software image 120 includes a sub-public key 126, a digital signature 128 on the sub-public key generated using the base private key, program data 130, and a digital signature 132 on the program data generated using the sub-private key.

In one embodiment, the processor 102 is configured to verify 136 the software image. Validating 136 the software image 120 includes: verifying 112 the sub-public key 126 from the digital signature 128 on the sub-public key and the base public key 110, computing 114 the verification public key by applying a finite group operation to the base public key 110 and the sub-public key 126; program data 130 is verified 116 based on a digital signature 132 on the program data and a verification public key.

The base private key and the base public key 110 form a public-private key pair. The child private key and the verification public key form a public-private key pair.

The apparatus 100 may be any desired type of computing device including, but not limited to, a mobile communication device such as a smart phone, wearable device, or tablet. In some embodiments, the apparatus 100 may be a personal computing apparatus such as a notebook computer or other type of personal computing device, or a server apparatus such as those used in cloud computing data centers and the like.

As shown in the example of fig. 1, the processor 102 is communicatively coupled to the memory 104 for reading the memory 104 and performing operations thereon. In certain embodiments, the apparatus 100 may include additional components including, but not limited to, a system memory (not shown), such as a disk drive or solid state disk for providing high capacity long term storage, and a network or other communication subsystem (not shown) to provide external communications over a wireless or wired communication network.

Processor 102 may generally include any suitable processing device that may be advantageously used in apparatus 100. Examples include: high performance multi-core computer processing devices, such as those used in large cloud computing data centers; multicore or mononuclear microprocessors, such as devices used in workstations and notebook computers; processing devices in embedded systems, such as system on a chip (SoC); or any suitable or special purpose processing device, such as those used in mobile communication devices; a telecommunications device; an intelligent device configured for the internet of things (internet of things, ioT).

Memory 104 may include any desired type or combination of computer-accessible memory, such as random-access memory (RAM), read-only memory (ROM), or other suitable types of volatile and non-volatile memory. The apparatus 100 further comprises a secure memory 106 for securely storing sensitive and confidential data. Secure memory 106 may comprise any suitable type of secure memory, and may include, for example, but not limited to, various types of hardware security modules (hardware security module, HSM). In some embodiments, the secure memory includes a one-time programmable memory (OTP) 118, which may be an eFuse or other suitable type of OTP memory.

Secure booting is a verification mechanism for ensuring that code modules, such as a boot loader, an OS kernel, etc., that are loaded and executed by a computing device are authorized and trusted. Standardized firmware interfaces have been developed to support secure booting, such as unified extensible firmware interfaces (unified extensible FIRMWARE INTERFACE, UEFI), which replace the early basic input output system (basic input output system, BIOS) used in older PC type computers. Without secure booting, the software image may contain malicious code that is difficult to detect and may be used to attack various assets, such as confidential user data and original equipment manufacturer (original equipment manufacturer, OEM) authentication keys, etc. Secure booting is particularly important for low-level system components, such as a boot loader and an Operating System (OS) kernel.

Secure booting is a multi-level process where the currently executing component is responsible for authenticating and loading the next component in the boot process. Two relatively common types of secure boot processes include verification boot and measurement boot. Verification boot is a solution in which the firmware or OS image is verified in a trusted manner before control passes to the verification software. After verification starts, stakeholders may trust that software (e.g., firmware, boot loader, and OS kernel) has been verified according to predefined security policies. This security policy is typically defined by the OEM and may be as simple as loading the component only if the digital signature verification is successful. Measurement start-up is a solution in which the system configuration and software are measured during start-up and the measurements can be stored in a trusted platform module (trusted platform module, TPM) for use during later start-up.

As will be discussed further below, modern computing devices are typically manufactured from components provided by several different suppliers or partners. A group of suppliers or partners that cooperate to provide computing devices (e.g., device 100) is referred to herein as a multi-partner ecosystem.

Each partner in the multi-partner ecosystem is provided with its own signing key for use in signing the software and firmware components they produce. Traditional signature schemes typically use public-private key pairs (i.e., asymmetric encryption) to sign and verify data and PKI infrastructure to provide trust. These keys and corresponding digital signatures may then be checked during secure boot to ensure that the loaded software is not corrupted.

The term "public-private key pair" as used herein generally refers to a pair of keys used with asymmetric encryption algorithms, wherein data encrypted using one key of the public-private key pair may be decrypted using only the corresponding other key of the public-private key pair. For example, data encrypted using a private key can only be decrypted using the corresponding public key in the same public-private key pair.

The security of various asymmetric cryptography-based digital signature algorithms, such as the widely used elliptic curve digital signature algorithm (ECDSA-curve digital signature algorithm) and the Edwards curve digital signature algorithm (Edwards-curve digital signature algorithm, edDSA), is based on the assumption that the discrete logarithm problem (discrete logarithm problem, DLP) is an exponential ambiguity in group size. To aid in understanding, exemplary embodiments of the secure boot process disclosed herein are described with reference to Elliptic Curve Digital Signature Algorithm (ECDSA). However, those skilled in the art will readily recognize that other DLP based digital signature algorithms, such as digital signature algorithms (digital signature algorithm, DSA), may be similarly extended to support embodiments of the authorized sub-key processes disclosed herein without departing from the spirit and scope of the present invention.

As used herein, the phrase "digital signature on a data block generated using a key" refers to the process of generating a digital signature for a data block using a particular encryption key. The digital signature on the data block D generated using the key K is represented using the symbol sig (D, K), where D is the data block and K is the signing key. For example, the encryption key may be a private key of a public-private key pair. One common method of generating a digital signature is to create a digest of a block of data by computing a cryptographic hash of the block of data, and then encrypt the digest using an encryption key, the resulting ciphertext becoming the digital signature. Verification of the digital signature may be accomplished by decrypting the digital signature using the public key and then comparing the decrypted value to the newly created hash of the data block.

In conventional PKI solutions, each partner or signer in the multi-partner ecosystem receives a private key and a certificate, wherein the certificate includes a public key corresponding to the private key and is signed by or can be linked back to a trusted certificate authority. The partner or signer generates a public-private key pair and then requests a certificate of the public key from a trusted certificate authority (CERTIFICATE AUTHORITY, CA).

While PKI provides a reliable solution, its advantages are also disadvantageous. In PKI: the computational cost of certificate generation is high, and the functions of a certificate issuing mechanism and the support of PKI are required; the computational cost of certificate consumption (including parsing and verification) can be high; also, the certificates can be large, typically about 2 kilobytes.

It should be appreciated that certain advantages of the disclosed embodiments are realized by utilizing the characteristics of the authorized sub-keys. As a non-limiting example, the following discussion provides an overview of authorized sub-key construction and use using ECDSA specifications. As described above, the authorization sub-key mechanism disclosed herein may be advantageously used with other DLP based cryptographic systems without departing from the spirit and scope of the disclosed embodiments.

The construction of the authorized sub-key begins with the selection of the basic private key d and the generation point P. In the following discussion, the private key d and the generation point P are based on ECDSA. The corresponding base public key dP is obtained by multiplying the generation point D by the base private key using elliptic curve scalar multiplication. The basic private key d is known only to the master authority, e.g. the OEM of the production device. The master authority, referred to herein as Key Generator (KG), is responsible for generating and distributing the authorized sub-keys. The authorized subkeys are then distributed to partners (also referred to as signers) to sign the software images they generate.

As is known in the art, elliptic curve scalar multiplication, also known as elliptic curve point multiplication, is an operation that uses elliptic curve point addition to sequentially add points along an elliptic curve to itself, where the scalar value defines the number of times the addition is performed.

Two types of additions, standard integer additions and block operations, are used in the cryptographic operations described herein. When two scalar values are added, such as when the base private key d and the random integer r are added, a standard integer addition is used to create sum d+r. When adding points from the finite group, the corresponding group operation will be applied. For example, in the case of ECDSA, when the basic public key dP and the sub-public key rP are added, the elliptic curve point addition is used to generate the sum dp+rp. Both operations are indicated here by the plus sign "+". Those skilled in the art will readily distinguish between these two types of additions depending on the context.

It can be seen that for any random integer r between 0 and an integer value n, 0 < r < n, where n is the order of the generation point P, the ordered pair [ d+r, (d+r) P ] forms a valid public-private key pair, where d is the base private key, d+r is the child private key, and (d+r) P is the corresponding public key. Public key (d+r) P is referred to herein as the authentication public key or authentication key, and private key (d+r) is referred to herein as the child private key.

The verification public key (d+r) P may be generated by first adding the basic private key d to the random number r to obtain the sub private key d+r. The verification public key (d+r) P may be generated by multiplying the generation point P by the child private key d+r. Or the verification public key (d+r) P may be generated by multiplying the generation point P by a random number r to produce a value referred to herein as the sub-public key rP. The verification public key (d+r) P may then be calculated by adding the base public key dP to the sub-public key rP: (d+r) P =dp+rp. This alternative calculation of the verification public key provides some unique benefits, as will be discussed further below.

KG securely distributes sub-key tuples having three values to each authorized partner in the multi-partner ecosystem. Each sub-key tuple { d+r, [ rP, sig (rP, d) ] } includes: the authorized sub-private key d+r, the corresponding sub-public key rP, and the digital signature on the sub-public key generated using the base private key sig (rP, d). The latter two values in the sub-key tuple are referred to herein as authorized blobs [ rP, sig (rP, d) ], and may be used with the base public key dP to verify the sub-public key rP and calculate the verification public key. The digital signature sig (rP, d) allows the entity to verify whether the sub-public key rP has been actually authorised by KG.

Compared to traditional certificates, authorizing a blob has several advantages: authorizing binary large object generation is simpler than issuing certificates requiring a certificate issuing authority and supporting PKI; less decoding logic and computing resources are required to parse the authorized blobs; the authorized blob is significantly smaller than the certificate (33 bytes are needed to store compressed NIST P-256 points, the P-256ECDSA signature is 64 bytes in length); their small size enables encoding multiple authorized blobs into a basic key certificate.

When signing a software image, the partner creates a digital signature sig (Data, d+r) on the program Data generated using the child private key, and creates a software image including the program Data and the corresponding digital signature sig (Data, d+r). The software image also includes a sub-public key rP and a digital signature sig (rP, d) on the sub-public key generated using the base private key. This digital signature sig (rP, d) is used to verify that the sub-public key rP and the corresponding sub-private key d+r have been authorized by KG.

Referring again to the exemplary device 100, the device 100 is provided with a base public key dP 110. In one embodiment, the base public key dP 110 may be securely provided in the secure memory 106 at the time of manufacture. Or the base public key dP 110 may be provided in a digital certificate such as an x.509 certificate and stored locally in the device 100.

To maintain the integrity and security of the computing device 100, the software image 120 is verified 136 by the processor 102 before being allowed to execute. This ensures that only authorized and trusted software modules are allowed to run on the device 100.

The software image 120 includes a sub-public key 126 associated with the provider of the software image and a digital signature on the sub-public key 128 generated using the base private key d. Program data 130 is also included in software image 120 along with a digital signature on program data 132 generated using a subprivate key. Recall that the base private key d and corresponding base public key are associated with KG that is issuing and authorizing the subkeys, and that the subprivate key and corresponding subpublic key are associated with a partner or signer that is creating the software program being distributed in the software image 120.

The processor 102 is configured to authenticate 136 the software image 120 based on the information included in the software image 120 and the base public key dP 110. Verification 136 begins with verifying 112 sub-public key 126 from the digital signature on base public key dP 110 and sub-public key 128. Verifying 112 the sub-public key 126 ensures that the sub-public key 126 has been authorized by KG.

The verification public key (d+r) P is then computed 114 by applying a finite group operation to the base public key 110 and the child public key 126. In one embodiment, finite group operations are implemented using elliptic curve point addition, and the verification public key is calculated by adding the base public key dP 110 to the child public key rP 126. As described above, the verification public key (d+r) P and the child private key d+r form a public-private key pair.

Processor 102 verifies 116 program data 130 based on the calculated verification public key and a digital signature 132 on the program data. Once the software image is successfully verified 136, the software image 120 can be securely loaded and executed. If any of the verification steps fails, it is determined that the software image is invalid and should not be used.

The multi-partner ecosystem is typically dynamic and the partners in the supply chain will change continuously. A secure boot signature scheme intended to operate in such a dynamic environment needs to provide an efficient method to revoke subkeys. The revocation of the sub-key is handled by storing revocation information in the secure memory 106, which revocation information may be used in the secure memory 106 when authenticating the software image 120. In an exemplary embodiment, the current revocation information is encoded in a plurality of bits referred to herein as current revocation bits 108. These current revocation bits 108 may then be checked while verifying 136 the software image 120 to ensure that the sub-public key and corresponding partner remain authentic.

FIG. 2 is a flow chart of an exemplary method 200 for verifying a software image that includes new revocation information in connection with aspects of the disclosed embodiments. The exemplary method 200 is similar to the verification method 136 described above and is suitable for use in a computing device such as the device 100 when verifying a software image 120 that includes a new revocation bit 122. The distribution of revocation information in each software image provides an efficient way of ensuring proper maintenance of subkey revocation information on a computing device.

In one exemplary embodiment, the updating of revocation information may be facilitated by including a new revocation bit 122 in the software image 120. Distributing the new revocation bits 122 in the software image 120 facilitates the current revocation bits 108 being updated each time a new software image is verified by the device 100. The integrity of the new revocation bit 122 may be established by including a digital signature on the new revocation bit 124 generated using the base private key.

When verifying 200 the software image 120, the processor 102 is further configured to verify 202 the new revocation bit 122 based on the digital signature on the new revocation bit 124 using the base public key 110. The verification 202 ensures that the new revocation bit 122 is created by KG and has not been tampered with.

The current revocation bit 108 is then updated 204 in accordance with the new revocation bit 122. The sub-public key 126 may be verified 206 based on the newly updated current revocation bit 108 to ensure that the sub-public key 126 is not revoked.

Method 200 continues similar to method 136 described above by verifying 208 sub-public key rP from the digital signature on sub-public key 128, calculating 210 a verification public key (d+r) P by adding the base public key dP to sub-public key rP, and verifying 212 the program data using the calculated verification public key.

In one embodiment, secure memory 106 includes OTP memory 118, where a bit may be set at any time, but once a bit is set, it is never reset. One example of this type of OTP memory is eFuse or electronic fuse memory. eFuses integrate micro-fuses into a computer chip that cannot be reconnected once the fuse is blown. As used herein, the term eFuse or eFuse memory refers to any type of OTP memory in which a bit may be set at any time, but once the bit is set, it is never reset.

Revocation bits 108 are used to identify the set of all revoked subkeys. Advantageously, the revocation bits 108 employ a revocation encoding scheme in which adding a newly revoked subkey to the set of all revoked subkeys is accomplished by setting one or more of the revocation bits 108, and without resetting any of the revocation bits 108 that have been set. This revocation encoding scheme may use eFuse type OTP memory to ensure that additional subkeys may be revoked at any time, but once a subkey is revoked, it is never deleted from the revoked set of subkeys. It should be appreciated that any method of encoding revocation information into revocation bits 108 that satisfies the above-described condition of adding keys by setting bits without resetting the bits may be advantageously employed without departing from the spirit and scope of the disclosed embodiments.

A useful property of the subkeys is that for a random value r, the code streams of the corresponding subpublic keys are almost evenly distributed. This allows KG to construct a random r value such that a predetermined number of LSBs of the sub-public key are used to serve as an identifier of the sub-public key. The size of the revocation bits may then be reduced by encoding the identifier into the revocation bits instead of the entire sub-public key.

A non-limiting exemplary embodiment of an encoding scheme that satisfies the above condition of adding a key by setting bits without resetting bits is to select a sub-public key such that a predetermined number n of LSBs (i.e., a key identifier) of the sub-public key represent an integer value. The revocation bits are configured as a bit vector, wherein each bit in the vector corresponds to an integer value of the LSB.

For example, in an embodiment using a predetermined number of n-bit sub-public keys LSB as key identifiers and configuring the revocation bits as a 2 ⁿ -bit vector, the sub-public keys may be revoked by setting one bit in the revocation bits. As a non-limiting example, consider a simple embodiment in which the predetermined number of LSBs is 3, n=3, and the sub-public key to be revoked has its three LSBs set to "011". The integer value of bit pattern "011" is 3, so setting the third bit in the revocation bit vector will indicate that the subpublic key of identifier "011" has been revoked. When three LSBs are used as key identifiers, the length of the vector of revocation bits is eight bits, with each bit corresponding to an integer value of 0 to 7.

In an alternative embodiment, the LSBs of the sub-public key may be interpreted as a bitmask and verification of the sub-public key is accomplished by comparing the LSBs of the sub-public key to the bitmask. For example, assume that n=4, and that the four LSBs of the subpublic key have bit pattern "0110". This means that the sub-public key values for bit 1 and bit 2 (based on zero) are set have been revoked. In this particular example, when four LSBs begin with "01", "11", "001" and "101", the child public key will be rejected.

As the number of revoked subkeys becomes greater, the number of revocation bits may increase and may slow down the generation of subkeys. This may occur in a large mature multi-partner ecosystem where many subkeys have been revoked. One beneficial optimization of the revocation bits is to configure the revocation bits as bloom filters. Bloom filters are a data structure that is capable of storing a set of elements, such as a set of revoked sub-public keys, in a compact form. It is a probabilistic data structure that can be tested to determine if a sub-public key is "certainly not in" or "likely in" a collection. An important feature of the bloom filter is that sub-keys may be added to the bloom filter set but cannot be deleted, thereby preventing revoked sub-keys from being deleted from the bloom filter.

In one embodiment, the revocation bits are configured as bloom filter representations of the revoked sub-public key sets. When revocation bit 108 is a bloom filter, the sub-public key is verified by testing whether the sub-public key is a member of the set of revoked sub-public keys. The bloom filter should be stored in an integrity protected memory, such as secure memory 106. Or the hash of the bloom filter may be stored in secure memory 106.

In one embodiment, checking whether the sub-public key has been revoked includes verifying the new revocation bit 122 based on a reference bloom filter value. The bloom filter represented by the new revocation bit 122 may not be exactly the same as the reference bloom filter when needed. In some embodiments, the bloom filter represented by the new revocation bit 122 may be more stringent than the reference bloom filter value.

In embodiments where the number of secure memory 106 is limited, space may be reduced by storing the hash 140 of the base public key 110 in the secure memory 106 instead of the base public key 110. The hash 140 may be generated by applying a cryptographic hash function to the base public key 110 to produce a significantly smaller hash value corresponding to the base public key 110. The base public key 134 may be provided in the software image 120 and verified using the stored hash 140 during verification of the software image 120. Or the base public key may be stored in the non-volatile memory of the device 100, as non-volatile memory is typically less costly than secure memory.

In one embodiment, the base public key 110 may be distributed in a certificate such as an X.509 certificate. A hash value of one or more authorized sub-public keys may also be included in the certificate along with the base public key 110. During the verification 136 of the software image 120, the certificate may be verified from the base public key 110. The sub-public key may then be verified based on the hash value included in the certificate. The benefit of including a hash of the authorized subkey in the certificate is that the subpublic key authorization information need not be included in the distributed software image 120. One disadvantage of this approach is that the set of subkeys is static and therefore cannot be used without providing a new certificate.

FIG. 3 is a diagram of a secure boot loading process 300 for use in a multi-partner ecosystem incorporating aspects of the present invention. The example secure boot loading process 300 is suitable for use in a computing device 302 such as the example device 100 described above. In the diagram shown in FIG. 3, solid arrows 326 indicate software components that are loaded by other software components, and dashed arrows 324 indicate software components that are produced and signed by the provider.

When the computing device boots up, a first level boot loader 306 is executed to begin loading software modules. In one embodiment, first level boot loader 306 may be included as firmware stored in ROM by system on a chip (SoC) provider 304. The first level boot loader 306 then begins building the software environment by validating and loading additional components, which in the illustrated embodiment include components such as a hypervisor 308 provided by a hypervisor provider 316 and a trusted execution environment (trusted execution environment, TEE) Operating System (OS) provided by a TEE OS provider 318. The hypervisor 308 may then load the OS boot loader 312 provided by the boot loader provider 320, which in turn, the boot loader provider 320 loads the rich execution environment (rich execution environment, REE) OS kernel 314, which may be provided by the REE kernel provider 322.

Each of these components 306, 308, 310, 312, 314 requires verification of a software image, such as software image 120 described above, using a verification process 136 or 200, etc. as described above. Furthermore, each component may be provided by a different provider and signed using a different private key. It is easy to see how the number of signing keys becomes quite large in a multi-partner ecosystem used by the device manufacturer.

Fig. 4 is a block diagram of an exemplary authorized sub-key generation and software image verification process 400 incorporating aspects of the disclosed embodiments. The exemplary process 400 is applicable to the signing and verification of software images, such as the software image 120 described above. KG 402 represents the entity that issued and authorized subkeys for partners in a multi-partner ecosystem. KG 402 may be a manufacturer or industry organization trusted by all partners that issues and authorizes subkeys for signing and verification of software images. Each partner 404, 406, 408 in the multi-partner ecosystem, referred to as signer 1 404, signer I406, and signer m 408, will sign their generated software images using their own child private keys. Thus, the partners may also be referred to as signers 404, 406, 408. Although three signers 404, 406, 408 are shown in the illustration of fig. 4, it should be understood that as few or as many signers as are needed and that the number of signers may be arbitrarily large. KG 402 generates sub-key tuples 416, 418, 420, wherein each sub-key tuple comprises a sub-key and a corresponding authorized blob, as described above. Each sub-key tuple 416, 418, 420 is securely distributed to the signers 404, 406, 408 such that only the signers, and if needed, KG 402 knows their sub-private keys. The verifier 410 is an entity that needs to verify or verify the software image 410, such as the computing device 100 described above. KG 402 also distributes 422 or otherwise provides the basic public key dP to verifier 410, allowing the verifier to verify the software image based only on the information included in software image 424 and the basic public key dP.

Verifier 410 receives 424 a software image including the sub-public key and program data, such as software image 120 described above with reference to fig. 1. Verifier 410 verifies the sub-public key using the base public key and computes a verified public key by adding the base public key to the sub-public key. The verifier 410 then verifies the program data based on the digital signature on the program data also included in the software image.

FIG. 5 is a block diagram of details of an exemplary authorized sub-key generation and software image verification process 500 incorporating aspects of the disclosed embodiments. The exemplary process 500 is similar to the exemplary process 400 described above and additional details of the authorized sub-key embodiments disclosed herein are described.

KG 502 performs one-time setup by generating a basic private key and calculating a corresponding basic public key to create a basic key pair. KG 502 then generates a subkey pair for each partner by generating a random number r _i and computing a subpublic key r _i P. When the LSB pattern of sub-public key r _i P does not match the desired bit pattern, KG 502 increments random number r _i and generates a new sub-public key. This operation is repeated until the LSB condition is satisfied. KG 502 also removes the pin key pair if necessary and maintains revocation information in the form of revocation bits to be distributed to partners who will include the revocation information in any software images they generate.

KG 502 distributes 520 sub-key tuples and signature revocation bits to each partner 506. The KG 502 provides the base public key and revocation bits to the manufacturer or OEM 512, and the manufacturer 512 burns 526 the base public key 536 and revocation bits 538 into each provider device 516 or computing apparatus manufactured by the OEM.

Partner 506 creates software image 524, where software image 524 includes signed revocation bit 528, the sub-public key and corresponding digital signature on the sub-public key generated using base private key 530, program data 532, and signature on program data 534 generated using the sub-private key.

When the software image 524 is distributed to the device 516 of the apparatus 100 and the like described above, the device 516 verifies the software image using an appropriate verification method (e.g., the exemplary method 134 or 200 described above) based on the base public key 536 and the revocation bits 538. The device 516 extracts LSBs from the subpublic key and compares them to the revocation bits 538. If the comparison finds that the sub-public key has been revoked, the verification fails and the software image will not be loaded. When the sub-public key has not been revoked, a verification public key is calculated by adding the base public key 536 to the sub-public key, and program data is verified using the verification public key.

Fig. 6 is a flow chart of an exemplary method 600 for generating authorized sub-key pairs in connection with aspects of the disclosed embodiments. The exemplary method 600 is suitable for use by a key authority (e.g., KG 502 described above) to generate and distribute authorized sub-keys to partners in a multi-partner ecosystem.

Method 600 begins when a key authority generates 602 a base key pair. In one non-limiting embodiment, the base key pair may be derived from the seed value according to a key generation method of an elliptic curve digital signature algorithm. Or the base key pair may be derived from any suitable DLP-based cryptosystem. In generating 602 a base key pair, a base private key d is first generated. The basic private key is kept secret so that only KG knows it. The basic public key dP is then generated, for example, by multiplying the elliptic curve generation point P by the basic private key d. The basic public key dP is distributed to partners in a trusted manner for use in authorizing the sub-public key.

A sub-key pair 620 is generated for each partner in the multi-partner ecosystem. The sub-key pair includes a sub-private key (d+r _i) and a sub-public key r _i P, and may be packaged for distribution in a sub-key tuple that includes the sub-private key and the authorized blob { d+r _i,[r_i P,sig(r_i P, d) ] } as described above. KG updates 614 the revocation bits and distributes the updated revocation bits to all partners in the multi-partner ecosystem.

The sub-key tuples { d+r _i,[r_i P,sig(r_i P, d) ] } and revocation bits are then distributed 616 to partners to generate and sign software images. It will be appreciated that using the method described above and with reference to fig. 6, a large number of unique sub-key pairs may be generated and distributed to partners.

The generation of each sub-key pair 620 is an iterative process that includes generating 606 a random number r _i and computing 608 a corresponding sub-public key r _i P by multiplying the generation point P by the random number r _i. The resulting one or more LSBs of the sub-public key LSB (r _i P) are then matched to a predetermined bit pattern. When the matches are not equal, the random number r _i is incremented and the corresponding sub-public key r _i P is generated. This process is repeated until one or more LSBs of the child public key r _i P match the predetermined bit pattern.

The one or more LSBs of the sub-public key may comprise any desired number of LSBs, and may be a fixed number of LSBs. The predetermined number of LSBs should be large enough to support the generation of the number of partners in the multi-partner ecosystem and the number of authorized sub-key pairs.

Matching 610 of one or more LSBs of the child public key to the predetermined bit pattern may be accomplished in any suitable manner. For example, in one non-limiting embodiment, one or more LSBs may be matched by testing a bloom filter. Or the LSB may be matched to the desired binary integer. In an exemplary embodiment, the matching operation is to ensure that the newly generated sub-public key has not been included in the set of revoked keys indicated by the revocation bits.

Once a matching sub-public key 610 is found, a corresponding sub-private key d+r _i is generated 612 by adding the base private key d to the random number r _i.

FIG. 7 is a flow chart of an exemplary method 700 for verifying a software image in connection with aspects of the disclosed embodiments. The exemplary method 700 of the disclosed embodiments is suitable for use in the apparatus 100 described above in connection with fig. 1. The exemplary method 700 provides an improved software image verification method that employs authorized subkeys to reduce software image size, simplify software image authorization, and provide an efficient key revocation mechanism.

When a computing device such as the device 100 described above receives 702 a software image, the software image should be verified before executing the software image. In the exemplary method 700, the software image includes: a new revocation bit, a digital signature on the new revocation bit generated using a base private key, an authorized sub-public key, a digital signature on the authorized sub-public key generated using the base private key, program data, and a digital signature on the program data generated using an authorized sub-private key.

The new revocation bits are verified 704 based on the base public key, and then, when the verification is successful, the current revocation bits stored in a secure memory within the computing device are updated 706 with the new revocation bits. As described above, it may be advantageous to encode the revocation bits in a manner that exploits the characteristics of eFuse-type OTP memories to ensure that reloading older software images does not delete revoked subkeys from the revoked subkey set indicated by the current revocation bit.

The authorized sub-public key included in the software image may then be verified 708 based on the current revocation bits. When it is determined that the authorized sub-public key has been revoked, verification of the software image may be terminated, and the software image is no longer executed. Verification will continue when the authorized sub-public key has not been revoked.

The integrity of the authorized sub-public key may be verified 710 using the base public key to verify the digital signature on the authorized sub-public key included in the software image. When signature verification 710 fails, verification of the software image is terminated and the software image will not be executed, and when verification 710 is successful, verification 700 continues. In one embodiment, the integrity of the authorized sub-public key may be verified 710 before verifying 708 whether the sub-public key has been revoked. Both of these verifications 708, 710 must pass to continue the software image verification.

The authentication key is calculated 712 by applying a finite set of operations to the base public key and the authorized sub-public key. When ECDSA is used, the verification key (d+r _i) P may be calculated by adding the base public key dP to the authorized sub-public key r _i P using elliptic curve point addition.

It should be appreciated that the software image verification method described above may be completely certificate-free, thereby eliminating the need to set up and maintain a complete PKI infrastructure to support secure booting.

KG may delegate signing capability to partners by distributing sub-key pairs and authorizing blobs. This approach eliminates semantic gaps compared to traditional HSM-based approaches, where the HSM signs each software image. More specifically, a partner or signer of the software image may examine metadata contained in the software image to learn what is being signed. Thus, the signer cannot use the authorized sub-private key to determine the base private key, nor can it calculate a new authorized sub-private key. It is also not possible for partners to cooperate to destroy the basic private key or calculate a new authorized sub-private key.

Each partner may obtain a number of authorized sub-private keys if desired. Each key may then be used to sign only one or a small number of software images. By allowing the base private key to be restricted to the HSM, thereby reducing exposure of the base private key, improved security may be provided.

Thus, while there have been shown, described, and pointed out fundamental novel features of the invention as applied to exemplary embodiments thereof, it will be understood that various omissions and substitutions and changes in the form and details of the devices and methods illustrated, and in their placement, may be made by those skilled in the art without departing from the spirit and scope of the invention. Moreover, it is expressly intended that all combinations of those elements that perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Furthermore, it should be recognized that structures and/or elements shown and/or described in connection with any form or embodiment of the disclosed invention may be incorporated in any other form or embodiment disclosed or described or suggested as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.

Claims (15)

1. An apparatus (100) comprising a processor (102) and a memory (104),

Wherein the memory (104) comprises a software image (120), the software image (120) comprising:

A sub public key (126);

-a digital signature (128) on the sub-public key generated using a basic private key;

Program data (130);

-a digital signature (132) on the program data generated using a subprivate key;

Wherein the processor (102) is configured to verify the software image (120) by:

Verifying the sub-public key (126) from the digital signature (128) and the base public key (110) on the sub-public key (126);

-computing a verification public key by applying a finite group operation to said basic public key (110) and said sub-public key (126);

validating said program data (130) based on said digital signature (132) and said validation public key on said program data,

Wherein the basic private key and the basic public key (110) form a public-private key pair, and the sub private key and the verification public key form a public-private key pair.

2. The apparatus (100) of claim 1, further comprising a one-time programmable memory (106), the software image (120) further comprising:

-a new revocation bit (122);

a digital signature on the new revocation bit (124) generated using the base private key,

Wherein verifying the software image (120) further comprises:

Validating the new revocation bit (122) based on the digital signature (124) and the base public key (110) on the new revocation bit;

-updating a current revocation bit (108) according to the new revocation bit (122), wherein the current revocation bit (108) is stored in the one-time programmable memory (106);

The sub-public key (126) is verified based on the updated current revocation bit (106).

3. The apparatus (100) of any of the above claims, wherein the one-time programmable memory (106) includes an eFuse type memory (118), and updating the current revocation bit (108) includes setting unset bits in the eFuse type memory (118) and leaving set bits in the current revocation bit (108) unchanged.

4. The apparatus (100) of any of the preceding claims, wherein the sub-public key (126) comprises a plurality of least significant bits, wherein the plurality of least significant bits form an identification of the sub-public key (126) and the plurality of least significant bits is equal to a predetermined bit pattern.

5. The apparatus (100) of claim 4, wherein the current revocation bit (108) comprises a bit vector, the plurality of least significant bits representing an integer that identifies one bit in the bit vector, the verifying the sub-public key (126) being based on the identified one bit.

6. The apparatus (100) of claim 4, wherein the current revocation bit (108) comprises a bitmask, and wherein validating the sub-public key (126) comprises comparing the plurality of least significant bits with the bitmask.

7. The apparatus (100) of claim 4, wherein the current revocation bit (108) comprises a bloom filter, and wherein verifying the sub-public key (126) comprises testing whether the sub-public key (126) is a member of the bloom filter.

8. The apparatus (100) of any of the preceding claims, wherein the one-time programmable memory (106) comprises a hash of the base public key, wherein the software image (120) comprises the base public key (134), and wherein verifying the software image comprises verifying the hash of the base public key from the base public key (134).

9. The apparatus (100) of any of the preceding claims, wherein the base public key (110) is provided in a certificate, wherein the certificate comprises a hash of the sub-public key, and wherein verifying the mirror (120) comprises verifying the sub-public key (126) from the hash of the sub-public key.

10. The apparatus (100) of any of the preceding claims, wherein the base public key (110) and the base private key correspond to elliptic curve based public key cryptography.

11. A method (600) comprising:

generating (602) a base key pair, wherein the base key pair corresponds to an elliptic curve-based public key cryptosystem;

Generating (620) a subkey pair;

updating (614) the undo bit;

-distributing (616) the subkey pair and the revocation bits;

repeating (618) the steps of generating (620) a sub-key pair, updating (614) a revocation bit, and distributing (616) the sub-key pair and the revocation bit one or more times,

Wherein generating (616) a subkey pair comprises:

Generating (606) a random number;

-calculating (608) a sub-public key from the random number;

Repeating the generating (606) random numbers and computing (608) sub-public keys steps until one or more least significant bits of the sub-public keys match a predetermined bit pattern;

a sub-private key corresponding to the sub-public key is calculated (616).

12. The method (600) of claim 11, wherein the revoked bit includes an array of one or more bits, and the revoked sub-public key includes a plurality of least significant bits identifying one bit of the array of one or more bits,

Wherein updating (614) the revocation bit comprises setting the one bit of the array of one or more bits corresponding to the revoked sub-public key.

13. The method (600) of claim 11, wherein the revocation bit comprises a bloom filter, and updating (614) the revocation bit comprises adding the revoked sub-public key to the bloom filter.

14. A method (700), comprising:

Receiving (702) a software image, wherein the software image comprises: a new revocation bit, a digital signature on the new revocation bit generated using a base private key, an authorized sub-public key, a digital signature on the authorized sub-public key generated using the base private key, program data, and a digital signature on the program data generated using an authorized sub-private key, wherein the authorized sub-private key corresponds to the authorized sub-public key;

Validating (704) the new revocation bit based on the digital signature and the base public key on the new revocation bit;

updating (706) the current revocation bit in dependence upon the new revocation bit;

validating (708) the sub-public key according to the updated current revocation bit;

verifying (710) the authorized sub-public key from the digital signature on the authorized sub-public key and the basic private key;

computing (712) a verification public key by applying a finite group operation to the base public key and the authorized sub-public key;

the program data is verified (714) based on the digital signature and the verification key on the program data.

15. A computer program product comprising a non-transitory computer readable storage medium having stored thereon program instructions which, when executed by a processor, cause the processor to perform the method according to any of claims 11 to 14.