WO2023222238A1

WO2023222238A1 - Apparatus and method for secure boot using authorized subkeys

Info

Publication number: WO2023222238A1
Application number: PCT/EP2022/063735
Authority: WO
Inventors: Arto NIEMI; Sampo Sovio; Pekka Laitinen; Jan-Erik Ekberg
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-05-20
Filing date: 2022-05-20
Publication date: 2023-11-23

Abstract

A computing apparatus incorporating secure boot and software image validation mechanisms based on authorized sub-key pairs is supported by a key generator that generatesthe authorized sub-key pairs, and image signers that generate cryptographically secure software images. An improved software image includes an authorized sub-public key, a digital signature over the authorized sub-public key generated with a base-private key, a program data, a digital signature over the program data generated with an authorized sub-private key, new revocation bits, and a digital signature over the new revocation bits generated with the base private key.The computing apparatus validates the new revocation bits, updates current revocation bits, validates the sub-public key based on the revocation bits and the base public key, generates a validation public key based on the sub-public key and the base public key, and validates the program data based on the validation public key.

Description

APPARATUS AND METHOD FOR SECURE BOOT USING AUTHORIZED SUBKEYS

TECHNICAL FIELD

The aspects of the disclosed embodiments relate generally to computer security and more particularly secure boot solutions.

BACKGROUND

Secure boot is a mechanism designed to ensure computing devices can be booted only with authorized and trustworthy software. Secure boot is a multi-stage process where a currently loaded component is responsible for authenticating and loading the next component. Modern computing devices are typically manufactured using components from several vendors thereby creating a multi-partner ecosystem. Conventional code signing solutions do not scale well in in large multi-partner ecosystems.

One conventional approach relies on public key infrastructures (PKI) where each partner has signing keys that can be validated using certificates. These solutions can be expensive to implement and maintain. PKI based solutions also require additional entities and complexities to support creation and distribution of certificate revocation lists to support revocation of signing authority as partners enter and leave a multi-partner ecosystem. PKI based solutions can also introduce additional overhead into software image metadata.

Rather than delegate signing authority to partners, an original equipment manufacturer (OEM) may provide a signing server for use by partners to sign their code modules. Code signing servers expose attack vectors and require expensive infrastructure to support high availability for large numbers of providers.

Thus, there is a need for improved apparatus and methods capable of providing lightweight code signing solutions that easily support revocation of signing authority. Accordingly, it would be desirable to provide methods and apparatus that addresses at least some of the problems described above. SUMMARY

The aspects of the disclosed embodiments are directed to apparatus and methods for providing an improved secure boot solution for multi-partner ecosystems. The aspects of the disclosed embodiments employ signing solutions based on authorized sub-key pairs to avoid the expense of PKI infrastructure, allow delegation of signing capability, remove the semantic gap associated with HSM based solutions, and reduce an amount of metadata required in software images.

According to a first aspect, the above and further implementations and advantages are obtained by an apparatus including a processor and a memory. The memory includes a software image and the software image includes a sub-public key; a digital signature over the sub-public key generated with a base-private key; program data; and a digital signature over the program data generated with a sub-private key. The processor is configured to validate the software image by validating the sub-public key based on the digital signature over the sub-public key and the base public key. The processor computes a validation key by applying a finite group operation on the base public key and the sub-public key, then validates the program data based on the digital signature over the program data and the validation public key. The base private key and the base public key form a public-private key pair, and the sub-private key and the validation public key form a public-private key pair. The employed signing solutions are based on authorized subkey pairs to avoid the expense of PKI infrastructure, allow delegation of signing capability, remove the semantic gap associated with HSM based solutions, and reduce an amount of metadata required in software images.

In a possible implementation form, the apparatus includes a one-time programmable memory, and the software image includes new revocation bits, and a digital signature over the new revocation bits generated with the base private key. Validating the software image includes validating the new revocation bits based on the digital signature over the new revocation bits and the base public key; updating current revocation bits based on the new revocation bits, wherein the current revocation bits are stored in the one-time programmable memory; and validating the sub-public key based on the updated current revocation bits. Including new revocation bits in the software image provides a reliable and efficient method of distributing revocation information to a computing apparatus. Validating the sub-public key against the revocation bits provides a trustworthy method of validating a software image and ensuring images signed with a revoked sub-key do not get executed. In a possible implementation form, the one-time programmable memory includes an eFuse type memory, and updating the current revocation bits comprises setting unset bits in the eFuse type memory and leaving set bits in the current revocation bits unchanged. This property of eFuse type memory to allow setting bits and prevent resetting bits ensures that the current revocation bits cannot be rolled back to an earlier version of the revocation bits.

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

In a possible implementation form, the current revocation bits form a vector of bits and the plurality of least significant bits represent an integer identifying one bit in the vector of bits. Validating the sub-public key is based on the identified one bit. Using a vector of revocation bits where each sub-public key corresponds to one bit in the vector of bits, provides a simple means of maintaining revocation bits. A sub-public key may be revoked simply by setting one bit in the revocation bits.

In a possible implementation form, the current revocation bits include a bit mask. Validating the sub-public key includes comparing the plurality of least significant bits to the bit mask. The use of a bit mask allows a revocation information to be encoded into a smaller number of revocation bits.

