Apparatus, apparatus, method and computer program for providing certificate chain

Abstract

The present disclosure describes an apparatus, a device, a method and a computer program for providing a certificate chain. Examples relate to an apparatus, a device, a method, and a computer program for a computing device for providing a certificate chain, and to a computing device. In one embodiment, an apparatus includes processor circuitry to: obtain information related to an identity of firmware being used to operate a computing device; generating a leaf certificate for the firmware being used to operate the computing device based on the identity of the firmware being used to operate the computing device, and using an intermediate certificate generated based on the identity of the firmware that has been used during cold boot of the computing device; and providing the certificate chain including the leaf certificate for the external verifier.

Description

Background Art

[0001] Seamless updates are often applied when firmware running on a data center System-on-Chip (SoC) is found to be vulnerable and is to be updated to a newer version that fixes this vulnerability. However, security models may not be able to verify the security enhancements of the seamlessly patched firmware beyond the boot-time firmware. This undermines the value of seamless patching because a server reboot is required for the security enhancement to become verifiable. But server reboots take a long time and should be avoided. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Some examples of apparatus and / or methods will be described below by way of example only and with reference to the accompanying drawings, in which:

[0003] Figure 1a schematic diagrams showing examples of apparatus or devices for computing devices, and schematic diagrams showing examples of computing devices including such apparatus or devices;

[0004] Figure 1b A flowchart illustrating an example of a method for a computing device;

[0005] Figure 2 A schematic diagram illustrating seamless firmware updates;

[0006] Figure 3 A schematic diagram showing derivation of two persistent keys and a leaf alias private key from a read-only memory (ROM) during a cold boot;

[0007] Figure 4 A schematic diagram showing the relationship between private keys, public keys and certificates;

[0008] Figure 5 The Device Identifier Composition Engine (DICE) certificate chain before the first seamless update is shown;

[0009] Figure 6 A schematic diagram showing the derivation of a new leaf alias private key by the ROM firmware during a seamless update;

[0010] Figure 7 shows the DICE certificate chain after seamless update; and

[0011] Figure 8 An example flow for cold boot and seamless update is shown. DETAILED DESCRIPTION

[0012] Some examples are now described in more detail with reference to the accompanying drawings. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of features and equivalents and alternatives of features. In addition, the terms used to describe certain examples herein should not limit further possible examples.

[0013] Throughout the description of the drawings, the same or similar reference numerals refer to the same or similar elements and / or features, which may be the same or implemented in a modified form while providing the same or similar functions. For clarity, the thickness of lines, layers and / or regions in the drawings may also be exaggerated.

[0014] When two elements A and B are combined using "or", this is to be understood as disclosing all possible combinations, i.e., only A, only B, and A and B, unless otherwise explicitly defined in individual cases. As an alternative wording for the same combination, "at least one of A and B" or "A and / or B" may be used. This applies equally to combinations of more than two elements.

[0015] If singular forms such as "a / an" and "the" are used and the use of only a single element is neither explicitly nor implicitly defined as mandatory, further examples may also use several elements to achieve the same function. If a function is described below as being achieved using multiple elements, further examples may use a single element or a single processing entity to achieve the same function. It is further understood that when the term "include", "including", "comprise" and / or "comprising" is used, it describes the presence of specified features, integers, steps, operations, processes, elements, components and / or groups thereof, but does not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or groups thereof.

[0016] In the following description, specific details are set forth, but examples of the techniques described herein may be implemented without these specific details. Well-known circuits, structures, and techniques are not shown in detail to avoid obscuring an understanding of the present description. “An example / example,” “various examples / examples,” “some examples / examples,” and the like may include features, structures, or characteristics, but not every example necessarily includes these particular features, structures, or characteristics.

[0017] Some examples may have some, all, or none of the features described for other examples. "First," "second," "third," and the like describe common elements and indicate different instances of similar elements being referenced. Such adjectives do not imply that the elements so described must be in a given order, either temporally or spatially, in ranking, or in any other way. "Connected" may indicate that elements are in direct physical or electrical contact with each other, and "coupled" may indicate that elements cooperate or interact with each other, but these elements may or may not be in direct physical or electrical contact.

[0018] As used herein, the terms "operate," "execute," or "run" are used interchangeably when referring to software or firmware associated with a system, device, platform, or resource, and may refer to software or firmware stored in one or more computer-readable storage media accessible by a system, device, platform, or resource, even if the instructions contained in the software or firmware are not being actively executed by the system, device, platform, or resource.

[0019] The specification may use the phrases "in an example / example", "in various examples", "in some examples / examples", and / or "in various examples / examples", each of which may refer to one or more of the same or different examples. In addition, the terms "comprising", "including", "having", etc. as used with respect to the examples of the present disclosure are synonymous.

[0020] Figure 1a A schematic diagram of an example of an apparatus 10 or apparatus 10 for use in a computing device 100 is shown. Apparatus 10 includes circuitry for providing the functionality of apparatus 10. For example, the circuitry of apparatus 10 may be configured to provide the functionality of apparatus 10. For example, Figure 1a The apparatus 10 includes an interface circuit system 12, a processor circuit system 14, and (optionally) a memory / storage circuit system 16. For example, the processor circuit system 14 may be coupled to the interface circuit system 12 and / or to the memory / storage circuit system 16. For example, the processor circuit system 14 may provide the functionality of the apparatus in combination with the interface circuit system 12 (for communicating with other entities inside or outside the computing device 100) and the memory / storage circuit system 16 (for storing information such as machine-readable instructions). Similarly, the device 10 may include a device for providing the functionality of the device 10. For example, the device may be configured to provide the functionality of the device 10. The components of the device 10 are defined as component devices that may correspond to or be implemented by corresponding structural components of the device 10. For example, Figure 1a The device 10 includes: means 14 for processing, which may correspond to or be implemented by the processor circuit system 14; means 12 for communication, which may correspond to or be implemented by the interface circuit system 12; and (optionally) means 16 for storing information, which may correspond to or be implemented by the memory or storage circuit system 16. In general, the functions of the processor circuit system 14 or the means for processing 14 can be implemented by the processor circuit system 14 or the means for processing 14 executing machine-readable instructions. Therefore, any features attributed to the processor circuit system 14 or the means for processing 14 can be defined by one or more instructions of a plurality of machine-readable instructions. The device 10 or apparatus 10 may include machine-readable instructions 16a (e.g., within the memory or storage circuit system 16 or the means for storing information 16).

