WO2024061442A1

WO2024061442A1 - Apparatus and method for layered attestation with additive asymmetric key derivation

Info

Publication number: WO2024061442A1
Application number: PCT/EP2022/075997
Authority: WO
Inventors: Arto NIEMI; Sampo Sovio
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-09-20
Filing date: 2022-09-20
Publication date: 2024-03-28

Abstract

Computing apparatus for generation and verification of attestation evidence associated with layered software systems is presented. Layered attestation evidence is generated based on an iterative process using additive asymmetric cryptographic keys. Each software layer in a boot chain generates a signed next layer attestation evidence for the next software layer by generating claims, generating a random factor, computing a next layer authorized sub-key pair based on the random factor, and generating a next layer attestation evidence including claims and the authorized sub-public key, then signing the next layer attestation evidence based on a sub-private key of the current layer and a DLP based signature scheme. Verification of the layered attestation evidence is achieved by an apparatus configured to iteratively compute a validation key based on the authorized sub-public key in each layer, validate integrity of each signed layer attestation evidence based on the validation key, appraise the claims.

Description

APPARATUS AND METHOD FOR LAYERED ATTESTATION TECHNICAL FIELD The aspects of the disclosed embodiments relate generally to computer security, and more particularly to layered attestation. BACKGROUND Computing devices typically employ multiple layers of software. During start-up, software layers are loaded in a boot chain where each layer is responsible for setting up and launching the next layer. A boot chain may, for example, include: a first-stage boot loaded; a second-stage boot loader; a hypervisor or OS kernel; and a virtual machine or application. During an attack on a layered system, an attacker who compromises one layer can easily compromise subsequent layers in the boot chain. A compromised layer can alter or swap code in the subsequent layer before booting it, and a compromised hypervisor or OS can influence behaviour of subsequent layers at runtime. Trust in a layer can be established using attestation. Attestation is a process where evidence of a layer’s trustworthiness is generated and presented to a verifier. The attestation evidence is cryptographically signed thereby allowing a verifier to examine the attestation evidence and decide whether to trust the attestee or not. In layered systems, attestation evidence is typically generated for each software layer. The attestation evidences can then be combined into a single layered attestation evidence. Each layer generates and cryptographically signs attestation evidence for subsequent layers in the boot chain. Signing may be done with either symmetric or asymmetric keys, however, because key management for symmetric keys is significantly more difficult, asymmetric keys are sometimes preferred. Asymmetric cryptography is not without its drawbacks. Every device and every software layer needs its own key pair for signing attestation evidence, leading to a very large population of cryptographic keys. Establishing a public key infrastructure (PKI) is not trivial, and generation, distribution, and management of a large population of keys can be expensive, complex, and expose certain security risks. The distribution of attestation keys can become a difficult problem. Thus, there is a need for improved apparatus and methods for layered attestation that can solve the key distribution problem. 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 improved antenna performance in mobile communications apparatus. According to a first aspect, the above and further implementations and advantages are obtained by an apparatus. In one embodiment the apparatus includes a processor and a memory, wherein the memory includes program instructions that when executed by the processor cause the processor to: generate one or more next layer claims; generate a next layer random factor; compute a next layer private key based on a current layer private key and the next layer random factor; compute a next layer sub-public key based on the next layer random factor and a group generation point; generate a next layer attestation evidence, wherein the next layer attestation evidence includes the one or more next layer claims, and the next layer sub-public key; Sign the next layer attestation evidence wherein the signed next layer attestation evidence includes the next layer attestation evidence and a signature over the next layer attestation evidence based on the current layer private key; pass the next layer private key and the signed next layer attestation evidence to a next layer; and pass control to the next layer. The use of additive asymmetric keys avoids the need to issue and manage separate asymmetric cryptographic key pairs for each layer in each device. In a possible implementation form, the signed next layer attestation evidence includes one or more of a signed current layer attestation evidence, a challenge value, and a monotonic counter value. Nesting the signed current layer attestation evidence in the signed next layer attestation evidence provides layer linking and sequencing via the sub-keys and signatures. Including a challenge value provides layer linking and allows a verifier to assure freshness. Including a monotonic counter value support layer sequencing. In a possible implementation form, the processor is configured to generate one or more measurements based on a next layer, and the one or more claims include one or more of the one or more measurements. Including measurements of the next layer in the one or more claims allows the verifier to appraise the claims based on in-memory state of the next layer. In a possible implementation form, the apparatus includes a one-time programmable memory, and the processor is configured to: receive a device root sub-private key, a device root sub- public key, and a signature over the device root sub-public key based on a master private key; and store the device root sub-private key, the device root sub-public key, and the signature over the device root sub-public key in the one-time programmable memory. Storing the device root sub-private key and the signed device root sub-public key in OTP memory secures these values against unauthorized access and tampering. In a possible implementation form, the one or more next layer claims include a hash of the next layer binary code. Including the hash allows a verifier to assure an attacker has not altered the layer’s binary code. In a possible implementation form, the one or more next layer claims include runtime status information of the next layer. Including run-time status information helps assure the program code has not been altered during runtime of the layer. In a possible implementation form, the signature over the next layer attestation evidence is generated with a discrete logarithm problem based asymmetric digital signature scheme. DLP based signature schemes support creation of additive asymmetric keys. In a possible implementation form of the apparatus, the signature over the next layer attestation information is generated based on an elliptic curve digital signature algorithm. Use of ECDSA allows the layered attestation evidence to be handled by a large class of computing apparatuses. In a possible implementation form, the one or more claims comprise a timestamp. Including a timestamp in the claims allows the verifier to determine freshness of the attestation evidence. In a possible implementation form according to the first aspect, the one or more claims comprise a master public key wherein the master public key is associated with the master private key. Including the master public key in the claims avoids having to separately distribute the master public key to verifiers and store the master public key in the verifier. In a possible implementation form, the apparatus further includes a pseudo random number generator, and generating the next layer random factor includes extracting a random number from the pseudo random number generator. Including a PRNG in the apparatus provides a reliable way to generate suitable random factors. In a possible implementation form, the apparatus includes a trusted execution environment and the memory includes one or more layers, and one or more of the one or more layers is configured to execute within the trusted execution environment. The disclosed embodiments may be used in computing apparatus that support trusted execution environments (TEE). In a possible implementation form, the processor is configured to execute a plurality of software layers, and wherein the plurality of software layers comprises one or more of a boot loader, an operating system, a hypervisor, and a virtual machine. The disclosed embodiments are applicable to many different types of software layers. In a possible implementation form, the apparatus comprises one or more of a mobile phone, a mobile communication device, an Internet of Things device, a wearable device, a laptop computer, and a desktop computer. The disclosed embodiments are useful in many different types of computing apparatuses. According to a second aspect, the above and further implementations and advantages are obtained by a method. In one embodiment the method includes generating one or more next layer claims; generating a next layer random factor; computing a next layer sub-private key based on a current layer sub-private key and the next layer random factor; computing a next layer sub-public key based on the next layer random factor and a group generator point; generating a next layer attestation evidence, wherein the next layer attestation evidence comprises the one or more next layer claims and the next layer sub-public key; signing the next layer next layer attestation evidence, wherein the signed next layer attestation evidence includes the next layer attestation evidence and a signature over the next layer attestation evidence based on the current layer sub-private key; passing the next layer sub-private key and the signed next layer attestation evidence to a next layer; and passing control to the next layer. The use of additive asymmetric keys avoids the need to issue and manage separate asymmetric cryptographic key pairs for each layer in each device. In a possible implementation form, the next layer attestation evidence comprises one or more of a current layer attestation evidence, a challenge value, and a monotonic counter value. Nesting the signed current layer attestation evidence in the signed next layer attestation evidence provides layer linking and sequencing via the sub-keys and signatures. Including a challenge value provides layer linking and allows a verifier to assure freshness. Including a monotonic counter value support layer sequencing. In a possible implementation form, the one or more claims include one or more measurements, and generating the one or more claims includes generating the one or more measurements based on the next layer. Including measurements of the next layer in the one or more claims allows the verifier to appraise the claims based on in-memory state of the next layer. According to a third aspect, the above and further implementations and advantages are obtained by an apparatus. In one embodiment the apparatus includes a processor and a memory, wherein the memory includes program instructions that when executed by the processor cause the processor to: receive a layered attestation evidence, wherein the layered attestation evidence comprises a signed current layer attestation evidence and a signed next layer attestation evidence, and wherein the signed current layer attestation evidence comprises a current layer sub-public key, and the signed next layer attestation evidence comprises one or more next layer claims. The processor computes a current layer validation key based on a prior layer validation key and a current layer sub-public key, wherein the prior layer validation key depends on a master public key and one or more random factors. The processor validates the signed next layer attestation evidence based on the current layer validation key; appraises the one or more next layer claims based on a predetermined attestation policy. When the validation or the appraisal fail, the processor indicates an attestation failure and exits the method. When the validation and the appraisal are successful, the processor repeats the compute, validate, and appraise steps until all the attestation evidence has been verified. Use of the additive asymmetric keys allows the apparatus to verify the layered attestation evidence while having only the master public key and no additional cryptographic key material. In a possible implementation form, the master public key is embedded in a CA-signed certificate and the apparatus is configured to store the CA-signed certificate in the memory (404). Embedding the master public key in a CA-signed certificate allows the certificate to be safely stored in an unsecured memory. In a possible implementation form, the apparatus further comprises a one-time programmable memory and the processor is configured to store the master public key in the one-time programmable memory. The use of a OTP memory avoid the need to validate a public key certificate each time an attestation evidence is verified. In a possible implementation form, the layered attestation evidence includes the master public key. Including the master public key in the layered attestation evidence avoid the need to distribute and store the mater public key in the verifier. In a possible implementation form, the layered attestation evidence includes a revocation information, and the processor is configured to check the revocation information before validating the layered attestation evidence. Processing revocation information prevents verification of layered attestation evidence generated after the master keys have been revoked or otherwise invalidated. In a possible implementation form, the apparatus includes one or more of a mobile phone, a mobile communication device, an Internet of Things device, a wearable device, a laptop computer, a desktop computer, and a server. The verification may be implemented in a variety of different types of computing apparatuses. According to a fourth aspect, the above and further implementations and advantages are obtained by a method. In one embodiment the method includes receiving a layered attestation evidence, wherein the layered attestation evidence includes a signed current layer attestation evidence and a signed next layer attestation evidence, and wherein the signed current layer attestation evidence includes a current layer sub-public key, and the signed next layer attestation evidence includes one or more next layer claims. The method computes a current layer validation key based on a prior layer validation key and a current layer sub-public key, wherein the prior layer validation key is computed based a master public key and one or more random factors; The method validates the signed next layer signed attestation evidence based on the current layer validation key, and appraises the one or more next layer claims based on a predetermined attestation policy. When the validation or the appraisal fail, the method indicates an attestation failure and exits. When the validation and the appraisal are successful, the method repeats the computing, validating, and appraising steps until the layered attestation evidence has been verified. Use of the additive asymmetric keys allows the method to verify the layered attestation evidence while having only the master public key and no additional cryptographic key material. 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 apparatus 100 configured to generate layered attestation evidence based on additive asymmetric keys incorporating aspects of the disclosed embodiments; Figure 2 illustrates an overview of an exemplary process for generating layered attestation evidence based on additive asymmetric keys incorporating aspects of the disclosed embodiments; Figure 3 illustrates a flowchart showing an exemplary method for generating layered attestation evidence based on additive asymmetric keys incorporating aspects of the disclosed embodiments; Figure 4 illustrates a block diagram of an exemplary apparatus configured to verify a layered attestation evidence incorporating aspects of the disclosed embodiments; and Figure 5 illustrates a flow chart of an exemplary method for validating a layered attestation evidence incorporating aspects of the disclosed embodiments. DETAILED DESCRIPTION OF THE DISCLOSED EMBODIMENTS Referring to Figure 1 there can be seen an exemplary apparatus 100 configured to generate layered attestation evidence based on additive asymmetric keys incorporating aspects of the disclosed embodiments. The exemplary apparatus 100 of the disclosed embodiments is directed to a computing apparatus 100 configured to leverage properties of additive asymmetric keys to generate a novel layered attestation evidence based on a single master asymmetric key pair. As is illustrated in Figure 1, in one embodiment the apparatus 100 includes a processor 102 and a memory 104. The memory 104 includes program instructions 130 that when executed by the processor 102 cause the processor 102 to generate 112 one or more next layer claims (c_(i+1)); generate 114 a next layer random factor (r_(i+1)); compute 116 a next layer private key (d_(i+1)) based on a current layer private key (d_i) and the next layer random factor (r_(i+1)); compute 118 a next layer sub-public key (r_(i+1) P) based on the next layer random factor (r_(i+1)) and a group generation point (P) and generate 120 a next layer attestation evidence (E_(i+1)). The next layer attestation evidence (E_(i+1)) has the one or more next layer claims (c_(i+1)), and the next layer sub-public key (ri+1P). The processor 102 is further configured to sign 122 the next layer attestation evidence (E_(i+1)). The signed next layer attestation evidence ({E_(i+1) }_(d_i )) includes the next layer attestation evidence (E_(i+1)) and a signature (Sig(E_(i+1) ,d_i )) over the next layer attestation evidence based on the current layer private key (d_i). The processor 102 is configured to pass 124 the next layer private key (d_(i+1)) and the signed next layer attestation evidence ({E_(i+1) }_(d_i )) to a next layer and pass 126 control to the next layer. The exemplary apparatus 100 uses random factors to derive multiple authorized sub-key pairs from a single master asymmetric key pair. Authorized sub-keys are derived from information included in the layered attestation evidence thereby reducing the key management and distribution burden and eliminating the need for a PKI or other key management solution. The aspects of the disclosed embodiments improve layered attestation by employing a layered attestation evidence structure based on additive asymmetric keys and nesting of attestation evidence which supports layer linking and sequencing while requiring distribution of only a single master public key. The exemplary apparatus 100 may be any desired type of computing apparatus including but not limited to smart phones, mobile communications devices, phablets, tablets, laptop computers, desktop computers, workstations, or other larger computing apparatus such as servers used in data centers or cloud computing networks. Included in the apparatus 100 is a processor 102 communicatively coupled to a memory 104 wherein the memory stores program instructions 130 that when executed by the processor 102 cause the processor to perform a variety of operations and methods. Any desired type or combination of computer accessible memory may be advantageously employed as the memory 104, including but not limited to random-access memory (RAM), read-only memory (ROM), or other suitable types of volatile and non-volatile memory. In certain embodiments the memory 104 may incorporate additional memory 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. In the illustrated embodiment, the apparatus 100 also includes a secure memory 108, such as a one-time programmable (OTP) memory for securely storing sensitive and confidential data. The secure memory 108 may include any suitable type of secure memory such as various types of hardware security modules (HSM), one-time programmable memory, an eFuse type memory, or other suitable type of secure immutable or OTP memory. Optionally, the processor 102 may incorporate any appropriate type of processing device including but not limited to a high-performance multi-core 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, wearables, and smart devices adapted for the Internet of Things (IoT). In certain embodiments, an interface 110 may be included in the exemplary apparatus 100, where the interface 110 is adapted to provide communications with external entities. Optionally any suitable type of interface may be advantageously employed as the interface 110, such as a network or other communication subsystem configured to provide communications over wireless or wired communication networks. The interface 110 is configured to securely receive confidential information during provisioning of the apparatus 100. The exemplary apparatus 100 includes a random number generator 106 configured to provide random values to support generation of additive asymmetric keys. In one embodiment the random number generator 106 incorporates a pseudo-random number generator (PRNG) configured to provide random values appropriate for use during key generation. Conventional computing systems typically have multiple layers of software executing within the apparatus. At start-up, each layer is responsible for setting up and launching, or booting, the next layer. Sequentially setting up and booting layers at start-up is referred to as a boot chain. For example, a boot chain within a virtualized system may begin at powerup when a first-stage bootloader sets up and launches a second-stage boot loader, which in-turn sets up and launches a hypervisor (HV) or operating system (OS) kernel, followed by one or more virtual machines and/or additional software applications. As used herein the term layer or software layer refers to a software component loaded into the memory 104. The term layer is used herein to highlight the sequential nature of loading software modules in a boot chain where each layer is responsible for setting up and launching the next layer. In a layered system, it is relatively simple for an attacker who succeeds in compromising one layer of a boot chain to compromise the remaining layers of the boot chain. For example, a compromised layer can alter or swap code of the next layer before booting it. When the compromised layer is a hypervisor or an operating system, the compromised layer may influence the behavior of subsequent layers at runtime. In contrast to a bootloader, a hypervisor or operating system remain running and in full control over the next layer’s execution. Successively loading software components in a layered system creates a reliance among layers where a layer can be trusted only if its parent layer can also be trusted. Trust in a layer may be established through a process referred to as attestation. With attestation, evidence of a layer’s trustworthiness is generated and later presented to a verifier to establish trust in the software layer. As will be described in more detail below, the attestation evidence generally includes an integrity protected blob of information, such as a cryptographic key, digital signature, and other desired information, configured to allow a verifier or verifying party to determine whether or not an attestee should be trusted. As used herein the term attestee refers to an entity, such as a software layer, that generated the attestation evidence. In the exemplary apparatus 100, one or more of the software layers may be configured as bootloaders, operating systems, hypervisors or virtual machines. Optionally, one or more of the software layers may execute in a Trusted Execution Environment (TEE), such as in the ARM TrustZone secure world or in other secure environments such as an INTEL SGX, an AMD SEV, or ARM CCA enclave. Generation of attestation evidence is an iterative process where a current layer generates attestation evidence for a next layer based on information provided by a prior layer. As used herein the current layer is the layer currently in control of the processor 102, which means the layer who’s software instruction are currently being executed by the processor 102. The current layer is denoted herein using a subscript i, where i may take on an integer value to indicate the layer of interest, i=0, 1, 2, …, n , where n is the number of layers in the system. The next layer is the layer for which attestation evidence is being generated and is denoted herein with a subscript i+1. The prior layer is the layer that generated attestation evidence for the current layer and is denoted herein with a subscript i-1. For example, during one iteration, the current layer, layer i, may be a hypervisor, the next layer, layer i+1, may be a guest OS, and the prior layer, layer i-1, may be a second stage boot loader. When employing layered attestation, each apparatus requires its own signing key and each layer in each computing device also requires its own signing key, resulting in a large population of signing keys. Distributing and maintaining confidentiality of a large population of secret keys can present challenging security problems. The use of asymmetric key pairs eliminates many of the problems associated with secret keys. Therefore, asymmetric key cryptography is used in the layered attestation embodiments disclosed herein. Reliably distributing and maintaining large populations of asymmetric key pairs requires deploying a highly available and reliable PKI. The expense of maintaining a sophisticated PKI and managing a large population of keys and certificates is avoided by employing additive sub- keys. Use of additive sub-keys also provides a clean solution for linking and sequencing of layered or nested attestation evidences. Additive asymmetric keys, also referred to herein as authorized sub-keys, are a type of asymmetric cryptographic key generated by exploiting a property of discrete logarithm problem (DLP) based digital signature algorithms. As an aid to understanding, examples provided herein are based on a commonly used DLP based digital signature algorithm known as the Elliptic Curve Digital Signature Algorithm (ECDSA). Those skilled in the art will readily recognize that any suitable DLP based digital signature algorithm may be advantageously employed without straying from the spirit and scope of the present disclosure. In a DLP based algorithm, a private key ^ is a scalar value, typically an integer modulo the order or number of elements in the group on which the algorithm is based. For a given private key ^ the corresponding public key ^ is obtained by repeatedly applying the group operation to the group generator or group generation point ^ a number of times specified by the private key ^. As an example, consider ECDSA. The group for ECDSA consists of points on an elliptic curve, the corresponding group operation is the elliptic curve point addition operation, and the group generator is referred to as a base point. In ECDSA, the public key is obtained by applying elliptic curve point addition to the base point a private key ^ number of times. Generation of the public key may be expressed in equation form as shown in Equation 1: ^ = ^^ = ^ + ^ + ⋯ + ^, ^{Eq. 1} where ^ is the group generator point, and the ellipses indicate the group operation is being applied ^ times. Successively applying the group operation as shown in Equation 1 may be referred to as multiplication and written in equation form as ^^. For reasons that will become apparent during the following discussion, the starting asymmetric key pair (^_^ , ^_^) will be referred to herein as the master key pair, with ^_^ being the mater private key and ^_^ being the master public key. The master key pair (^_^ , ^_^ ) may be a conventionally generated asymmetric key pair having a public key certificate issued by a certificate authority (CA). Additional asymmetric key pairs may be derived from the master key pair (^_^ , ^_^) by adding a random factor ^_^ to the master private key ^_^ to form a new private key ^_^ as shown in Equation 2: ^_{^ = ^^ + ^^,} ^{Eq. 2} . A private key formed by adding a random factor to a private key as illustrated in Equation 2 is referred to herein as a sub-private key. A corresponding public key ^_^ , is derived by multiplying the group generation point ^ by the sub-private key ^_^ as shown in equation 3: ^_{^ = ^^^ .} ^{Eq. 3} The derived public key ^_^ may be used to validate signatures generated with the sub-private key ^_^, and is referred to herein as a validation key ^_^. Scalar multiplication, like integer multiplication, is distributive. The distributive principle allows a validation key ^_^ to be factored as shown in Equation 4: ^_^ = ^_^^ = (^_^ + ^_^)^ = ^_^^ + ^_^^ = ^_^ + ^_^^, Eq.4 where ^_^ is the master public key, ^_^ is a random factor, ^ is the group generator or group generation point, and ^_^^ is a value referred to herein as a sub-public key. The sub-public key ^_^^ may be derived by multiplying the group generation point ^ by the random factor ^_^. The validation key ^_^ is obtained by adding the sub-public key ^_^^ to the master public key ^_^. The validation key ^_^ is used to validate signatures generated with the corresponding sub- private key^_^ . The master public key ^_^ may be a conventionally generated public key distributed to verifying parties in any appropriately trusted fashion. For example, the master public key ^_^ may be embedded in a conventional digital certificate issued by a trusted certificate authority (CA). The sub-public key ^_^^ may be distributed to verifying parties separately from the master public key ^_^ and can then be combined with the master public key ^_^ to produce a validation key ^_^ which may be used to verify signatures generated with the sub-private key ^_^. When a signature generated with the sub-private key ^_^ is successfully verified by the validation key ^_^, the verifying party can trust that the sub-private key ^_^ and corresponding sub-public key ^_^^ were derived from and authorized by the holder of the master private key. The additive asymmetric key pair (^_^, ^_^^) is therefore referred to herein as an authorized sub-key pair, and the quantity ^_^^ is referred to as an authorized sub-public key. Once an authorized sub-key pair (^_^, ^_^^) has been generated, additional authorized sub-key pairs (^_^, ^_^^) may be derived therefrom. Additional authorized sub-key pairs (^_^, ^_^^) are computed by generating another random factor ^_^, then repeating the above-described process with the first authorized sub-key pair (^_^, ^_^^) as follows. The next sub-private key ^_^^^ is computed by adding the next random factor ^_^^^ to the current sub-private key ^_^ as shown in Equation 5: ^_^^^ = ^_^ + ^_^^^ . Eq.5 The next sub-public key ^_^^^^ is obtained by multiplying the generation point P by the next random factor ^_^^^. Then the next validation key ^_^^^ may be obtained by adding the next sub- public key ^_^^^^ to the current validation key as shown in Equation 6: ^_^^^ = ^_^ + ^_^^^^ = ^_^ + ^_^^ + ^_^^^^. Eq.6 Equation 5 shows that the next validation key ^_^^^ may be computed by any party having a trusted copy of the master public key ^_^ and each of the authorized sub-public keys ^_^^, and ^_^^^^. As will be described further below, the factoring illustrated in Equation 5 is employed by embodiments disclosed herein when generating layered attestation evidence. Referring again to the apparatus 100 illustrated in Figure 1, a portion of the program instructions 130 stored in the memory 104 of the apparatus 100, are configured to perform a method 128 that generates a signed attestation evidence for a software layer. As will be discussed in more detail below, generation of layered attestation evidence is an iterative process were signed attestation evidence is created successively for each layer and combined to form a layered attestation evidence representing all layers loaded in the apparatus 100. The exemplary method 128 represents a single iteration of the iterative process and may therefore be referred to interchangeably as method 128 or iteration 128. The exemplary method 128 may be repeated by each successive layer until all layers have been incorporated into the layered attestation evidence. In certain embodiments, the layered attestation evidence produced by the exemplary method 128 includes nested signed attestation evidence where each layer nests a copy of its own signed attestation evidence within the signed attestation evidence being prepared for the next layer. As used herein the notation ^^^⁽^ , ^ ⁾ represents a digital signature over a block of data ^ generated using a private key ^ . The notation ^{^^} _^ is used herein to represent a quantity including both the block of data itself ^ together with the digital signature ^^^⁽^ , ^ ⁾. At the beginning of an iteration 128, the current layer has access to a current layer sub-private key ^_^ , a current layer sub-public key ^_^^ , and a signed current layer attestation evidence ^{^_^ ^} _^^^^. These values may be generated during an initialization phase, or by a prior iteration and are made available to the iteration 128 as needed. During an iteration 128, one or more next layer claims ^_^^^ are generated 112. The one or more next layer claims ^_^^^ may include any desired information, such as information useful to a verifier when establishing trust in a software layer. In one embodiment, the generated 112 one or more next layer claims ^_^^^ include measured values such as a hash of a layer’s binary code or a hash of the next layer code as loaded in memory. In certain embodiments, the one or more claims may include state information representing an execution state of the next layer, or other runtime status information associated with the next layer. Optionally, the one or more next layer claims ^_^^^ may include a version number, identifying information such as a program name, or other information associated with the layer or the manufacturer of the layer. When freshness is desired, a timestamp may be included in the one or more next layer claims ^_^^^ to show when the claims were generated or the measurements were made. The embodiments disclosed herein are independent of information included in the claims and may be employed equally beneficially with any desired claim information. In one embodiment the master public key ^_^ is included in the one or more next layer claims ^_^^^. When the master public key ^_^ is included in the one or more next layer claims ^_^^^ the verifier need not have a copy of the master public key ^_^ in advance. It is beneficial to provide the verifier with a way to check authenticity of the master public key ^_^. Authenticity may be checked through any appropriate means, such as by checking an endorsement database, or by verifying an endorsement, such as a digital certificate signed by a trusted CA, that is included in the one or more next layer claims ^_^^^. The iteration 128 generates 114 a next layer random factor ^_^^^ for use when computing cryptographic values for the next layer. The random factor may be any suitable random value such as a random value generated by a pseudo-random number generator or other appropriately random value suitable for creation of cryptographic keys. A next layer private key ^_^^^ is computed 116 based on a current layer private key ^_^ and the next layer random factor ^_^^^. The next layer private key may be computed by adding the next layer random factor ^_^^^ to the current layer private key, ^_^^^ = ^_^ + ^_^^^, as described above. A next layer sub-public key ^_^^^^ is computed 118 based on the next layer random factor ^_^^^ and a group generation point ^ . In one embodiment the next layer sub-public key ^_^^^^ is computed by multiplying the group generation point ^ by next layer random factor ^_^^^ as described above. Next layer attestation evidence ^_^^^ is generated 120 by combining the one or more next layer claims ^_^^^ with the next layer sub-public key ^_^^^^. The next layer attestation evidence ^_^^^ is configured to aid a verifier when establishing trust in the next layer during verification of the layered attestation evidence. Optionally, the next layer attestation evidence ^_^^^ may include one or more of the signed current layer attestation evidence