In a possible implementation form, the current revocation bits form a Bloom filter. Validating the sub-public key includes testing whether the sub-public key is a member of the bloom filter. A Bloom filter provides a very compact representation of a set of elements and has the additional advantage that adding members to the set requires only setting additional bits and does not require resetting any bits.

In a possible implementation form, the one-time programmable memory includes a hash of the base public key, and the software image includes the base public key. Validating the software image comprises verifying the hash of the base public key based on the base public key. Including a hash of the base public key instead of the full base public key in one-time programmable memory (OTP), reduces the amount of OTP memory required. In a possible implementation form, the base public key and the base private key correspond to an elliptic curve based public key cryptographic system (ECDSA). ECDSA is a well known and widely used cryptographic system thereby eliminating the need to implement and distribute new cryptographic algorithms to the apparatus.

According to a second aspect, the above and further implementations and advantages are obtained by a method. In one embodiment the method includes generating a base key pair, where the base key pair corresponds to an elliptic curve based public key cryptographic system (ECDSA). The method includes generating a sub-key pair; updating revocation bits; distributing the sub-key pair along with the revocation bits, and repeating the generating a subkey pair, updating, and distributing steps one or more times. Generating a sub-key pair includes generating a random number; computing a sub-public key based on the random number; repeating the generating a random number and computing a sub-public key steps until one or more least significant bits of the sub-public key match a pre-determined bit pattern; and computing a sub-private key corresponding to the sub-public key. This method generates authorized sub-key pairs that may be distributed to partners or authorized signers in a multipartner ecosystem.

In a possible implementation form, the revocation bits comprise an array of one or more bits, and a revoked sub-public key comprises a plurality of least significant bits configured to identify one bit in the array of one or more bits. Updating the revocation bits comprises setting the one bit in the array of one or more bits corresponding to the revoked sub-public key. Use of an array of bits having a one-to-one correspondence with an LSB pattern of the revoked subpublic key provides a simple method of identifying revoked sub-public keys and updating the revocation bits.

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

According to a third aspect, the above and further implementations and advantages are obtained by a method. In one embodiment the method includes receiving a software image, where the software image includes new revocation bits, a digital signature over the new revocation bits generated with a base private key, an authorized sub-public key, a digital signature over the authorized sub-public key generated with the base private key, a program data, and a digital signature over the program data generated with an authorized sub-private key. The authorized sub-private key corresponds to the authorized sub-public key. The method includes validating the new revocation bits based on the digital signature over the new revocation bits and the base public key; updating a current revocation bits based on the new revocation bits; validating the sub-public key based on the updated current revocation bits; validating the authorized subpublic key based on the digital signature over the authorized sub-public key and the base private key; computing a validation key by applying a finite group operation on the base public key and the authorized sub-public key; and validating the program data based on the digital signature over the program data and the validation key. This method allows a computing apparatus to reliably validate a software image during secure boot.

According to a fifth aspect, the above and further implementations and advantages are obtained by a computer program product. In one embodiment, the computer program product includes a non-transitory computer readable media that has stored thereon program instructions, which when executed by a processor cause the processor to perform the method according to the second or third aspect and the possible implementation forms described herein.

These and other aspects, implementation forms, 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, however, that the description and drawings are designed solely for purposes of illustration and not as a definition of the limits of the disclosed invention, for which reference should be made to the appended claims. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following detailed portion of the present disclosure, the invention will be explained in more detail with reference to the example embodiments shown in the drawings, in which like references indicate like elements and:

Figure 1 illustrates a block diagram of an exemplary computing apparatus configured to support an improved secure boot process incorporating aspects of the disclosed embodiments; Figure 2 illustrates a flow diagram showing an exemplary method for validating a software image having new revocation information, incorporating aspects of the disclosed embodiments;

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

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

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

Figure 6 illustrates a flow chart of an exemplary method for generating authorized sub-key pairs incorporating aspects of the disclosed embodiments;

Figure 7 illustrates a flow chart of an exemplary method for validating a software image incorporating aspects of the disclosed embodiments.

DETAILED DESCRIPTION OF THE DISCLOSED EMBODIMENTS

Figure 1 illustrates a block diagram of an exemplary apparatus 100 configured to support an improved secure boot process incorporating aspects of the disclosed embodiments. The exemplary apparatus 100 of the disclosed embodiments generally comprises a computing apparatus that is configured to employ authorized sub-keys to ensure that the computing apparatus 100 is booted only with authorized and trustworthy software components. Among other benefits, the use of authorized sub-keys reduces image size, simplifies authorization, and provides an efficient key revocation mechanism. These improvements and advantages are obtained in part through derivation and distribution of authorized sub-key pairs configured for use in conjunction with a base key pair.

Referring to Figure 1, in one embodiment the exemplary computing apparatus 100 comprises a processor 102 and a memory 104. The memory 104 comprises a software image 120. In one embodiment the software image 120 includes a sub-public key 126, a digital signature 128 over the sub-public key generated with a base-private key, program data 130 and a digital signature 132 over the program data generated with a sub-private key. In one embodiment, the processor 102 is configured to validate 136 the software image. Validating 136 the software image 120 includes validating 112 the sub-public key 126 based on the digital signature 128 over the sub-public key and the base public key 110, computing 114 a validation public key by applying a finite group operation on the base public key 110 and the sub-public key 126 and validating 116 the program data 130 based on the digital signature 132 over the program data and the validation public key.