[0021] The processor circuit system 14 or the means for processing 14 is used to obtain information related to the identity of the firmware being used to operate the computing device. The processor circuit system 14 or the means for processing 14 is used to generate a leaf certificate for the firmware being used to operate the computing device based on the identity of the firmware being used to operate the computing device and using an intermediate certificate generated based on the identity of the firmware that has been used during a cold boot of the computing device. The processor circuit system 14 or the means for processing 14 is used to provide a certificate chain to an external validator, the certificate chain including the leaf certificate.

[0022] In some examples, the memory or storage circuitry 16 or means for storing information 16 includes at least one portion 16b; 16c that is inaccessible during normal operation of the apparatus 10, device 10, or computing device 100. For example, the memory or storage circuitry 16 or means for storing information 16 may include a portion 16b; 16c that is accessible during a cold boot of the computing device or after a seamless update of the computing device. In some embodiments, a first sub-portion 16b of the portion may be accessible only during a cold boot of the computing device (and used to store a unique device secret of the computing device), and a second sub-portion 16c may be accessible during a cold boot and after a seamless update (e.g., during a warm boot / reset).

[0023] Figure 1aA computing device 100 including the apparatus 10 or device 10 is further shown. For example, the computing device 100 may be a computer system such as a server computer system, a workstation computer system, a desktop computer system, a laptop computer system, or an Internet of Things (IoT) computer system. Alternatively, the computing device 100 may be a mobile device such as a smart phone, a tablet computer, a wearable device, or a vehicle.

[0024] Figure 1b A flowchart of an example of a corresponding method for a computing device 100 is shown. The method includes: 120: obtaining information related to the identity of the firmware being used to operate the computing device. The method includes: 130: generating a leaf certificate for the firmware being used to operate the computing device based on the identity of the firmware being used to operate the computing device and using an intermediate certificate generated based on the identity of the firmware that has been used during a cold boot of the computing device. The method includes: 140: providing a certificate chain including the leaf certificate to an external validator. For example, the method can be performed by the computing device 100, such as by the apparatus 10 or device 10 of the computing device 100.

[0025] In the following, features of the apparatus 10, devices 10, computing devices 100, methods and computer programs will be described in more detail with reference to the apparatus 10. Features introduced in connection with the apparatus 10 may also be introduced in the corresponding devices 10, computing devices 100, methods and computer programs.

[0026] Various examples of the present disclosure relate to the generation of a leaf certificate for the firmware of a computing device, and to the provision of a certificate chain that includes the leaf certificate. This is generally performed as part of device authentication. Device authentication is a process for verifying the authenticity and integrity of a device. It involves generating a unique identifier (commonly referred to as a device ID or fingerprint) for a device and then confirming its authenticity to a trusted entity (such as a server or service). This ensures that only trusted devices are allowed to access certain resources or services on a server or service. Device authentication typically involves the use of cryptographic techniques (such as digital signatures or certificates) to securely prove the identity of the device. In the current context, a leaf certificate and certificate chain are used for device authentication purposes to prove to an external entity that the computing device is trustworthy, for example, to indicate that the computing device is operating using firmware that does not include known vulnerabilities. Accordingly, a certificate chain including a leaf certificate can be provided to an external verifier as part of a device authentication protocol.

[0027] For example, device authentication using a certificate chain can be performed by creating a so-called hardware root of trust certificate chain. The certificate chain starts with a root certificate issued by a root certificate authority (usually the hardware vendor), which is used to sign or verify the authenticity and identity of the hardware root of trust itself. The certificate chain includes one or more further intermediate certificates (such as Figure 5 and Figure 7 The intermediate and leaf certificates are part of a hardware trusted root certificate chain. Figure 5 In , the leaf certificate is represented as a boot-time firmware (BTFW) leaf alias certificate 560 and is generated for firmware used during a cold boot of a computing device; in Figure 7 In FIG. 1 , the leaf certificate is represented as a new firmware (NFW) leaf alias certificate 760, which is generated for the firmware used to operate the computing device after the seamless update. In addition, the certificate chain (including certificates 510-540, 560 and certificates 710-740, 760, respectively) includes an intermediate certificate. Figure 5 and Figure 7 In the figure, it is represented as BTFW intermediate CA certificate 540, 740.

[0028] In a specific implementation, the proposed concept is used to improve the security of the Device Identifier Composition Engine (DICE) certificate chain. Accordingly, the hardware trust root certificate chain can be the DICE certificate chain. The Device Identifier Composition Engine is a software or firmware mechanism or module responsible for generating and managing unique identifiers for devices. It is typically used in systems that require device identification for various purposes, such as device management, security, and authentication.

[0029] from Figure 5 and Figure 7It can be clearly seen that although the proposed concept can also be used for computing devices on which firmware updates have been applied only during cold boot, the motivation behind the proposed concept is the use of seamless updates. Seamless updates are updates to the firmware of a computing device that do not require a cold boot of the computing device (which may require a considerable amount of time) but can be applied at runtime or applied using a hot boot. However, such seamless updates may provide an interface for device authentication because the device secrets required to generate a leaf certificate are only accessible during a cold boot for security reasons. Specifically, in some other concepts, a unique device secret (UDS) may be used to generate a leaf certificate. However, the unique device secret may not be available after a cold boot of the computing device.

[0030] In the proposed concept, another certificate can be used as an intermediate certificate (in Figure 5 and Figure 7 This limitation can be circumvented by adding an intermediate CA certificate 540, 740 (shown as BTFW in FIG. 1 ) to the root of trust. In the proposed concept, the intermediate certificate is generated using UDS and is subsequently used to derive information used to sign the leaf certificate. As a further reference, in addition to UDS, the identity of the firmware used during the cold boot (e.g., the firmware version number and / or a hash of the firmware) can also be used to generate the intermediate certificate, thereby including not only information related to the firmware currently used to operate the computing device but also information related to the firmware used during the cold boot of the computing device into the certificate chain. In fact, the intermediate certificate can be generated based on the unique device secret of the computing device and based on the identity of the firmware that has been used during the cold boot of the computing device.

[0031] Obviously, at least the intermediate certificates are generated during a cold boot of the computing device. In various examples, the various certificates and keys used for the proposed concept are prepared (and stored) during a cold boot for use during a cold boot (to generate a leaf certificate for the firmware used during the cold boot) and after a seamless update (to generate a leaf certificate for the firmware installed by the seamless update).

[0032] exist Figure 4 In , an overview of various certificates, public and private keys, and seeds used in some examples of the proposed concept is given. Figure 4A UDS 410 and identity 420 of firmware (boot-time firmware (BTFW)) used during a cold boot of a computing device are shown, which may be used to generate an intermediate alias private key 422 that is used to: a) sign a leaf alias certificate 446, and b) generate an intermediate certificate 426 (by deriving an intermediate public key 424 included in the intermediate certificate 426). Additionally, a Seed_for_Leaf 430 (a seed for generating a leaf certificate) is shown, which is later used to generate a leaf private key 442 from which a leaf public key 444 included in the leaf certificate 446 is derived. In practice, the processor circuitry may use the intermediate certificate and use the seed to generate a leaf certificate. For example, Figure 4 As shown in , intermediate certificate 422 may be used to generate (eg, sign, endorse) a leaf certificate 446 and includes a leaf public key 444 derived from seed 430 and identity 440 of the firmware being used to operate the computing device.