a challenge value, and a monotonic counter value. Including the signed current layer attestation evidence

in the next layer attestation evidence ^_^^^ cryptographically binds each layer’s attestation evidence in a way that allows a verifier to check proper layer linking and sequencing. When desired a challenge value may be included in the next layer attestation evidence. The challenge value may for example be received from an external entity, such as a verifier, and included in each layer attestation evidence to link the attestation evidences together and allow the verifier to determine freshness. Optionally, a monotonically increasing counter value may be incorporated into each layer’s attestation evidence to support layer sequencing. The next layer attestation evidence ^_^^^ is signed 122 with the current layer sub-private key ^_^ to create a signed next layer attestation evidence {^_^^^}_^^ . Signing 122 the next layer attestation evidence ^_^^^ includes generating a digital signature over the next layer attestation evidence ^^^⁽^_^^^ , ^_^ ⁾ based on the current layer sub-private key ^_^, and including both the next layer attestation evidence ^_^^^ and the digital signature ^^^⁽^_^^^ , ^_^ ⁾ in the signed next layer attestation evidence ^{^_^^^ ^} _^^ The next layer private key ^_^ and the signed next layer attestation evidence ^{^_^^^ ^} _^^ are passed 124 to, or otherwise made available to, the next layer. Control is then then passed 126 to the next layer, allowing the next layer to repeat the method 128 to create a signed attestation evidence for a following layer. Passing control to a layer refers to having a thread of execution of the processor 102 begin execution of program instructions 130 associated with the next layer. Figure 2 illustrates an overview of an exemplary process 200 for generating layered attestation evidence ^_^ based on additive asymmetric keys incorporating aspects of the disclosed embodiments. The illustrated process 200 is suitable for use in a computing apparatus or device, such as the apparatus 100 described above, and employs authorized sub-key pairs to create digital signatures for layered attestation evidence. Creation of sub-key pairs avoids the expense and complexity associated with PKI implementations. Additional benefits provided by the exemplary process 200 include providing layer linking and sequencing without adding additional processing or complexity. The exemplary process 200 allows a manufacturer 202, such as an original equipment manufacturer (OEM), to provision a large population of computing apparatuses based on a single master asymmetric key pair (^_^, ^_^). Three entities are involved in the layered attestation system illustrated in Figure 2: a manufacturer 202, a verifier 218, and a computing apparatus 204, where the computing apparatus and associated processing is generally indicated by the bracket 204. A manufacturer 202, such as an OEM, provisions the computing apparatus 204 with any desired key material. Prior to provisioning a new device 204, the manufacturer 202 obtains a master asymmetric key pair (^_^, ^_^) and securely retains the master private key ^_^. The manufacturer uses a suitable random number generator, such as a PRNG, to generate a random factor ^_^, and uses the random factor to compute an authorized sub-key pair (^_^, ^_^^) as described above. The authorized sub- public ^_^^ key is signed with the master private key ^_^ to produce a signed authorized sub- public key ^{^_^^^} _^^ . When a computing apparatus 204 is manufactured, the authorized sub- private key ^_^ and the corresponding signed authorized sub-public key ^{^_^^^} _^^ are securely provisioned 206 within the device, such as by storing in a suitably secure memory 208. The provisioned authorized sub-key pair (^_^, ^_^^) becomes the device root sub-key pair for the apparatus 204 and, as will be described further below, is used to generate and sign additional authorized sub-key pairs during generation of layered attestation evidence. The computing apparatus 204 is configured to generate a layered attestation evidence ^_^ incorporating information corresponding to each software layer, 226, 228, 230, 232, executing on the computing apparatus. The layered attestation evidence ^_^ may then be verified by any entity, such as a verifier 218, having access to a trusted copy of the master public key ^_^. Figure 2 depicts an iterative process 200 for generation of attestation evidence where each layer generates signed attestation evidence for the next layer until attestation evidence for all layers is incorporated into the layered attestation evidence ^_^. The iterative process 200 is organized with information corresponding to each layer aligned horizontally, and processing steps organized in columns. Processing performed by the computing apparatus 204 is illustrated by the first column located below the bracket 204. The next column 212 shows the attestation signing keys used by each layer to create digital signatures for the attestation evidence, column 214 shows the claims generated by each layer, and column 216 shows the signed attestation evidence generated by each layer. Generation of attestation evidence generally takes place during on-field operation of the apparatus, and is referred to herein as the attestation phase or simply attestation. As an illustration, consider an occasion when a computing apparatus, such as the exemplary apparatus 100, attempts to access a highly secure service, such as a banking service. In addition to verifying the identity of a device, such as by verifying an x.509 formatted identity certificate, a highly sensitive service may require attestation to verify integrity of the software executing on the device before allowing sensitive operations, such as banking transactions, to proceed. When attestation is required, the apparatus generates layered attestation evidence ^_^ and sends 220 the layered attestation evidence ^_^ to a verifier 218 where a trust determination can be made. In certain embodiments, the verifier 218 may be incorporated within the service itself as an integral component. Alternatively, the verifier 218 may be a separate service, such as provided by a separate entity trusted by the banking service to make trust determinations on behalf of the banking service. In the exemplary process 200, generation of layered attestation evidence ^_^ is an iterative process where one software layer, referred to herein as the current layer, generates and signs attestation evidence for a next layer, based on information obtained from a prior layer. The exemplary process 200 protects integrity of the layered attestation evidence using additive asymmetric keys. In general, the current layer, also referred to as the attesting layer: derives an authorized sub-private key for the next layer by adding a random factor to its own authorized sub-private key as illustrated in column 212; generates one or more claims as illustrated in column 214; generates a signed attestation evidence as illustrated in column 216; and provides 224 the next layer’s sub-private key, and signed attestation evidence to the next layer. With the exemplary process 200, each attesting layer receives a unique authorized sub-private signing key and a corresponding authorized sub-public key. Each layer’s corresponding sub- public key is certified or authorized, by the previous layer via a digital signature, thereby eliminating any requirement for use of an X.509 certificate structure or certificate processing. In one embodiment, generation of layered attestation evidence ^_^ proceeds by generating and incorporating attestation evidence for each layer in the same order as layers are loaded during the boot sequence. Alternatively, attestation evidence for each layer may be incorporated into the layered attestation evidence in any suitable order as desired. The first layer 232, referred to herein as Layer 0, has no prior layer and therefore generates and signs its own attestation evidence ^_^. Layer 0 reads 210 both the device root sub-private key ^_^ and the signed device root sub-public key ^{^_^^^} _^^ from secure storage 208, then incorporates the signed device root sub-public key {^_^^}_^^ into the layer 0 attestation evidence ^_^. The layer 0 attestation evidence ^_^ is signed with the device root private key ^_^ to form the signed layer 0 attestation evidence as shown in Equation 7:

In certain embodiments, layer 0 generates one or more layer 0 claims ^_^ where the layer 0 claims include information about the layer 0 code, and optionally represent an execution state of the layer 0 code. The one or more layer 0 claims ^_^ may be incorporated into the layer 0 attestation evidence ^_^ and signed with the device root private key ^_^ to generate the signed layer 0 attestation evidence ^{^_^ ^} _^^. When a layer generates and signs its own attestation evidence, it is referred to as self-attestation. Self-attestation relies on a certain level of trust between a verifier 218 and the self-attesting layer, which is Layer 0 in the present example. A suitable level of trust may be established when the self-attesting layer is a trusted component, such as a first-stage boot loader stored in an immutable secure memory. Once Layer 0 generates its own signed attestation evidence {^_^}_^^, an iterative process begins where a current layer generates signed attestation evidence for the next layer. The iterative process begins with Layer 0 measuring 222 layer 1 and generating one or more layer 1 claims ^_^. A layer 1 random factor ^_^ is generated and used to compute a layer 1 sub-private key ^_^ and a layer 1 sub-public key ^_^^ as described above. The layer 1 claims ^_^ , signed layer 0 attestation evidence ^{^_^ ^} _^^, and the layer 1 sub-public key ^_^^ are combined to form a layer 1 attestation evidence ^_^, which is then signed using the layer 0 private key ^_^ to form the signed layer 1 attestation evidence as shown in Equation 8:

The layer 1 sub-private key ^_^ and the signed layer 1 attestation evidence {^_^}_^^ are then passed 224 to layer 1 in preparation for the next iteration. In the next iteration, the above steps are repeated by Layer 1 to compute a layer 2 sub-private key ^_^ and generate a signed layer 2 attestation evidence {^_^}_^^ = ^^_^, {^_^}_^^ , ^_^^^_^^. The layer 2 sub-private key ^_^ and the signed layer 2 attestation evidence {^_^}_^^are then passe 234 to Layer 2 in preparation for the next iteration. The above-described iterative process repeats for each layer until signed attestation evidence ^{^_^ ^} _^^^^ is generated for the last layer 226, labelled as Layer n in Figure 2. The final signed layer n attestation evidence ^{^_^ ^} _^^^^ becomes the layered attestation evidence ^_^ incorporating signed layer attestation evidences for all layers executing within the apparatus 204. The iterative process results in a layered attestation evidence ^_^ that includes recursively nested signed attestation evidence for all the layers. When attestation is desired, the layered attestation evidence ^_^, may be sent 220 to a verifier 218 where it may be verified. The layered attestation evidence ^_^ includes all information necessary to allow a verifier 218 to generate the required keys and cryptographically verify each signed attestation evidence included in the layered attestation evidence, based only on a trusted copy of the master public key ^_^,. With the layered attestation evidence ^_^ generated by the exemplary process 200, a verifier 218 needs only a single manufacturer-specific master public key to fully verify the layered attestation evidence. There is no need for any device-specific public keys or software layer specific keys, no need to distribute any device specific public keys to verifiers, and verifiers do not need to store any device-specific keys. All validation keys necessary to verify a layered attestation evidence can be constructed using the master public key and the sub-public keys incorporated in the layered attestation evidence ^_^. Figure 3 illustrates a flowchart showing an exemplary method 300 for generating layered attestation evidence based on additive asymmetric keys incorporating aspects of the disclosed embodiments. The exemplary method 300 of the disclosed embodiments is appropriate for generating a layered attestation evidence ^_^ on a computing apparatus, such as the apparatus 100 described above. The exemplary method 300 avoids proliferation of asymmetric key pairs and eliminates the need to deploy a complex PKI to distribute and maintain a large population of keys. Generation of layered attestation evidence relies on availability of a device root sub-private key ^_^ and a device root sub-public key ^_^. These values may be provisioned by the manufacturer and stored in a secure memory, such as an OTP memory. The exemplary method 300 obtains the device root sub-private key ^_^ and the device root sub-public key ^_^ such as by reading them from the secure memory. A loop 304 is used to iteratively generate and incorporate attestation evidence for each layer beginning with layer zero and incorporating each subsequent layer until all layers have been incorporated into the layered attestation evidence. Those skilled in the art will recognize that steps illustrated in the exemplary method 300, and similarly steps of the process 128 described above, may be performed in any order without straying from the spirit and scope of the present disclosure. In the illustrated method 300 an iteration begins with the current layer measuring 304 the next layer. The measurements may include any desired measured values such as a hash of the next layer’s program code, runtime state or other program values, and a timestamp, etc. One or more next layer claims ^_^^^ are generated 308, based when desired on the measurements. The one or more next layer claims ^_^^^ may incorporate any suitable information, including but not limited to the measurements 304 of the next layer, a timestamp, a challenge value, a monotonic counter value, etc. Examples of useful information that may optionally be included in the one or more next layer claims ^_^^^ include, a software version number, a package name or identifier, and a manufacturer of the next layer software, etc. In certain embodiments the one or more next layer claims ^_^^^ may include a challenge value, such as a challenge value received from a verifying party. The challenge value may provide evidence of layer linking. Optionally, a counter value may be included in the one or more claims, thereby providing support for layer sequencing. A next layer random factor ^_^^^ is generated 310. The next layer random factor ^_^^^ may be generated in any suitable fashion such as by a PRNG. The next layer random factor ^_^^^ is used to compute 312 the next layer sub-private key ^_^^^ by adding the next layer random factor ^_^^^ to the current layer sub-private key ^_^. The corresponding next layer sub-public key ^_^^^^ is computed 314 by multiplying the group generation point ^ by the next layer random factor ^_^^^ . Next layer attestation evidence ^_^^^ is generated 316, where the next layer attestation evidence ^_^^^ includes the one or more next layer claims ^_^^^ along with the next layer sub-public key ^_^^^^. In certain embodiments the signed current layer attestation evidence {^_^}_^^^^ is included in the next layer attestation evidence ^_^^^ . Nesting the signed current layer attestation evidence within the next layer attestation evidence ^_^^^ supports layer linking and sequencing and also produces a single layered attestation evidence that include attestation evidence for verification of all the software layers. Integrity of the next layer attestation evidence is protected by signing 318 the next layer attestation evidence ^_^^^ with the current layer sub-private key ^_^ to produce a signed next layer attestation evidence ^{^_^^^ ^} _^^ as shown in Equation 9:

As described above the signed next layer attestation evidence ^{^_^^^ ^} _^^ includes both the next layer attestation evidence ^_^^^ and the signature ^^^{^_^^^}_^^ produced by signing the next layer attestation evidence {^_^^^}_^^ with the current layer sub-private key ^_^. The next layer sub-private key ^_^^^and the signed next layer attestation evidence ^{^_^^^ ^} _^^ are passed 320 or otherwise made available to the next layer, and control is passed 322 to the next layer. When there are additional layers requiring attestation evidence, the next layer next layer performs another iteration of the above process. Once all layers have been added to the signed layered attestation evidence the process terminates 324. Figure 4 illustrates a block diagram of an exemplary apparatus 400 configured to verify a layered attestation evidence incorporating aspects of the disclosed embodiments. The exemplary apparatus 400 is adapted to verify a layered attestation evidence, such as the layered attestation evidence ^_^ described above and with reference to Figure 1 through Figure 3. With the exemplary method 400 a layered attestation evidence ^_^ may be verified base only on a trusted copy of the master public key ^_^. All other information necessary to verify the layered attestation evidence ^_^ is incorporated within the layered attestation evidence ^_^ itself. The exemplary apparatus 400 may be any desired type of computing apparatus or general- purpose computing apparatus including but not limited to large scale computing apparatuses such as servers used in data centers, cloud computing centers, or cloud computing networks. The exemplary apparatus 400 may also be advantageously employed on smaller computing apparatus such as a smart phone, a mobile communications device, a phablet, a tablet, a laptop computer, a desktop computer, a workstation, or other general purpose computing apparatus. Included in the apparatus 400 is a processor 402 communicatively coupled to a memory 404 wherein the memory stores program instructions 430 that when executed by the processor 402 cause the processor to perform a variety of operations and methods. Any desired type or combination of computer accessible memory may be advantageously employed as the memory 404, including but not limited to random-access memory (RAM), read-only memory (ROM), or other suitable types of volatile and non-volatile memory. In certain embodiments the memory 404 may incorporate additional memory 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. Optionally, the apparatus 400 may include a secure memory 408, such as a one-time programmable (OTP) memory for securely storing sensitive and confidential data. The secure memory 408 may include any suitable type of secure memory such as various types of hardware security modules (HSM), one-time programmable memory, an eFuse type memory, or other suitable type of secure immutable memory. The processor 402 may incorporate any appropriate type of processing device as desired, including but not limited to a high-performance multi-core 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, wearables, and smart devices adapted for the internet of things (IoT). In certain embodiments, an interface 406 is be included in the exemplary apparatus 400, where the interface 406 is adapted to provide communications with external entities. Optionally any suitable type of interface may be advantageously employed as the interface 110, such as a network or other communication subsystem configured to provide communications over wireless or wired communication networks. Verification of a layered attestation evidence ^_^ , also referred to as the verification phase, typically takes place on an apparatus different than the attestation phase. For example, when an attesting apparatus, such as the exemplary apparatus 100 described above, needs to prove its trustworthiness to gain access to a service on the internet, verification of the attestation evidence may be performed by a separate apparatus 400 such as a web server. The relying party, which is the party requiring assurance of the attesting apparatus’s trustworthiness, may also be separate from the verifier, which is the party that validates the attestation evidence. The embodiments disclosed herein are equally applicable to systems where the relying party and verifying party are the same or separate entities. The exemplary apparatus 400 is configured as a verifier and may when desired be pre- provisioned with the master public key ^_^. The master public key ^_^ may be protected in a digital certificate 432 signed by a trusted CA and stored in the memory 104. Alternatively, the master public key ^_^ may be securely provisioned and stored in a secure memory 408. An overview of the verification method is informative as an aid to understanding verification of the attestation evidence is accomplished. The verifier recursively extracts the signed layer attestation evidences