The base private key and the base public key 110 form a public-private key pair. The sub-private key and the validation public key form a public-private key pair.

The apparatus 100 may be any desired type of computing apparatus including but not limited to a mobile communications device such as a smartphone, wearable, or tablet. In certain embodiments the apparatus 100 may be a personal computing apparatus such as a laptop or other type of personal computing device, or a server apparatus such as those used in cloud computing data centers etc.

As is shown in the example of Figure 1, the processor 102 is communicatively coupled to the memory 104 and is configured to read and perform operations on the memory 104. In certain embodiments the apparatus 100 may include additional components including but not limited to a system storage (not shown) such as a disk drive or solid-state disk configured to provide high-capacity long term storage capabilities, and network or other communication subsystems (not shown) to provide external communications over wireless or wired communication networks.

The processor 102 can generally comprise any suitable processing device that may be advantageously employed in the apparatus 100. Examples include a high-performance multicore computer processing device such as those used in large cloud computing data centers, a multi-core or single core microprocessor such as those used in workstations and laptop computers, a processing device embedded in a system such as a system on a chip (SoC), or any suitable or specialized processing device such as those used in mobile communications devices, telecommunications equipment, and smart devices configured for the internet of things (loT).

The 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 also includes secure memory 106 for securely storing sensitive and confidential data. The secure memory 106 may include any suitable type of secure memory and such as but not limited to various types of hardware security modules (HSM). In certain embodiments the secure memory includes one-time programmable memory (OTP) 118, which may be an eFuse or other suitable type of OTP memory.

Secure boot is a verification mechanism for ensuring code modules, such as a boot loader, OS kernel, etc., that are loaded and executed by a computing apparatus are authorized and trusted. Standardized firmware interfaces have been developed to support secure boot such as the unified extensible firmware interface (UEFI), which has replaced the earlier basic input output system (BIOS) used in older PC type computers. Without secure boot, software images may contain malicious code that is difficult to detect and can be used to attack various assets such as confidential user data and original equipment manufacturer (OEM) authentication keys, etc. Secure boot is especially important for the low-level system components such as the boot loader and operating system (OS) kernel.

Secure boot is a multi-stage process, where the currently executing component is responsible for authenticating and loading the next component in the boot process. Two of the more common types of secure boot processes include verified boot and measured boot. Verified boot is a solution where the firmware or OS image is validated in a trustworthy manner before control is passed to the validated software. After verified boot, stakeholders can trust that the software (such as firmware, boot loader, and OS Kernel) have been validated according to a pre-defined security policy. This security policy is typically defined by the OEM and can be as simple as loading a component only when a digital signature validation succeeds. Measured boot is a solution where system configuration and software are measured during the boot and the measured values may be stored for example in a trusted platform module (TPM) for use during a later boot.

As will be discussed further below, modern computing apparatus are often manufactured with components provided by several different vendors or partners. A group of vendors or partners working together to provide a computing apparatus, such as the apparatus 100, are referred to herein as a multi-partner ecosystem.

It is beneficial to provide each partner in the multi-partner ecosystem with own signing keys to be used to be used when signing software and firmware components they produce. Conventional signing solutions often use public-private key pairs, i.e., asymmetric cryptography, to sign and validate data, and employ a PKI infrastructure to provide trust. These keys and the corresponding digital signatures may then be verified during secure boot to ensure loaded software has not been compromised.

As used herein the term "public-private key pair" generally refers to a pair of keys used with an asymmetric cryptography algorithm where data that is encrypted with one key from the publicprivate key pair may be decrypted only with the corresponding other key from the public-private key pair. For example, data encrypted with the private key can be decrypted only with the corresponding public key from the same public-private key pair.

Security of various asymmetric cryptography based digital signature algorithms, such as the widely used elliptic-curve digital signature algorithm (ECD SA) and the Edwards-curve digital signature algorithm (EdDSA), are based on the assumption that the discrete logarithm problem (DLP) is exponentially hard to solve in terms of group size. As an aid to understanding, exemplary embodiments of the secure boot process disclosed herein are described with reference to an elliptic-curve digital signature algorithm (ECDSA). However, those skilled in the art will readily recognize that other DLP based digital signature algorithms, such as DS A (digital signature algorithm), can be similarly extended to support embodiments of the authorized sub-key processes disclosed herein without straying from the spirit and scope of the present disclosure.

As used herein, the phrase “a digital signature over a data block generated with a key", refers to the process of generating a digital signature for a data block using a particular encryption key. A digital signature over a data block D generated with a key K is represented using the notation: sig(D,K), where D is the data bloc, and K is the signing key. The encryption key may for example be the private key from a public-private key pair. One common approach for generating a digital signature is to create a digest of the data block by computing a cryptographic hash of the data block, the digest is then encrypted with the encryption key and the resulting cyphertext becomes the digital signature. Validation of the digital signature may be accomplished by decrypting the digital signature using the public key, then comparing the decrypted value to a newly created hash of the data block.