[0033] The components (422, 424, 426, and 430) may be generated (and stored) during a cold boot of the computing device, for example, so that the UDS 410 does not have to be unlocked after a cold boot, and so that the Seed_for_Leaf 430 cannot be changed after a cold boot. The processor circuit system may generate the intermediate certificate (and thereby generate the public key associated with the intermediate certificate), the private key associated with the intermediate certificate, and the seed for generating the leaf certificate during a cold boot of the computing device. Accordingly, as Figure 1b As further shown in , the method may include: 114: During a cold boot of the computing device, generating an intermediate certificate, a private key associated with the intermediate certificate, and a seed for generating a leaf certificate. The processor circuit system may store the intermediate certificate, the private key associated with the intermediate certificate, and the seed in a portion 16b; 16c (e.g., a second sub-portion 16c of the portion) of the storage circuit system 16 that is accessible (only) during a cold boot of the computing device or after a seamless update of the computing device. Accordingly, as Figure 1b As further shown in , the method may include: 116: storing the intermediate certificate, the private key associated with the intermediate certificate, and the seed in a portion 16b of the storage circuit system 16 that is accessible (only) during a cold boot of the computing device or after a seamless update of the computing device. The identity 420 of the boot-time firmware and the identity 440 of the currently running firmware (which are the same during a cold boot) are common (and static for the respective firmware) information and do not have to be generated during a cold boot.

[0034] In addition to the intermediate certificates (and corresponding keys), device identifier keys 412, 414 and device identifier certificate 416 may also be generated based on the unique device secret during a cold boot of the computing device. The processing circuit system may derive the device identifier private key (and the corresponding public key 414 and certificate 416 from the device identifier private key 412) from the unique device secret of the computing device during a cold boot of the computing device. Accordingly, as Figure 1b As further shown, the method may include: 112: deriving a device identifier private key from a unique device secret of the computing device during a cold boot of the computing device. Now, the intermediate certificate may be signed or endorsed by the device identifier private key.

[0035] The intermediate certificate (or more precisely, the private key associated with the intermediate certificate) can now be used to generate a leaf certificate based on the identity of the firmware being used to operate the computing device (at the time the leaf certificate is being generated). As outlined above, the identity of the firmware may include an identifier of the firmware (e.g., a version number) and / or a hash value characterizing the firmware. For example, the identity of the firmware being used to operate the computing device ( Figure 4 Information about the identity 440 of the running firmware in the computing device can be read from the firmware being used to operate the computing device. The processor circuit system generates a leaf certificate for the specific firmware, for example, by following the steps of: deriving a leaf private key 442 from the seed 430 and the identity 440 of the firmware being used to operate the computing device, deriving a leaf public key 444 from the leaf private key 442, including the leaf public key 444 in the leaf certificate 446, and signing / endorsing the leaf certificate 446 using the private key 422 associated with the intermediate certificate 426. As outlined above, the process can be repeated for each firmware being used to operate the computing device (e.g., for the firmware being used for cold boot) and for any subsequent firmware applied by seamless firmware update. In other words, the processor circuit system can generate a leaf certificate for the firmware used after the seamless firmware update after the seamless firmware update. For example, the firmware used after the seamless firmware update can be different from the firmware that has been used before the seamless update, and the firmware that has been used before the seamless update can be the firmware used during the cold boot of the computing device or another firmware applied during a previous seamless firmware update. In some examples, it is even possible that the firmware applied in the firmware update corresponds to the firmware used during the cold boot of the computing device, for example if another firmware is applied using a seamless firmware update and a subsequent seamless firmware update (which is a downgrade) to the firmware used during the cold boot is applied.

[0036] The main application of the proposed concept is the subsequent generation of leaf certificates for firmware used during a cold boot and any firmware applied by a seamless update. In this case, the processor circuit system can generate a first leaf certificate for firmware that has been used during a cold boot of the computing device (i.e., boot-time firmware) during a cold boot of the computing device, and generate a second leaf certificate for firmware used after a seamless firmware update (i.e., new firmware) after a seamless firmware update.

[0037] The interface circuit system 12 or the means for communicating 12 may correspond to one or more inputs and / or outputs for receiving and / or transmitting information within a module, between modules, or between modules of different entities, which information may be in the form of digital (bit) values ​​according to a specified code. For example, the interface circuit system 12 or the means for communicating 12 may include a circuit system configured to receive and / or transmit information.

[0038] For example, the processor circuit system 14 or the means for processing 14 may be implemented using one or more processing units, one or more processing devices, any means for processing (such as a processor, a computer, or a programmable hardware component that can operate with correspondingly adapted software). In other words, the described functions of the processor circuit system 14 or the means for processing may also be implemented using software, which is then executed on one or more programmable hardware components. Such hardware components may include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0039] For example, the memory or storage circuit system 16 or the device 16 for storing information can be a volatile memory, such as a random access memory (such as a dynamic random-access memory (DRAM)), and / or can include at least one element of the group of computer-readable storage media, which computer-readable storage media is such as a magnetic or optical storage medium, for example, a hard drive, a flash memory, a floppy disk, a random access memory (Random Access Memory, RAM), a programmable read only memory (Prom), an erasable programmable read only memory (Erasable Programmable Read Only Memory, EPROM), an electrically erasable programmable read only memory (Electronically Erasable Programmable Read Only Memory, EEPROM) or a network storage device.