…, {^_^}_^^^^, along with the corresponding sub- public keys ^_^^ , ^_^^, ^_^^, ..., ^_^^^^. The verifier then validates the signature on the signed device root sub-public key {^_^^}_^^ using the master public key ^_^ . When the signature validates correctly, the verifier is assured that the device root sub-public key ^_^^ was generated by the entity in possession of the master public key ^_^. Next the verifier computes a device root validation key as ^_^ = ^_^^ + ^_^^ , based on the master public key ^_^^ and the device root sub-public key ^_^^ , and uses it to validate the signature on the signed layer 0 attestation evidence ^{^_^ ^} _^^, where the contents of the layer 0 attestation evidence ^{^_^ ^} _^^ are as shown in Equation 7 above. When the signature validates correctly, the verifier is assured that the signed layer 0 attestation evidence {^_^}_^^ is valid and verifies that the layer 0 claims ^_^ are correct for layer 0. The verifier then validates the signed layer 1 attestation evidence ^{^_^ ^} _^^ based on the device root validation key ^_^, where signed layer 1 attestation evidence ^{^_^ ^} _^^ is shown in Equation 8 above. When the signature validates correctly, the layer 1 claims ^_^ are audited, such as against pre-determined claim policies. A layer 1 validation key

= ^_^ + ^_^^ is computed based on the layer 0 validation key ^_^ and the layer 1 sub-public key ^_^^, The layer 1 sub- public key ^_^^ is signed into the layer 1 attestation evidence ^{^_^ ^} _^^. Allowing verification of the sub-public key prior to use. The verifier repeats the above verification steps on each successive signed attestation evidence in an iterative fashion until all signed layer attention evidences included in the layered attestation evidence ^_^ have been validated, or until a failure is detected. Referring again to Figure 4, the memory 404 includes program instructions 430 that when executed by the processor 402 cause the processor to employ an iterative verification method 434 to verify a layered attestation evidence ^_^ such as the layered attestation evidence ^_^ described above. The exemplary verification method 434 receives 410 a layered attestation evidence ^_^ , wherein the layered attestation evidence ^_^ includes a signed current layer attestation evidence ^{^_^ ^} _^^^^ and a signed next layer attestation evidence ^{^_^^^ ^} _^^. The signed next layer attestation evidence ^{^_^^^ ^} _^^ includes one or more next layer claims ^_^^^, a signed current layer attestation evidence , and the next layer sub-public key ^_^^^^ as shown above in Equation 9. A current layer validation key ^_^ is computed based on a prior layer validation key