In a conventional PKI solution, each partner or signer in the multi-partner ecosystem receives a private key and a certificate, where the certificate incorporates the public key corresponding to the private key and is signed by a trusted certificate authority or may be chained back to a trusted certificate authority. Beneficially, the partner or signer generate a public-private key pair, then request a certificate for the public key from a trusted certificate authority (CA).

While PKI provides a reliable solution, its advantages come with drawbacks. In PKI: certificate generation is computationally expensive and requires certificate authority functionality and supporting PKI; certificate consumption, including parsing and validation, can be computationally expensive; and, the certificates can be large, often about two kilobytes.

It will be appreciated that certain advantages of the disclosed embodiments are achieved by leveraging properties of authorized sub-keys. As a non-limiting example, the following discussion provides an overview of authorized sub-key construction and usage illustrated with the ECDSA. As discussed above, the authorized sub-key mechanisms disclosed herein may be advantageously employed with other DLP based cryptography systems without straying from the spirit and scope of the disclosed embodiments.

Construction of authorized sub-keys begins with selection of a base private key d and a generator point P. In the following discussion the private key d and generator point P are based on an ECDSA. The corresponding base public key dP is obtained using elliptic curve scalar multiplication to multiply the generator point D by the base private key. The base private key d is known only to the primary authority, such as the OEM producing the devices. The primary authority is referred to herein as the key generator (KG) and is responsible for generating and issuing authorized sub-keys. The authorized sub-keys are then distributed to partners, also referred to as signers, to sign software images they produce.

As is known in the art, elliptic curve scalar multiplication, also referred to as elliptic curve point multiplication, is the operation of successively adding, using elliptic curve point addition, a point along an elliptic curve to itself, where the scalar value defines how many times the addition is performed.

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

It can be shown that for any random integer r between zero and an integer value n, 0 < r < n, where n is the order of the generator point P, the ordered pair [d+r, (d+r)P] forms a valid publicprivate key pair, where d is a base private key, d+r is a sub-private key, and (d+r)P is the corresponding public key. The public key (d+r)P is referred to herein as the validation public key or validation key, and the private key (d+r) is referred to herein as the sub-private key.

The validation public key (d+r)P may be generated by first adding the base private key d with the random number r to get the sub-private key d+r. The validation public key (d+r)P may be generated by multiplying the generator point P by the sub-private key d+r. Alternatively, the validation public key (d+r)P may be generated by multiplying the generator point P by the random number r to produce a value referred to herein as a sub-public key rP. The validation public key (d+r)P may then be computed by adding the base public key dP to the sub-public key rP: (d+r)P = dP+rP. As will be discussed further below, this alternate computation of the validation public key provides some distinct benefits.

The KG securely distributes a sub-key tuple having three values to each authorized partner in the multi-partner eco-system. Each sub-key tuple { d+r, [rP, sig(rP, d)]} includes: an authorized sub-private key d+r, a corresponding sub-public key rP, and a digital signature over the subpublic key generated with the base private key, sig(rP, d). The second two values in the sub-key tuple are referred to herein as an authorization blob [rP, sig(rP, d)] and may be used along with the base public key dP to validate the sub-public key rP and compute the validation public key. The digital signature sig(rP, d) allows an entity to verify that the sub-public key rP has actually been authorized by the KG.

The authorization blob has several advantages over a conventional certificate: the authorization blob is simpler to generate as compared to issuing a certificate which requires a certificate authority and supporting PKI; parsing the authorization blob requires less decoding logic and computing resources; the authorization blob is significantly smaller than a certificate (thirty- three bytes are required to store a compressed NIST P-256 point and a P-256 ECDSA signature is sixty-four bytes long); Their small size allows several authorization blobs to be encoded into a base key certificate. When signing a software image, a partner creates a digital signature over the program data generated with the sub-private key, sig(Data, d+r) and creates a software image that includes both the program data and corresponding digital signature sig(Data, d+r). The software image also includes the sub-public key rP along with a digital signature over the sub-public key generated with the base private key, sig(rP, d). This digital signature sig(rP, d) acts to prove the sub-public key rP, and corresponding sub-private key d+r have been authorized by the KG.

Referring once again to the exemplary apparatus 100, the apparatus 100 is provisioned with the base public key, dP 110. In one embodiment, the base public key, dP 110 may be securely provisioned in the secure memory 106 at manufacturing time. Alternatively, the base public key, dP 110 may be provided in a digital certificate, such as a X.509 certificate and stored locally in the apparatus 100.

To maintain integrity and security of the computing apparatus 100, software images 120 are validated 136 by the processor 102 before they are allowed to execute. This ensures only authorized and trusted software modules are allowed to run on the apparatus 100.

The software image 120 includes a sub-public key 126 associated with the provider of the software image, and a digital signature over the sub-public key 128 generated with the base private key d. The program data 130 is also included in the software image 120 along with a digital signature over the program data 132 generated with the sub-private key. Recall that the base private key d and the corresponding base public key are associated with the KG that is issuing and authorizing the sub-keys, and the sub-private key and corresponding sub-public 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 validate 136 the software image 120 based on information included in the software image 120 and the base public key, dP 110. Validation 136 begins by validating 112 the sub-public key 126 based on the base-public key, dP 110, and the digital signature over the sub-public key 128. Validating 112 the sub-public key 126 ensures the subpublic key 126 has been authorized by the KG.