[0040] with the proposed concept or the context above or below (e.g. Figures 2 to 8 ) In conjunction with one or more examples described in the foregoing, the apparatus 10, device 10, computing device 100, method and computer program are mentioned for more details and aspects. The apparatus 10, device 10, computing device 100, method and computer program may include one or more additional optional features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.

[0041] Examples of the present disclosure relate to concepts of certificate chain building (eg, Device Identifier Composition Engine (DICE) certificate chain building) for seamless firmware updates.

[0042] The Caliptra specification (a specification for an open source silicon root of trust (RoT)) states that the DICE certificate chain created for "Old Firmware (OFW)" (usually boot-time firmware) should be preserved across seamless updates "because it is insecure to unlock the Unique Device Secret (UDS) again and it is not feasible to extend the DICE hierarchy with measurements from the new firmware." In other words, the alias key and alias certificate corresponding to the OFW are passed to the "New Firmware (NFW)" (the firmware installed via seamless updates) and used by the NFW. The NFW uses the alias key and certificate to report its own measurements to the authenticator via the Security Protocol and Data Model (SPDM). This is done in the context of a seamless update. Figure 2 Shown in.

[0043] Figure 2 Schematic diagram showing seamless firmware update according to the Caliptra specification. Figure 2 On the left is shown a security intellectual property (IP) block 200 which includes a DICE chain for the OFW, which is then also used for the NFW after a seamless update. The verifier 210 (shown on the right) issues a GET_CERT command to the security IP 200, which responds with a DICE certificate chain based on the OFW. The verifier 210 then issues a GET_MEASUREMENTS command, where the security IP block 200 responds with an identifier for the NFW. According to the specification, the OFW may report the identity of the NFW (or any ID of the firmware, if it wishes), which may be considered to compromise security. If the OFW is vulnerable (recall that this is exactly why seamless updates are applied), the verifier in the Caliptra approach (such as Figure 2 If the OFW is not authenticated by the authenticator (as shown), there is no way to confirm that a seamless update to the NFW actually occurred. A vulnerable OFW can report the identity of the NFW to the authenticator (or rather, the identity of any firmware that the authenticator will accept) and pretend that the update has occurred. This could lead to serious security consequences if the authenticator trusts the report and loads the asset into the security IP 200 that is still running the OFW.

[0044] The proposed concept introduces an intermediate layer in the DICE certificate chain. In the proposed concept, when the DICE certificate chain is obtained from the security engine after seamless update, the DICE certificate chain is based on the intermediate layer. By using the intermediate layer, the proposed concept does not need to unlock the UDS at runtime, but can still issue an alias certificate with the measurement of the NFW after seamless update. Therefore, the proposed concept solves the security problem.

[0045] Examples of the present disclosure are based on using an intermediate certificate authority (CA) that reflects the boot-time firmware to issue an alias certificate to the current runtime firmware before or after a seamless update. The intermediate CA can be revoked using a dedicated certificate revocation list (CRL).

[0046] In the following, the construction of the certificate chain during boot (DICE) is explained. During manufacturing, the vendor provides the UDS (unique for each component) and the associated certificate to the Read-Only Memory (ROM) of the security IP. The serial number of the certificate is unique for each component.

[0047] Figure 3 Schematic diagram showing the derivation of two persistent keys and a leaf alias private key by a read-only memory during a cold boot. Figure 3As shown, during a (cold) boot, the ROM derives two persistent keys from the boot-time firmware (BTFW) UDS 310 and identity 320: a "seed for leaf" ("S") 340 (using key generation block 330 and a "leafseed" seed), which is used together with the runtime firmware identity 320 to generate 370 a leaf alias (private) key 380. In other words, the ROM also derives a "leaf alias private key for BTFW" ("K1") from S and the identity of the BTFW. In addition, the ROM uses the key generation block 350 to derive a persistent key "intermediate alias private key" ("PK"), which is used to sign and publish leaf alias certificates. Seed_for_Leaf (S) 340 and the intermediate alias private key 360 are stored in a portion of memory that only the ROM can call during a cold boot and seamless update. "Persistent" here refers to the fact that the two keys are stored in a dedicated key storage hardware block and their values ​​do not change across seamless updates. The UDS is open for ROM use only during a cold boot. Thereafter, the UDS is locked until the next cold boot.

[0048] S and PK reflect the identity of the BTFW (i.e., before the first seamless update). At boot time and during seamless updates, S will be used as a seed to derive the leaf alias private key for the firmware that will be running. S 340 itself can be generated or derived from the following values: UDS 310, the identity of the BTFW (which can be a firmware version, security version, a hash of the firmware binary, or some other identity), and the seed string ( Figure 3 "leaf-seed" or some other string in .

[0049] At boot time and during seamless updates, the PK can sign the leaf alias certificate for the running firmware. The PK itself can be generated or derived from the following values ​​- UDS 310, the identity of the BTFW 320, another substring ( Figure 3 or some other string different from the seed string S). Figure 4 The diagram in FIG. 1 illustrates the relationship between each private key, the corresponding public key, and the certificates containing these public keys. Figure 4 A diagram showing the relationship between private keys, public keys, and certificates. Figure 4As shown in FIG. 4 , UDS 410 can be used to derive a device identifier (DevID) private key 412 and used together with the boot-time firmware identity 420 to derive an intermediate alias private key (PK) 422. DevID private key 412 can be used to derive DevID public key 414, which is included in DevID certificate authority (CA) 416 (i.e., certificate). Intermediate alias private key 422 can be used to derive intermediate alias public key 424, which is included in boot-time firmware intermediate CA certificate 426, which can be signed / endorsed by DevID private key 412. Seed_for_leaf 430 and the identity 440 of the running firmware (boot-time firmware or new firmware) can be used to derive a leaf alias private key (K1 or K2) 442, which can then be used to derive a leaf alias public key 444, which can be included in a leaf alias certificate 446 (signed / endorsed by the intermediate alias private key 422).

[0050] Figure 5 The DICE certificate chain before the first seamless update is shown. The certificate chain includes the root CA 510, one or more intermediate CAs 520 (external to the computing device), the DevID CA 530, the boot-time firmware intermediate CA certificate 540 (associated with the PK), and the boot-time firmware leaf alias certificate 560 (which is signed by the ROM during boot using the intermediate alias private key (PK) 550). The identity of the boot-time firmware can be recorded in the DiceTcbInfo extension of the leaf certificate for verification by an external verifier during validation. Figure 5 It is obvious that the intermediate CA certificate 540 may not only be used after seamless update, but also be used for the leaf certificate of the firmware at boot time. In this way, the certificate chain layer is consistent before and after seamless update, thereby simplifying the implementation of the verifier.

[0051] In the following, the construction of the certificate chain during seamless update (DICE) is discussed. Figure 6 As shown in FIG. 6 , during a seamless update, the ROM (using key generation block 630 ) derives a new leaf alias private key 640 (denoted as K2 ) for the NFW from S 610 and from the identity 620 of the NFW. Figure 6 Schematic diagram showing the ROM firmware deriving a new leaf alias private key during a seamless update.

[0052] Figure 7The DICE certificate chain after a seamless update from OFW (boot time firmware) to NFW is shown. The ROM calls the PK to sign the new leaf alias certificate. The certificate chain includes a root CA 710, one or more intermediate CAs 720 (outside the computing device), a DevID CA 730, a boot time firmware intermediate CA certificate 740 (associated with the PK), and a NFW leaf alias certificate 760 (which is signed by the ROM using the intermediate alias private key (PK) 750 during the seamless update). The identity of the NFW can be recorded in the DiceTcbInfo extension of the leaf certificate for verification by an external verifier during verification. The intermediate CA is not updated and remains to reflect the identity of the BTFW because the PK is derived using the identity of the BTFW.

[0053] In the following, the key storage hardware blocks and the overall flow are shown. Figure 8 An example process for cold boot and seamless update is shown. To support key and certificate generation, a key storage hardware block 820 with the following properties can be implemented: ROM or firmware can generate keys into key slots of key storage. Keys in the key slots can be called by ROM or firmware for cryptographic operations (such as key generation and signature generation), but cannot be read out. The values ​​in all key slots may be lost when power is off. A "close access" attribute can be supported for each key slot: ROM or firmware can set a "close access" attribute for a specific key slot to prevent access to the key slot (including providing new values, deleting current values, or calling values ​​for cryptographic operations) until a hot reset. Access can be automatically reopened upon a hot reset.

[0054] During a cold boot 810, the key storage hardware block 810 may: 825: open access to the S and PK key slots; and 832: the ROM 830 will check if S and PK exist in the key storage; 834: if S and PK are not found in the key storage, then S and PK (according to Figure 3 ) into its key slot. After deriving K1 and signing the BTFW leaf alias certificate with PK, proceed 838: ROM 830 closes access to S and PK to prevent access from BTFW.

[0055] After seamless update 840, proceed 845: OFW may copy NFW to memory and trigger warm reset 810, and pass control back to ROM 830. At warm reset, proceed 825: key slots for S and PK may be reopened. ROM 830 finds S and PK available in key storage and understands that this is a seamless update flow (not a cold boot). Next, ROM may perform necessary operations 836 to load NFW (such as verifying the vendor's signature on NFW), derive K2 from S (according to Figure 6 ), and use PK to sign the NFW leaf alias certificate (according to Figure 7 ). ROM 830 may then shut down access to S and PK to prevent access from NFW. Even if OFW is damaged and does not trigger a hot reset, OFW may not be able to generate a NFW leaf alias certificate and maliciously authenticate itself as NFW to the verifier because OFW cannot access PK.

[0056] In some examples of the proposed concept, revocation and recovery can be considered. The reason for not unlocking the UDS during seamless updates is to protect the UDS from potential corruption in the event that there is a vulnerability in the ROM that could expose secrets at runtime. Therefore, the scenario of a ROM vulnerability that exposes S and / or PK (secrets available to the ROM) at runtime can also be considered. Fortunately, S and PK are derived from the identity of the BTFW and are therefore revocable and recoverable.

[0057] Two types of ROM vulnerabilities can be considered. If a ROM vulnerability can be patched by firmware, the firmware version that does not include the patch for the ROM vulnerability can be revoked in the certificate revocation list (CRL). Such firmware itself may not contain any known vulnerabilities. If the ROM vulnerability cannot be patched by firmware, the platform may no longer perform secure seamless updates. The vendor can issue a security advisory and require customers to always run a full firmware update (which requires a reboot) to patch the firmware vulnerability.

[0058] When a firmware version is revoked (due to a firmware vulnerability and / or missing ROM patch), both its BTFW intermediate CA certificate and leaf alias certificate may be revoked. Since these two certificates are issued by different CAs, vendors can appeal to two CRLs separately to revoke these certificates.

[0059] In combination with the proposed concept or the above or below (for example, Figure 1a to Figure 1b ) One or more examples described herein mention more details and aspects of the concept of certificate chain construction. The concept of certificate chain construction may include one or more additional optional features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.

[0060] In the following, some examples of the proposed concept are presented:

[0061] An example (e.g., Example 1) relates to an apparatus (10) for a computing device (100), the apparatus comprising an interface circuit system (12), machine-readable instructions, and a processor circuit system (14), the processor circuit system (14) being used to execute the machine-readable instructions to: obtain information related to the identity of firmware being used to operate the computing device; generate a leaf certificate for the firmware being used to operate the computing device based on the identity of the firmware being used to operate the computing device and using an intermediate certificate generated based on the identity of the firmware that has been used during a cold boot of the computing device; and provide a certificate chain including the leaf certificate to an external validator.

[0062] Another example (e.g., Example 2) relates to the preceding example (e.g., Example 1) or to any other example, further including, a processor circuit system for executing machine-readable instructions to perform: after a seamless firmware update, generating a leaf certificate for firmware used after the seamless firmware update.

[0063] Another example (eg, Example 3) relates to the preceding example (eg, Example 2) or to any other example, further comprising: the firmware used after the seamless firmware update is different from the firmware that had been used during a cold boot of the computing device.

[0064] Another example (e.g., Example 4) relates to the preceding example (e.g., Example 3) or to any other example, further including, a processor circuit system for executing machine-readable instructions to: during a cold boot of a computing device, generate a first leaf certificate for firmware that has been used during a cold boot of the computing device; and after a seamless firmware update, generate a second leaf certificate for firmware that is used after the seamless firmware update.

[0065] Another example (e.g., Example 5) relates to the aforementioned examples (e.g., one of Examples 1 to 4) or to any other example, further including, a processor circuit system for executing machine-readable instructions to: generate an intermediate certificate, a private key associated with the intermediate certificate, and a seed for generating a leaf certificate during a cold boot of the computing device; and use the intermediate certificate and use the seed to generate a leaf certificate.

[0066] Another example (e.g., Example 6) relates to the preceding example (e.g., Example 5) or to any other example, further including: the intermediate certificate is generated based on a unique device secret of the computing device and based on the identity of firmware that has been used during a cold boot of the computing device.

[0067] Another example (eg, Example 7) relates to the preceding example (eg, Example 6) or to any other example, further comprising: the unique device secret is not available after a cold boot of the computing device.

[0068] Another example (e.g., Example 8) relates to the preceding examples (e.g., one of Examples 5 to 7) or to any other example, further including: the leaf certificate is generated using an intermediate certificate, and the leaf certificate includes a leaf public key derived from a seed and an identity of the firmware being used to operate the computing device.

[0069] Another example (e.g., Example 9) relates to the preceding examples (e.g., one of Examples 5 to 8) or to any other example, further including that the apparatus includes a storage circuit system, wherein the processor circuit system is used to execute machine-readable instructions to: store an intermediate certificate, a private key associated with the intermediate certificate, and a seed in a portion (16b) of the storage circuit system (16) that is accessible during a cold boot or after a seamless update of the computing device.

[0070] Another example (e.g., Example 10) relates to the preceding example (e.g., one of Examples 1 to 9) or to any other example, further comprising: a processor circuit system for executing machine-readable instructions to perform: during a cold boot of the computing device, deriving a device identifier private key from a unique device secret of the computing device, wherein the intermediate certificate is signed or endorsed by the device identifier private key.

[0071] Another example (e.g., Example 11) relates to the preceding example (e.g., one of Examples 1 to 10) or to any other example, further including: the intermediate certificate and the leaf certificate are part of a hardware trusted root certificate chain.

[0072] Another example (e.g., Example 12) relates to the preceding example (e.g., Example 11) or to any other example, further including: the hardware trust root certificate chain is a Device Identifier Composition Engine (DICE) certificate chain.

[0073] Another example (e.g., Example 13) relates to the preceding example (e.g., one of Examples 1 to 12) or to any other example, further comprising: a certificate chain including a leaf certificate is provided to an external verifier as part of a device certification protocol.

[0074] An example (e.g., Example 14) relates to an apparatus (10) for a computing device (100), the apparatus comprising a processor circuit system (14) configured to: obtain information related to the identity of firmware being used to operate the computing device; generate a leaf certificate for the firmware being used to operate the computing device based on the identity of the firmware being used to operate the computing device and using an intermediate certificate generated based on the identity of the firmware that has been used during a cold boot of the computing device; and provide a certificate chain including the leaf certificate to an external validator.

[0075] An example (e.g., Example 15) relates to a device (10) for a computing device (100), the device comprising a means for processing (14), the means for processing (14) being used to: obtain information related to the identity of firmware being used to operate the computing device; generate a leaf certificate for the firmware being used to operate the computing device based on the identity of the firmware being used to operate the computing device and using an intermediate certificate generated based on the identity of the firmware that has been used during a cold boot of the computing device; and provide a certificate chain including the leaf certificate to an external validator.

[0076] Another example (eg, Example 16) relates to a computing device (100) comprising an apparatus (10) or device (10) according to one of Examples 1 to 15 (or according to any other example).

[0077] Another example (eg, Example 17) relates to the preceding example (eg, Example 16) or to any other example, further including: the computing device is a computer system.

[0078] Another example (eg, Example 18) relates to the preceding example (eg, Example 16) or to any other example, further including: the computing device is a mobile device.

[0079] An example (e.g., Example 19) relates to a method for a computing device (100), the method comprising: 120: obtaining information related to the identity of firmware being used to operate the computing device; 130: generating a leaf certificate for the firmware being used to operate the computing device based on the identity of the firmware being used to operate the computing device and using an intermediate certificate generated based on the identity of the firmware that has been used during a cold boot of the computing device; and 140: providing a certificate chain including the leaf certificate to an external validator.

[0080] Another example (e.g., Example 20) relates to the aforementioned example (e.g., Example 19) or to any other example, further including that the method includes: after the seamless firmware update, generating a leaf certificate for the firmware used after the seamless firmware update.

[0081] Another example (eg, Example 21) relates to the preceding example (eg, Example 20) or to any other example, further comprising: the firmware used after the seamless firmware update is different from the firmware that had been used during a cold boot of the computing device.

[0082] Another example (e.g., Example 22) relates to the preceding example (e.g., Example 21) or to any other example, further including that the method comprises: 130: during a cold boot (110) of the computing device, generating a first leaf certificate for firmware that has been used during the cold boot of the computing device; and 130: after a seamless firmware update, generating a second leaf certificate for firmware that is used after the seamless firmware update.

[0083] Another example (e.g., Example 23) relates to the preceding example (e.g., one of Examples 19 to 22) or to any other example, further including that the method comprises: 114: during a cold boot of the computing device, generating an intermediate certificate, a private key associated with the intermediate certificate, and a seed for generating a leaf certificate; and 130: using the intermediate certificate and using the seed to generate a leaf certificate.

[0084] Another example (e.g., Example 24) relates to the preceding example (e.g., Example 23) or to any other example, further including: the intermediate certificate is generated based on a unique device secret of the computing device and based on the identity of firmware that has been used during a cold boot of the computing device.

[0085] Another example (eg, Example 25) relates to the preceding example (eg, Example 24) or to any other example, further comprising: the unique device secret is not available after a cold boot of the computing device.

[0086] Another example (e.g., Example 26) relates to the preceding examples (e.g., one of Examples 23 to 25) or to any other example, further including: the leaf certificate is generated using an intermediate certificate, and the leaf certificate includes a leaf public key derived from a seed and an identity of the firmware being used to operate the computing device.

[0087] Another example (e.g., Example 27) relates to the preceding examples (e.g., one of Examples 23 to 26) or to any other example, further including that the method comprises: 116: storing an intermediate certificate, a private key associated with the intermediate certificate, and a seed in a portion (16b) of the storage circuit system (16) that is accessible during a cold boot or after a seamless update of the computing device.

[0088] Another example (e.g., Example 28) relates to the preceding examples (e.g., one of Examples 19 to 27) or to any other example, further including: 112: During a cold boot of the computing device, deriving a device identifier private key from a unique device secret of the computing device, wherein the intermediate certificate is signed or endorsed by the device identifier private key.

[0089] Another example (e.g., Example 29) relates to the preceding example (e.g., one of Examples 19 to 28) or to any other example, further including: the intermediate certificate and the leaf certificate are part of a hardware trusted root certificate chain.

[0090] Another example (e.g., Example 30) relates to the preceding example (e.g., Example 29) or to any other example, further including: the hardware trust root certificate chain is a Device Identifier Composition Engine (DICE) certificate chain.

[0091] Another example (e.g., Example 31) relates to the preceding example (e.g., one of Examples 19 to 30) or to any other example, further comprising: a certificate chain including a leaf certificate is provided to an external verifier as part of a device certification protocol.

[0092] Another example (eg, Example 32) relates to a computing device (100) configured to perform a method according to one of Examples 19 to 31 (or according to any other example).

[0093] Another example (e.g., Example 33) relates to a non-transitory computer-readable medium comprising program code that, when executed on a processor, a computer, or a programmable hardware component, causes the processor, the computer, or the programmable hardware component to perform a method according to one of Examples 19 to 31 (or according to any other example).

[0094] Another example (eg, Example 34) relates to a non-transitory machine-readable storage medium comprising a program code that, when executed, causes a machine to perform a method according to one of Examples 19 to 31.

[0095] Another example (eg, Example 35) relates to a computer program having a program code for performing a method as described in one of Examples 19 to 31 when the computer program is executed on a computer, a processor or a programmable hardware component.

[0096] Another example (e.g., Example 36) relates to a machine-readable storage device comprising machine-readable instructions that, when executed, implement a method as claimed in the appended claims or shown in any example, or realize an apparatus as claimed in the appended claims or shown in any example.

[0097] Aspects and features described in relation to a particular one of the preceding examples may be combined with one or more of the further examples to replace the same or similar features of the further examples or to introduce these features in addition to the further examples.

[0098] Examples may further be or relate to (computer) programs, including program code, which is used to perform one or more of the above methods when the program is executed on a computer, a processor or other programmable hardware component. Thus, the steps, operations or processes of the different methods in the methods described above can also be performed by a programmed computer, a processor or other programmable hardware component. Examples may also cover program storage devices, such as digital data storage media, which are machine-readable, processor-readable or computer-readable, and encode and / or contain machine-executable, processor-executable or computer-executable programs and instructions. For example, a program storage device may include or may be a digital storage device, a magnetic storage medium (such as a disk and a tape), a hard drive or an optically readable digital data storage medium. Other examples may also include a computer, a processor, a control unit, a (field) programmable logic array ((field) programmable logic array, (F) PLA), a (field) programmable gate array ((field) programmable gate array, (F) PGA), a graphics processor unit (GPU), an application-specific integrated circuit (ASIC), an integrated circuit (IC), or a system-on-a-chip (SoC) system programmed to perform the steps of the method described above.

[0099] It is also understood that the disclosure of several steps, processes, operations or functions disclosed in the specification or claims should not be interpreted as implying that these operations must be in the described order, unless explicitly stated in a separate use case or necessary for technical reasons. Therefore, the previous description does not limit the performance of several steps or functions to a certain order. In addition, in other examples, a single step, function, process or operation may include and / or be decomposed into sub-steps, sub-functions, sub-processes or sub-operations.

[0100] If some aspects have been described in conjunction with a device or system, these aspects should also be understood as descriptions of corresponding methods. For example, a block, device, or functional aspects of a device or system may correspond to features (such as method steps) of a corresponding method. Accordingly, aspects described in conjunction with a method should also be understood as descriptions of properties or functional features of the corresponding block, corresponding element, corresponding device, or corresponding system.

[0101] As used herein, the term "module" refers to a logic for performing one or more operations in accordance with the present disclosure that can be implemented using hardware components or devices, software or firmware running on a processing unit, or a combination thereof. Software and firmware can be embodied as instructions and / or data stored on a non-transient computer-readable storage medium. As used herein, the term "circuitry" can include, alone or in any combination, non-programmable (hard-wired) circuitry, programmable circuitry (such as a processing unit), state machine circuitry, and / or firmware storing instructions that can be executed by a programmable circuit. The modules described herein can be embodied together or individually as circuitry forming part of a computing system. Thus, any one of the modules can be implemented as a circuitry. A computing system that is referred to as being programmed for executing a method can be programmed to execute the method via software, hardware, firmware, or a combination thereof.

[0102] Any of the disclosed methods (or portions thereof) may be implemented as computer-executable instructions or computer program products. Such instructions may enable a computing system or one or more processing units capable of executing computer-executable instructions to perform any of the disclosed methods. As used herein, the term "computer" refers to any computing system or device described or mentioned herein. Thus, the term "computer-executable instructions" refers to instructions that can be executed by any computing system or device described or mentioned herein.

[0103] Computer executable instructions may be, for example, part of an operating system of a computing system, an application stored locally on a computing system, or a remote application accessible to a computing system (e.g., via a web browser). Any of the methods described herein may be performed by computer executable instructions executed by a single computing system or by one or more networked computing systems operating in a network environment. Computer executable instructions and updates to computer executable instructions may be downloaded from a remote server to a computing system.

[0104] In addition, it should be understood that implementation of the disclosed techniques is not limited to any particular computer language or program. For example, the disclosed techniques can be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, C#, assembly language, or any other programming language. Likewise, the disclosed techniques are not limited to any particular computer system or any particular type of hardware.

[0105] In addition, any of the software-based examples (including, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed via suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, cables (including fiber optic cables), magnetic communications, electromagnetic communications (including RF, microwave, ultrasonic, and infrared communications), electronic communications, or other such communication means.

[0106] The disclosed methods, apparatuses, and systems should not be interpreted as limiting in any way. Instead, the present disclosure is directed to all novel and non-obvious features and aspects of each disclosed example, individually and in various combinations and sub-combinations with each other. The disclosed methods, apparatuses, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed examples require the existence of any one or more specific advantages or the resolution of any one or more specific problems.

[0107] The theories of operation, scientific principles, or other theoretical descriptions presented herein with reference to the devices or methods of the present disclosure are provided for the purpose of better understanding and are not intended to limit the scope. The devices and methods in the appended claims are not limited to those devices and methods that function in the manner described by such theories of operation.

[0108] The attached claims are hereby included in the detailed description, wherein each claim itself can serve as a separate example. It should be noted that although a dependent claim refers to a specific combination with one or more other claims in the claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are expressly proposed here, unless it is stated in individual cases that a specific combination is not intended. In addition, even if a claim is not directly limited to referring to any other independent claim, the features of the claim should also be included with respect to any other independent claim.

Claims

1. An apparatus for a computing device, the apparatus comprising interface circuitry, machine-readable instructions, and processor circuitry, the processor circuitry being configured to execute the machine-readable instructions to: obtaining information related to an identity of firmware being used to operate the computing device; generating a leaf certificate for the firmware being used to operate the computing device based on the identity of the firmware being used to operate the computing device and using an intermediate certificate generated based on the identity of the firmware that had been used during a cold boot of the computing device; as well as The external validator is provided with a certificate chain including the leaf certificate.

2. The device according to claim 1, wherein: The processor circuit system is used to execute the machine-readable instructions to: after a seamless firmware update, generate a leaf certificate for firmware used after the seamless firmware update.

3. The device according to claim 2, wherein: The firmware used after the seamless firmware update is different than the firmware that had been used during the cold boot of the computing device.

4. The device according to claim 3, wherein: The processor circuitry is to execute the machine-readable instructions to: during the cold boot of the computing device, generate a first leaf certificate for firmware that has been used during the cold boot of the computing device; And after the seamless firmware update, generating a second leaf certificate for the firmware used after the seamless firmware update.

5. The device according to claim 1, wherein: The processor circuitry is to execute the machine-readable instructions to: during a cold boot of the computing device, generate the intermediate certificate, a private key associated with the intermediate certificate, and a seed for generating the leaf certificate; And using the intermediate certificate and using the seed to generate the leaf certificate.

6. The device according to claim 5, wherein: The intermediate certificate is generated based on a unique device secret of the computing device and based on an identity of firmware that has been used during a cold boot of the computing device.

7. The device according to claim 6, wherein: The unique device secret is not available after a cold boot of the computing device.

8. The device according to claim 5, wherein: The leaf certificate is generated using the intermediate certificate, and the leaf certificate includes a leaf public key derived from the seed and an identity of firmware being used to operate the computing device.

9. The device according to claim 5, wherein: The apparatus comprises a storage circuit system, wherein the processor circuit system is used to execute the machine-readable instructions to: store the intermediate certificate, the private key associated with the intermediate certificate, and the seed in a portion of the storage circuit system that is accessible during the cold boot or after a seamless update of the computing device.

10. The device according to claim 1, wherein: The processor circuitry is to execute the machine-readable instructions to: derive a device identifier private key from a unique device secret of the computing device during a cold boot of the computing device, wherein the intermediate certificate is signed or endorsed by the device identifier private key.

11. The device according to claim 1, wherein: The intermediate certificate and the leaf certificate are part of a hardware trusted root certificate chain.

12. The device according to claim 11, wherein: The hardware trusted root certificate chain is the Device Identifier Combination Engine DICE certificate chain.

13. The device according to claim 1, wherein: The certificate chain including the leaf certificate is provided to an external validator as part of a device certification protocol.

14. A computing device comprising the apparatus according to claim 1.

15. The computing device of claim 14, wherein: The computing device is a computer system.

16. The computing device of claim 14, wherein: The computing device is a mobile device.

17. A method for a computing device, the method comprising: obtaining information related to an identity of firmware being used to operate the computing device; generating a leaf certificate for the firmware being used to operate the computing device based on the identity of the firmware being used to operate the computing device and using an intermediate certificate generated based on the identity of the firmware that had been used during a cold boot of the computing device; as well as The external validator is provided with a certificate chain including the leaf certificate.

18. The method according to claim 17, further comprising: After the seamless firmware update, a leaf certificate is generated for the firmware used after the seamless firmware update.

19. The method according to claim 18, further comprising: The firmware used after the seamless firmware update is different than the firmware that had been used during the cold boot of the computing device.

20. The method according to claim 19, further comprising: generating, during the cold boot of the computing device, a first leaf certificate for firmware that has been used during the cold boot of the computing device; And after the seamless firmware update, generating a second leaf certificate for the firmware used after the seamless firmware update.

21. The method of claim 17, further comprising: generating, during a cold boot of the computing device, the intermediate certificate, a private key associated with the intermediate certificate, and a seed for generating the leaf certificate; And using the intermediate certificate and using the seed to generate the leaf certificate.

22. The method according to claim 21, further comprising: The intermediate certificate is generated based on a unique device secret of the computing device and based on an identity of firmware that has been used during a cold boot of the computing device.

23. The method according to claim 22, further comprising: The unique device secret is not available after a cold boot of the computing device.

24. The method of claim 17, further comprising: The leaf certificate is generated using the intermediate certificate, and the leaf certificate includes a leaf public key derived from the seed and an identity of firmware being used to operate the computing device.

25. A non-transitory computer-readable medium comprising a program code, which, when executed on a processor, a computer or a programmable hardware component, causes the processor, the computer or the programmable hardware component to perform the method of one of claims 17-24.

Images