and a current layer sub-public key ^_^^. Being an iterative process, these values can be viewed as pre- conditions of the current iteration retained from the prior iteration and used to compute the current layer validation key ^_^ for use in the current iteration. It is interesting to note that the prior layer validation key

depends on the master public ^_^ key and all prior random factors ^_^ , ^_^ , …, ^_^^^ . Thus, the current layer validation key may be considered as being authorized by the holder of the master private key ^_^. The signed next layer validation evidence ^{^_^^^ ^} _^^ is validated 414 based on the current layer validation key ^_^, then the one or more claims are appraised 416 based on a pre-determined attestation policy. The pre-determined attestation policy may include any desired criteria suitable for evaluation of the one or more next layer claims ^_^^^ in preparation for making trust determinations. When validation 414 of the signed next layer validation evidence ^{^_^^^ ^} _^^ fails or appraisal 416 of the one or more next layer claims ^_^^^ fails 418, an attestation failure is indicated 418 and the method 434 exits 420. When both the validation 414 and appraisal 416 are successful 428, the method 432 checks 422 whether all layers have been validated. When all layers have not been validated, the compute 412, validate 414, and appraise 416 steps are repeated 426. Once all layers have been successfully validated 414 and appraised 416, the method 432 exits 424 and the apparatus 400 indicates the layered attestation evidence ^_^ is valid. In one embodiment the master public key ^_^ is embedded in a digital certificate signed by a trusted CA. The certificate may be validated based on a public key associated with the trusted CA, then the validated master public key ^_^ may be used for verification of the layered attestation evidence ^_^. Alternatively, the apparatus may include a secure memory 408, such as an OTP memory, and the master public key ^_^ may be securely stored in the secure memory 408. From time-to-time public keys are revoked, for example when a manufacturer goes out of business and wants to prevent unauthorized use. In certain embodiments it may be beneficial to include revocation information in the layered attestation evidence ^_^. The apparatus 400 may then validate the master public ^_^ key against the revocation information before using the master public key ^_^ to verify the layered attestation evidence ^_^. Figure 5 illustrates a flow chart of an exemplary method 500 for validating a layered attestation evidence based on additive asymmetric keys incorporating aspects of the disclosed embodiments. The exemplary method 500 is appropriate for use in a computing apparatus, such as the apparatus 400 described above and with reference to Figure 4. The exemplary method 500 is adapted to validate a layered attestation evidence, such as the layered attestation evidence ^_^ described above, based on a single master public key ^_^. The exemplary method 500 eliminates the need to securely distribute and store a large number of public keys when validating layered attestation evidence ^_^ for a large population of mobile computing apparatuses. The method 500 begins when a layered attestation evidence ^_^is received 502, wherein the layered attestation evidence ^_^ includes a signed current layer attestation evidence ^{^_^ ^} _^^^^ and a signed next layer attestation evidence {^_^^^}_^^ . The signed next layer attestation evidence {^_^^^}_^^ includes one or more next layer claims ^_^^^, signed current layer attestation evidence ^{^_^ ^} _^^^^ , and the next layer sub-public key ^_^^^^ as shown above in Equation 9. A current layer validation key ^_^ is computed 510 based on a prior layer validation key ^_^^^ and a current layer sub-public key ^_^^. In an iterative method, the prior layer validation key ^_^^^ and a current layer sub-public key ^_^^, having been computed during the prior iteration, may be viewed as pre-conditions of the current iteration. The prior layer validation key

and a current layer sub-public key ^_^^ are then used by the current iteration to compute 510 the current layer validation key

The signed next layer validation evidence ^{^_^^^ ^} _^^ is validated 512 based on the current layer validation key ^_^, then the one or more claims are appraised 514 based on a pre-determined attestation policy. The pre-determined attestation policy includes any desired criteria that may be advantageously employed to evaluate the one or more next layer claims ^_^^^ and make trust determinations. When validation 512 of the signed next layer validation evidence ^{^_^^^ ^} _^^ fails or appraisal 514 of the one or more next layer claims ^_^^^ fails 516, an attestation failure is indicated and the method 500 exits 518. When both the validation 512 and appraisal 514 are successful 520, the compute 510, validate 512, and appraise 514 steps are repeated until all layers have been processed. When all layers have been successfully validated 512 and successfully appraised 514, the method 500 exits 508 and indicates the layered attestation evidence ^_^ is valid. 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

CLAIMS 1. An apparatus (100) comprising a processor (102) and a memory (104), wherein the memory (104) comprises program instructions (130) that when executed by the processor (102) cause the processor (102) to: generate one or more next layer claims (^_^^^); generate a next layer random factor (^_^^^); compute a next layer private key (^_^^^) based on a current layer private key (^_^) and the next layer random factor (^_^^^); compute a next layer sub-public key (^_^^^^) based on the next layer random factor (^_^^^) and a group generation point (P); generate a next layer attestation evidence (^_^^^), wherein the next layer attestation evidence (^_^^^) comprises the one or more next layer claims (^_^^^), and the next layer sub- public key (ri+1P); sign the next layer attestation evidence ( ^_^^^ ) wherein the signed next layer attestation evidence (^{^_^^^ ^} _^^) comprises the next layer attestation evidence (^_^^^) and a signature (^^^(^_^^^ , ^_^ )) over the next layer attestation evidence based on the current layer private key (^_^); pass the next layer private key (^_^^^) and the signed next layer attestation evidence (^{^_^^^ ^} _^^) to a next layer; and pass control to the next layer.