A validation public key (d+r)P is then computed 114 by applying a finite group operation on the base public key 110 and the sub-public key 126. In one embodiment the finite group operation is implemented using elliptic curve point addition, and validation public key is computed by adding the base public key, dP 110, with the sub-public key rP 126. As discussed above, the validation public key (d+r)P and the sub-private key d+r form a public-private key pair.

The processor 102 validates 116 the program data 130 based on the computed validation public key and the digital signature 132 over the program data. Once the software image is successfully validated 136, it is safe to load and execute the software image 120. If any of the validation steps fail, the software image is determined to be invalid and should not be used.

Multi-partner ecosystems are typically dynamic with partners in the supply chain constantly changing. A secure boot signing solution intended to operate in this dynamic environment needs to provide an efficient method for revoking sub-keys. Revocation of sub-keys is handled by storing revocation information in the secure memory 106 where it can be used while validating software images 120. In an exemplary embodiment, 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 validating 136 a software image 120 to ensure the subpublic key and the corresponding partner are still trusted.

Figure 2 illustrates a flow chart showing an exemplary method 200 for validating a software image including new revocation information incorporating aspects of the disclosed embodiments. The exemplary method 200 is similar to the validation method 136 described above and is appropriate for use in a computing apparatus, such as the apparatus 100, when validating a software image 120 that includes new revocation bits 122. Distribution of revocation information in each software image provides an efficient way to ensure sub-key revocation information is properly maintained on a computing apparatus.

In one exemplary embodiment, update of the revocation information may be facilitated by including new revocation bits 122 in the software image 120. Distributing new revocation bits 122 in the software image 120 allows the current revocation bits 108 to be updated each time a new software image is validated by the apparatus 100. Integrity of the new revocation bits 122 may be established by including a digital signature over the new revocation bits 124 generated with the base private key.

When validating 200 a software image 120, the processor 102 is further configured to validate 202 the new revocation bits 122 based on the digital signature over the new revocation bits 124 using the base public key 110. This validation 202 ensures the new revocation bits 122 were created by the KG and have not been tampered with. The current revocation bits 108 are then updated 204 based on the new revocation bits 122 The sub-public key 126 can be validated 206 against the newly updated current revocation bits 108 to ensure the sub-public key 126 has not been revoked.

The method 200 continues similar to the method 136 described above, by validating 208 the sub-public key rP based on the digital signature over the sub-public key 128, computing 210 a validation public key (d+r)P by adding the base public key dP to the sub-public key rP, and validating 212 the program data using computed the validation public key.

In one embodiment, the secure memory 106 includes an OTP memory 118, where bits can be set at any time, but once a bit is set it can never be reset. An example of this type of OTP memory is an eFuse or electronic fuse memory. eFuse incorporates microscopic fuses into a computer chip and once a fuse is blown it cannot be re-connected. As used herein, the term eFuse or eFuse memory refers to any type of OTP memory where bits can be set at any time, but once a bit is set it can never be reset.

The revocation bits 108 are configured to identify the set of all revoked sub-keys. Advantageously, the revocation bits 108 employ a revocation encoding scheme where adding a newly revoked sub-key to the set of all revoked sub-keys is accomplished by setting one or more bits in the revocation bits 108 and does not require any already set revocations bits 108 to be reset. This revocation encoding scheme allows eFuse type OTP memory to be employed to ensure additional sub-keys can be revoked at any time, but once a sub-key has been revoked it can never be removed from the set of revoked sub-keys. It will be appreciated that any method of encoding revocation information into the revocation bits 108 that satisfies the abovedescribed condition of adding keys by setting bits without resetting bits may be advantageously employed without traying from the spirit and scope of the disclosed embodiments.

A useful property of the sub-keys is that for a random value r, the bit stream of a corresponding sub-public key is nearly uniformly distributed. This allows the KG to construct random r values is such a way that a pre-determined number of LSB of the sub-public key are configured to act 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 rather than the entire sub-public key.

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

For example, in an embodiment employing a predetermined number of n bits of the sub-public key LSB as the key identifier and configuring the revocation bits as a vector of 2ⁿ bits, allows a sub-public key to be revoked by setting one bit in the revocation bits. As a non-limiting example, consider a simple embodiment where the predetermined number of LSB is three, n=3, and the sub-public key to be revoked has its three LSB set to ‘011’ . The bit pattern ‘OI L has an integer value of 3, so setting the third bit in the vector of revocation bits will indicate the subpublic key with identifier of ‘ 011’ has been revoked. When using three LSB as the key identifier, the vector of revocation bits will be eight bits long where each bit corresponds to an integer value of zero to seven.

In an alternate embodiment, the LSB of the sub-public key may be interpreted as a bit mask, and validating the sub-public key is accomplished by comparing the LSB of the sub-public key to the bit mask. For example, assume n=4 and the four LSB of the sub-public key have the bit pattern ‘0110’. This would mean the that sub-public key values where bits 1 and 2 (zero based) are set have been revoked. In this particular example sub-public keys would be rejected when the four LSB start with ‘01’, ‘ 11’, 001, and ‘ 101’.

