Network Working Group A. Fuchs Internet-Draft H. Birkholz Intended status: Informational Fraunhofer SIT Expires: April 26, 2019 I. McDonald High North Inc C. Bormann Universitaet Bremen TZI October 23, 2018 Time-Based Uni-Directional Attestation draft-birkholz-i2nsf-tuda-04 Abstract This memo documents the method and bindings used to conduct time- based uni-directional attestation between distinguishable endpoints over the network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 26, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Fuchs, et al. Expires April 26, 2019 [Page 1] Internet-Draft tuda October 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Remote Attestation . . . . . . . . . . . . . . . . . . . 4 1.2. Evidence Creation . . . . . . . . . . . . . . . . . . . . 5 1.3. Evidence Appraisal . . . . . . . . . . . . . . . . . . . 5 1.4. Activities and Actions . . . . . . . . . . . . . . . . . 5 1.5. Attestation and Verification . . . . . . . . . . . . . . 6 1.6. Information Elements and Conveyance . . . . . . . . . . . 6 1.7. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 7 1.8. Hardware Dependencies . . . . . . . . . . . . . . . . . . 7 1.9. Requirements Notation . . . . . . . . . . . . . . . . . . 7 2. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Universal Terms . . . . . . . . . . . . . . . . . . . . . 9 3.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. General Types . . . . . . . . . . . . . . . . . . . . 11 3.2.2. RoT specific terms . . . . . . . . . . . . . . . . . 11 3.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 11 4. Time-Based Uni-Directional Attestation . . . . . . . . . . . 11 4.1. TUDA Information Elements Update Cycles . . . . . . . . . 13 5. Sync Base Protocol . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 21 Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 21 B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 22 B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 22 B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 22 B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 22 B.2. Relationship to Host Resources MIB . . . . . . . . . . . 23 B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 23 B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 23 B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 23 Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 39 Appendix D. Realization with TPM functions . . . . . . . . . . . 54 D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 54 D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 54 D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 55 D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 55 Fuchs, et al. Expires April 26, 2019 [Page 2] Internet-Draft tuda October 2018 D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 55 D.2. IE Generation Procedures for TPM 1.2 . . . . . . . . . . 56 D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 56 D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 57 D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 59 D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 61 D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 62 D.2.6. Attestation Verification Approach . . . . . . . . . . 63 D.3. IE Generation Procedures for TPM 2.0 . . . . . . . . . . 65 D.3.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 65 D.3.2. Synchronization Token . . . . . . . . . . . . . . . . 66 D.3.3. Measurement Log . . . . . . . . . . . . . . . . . . . 66 D.3.4. Explicit time-based Attestation . . . . . . . . . . . 67 D.3.5. Sync Proof . . . . . . . . . . . . . . . . . . . . . 67 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 1. Introduction Remote attestation (RA) describes the attempt to determine and appraise properties, such as integrity and trustworthiness, of an endpoint -- the Attestor -- over a network to another endpoint -- the Verifier -- without direct access. Typically, this kind of appraisal is based on integrity measurements of software components right before they are loaded as software instances on the Attestor. In general, attestation procedures are utilizing a hardware root of trust (RoT). The TUDA protocol family uses hash values of all started software components that are stored (extended into) a Trust- Anchor (the RoT) implemented as a Hardware Security Module (e.g. a Trusted Platform Module or similar) and are reported via a signature over those measurements. This draft introduces the concept of including the exchange of evidence -- created via a hardware RoT containing a shielded secret that is inaccessible to the user -- in order to increase the confidence in a communication peer that is supposed to be a Trusted System [RFC4949]. In consequence, this document introduces the term forward authenticity. Forward Authenticity (FA): A property of secure communication protocols, in which later compromise of the long-term keys of a data origin does not compromise past authentication of data from that origin. FA is achieved by timely recording of assessments of the authenticity from entities (via "audit logs" during "audit sessions") that are authorized for this purpose, in a time frame much shorter than that expected for the compromise of the long- term keys. Fuchs, et al. Expires April 26, 2019 [Page 3] Internet-Draft tuda October 2018 Forward Authenticity enables new level of guarantee and can be included in the basically every protocol, such as ssh, router advertisements, link layer neighbor discover, or even ICMP echo. 1.1. Remote Attestation In essence, remote attestation (RA) is composed of three activities. The following definitions are derived from the definitions presented in [PRIRA] and [TCGGLOSS]. Attestation: The creation of one ore more claims about the properties of an Attestor, such that the claims can be used as evidence. Conveyance: The transfer of evidence from the Attestor to the Verifier via an interconnect. Verification: The appraisal of evidence by evaluating it against declarative guidance. With TUDA, the claims that compose the evidence are signatures over trustworthy integrity measurements created by leveraging a hardware RoT. The evidence is appraised via corresponding signatures over reference integrity measurements (RIM, represented, for example via [I-D.ietf-sacm-coswid]). Protocols that facilitate Trust-Anchor based signatures in order to provide RATS are usually bi-directional challenge/response protocols, such as the Platform Trust Service protocol [PTS] or CAVES [PRIRA], where one entity sends a challenge that is included inside the response to prove the recentness -- the freshness (see fresh in [RFC4949]) -- of the attestation information. The corresponding interaction model tightly couples the three activities of creating, transferring and appraising evidence. The Time-Based Uni-directional Attestation family of protocols -- TUDA -- described in this document can decouple the three activities RATS are composed of. As a result, TUDA provides additional capabilities, such as: o remote attestation for Attestors that might not always be able to reach the Internet by enabling the verification of past states, o secure audit logs by combining the evidence created via TUDA with integrity measurement logs that represent a detailed record of corresponding past states, Fuchs, et al. Expires April 26, 2019 [Page 4] Internet-Draft tuda October 2018 o an uni-directional interaction model that can traverse "diode- like" network security functions (NSF) or can be leveraged in RESTful architectures (e.g. CoAP [RFC7252]), analogously. 1.2. Evidence Creation TUDA is a family of protocols that bundles results from specific attestation activities. The attestation activities of TUDA are based on a hardware Root of Trust that provides the following capabilities: o Platform Configuration Registers (PCR) that store measurements consecutively (corresponding terminology: "to extend a PCR") and represent the chain of measurements as a single measurement value ("PCR value"), o Restricted Signing Keys (RSK) that can only be accessed, if a specific signature about measurements can be provided as authentication, and o a dedicated source of (relative) time, e.g. a tick counter. 1.3. Evidence Appraisal To appraise the evidence created by an Attestor, the Verifier requires corresponding Reference Integrity Measurements (RIM). Typically, a set of RIM are bundled in a RIM-Manifest (RIMM). The scope of a manifest encompasses, e.g., a platform, a device, a computing context, or a virtualised function. In order to be comparable, the hashing algorithms used by the Attestor to create the integrity measurements have to match the hashing algorithms used to create the corresponding RIM that are used by the Verifier to appraise the integrity evidence. 1.4. Activities and Actions Depending on the platform (i.e. one or more computing contexts including a dedicated hardware RoT), a generic RA activity results in platform-specific actions that have to be conducted. In consequence, there are multiple specific operations and data models (defining the input and output of operations). Hence, specific actions are are not covered by this document. Instead, the requirements on operations and the information elements that are the input and output to these operations are illustrated using pseudo code in Appendix C and D. Fuchs, et al. Expires April 26, 2019 [Page 5] Internet-Draft tuda October 2018 1.5. Attestation and Verification Both the attestation and the verification activity of TUDA also require a trusted Time Stamp Authority (TSA) as an additional third party next to the Attestor and the Verifier. The protocol uses a Time Stamp Authority based on [RFC3161]. The combination of the local source of time provided by the hardware RoT (located on the Attestor) and the Time Stamp Tokens provided by the TSA (to both the Attestor and the Verifier) enable the attestation and verification of an appropriate freshness of the evidence conveyed by the Attestor -- without requiring a challenge/response interaction model that uses a nonce to ensure the freshness. Typically, the verification activity requires declarative guidance (representing desired or compliant endpoint characteristics in the form of RIM, see above) to appraise the individual integrity measurements the conveyed evidence is composed on. The acquisition or representation (data models) of declarative guidance as well as the corresponding evaluation methods are out of the scope of this document. 1.6. Information Elements and Conveyance TUDA defines a set of information elements (IE) that are created and stored on the Attestor and are intended to be transferred to the Verifier in order to enable appraisal. Each TUDA IE: o is encoded in the Concise Binary Object Representation (CBOR [RFC7049]) to minimize the volume of data in motion. In this document, the composition of the CBOR data items that represent IE is described using the Concise Data Definition Language, CDDL [I-D.ietf-cbor-cddl] o that requires a certain freshness is only created/updated when out-dated, which reduces the overall resources required from the Attestor, including the utilization of the hardware root of trust. The IE that have to be created are determined by their age or by specific state changes on the Attestor (e.g. state changes due to a reboot-cycle) o is only transferred when required, which reduces the amount of data in motion necessary to conduct remote attestation significantly. Only IE that have changed since their last conveyance have to be transferred o that requires a certain freshness can be reused for multiple remote attestation procedures in the limits of its corresponding Fuchs, et al. Expires April 26, 2019 [Page 6] Internet-Draft tuda October 2018 freshness-window, further reducing the load imposed on the Attestor and its corresponding hardware RoT. 1.7. TUDA Objectives The Time-Based Uni-directional Attestation family of protocols is designed to: o increase the confidence in authentication and authorization procedures, o address the requirements of constrained-node networks, o support interaction models that do not maintain connection-state over time, such as REST architectures [REST], o be able to leverage existing management interfaces, such as SNMP [RFC3411]. RESTCONF [RFC8040] or CoMI [I-D.ietf-core-comi] -- and corresponding bindings, o support broadcast and multicast schemes (e.g. [IEEE1609]), o be able to cope with temporary loss of connectivity, and to o provide trustworthy audit logs of past endpoint states. 1.8. Hardware Dependencies The binding of the attestation scheme used by TUDA to generate the TUDA IE is specific to the methods provided by the hardware RoT used (see above). In this document,expositional text and pseudo-code that is provided as a reference to instantiate the TUDA IE is based on TPM 1.2 and TPM 2.0 operations. The corresponding TPM commands are specified in [TPM12] and [TPM2]. The references to TPM commands and corresponding pseudo-code only serve as guidance to enable a better understanding of the attestation scheme and is intended to encourage the use of any appropriate hardware RoT or equivalent set of functions available to a CPU or Trusted Execution Environment [TEE]. 1.9. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119]. Fuchs, et al. Expires April 26, 2019 [Page 7] Internet-Draft tuda October 2018 2. TUDA Core Concept There are significant differences between conventional bi-directional attestation and TUDA regarding both the information elements conveyed between Attestor and Verifier and the time-frame, in which an attestation can be considered to be fresh (and therefore trustworthy). In general, remote attestation using a bi-directional communication scheme includes sending a nonce-challenge within a signed attestation token. Using the TPM 1.2 as an example, a corresponding nonce- challenge would be included within the signature created by the TPM_Quote command in order to prove the freshness of the attestation response, see e.g. [PTS]. In contrast, the TUDA protocol uses the combined output of TPM_CertifyInfo and TPM_TickStampBlob. The former provides a proof about the platform's state by creating evidence that a certain key is bound to that state. The latter provides proof that the platform was in the specified state by using the bound key in a time operation. This combination enables a time-based attestation scheme. The approach is based on the concepts introduced in [SCALE] and [SFKE2008]. Each TUDA IE has an individual time-frame, in which it is considered to be fresh (and therefore trustworthy). In consequence, each TUDA IE that composes data in motion is based on different methods of creation. The freshness properties of a challenge-response based protocol define the point-of-time of attestation between: o the time of transmission of the nonce, and o the reception of the corresponding response. Given the time-based attestation scheme, the freshness property of TUDA is equivalent to that of bi-directional challenge response attestation, if the point-in-time of attestation lies between: o the transmission of a TUDA time-synchronization token, and o the typical round-trip time between the Verifier and the Attestor. The accuracy of this time-frame is defined by two factors: o the time-synchronization between the Attestor and the TSA. The time between the two tickstamps acquired via the hardware RoT Fuchs, et al. Expires April 26, 2019 [Page 8] Internet-Draft tuda October 2018 define the scope of the maximum drift ("left" and "right" in respect to the timeline) to the TSA timestamp, and o the drift of clocks included in the hardware RoT. Since the conveyance of TUDA evidence does not rely upon a Verifier provided value (i.e. the nonce), the security guarantees of the protocol only incorporate the TSA and the hardware RoT. In consequence, TUDA evidence can even serve as proof of integrity in audit logs with precise point-in-time guarantees, in contrast to classical attestations. Appendix A contains guidance on how to utilize a REST architecture. Appendix B contains guidance on how to create an SNMP binding and a corresponding TUDA-MIB. Appendix C contains a corresponding YANG module that supports both RESTCONF and CoMI. Appendix D.2 contains a realization of TUDA using TPM 1.2 primitives. Appendix D.3 contains a realization of TUDA using TPM 2.0 primitives. 3. Terminology This document introduces roles, information elements and types required to conduct TUDA and uses terminology (e.g. specific certificate names) typically seen in the context of attestation or hardware security modules. 3.1. Universal Terms Attestation Identity Key (AIK): a special purpose signature (therefore asymmetric) key that supports identity related operations. The private portion of the key pair is maintained confidential to the entity via appropriate measures (that have an impact on the scope of confidence). The public portion of the key pair may be included in AIK credentials that provide a claim about the entity. Claim: A piece of information asserted about a subject [RFC4949]. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value [RFC7519]. In the context of SACM, a claim is also specialized as an attribute/value pair that is intended to be related to a statement [I-D.ietf-sacm-terminology]. Fuchs, et al. Expires April 26, 2019 [Page 9] Internet-Draft tuda October 2018 Endpoint Attestation: the creation of evidence on the Attestor that provides proof of a set of the endpoints's integrity measurements. This is done by digitally signing a set of PCRs using an AIK shielded by the hardware RoT. Endpoint Characteristics: the context, composition, configuration, state, and behavior of an endpoint. Evidence: a trustworthy set of claims about an endpoint's characteristics. Identity: a set of claims that is intended to be related to an entity. Integrity Measurements: Metrics of endpoint characteristics (i.e. composition, configuration and state) that affect the confidence in the trustworthiness of an endpoint. Digests of integrity measurements can be stored in shielded locations (i.e. PCR of a TPM). Reference Integrity Measurements: Signed measurements about the characteristics of an endpoint's characteristics that are provided by a vendor and are intended to be used as declarative guidance [I-D.ietf-sacm-terminology] (e.g. a signed CoSWID). Trustworthy: the qualities of an endpoint that guarantee a specific behavior and/or endpoint characteristics defined by declarative guidance. Analogously, trustworthiness is the quality of being trustworthy with respect to declarative guidance. Trustworthiness is not an absolute property but defined with respect to an entity, corresponding declarative guidance, and has a scope of confidence. Trustworthy Endpoint: an endpoint that guarantees trustworthy behavior and/or composition (with respect to certain declarative guidance and a scope of confidence). Trustworthy Statement: evidence that is trustworthy conveyed by an endpoint that is not necessarily trustworthy. 3.2. Roles Attestor: the endpoint that is the subject of the attestation to another endpoint. Verifier: the endpoint that consumes the attestation of another endpoint to conduct a verification. TSA: a Time Stamp Authority [RFC3161] Fuchs, et al. Expires April 26, 2019 [Page 10] Internet-Draft tuda October 2018 3.2.1. General Types Byte: the now customary synonym for octet Cert: an X.509 certificate represented as a byte-string 3.2.2. RoT specific terms PCR: a Platform Configuration Register that is part of a hardware root of trust and is used to securely store and report measurements about security posture PCR-Hash: a hash value of the security posture measurements stored in a TPM PCR (e.g. regarding running software instances) represented as a byte-string 3.3. Certificates TSA-CA: the Certificate Authority that provides the certificate for the TSA represented as a Cert AIK-CA: the Certificate Authority that provides the certificate for the attestation identity key of the TPM. This is the client platform credential for this protocol. It is a placeholder for a specific CA and AIK-Cert is a placeholder for the corresponding certificate, depending on what protocol was used. The specific protocols are out of scope for this document, see also [AIK-Enrollment] and [IEEE802.1AR]. 4. Time-Based Uni-Directional Attestation A Time-Based Uni-Directional Attestation (TUDA) consists of the following seven information elements. They are used to gain assurance of the Attestor's platform configuration at a certain point in time: TSA Certificate: The certificate of the Time Stamp Authority that is used in a subsequent synchronization protocol token. This certificate is signed by the TSA-CA. AIK Certificate: A certificate about the Attestation Identity Key (AIK) used. This may or may not also be an [IEEE802.1AR] IDevID or LDevID, depending on their setting of the corresponding identity property. ([AIK-Credential], [AIK-Enrollment]; see Appendix D.2.1.) Synchronization Token: The reference for attestations are the relative timestanps provided by the hardware RoT. In order to put Fuchs, et al. Expires April 26, 2019 [Page 11] Internet-Draft tuda October 2018 attestations into relation with a Real Time Clock (RTC), it is necessary to provide a cryptographic synchronization between these trusted relative timestamps and the regular RTC that is a hardware component of the Attestor. To do so, a synchronization protocol is run with a Time Stamp Authority (TSA). Restriction Info: The attestation relies on the capability of the hardware RoT to operate on restricted keys. Whenever the PCR values for the machine to be attested change, a new restricted key is created that can only be operated as long as the PCRs remain in their current state. In order to prove to the Verifier that this restricted temporary key actually has these properties and also to provide the PCR value that it is restricted, the corresponding signing capabilities of the hardware RoT are used. It creates a signed certificate using the AIK about the newly created restricted key. Measurement Log: Similarly to regular attestations, the Verifier needs a way to reconstruct the PCRs' values in order to estimate the trustworthiness of the device. As such, a list of those elements that were extended into the PCRs is reported. Note though that for certain environments, this step may be optional if a list of valid PCR configurations (in the form of RIM available to the Verifier) exists and no measurement log is required. Implicit Attestation: The actual attestation is then based upon a signed timestamp provided by the hardware RoT using the restricted temporary key that was certified in the steps above. The signed timestamp provides evidence that at this point in time (with respect to the relative time of the hardware RoT) a certain configuration existed (namely the PCR values associated with the restricted key). Together with the synchronization token this timestamp represented in relative time can then be related to the real-time clock. Concise SWID tags: As an option to better assess the trustworthiness of an Attestor, a Verifier can request the reference hashes (RIM, which are often referred to as golden measurements) of all started software components to compare them with the entries in the measurement log. References hashes regarding installed (and therefore running) software can be provided by the manufacturer via SWID tags. SWID tags are provided by the Attestor using the Concise SWID representation [I-D.ietf-sacm-coswid] and bundled into a CBOR array (a RIM Manifest). Ideally, the reference hashes include a signature created by the manufacturer of the software to prove their integrity. Fuchs, et al. Expires April 26, 2019 [Page 12] Internet-Draft tuda October 2018 These information elements could be sent en bloc, but it is recommended to retrieve them separately to save bandwidth, since these elements have different update cycles. In most cases, retransmitting all seven information elements would result in unnecessary redundancy. Furthermore, in some scenarios it might be feasible not to store all elements on the Attestor endpoint, but instead they could be retrieved from another location or be pre-deployed to the Verifier. It is also feasible to only store public keys on the Verifier and skip the whole certificate provisioning completely in order to save bandwidth and computation time for certificate verification. 4.1. TUDA Information Elements Update Cycles An endpoint can be in various states and have various information associated with it during its life cycle. For TUDA, a subset of the states (which can include associated information) that an endpoint and its hardware root of trust can be in, is important to the attestation process. States can be: o persistent, even after a hard reboot. This includes certificates that are associated with the endpoint itself or with services it relies on. o volatile to a degree, because they change at the beginning of each boot cycle. This includes the capability of a hardware RoT to provide relative time which provides the basis for the synchronization token and implicit attestation--and which can reset after an endpoint is powered off. o very volatile, because they change during an uptime cycle (the period of time an endpoint is powered on, starting with its boot). This includes the content of PCRs of a hardware RoT and thereby also the PCR-restricted signing keys used for attestation. Depending on this "lifetime of state", data has to be transported over the wire, or not. E.g. information that does not change due to a reboot typically has to be transported only once between the Attestor and the Verifier. There are three kinds of events that require a renewed attestation: o The Attestor completes a boot-cycle o A relevant PCR changes o Too much time has passed since the last attestation statement Fuchs, et al. Expires April 26, 2019 [Page 13] Internet-Draft tuda October 2018 The third event listed above is variable per application use case and also depends on the precision of the clock included in the hardware RoT. For usage scenarios, in which the device would periodically push information to be used in an audit-log, a time-frame of approximately one update per minute should be sufficient in most cases. For those usage scenarios, where Verifiers request (pull) a fresh attestation statement, an implementation could use the hardware RoT continuously to always present the most freshly created results. To save some utilization of the hardware RoT for other purposes, however, a time-frame of once per ten seconds is recommended, which would typically leave about 80% of utilization for other applications. Attestor Verifier | | Boot | | | Create Sync-Token | | | Create Restricted Key | Certify Restricted Key | | | | AIK-Cert ---------------------------------------------> | | Sync-Token -------------------------------------------> | | Certify-Info -----------------------------------------> | | Measurement Log --------------------------------------> | | Attestation ------------------------------------------> | | Verify Attestation | | |