2. The apparatus (100) according to claim 1 wherein the signed next layer attestation evidence (^{^_^^^ ^} _^^ ) comprises one or more of a signed current layer attestation evidence (^_^ ), a challenge value, and a monotonic counter value.

3. The apparatus (100) according to claim 1 wherein the processor (102) is configured to generate one or more measurements based on a next layer, and the one or more claims (^_^^^) comprise one or more of the one or more measurements.

4. The apparatus (100) according to any one of the preceding claims wherein the apparatus (100) comprises a one-time programmable memory (108), and wherein the processor (102) is configured to: receive a device root sub-private key (^_^), a device root sub-public key (^_^^), and a signature (^^^⁽^_^^ , ^_^ ⁾) over the device root sub-public key (^_^^) based on a master private key (^_^); and store the device root sub-private key (^_^), the device root sub-public key (^_^^), and the signature (^^^⁽^_^^ , ^_^ ⁾) over the device root sub-public key (^_^^) in the one-time programmable memory (108).

5. The apparatus (100) according to any one of the preceding claims wherein the one or more next layer claims (^_^^^) comprise a hash of the next layer binary code.

6. The apparatus (100) according to any one of the preceding claims wherein the one or more next layer claims (^_^^^) comprise runtime status information of the next layer.

7. The apparatus (100) according to any one of the preceding claims wherein the signature , ^_^ ) ) over the next layer attestation evidence is generated with a discrete logarithm problem based asymmetric digital signature scheme.

8. The apparatus (100) according to any one of the preceding claims wherein the signature (^^^(^_^^^ , ^_^ )) over the next layer attestation information is generated based on an elliptic curve digital signature algorithm.

9. The apparatus (100) according to any one of the preceding claims wherein the one or more claims (^_^^^) comprise a timestamp.

10. The apparatus according to any one of the preceding claims wherein the one or more claims (^_^^^) comprise a master public key (^_^) wherein the master public key (^_^) is associated with the master private key (^_^).

11. The apparatus (100) according to any one of the preceding claims wherein the apparatus further comprises a pseudo random number generator (106) and generating the next layer random factor (^_^^^ ) comprises extracting a random number from the pseudo random number generator (106).

12. The apparatus (100) according to any one of the preceding claims wherein the apparatus (100) comprises a trusted execution environment and the memory (104) comprises one or more layers, and wherein one or more of the one or more layers is configured to execute within the trusted execution environment.

13. The apparatus (100) according to any one of the preceding claims wherein the processor (102) is configured to execute a plurality of software layers, and wherein the plurality of software layers comprises one or more of a boot loader, an operating system, a hypervisor, and a virtual machine.

14. The apparatus (100) according to any one of the preceding claims wherein the apparatus (100) comprises one or more of a mobile phone, a mobile communication device, an Internet of Things device, a wearable device, a laptop computer, and a desktop computer.

15. A method (300) comprising: generating (308) one or more next layer claims (^_^^^); generating (310) a next layer random factor (^_^^^); computing (312) a next layer sub-private key (^_^^^) based on a current layer sub- private key (^_^) and the next layer random factor (^_^^^); computing (314) a next layer sub-public key (^_^^^^) based on the next layer random factor (^_^^^) and a group generator point (P); generating (316) a next layer attestation evidence (^_^^^), wherein the next layer attestation evidence (^_^^^) comprises the one or more next layer claims (^_^^^) and the next layer sub-public key (ri+1P); signing (318) the next layer next layer attestation evidence (^_^^^ ), wherein the signed next layer attestation evidence ( ^{^_^^^ ^} _^^ ) comprises the next layer attestation evidence (^_^^^) and a signature (^^^⁽^_^^^ , ^_^ ⁾) over the next layer attestation evidence based on the current layer sub-private key (^_^); passing (320) the next layer sub-private key (^_^^^ ) and the signed next layer attestation evidence (^{^_^^^ ^} _^^) to a next layer; and passing (322) control to the next layer.

16. The method (300) according to claim 15 wherein the next layer attestation evidence (^_^^^) comprises one or more of a current layer attestation evidence (^_^), a challenge value, and a monotonic counter value.

17. The method (300) according to any one of claims 15 or 16 wherein the one or more claims (^_^^^) comprise one or more measurements, and generating (308) the one or more claims (^_^^^) comprises generating (308) the one or more measurements based on the next layer.

18. An apparatus (400) comprising a processor (402) and a memory (404), wherein the memory comprises program instructions (430) that when executed by the processor (402) cause the processor (402) to: receive a layered attestation evidence (^_^), wherein the layered attestation evidence (^_^) comprises a signed current layer attestation evidence (^{^_^ ^} _^^^^) and a signed next layer attestation evidence (^{^_^^^ ^} _^^), and wherein the signed current layer attestation evidence (^{^_^ ^} _^^^^) comprises a current layer sub-public key (^_^^), and wherein the signed next layer attestation evidence ({^_^^^}_^^) comprises one or more next layer claims (^_^^^); compute a current layer validation key (^_^) based on a prior layer validation key (^_^^^ ) and a current layer sub-public key (^_^^ ), wherein the prior layer validation key (^_^^^) depends on a master public key (^_^) and one or more random factors (^_^, ^_^,…); validate the signed next layer attestation evidence ({^_^^^}_^^) based on the current layer validation key (^_^); appraise the one or more next layer claims ( ^_^^^ ) based on a predetermined attestation policy; when the validation or the appraisal fail, indicate an attestation failure and exit; and when the validation and the appraisal are successful, repeat the compute, validate and appraise steps until all the attestation evidence has been verified.

19. The apparatus (400) according to claim 18 wherein the master public key (^_^) is embedded in a CA-signed certificate (432) and the apparatus (400) is configured to store the CA- signed certificate (432) in the memory (404).

20. The apparatus (400) according to claim 18 wherein the apparatus (400) further comprises a one-time programmable memory (408) and the processor is configured to store the master public key (^_^) in the one-time programmable memory (408).

21. The apparatus (400) according to claim 18 wherein the layered attestation evidence (^_^) comprises the master public key (^_^).

22. The apparatus (400) according to any one of the claims 18 through 21 wherein the layered attestation evidence (^_^) further comprises a revocation information, and the processor is configured to check the revocation information before validating the layered attestation evidence (^_^).

23. The apparatus (400) according to any one of the claims 18 through 22 wherein the apparatus comprises one or more of a mobile phone, a mobile communication device, an Internet of Things device, a wearable device, a laptop computer, a desktop computer, and a server.

24. A method (500) comprising: receiving (502) a layered attestation evidence (^_^), wherein the layered attestation evidence (^_^) comprises a signed current layer attestation evidence (^{^_^ ^} _^^^^) and a signed next layer attestation evidence ({^_^^^}_^^), and wherein the signed current layer attestation evidence ({^_^}_^^^^) comprises a current layer sub-public key (^_^^) and the signed next layer attestation evidence (^{^_^^^ ^} _^^) comprises one or more next layer claims (^_^^^); computing (510) a current layer validation key (^_^) based on a prior layer validation key (^_^^^) and a current layer sub-public key (^_^^), wherein the prior layer validation key (^_^^^) is computed based a master public key (^_^) and one or more random factors (^_^, ^_^,…); validating (512) the signed next layer signed attestation evidence (^{^_^^^ ^} _^^) based on the current layer validation key (^_^); appraising (514) the one or more next layer claims (^_^^^) based on a predetermined attestation policy; when the validating (512) or the appraising (514) fail (516), indicating (518) an attestation failure and exit; when the validating (512) and the appraising (514) are successful (520), repeat the computing (510), validating (512), and appraising (514) until the layered attestation evidence (^_^) has been verified (508).