When the number of revoked subkeys becomes large, the amount of revocation bits increases and can slow down sub-key generation. This may occur in large mature multi-partner ecosystems where many of the sub-keys have been revoked. A beneficial optimization of the revocation bits is to configure the revocation bits as a Bloom filter. A Bloom filter is a data structure that is capable of storing a set of elements, such as the set of revoked sub-public keys, in a compact form. It is a probabilistic data structure that can be tested to determine if a subpublic key is “definitely not in” the set or “possibly in” the set. An important property of Bloom filters is that sub-keys can be added to the Bloom filter set but cannot be removed, thereby preventing revoked sub-keys from being removed from the Bloom filter.

In one embodiment the revocation bits are configured as a Bloom filter representation of the set of revoked sub-public keys. When the revocation bits 108 are a Bloom filter, validating a subpublic key is performed 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 integrity protected memory, such as the secure memory 106. Alternatively, a hash of the Bloom filter may be stored in the secure memory 106.

In one embodiment, checking whether a sub-public key has been revoked, includes validating the new revocation bits 122 against a reference Bloom filter value. When desired, the Bloom filter represented by the new revocation bits 122 may not be exactly the same as the reference Bloom filter. In certain embodiments the Bloom filter represented by the new revocation bits 122 may be stricter than the reference Bloom filter value.

In embodiments where the amount of secure memory 106 is limited, space can be reduced by storing a hash 140 of the base public key 110 in 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 that corresponds to the base public key 110. The base-public key 134 may be provided in the software image 120 and validated during validation of the software image 120 using the stored hash 140. Alternatively, since nonvolatile memory is typically less costly than secure memory, the base public key can be stored in non-volatile memory of the apparatus 100.

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 can also be included in the certificate along with the base public key 110. During validation 136 of a software image 120, the certificate can be validated based on the base public key 110. The sub-public key can then be validated based on the hash value included in the certificate. The benefit of including a hash of the authorized sub-keys in the certificate is that sub-public key authorization information need not be included in distributed software images 120. A drawback of this approach is that the group of sub-keys is static so new sub-keys cannot be used without provisioning a new certificate.

Figure 3 illustrates a diagram of a secure boot loading process 300 configured for use in a multipartner ecosystem incorporating aspects of the present disclosure. The exemplary secure boot loading process 300 is appropriate for use in a computing apparatus 302 such as the exemplary apparatus 100 described above. In the diagram illustrated in Figure 3, solid arrows 326 indicate software components being loaded by other software components, and dashed arrows 324 indicate a software component being produced and signed by a provider. When a computing apparatus starts up, a first stage boot loader 306 is executed to begin loading software modules. In one embodiment the first stage boot loader 306 may be included as firmware stored in ROM by a system on a chip (SoC) provider 304. The first stage boot loader 306 then begins building a 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 (TEE) operating system (OS) provided by a TEE OS provider 318. The hypervisor 308 may then load an OS bootloader 312 provided by a bootloader provider 320 which in turn loads a rich execution environment (REE) OS kernel 314 that may be provided by a REE Kernel provider 322.

Each of these components 306, 308, 310, 312, 314 needs to be validated using for example a validation procedure, such as the validation procedure 136 or 200 described above, to validate a software image, such as the software image 120 described above. Further, each component may be provided by a different provider and be signed with different private keys. It is easy to see how the number of signing keys can become quite large in the multi-partner ecosystem used by a device manufacturer.

Figure 4 illustrate 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 appropriate for signing and verification of software images, such as the software image 120 described above. A KG 402 represents an entity that issues and authorizes sub-keys for partners in a multi-partner ecosystem. The KG 402 may be a manufacturer or industry organization that is trusted by all partners to issue and authorize subkeys for signing and validation of software images. Each partner 404, 406, 408 in the multipartner ecosystem, referred to as Signer 1 404, Signer 1406 and Signer m 408, will sign software images they produce with their own sub-private key. Therefore, a partner can also be referred to as a signer 404, 406, 408. While three signers 404, 406, 408 are shown in the illustration of Figure 4, it will be understood that there can be as few or as many signers as desired and the number of signers can be arbitrarily large. The KG 402 generates sub-key tuples 416, 418, 420, where, as described above, each sub-key tuple includes a sub-key and corresponding authorization blob. Each sub-key tuple 416, 418, 420 is securely distributed to a signer 404, 406, 408 such that only the signer, and when desired, the KG 402 know their sub-private key. The verifier 410 is an entity, such as the computing apparatus 100 described above, that needs to validate or verify a software image 410. The KG 402 also distributes 422, or otherwise makes available, the base public key dP to the verifier 410, thereby allowing the verifier to validate a software image based only on information included in the software image 424 and the base public key dP.

The Verifier 410 receives 424 a software image, such as the software image 120 described above and with reference to Figure 1, that includes a sub-public key and a program data. The verifier 410 validates the sub-public key using the base public key and computes a validation public key by adding the base public key to the sub-public key The verifier 410 then validates the program data based on a digital signature over the program data that is also included in the software image.

Figure 5 illustrates a block diagram showing 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 depicts additional details of the authorized sub-key embodiments disclosed herein.

A KG 502 performs a one-time setup by generating a base private key and computing a corresponding base public key to create a base key pair. The KG 502 then generates a sub-key pair for each partner by generating a random number n and computing a sub-public key riP. When a pattern of LSB of the sub-public key r,P does not match a desired bit pattern, the KG 502 increments the random number n and generates a new sub-public key. This is repeated until the LSB condition is met. The KG 502 also revokes sub-key pairs when 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 produce.

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

The partner 506 creates a software image 524 that includes the signed revocation bits 528, the sub-public key and a corresponding digital signature over the sub-public key generated with the base private key 530, the program data 532, and a signature over the program data 534 generated with the sub-private key.

When a software image 524 is distributed to a device 516, such as the apparatus 100 described above, the device 516 validates the software image based on the base public key 536 and the revocation bits 538 using a suitable validation method, such as the exemplary methods 134 or 200 described above. The device 516 extracts the LSB from the sub-public key and compares them to the revocation bits 538. If the comparison reveals that the sub-public key has been revoked, the validation fails, and the software image is not loaded. When the sub-public key has not been revoked, a validation public key is computed by adding the base public key 536 with the sub-public key and the program data is validated using the validation public key.

Figure 6 illustrates a flow chart of an exemplary method 600 for generating authorized sub-key pairs incorporating aspects of the disclosed embodiments. The exemplary method 600 is appropriate for use by a key authority, such as the KG 502 described above, to generate and distribute authorized sub-keys to partners in a multi-partner ecosystem.

The 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 a seed value according to a key generation method of an elliptic curve digital signature algorithm. Alternatively, the base key pair may be derived based on any suitable DLP based cryptographic system. When generating 602 the base key pair, a base private key d is first generated. The base private key is kept confidential, so it is known only to the KG. Abase public key dP is then generated for example by multiplying an elliptic curve generation point P by the base private key d. The base public key dP is distributed in a trustworthy manner to partners for use when authorizing sub-public keys.

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

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

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

The one or more LSB of the sub-public key may include any desired number of LSB and may be a fixed number of LSB. The pre-determined number of LSB should be large enough to support the number of partners in the multi-partner ecosystem and the number of authorized sub-key pairs to be generated.

Matching 610 of the one or more LSB of the sub-public key to a pre-determined bit pattern may be accomplished in any appropriate fashion. For example, in one non-limiting embodiment the one or more LSB may be matched by testing a Bloom filter. Alternatively, the LSB may be matched against a desired binary integer. In one exemplary embodiment the matching operation is configured to ensure the newly generated sub-public key is not already included in the set of revoked keys indicated by the revocation bits.

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

Figure 7 illustrates a flow chart of an exemplary method 700 for validating a software image incorporating aspects of the disclosed embodiments. The exemplary method 700 of the disclosed embodiments is appropriate for use in the apparatus 100 described above and with reference to Figure 1. The exemplary method 700 provides an improved software image validation method that employs authorized sub-keys to reduce software image size, simplify software image authorization, and provide an efficient key revocation mechanism.

When a computing apparatus, such as the apparatus 100 described above, receives 702 a software image, the software image should be validated before being executed. In the exemplary method 700 the software image includes: new revocation bits, a digital signature over the new revocation bits generated with a base private key, an authorized sub-public key, a digital signature over the authorized sub-public key generated with the base private key, a program data, and a digital signature over the program data generated with an authorized subprivate key.

The new revocation bits are validated 704 based on the base public key, then, when validation succeeds, the new revocation bits are used to update 706 the current revocation bits stored in secure memory within the computing apparatus. As discussed above, it may be advantageous to encode the revocation bits in a way that leverages the properties of an eFuse type OTP memory to ensure that reloading of an older software image will not remove revoked sub-keys from the set of revoked sub-keys indicated by the current revocation bits.

The authorized sub-public key included in the software image can then be verified 708 against current revocation bits. When it is determined that the authorized sub-public key has been revoked, validation of the software image can be terminated and the software image will not be executed. When the authorized sub-public key has not been revoked, validation continues.

Integrity of the authorized sub-public key can be validated 710 using the base public key to verify the digital signature over the authorized sub-public key included in the software image. When signature validation 710 fails, validation of the software image is terminated and the software image will not be executed, and when the validation 710 is successful, validation 700 continues. In one embodiment, integrity of the authorized sub-public key may be verified 710 before validating 708 whether the sub-public key has been revoked. Both these validations 708, 710 must pass for software image validation to continue.

A validation key is computed 712 by applying a finite group operation on the base public key and the authorized sub-public key. When employing ECDSA, the validation key (d+ )P may be computed by using elliptic curve point addition to add the base public key dP with the authorized sub-public key r,P.

It will be appreciated that the above-described software image validation methods can be fully certificateless, thereby eliminating the need to setup and maintain a full PKI infrastructure to support secure boot.

The KG can delegate signing capability to partners by distributing sub-key pairs and authorization blobs. This approach removes a sematic gap as compared to conventional HSM based approaches where an HSM signs every software image. More particularly, a partner or signer of software images can examine metadata included in the software image to understand what is being signed. Beneficially, the signer cannot use the authorized sub-private keys to determine the base private key and cannot compute new authorized sub-private keys. It is also not possible for partners to collaborate with each other to compromise either the base private key or compute new authorized sub-private keys. When desired each partner can be given a large number of authorized sub-private keys. Each key can then be used to sign only one or a small number of software images. This potentially provides improved security by allowing the base private key to be confined to a HSM thereby reducing exposure of the base private key. Thus, while there have been shown, described and pointed out, fundamental novel features of the invention as applied to the exemplary embodiments thereof, it will be understood that various omissions, substitutions and changes in the form and details of devices and methods illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit and scope of the presently disclosed invention. Further, it is expressly intended that all combinations of those elements, which perform substantially the same function in substantially the same way to achieve the same results, are within the scope of the invention. Moreover, it should be recognized that structures and/or elements shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment 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

What is claimed is:

1. An apparatus (100) comprising a processor (102) and a memory (104), wherein the memory (104) comprises a software image (120) and the software image (120) comprises: a sub-public key (126); a digital signature (128) over the sub-public key generated with a base-private key; program data (130); and a digital signature (132) over the program data generated with a sub-private key; wherein the processor (102) is configured to validate the software image (120)by: validating the sub-public key (126) based on the digital signature (128) over the sub-public key (126) and the base public key (110); computing a validation public key by applying a finite group operation on the base public key (110) and the sub-public key (126); and validating the program data (130) based on the digital signature (132) over the program data and the validation public key, wherein the base private key and the base public key (110) form a public-private key pair, and the sub-private key and the validation public key form a public-private key pair.

2. The apparatus (100) according to claim 1 further comprising a one-time programmable memory (106), and the software image (120) further comprises: new revocation bits (122); and a digital signature over the new revocation bits (124) generated with the base private key, and wherein validating the software image (120) further comprises: validating the new revocation bits (122) based on the digital signature (124) over the new revocation bits and the base public key (110); updating current revocation bits (108) based on the new revocation bits (122), wherein the current revocation bits (108) are stored in the one-time programmable memory (106); and validating the sub-public key (126) based on the updated current revocation bits

(106).

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

4. The apparatus (100) of any one 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 identity of the sub-public key (126) and the plurality of least significant bits are equal to a predetermined bit pattern.

5. The apparatus (100) of claim 4 wherein the current revocation bits (108) comprise a vector of bits and the plurality of least significant bits represent an integer identifying one bit in the vector of bits and validating the sub-public key (126) is based on the identified one bit.

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

7. The apparatus (100) of claim 4 wherein the current revocation bits (108) comprise a Bloom filter and validating 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 one of the preceding claims wherein the one-time programmable memory (106) comprises a hash of the base public key, the software image (120) comprises the base public key (134) and validating the software image comprises verifying the hash of the base public key based on the base public key (134).

9. The apparatus (100) of any one of the preceding claims wherein the base public key (110) is provisioned in a certificate, wherein the certificate comprises a hash of the sub-public key and validating the image (120) comprises verifying the sub-public key (126) based on the hash of the sub-public key. he apparatus (100) of any one of the preceding claims wherein the base public key (110) and the base private key correspond to an elliptic curve based public key cryptographic system. method (600) comprising: generating (602) a base key pair, wherein the base key pair corresponds to an elliptic curve based public key cryptographic system; generating (620) a sub-key pair; updating (614) a revocation bits; distributing (616) the sub-key pair and revocation bits, and repeating (618) the generating a sub-key pair (620), updating revocation bits (614) and distributing the sub-key pair and revocation bits (616) steps one or more times, wherein generating (616) a sub-key pair comprises: generating (606) a random number; computing (608) a sub-public key based on the random number; repeating the generating (606) a random number and computing (608) a sub-public key steps until a one or more least significant bits of the sub-public key matches a predetermined bit pattern; and computing (616) a sub-private key corresponding to the sub-public key. he method (600) of claim 11 wherein the revocation bits comprise an array of one or more bits, and a revoked sub-public key comprises a plurality of least significant bits configured to identify one bit in the array of one or more bits, and wherein updating (614) the revocation bits comprises setting the one bit in the array of one or more bits corresponding to the revoked sub-public key. he method (600) of claim 11 wherein the revocation bits comprise a Bloom filter and updating (614) the revocation bits comprises adding a revoked sub-public key to the Bloom filter. method (700) comprising: receiving (702) a software image, wherein the software image comprises: new revocation bits, a digital signature over the new revocation bits generated with a base private key, an authorized sub-public key, a digital signature over the authorized sub-public key generated with the base private key, a program data, and a digital signature over the program data generated with an authorized sub-private key, wherein the authorized subprivate key corresponds to the authorized sub-public key; validating (704) the new revocation bits based on the digital signature over the new revocation bits and the base public key; updating (706) current revocation bits based on the new revocation bits; validating (708) the sub-public key based on the updated current revocation bits, validating (710) the authorized sub-public key based on the digital signature over the authorized sub-public key and the base private key; computing (712) a validation key by applying a finite group operation on the base public key and the authorized sub-public key; and validating (714) the program data based on the digital signature over the program data and the validation key. computer program product comprising a non-transitory computer readable storage media having stored thereon program instructions, which when executed by a processor cause the processor to perform the method according to any one of the preceding claims 11 through 14.