idnits 2.17.1 draft-birkholz-tuda-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2598 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AIK-Cert' is mentioned on line 2498, but not defined == Missing Reference: 'TSA-Cert' is mentioned on line 2498, but not defined == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-09 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-00 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-01 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-11 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7320 (Obsoleted by RFC 8820) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Fuchs 3 Internet-Draft H. Birkholz 4 Intended status: Informational Fraunhofer SIT 5 Expires: September 14, 2017 I. McDonald 6 High North Inc 7 C. Bormann 8 Universitaet Bremen TZI 9 March 13, 2017 11 Time-Based Uni-Directional Attestation 12 draft-birkholz-tuda-04 14 Abstract 16 This memo documents the method and bindings used to conduct time- 17 based uni-directional attestation between distinguishable endpoints 18 over the network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 14, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Remote Attestation . . . . . . . . . . . . . . . . . . . 3 56 1.2. Attestation and Verification . . . . . . . . . . . . . . 4 57 1.3. Information Elements and Conveyance . . . . . . . . . . . 4 58 1.4. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 5 59 1.5. Hardware Dependencies . . . . . . . . . . . . . . . . . . 5 60 1.6. Requirements Notation . . . . . . . . . . . . . . . . . . 6 61 2. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.1.1. Universal Terms . . . . . . . . . . . . . . . . . . . 7 64 2.1.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . 9 65 2.1.3. General Types . . . . . . . . . . . . . . . . . . . . 9 66 2.1.4. TPM-Specific Terms . . . . . . . . . . . . . . . . . 9 67 2.1.5. Certificates . . . . . . . . . . . . . . . . . . . . 9 68 3. Time-Based Uni-Directional Attestation . . . . . . . . . . . 9 69 3.1. TUDA Information Elements Update Cycles . . . . . . . . . 11 70 4. Sync Base Protocol . . . . . . . . . . . . . . . . . . . . . 13 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 9.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 18 79 Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 19 80 B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 19 81 B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 20 82 B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 20 83 B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 20 84 B.2. Relationship to Host Resources MIB . . . . . . . . . . . 21 85 B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 21 86 B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 21 87 B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 21 88 Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 37 89 Appendix D. Realization with TPM 1.2 functions . . . . . . . . . 51 90 D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 51 91 D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 51 92 D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 52 93 D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 52 94 D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 53 95 D.2. Protocol and Procedure . . . . . . . . . . . . . . . . . 53 96 D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 53 97 D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 54 98 D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 56 99 D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 58 100 D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 59 101 D.2.6. Attestation Verification Approach . . . . . . . . . . 60 102 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 62 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 105 1. Introduction 107 Remote attestation describes the attempt to determine and appraise 108 properties, such as integrity and trustworthiness, of an endpoint -- 109 the attestee -- over a network to another endpoint -- the verifier -- 110 without direct access. Typically, this kind of assessment is based 111 on measurements of software components running on the attestee, where 112 the hash values of all started software components are stored 113 (extended into) a Trust-Anchor implemented as a Hardware Security 114 Module (e.g. a Trusted Platform Module or similar) and reported via a 115 signature over the measurements. 117 1.1. Remote Attestation 119 In essence, remote attestation is composed of three activities. The 120 following definitions are derived from the definitions presented in 121 [PRIRA] and [TCGGLOSS]. 123 Attestation: The creation of a claim about the properties of an 124 attestee, such that the claim can be used as evidence. 126 Conveyance: The transfer of evidence from the attestee to the 127 verifier. 129 Verification: The appraisal of evidence by evaluating it against 130 declarative guidance. 132 Protocols that facilitate Trust-Anchor based signatures in order to 133 provide remote attestation are usually bi-directional challenge/ 134 response protocols, such as the Platform Trust Service protocol [PTS] 135 or CAVES [PRIRA], where one entity sends a challenge that is included 136 inside the response to ensure the recentness -- the freshness -- of 137 the attestation information. The corresponding interaction model 138 tightly couples the three activities of creating, transferring and 139 appraising evidence. 141 The Time-Based Uni-directional Attestation family of protocols -- 142 TUDA -- described in this document can decouple the three activities 143 remote attestation is composed of. As a result, TUDA provides 144 additional capabilities, such as: 146 o remote attestation for attestees that might not always be able to 147 reach the Internet by enabling the verification of past states, 149 o secure audit logs by combining the evidence created via TUDA with 150 measurement logs that represent a detailed record of corresponding 151 past states, 153 o an uni-directional interaction model that can traverse "diode- 154 like" network security functions or can be leveraged in RESTful 155 architectures (e.g. CoAP [RFC7252]), analogously. 157 1.2. Attestation and Verification 159 TUDA is a family of protocols that package results from specific 160 attestation and verification protocols. TUDA is currently 161 instantiated for attestion activity based on a Trusted Platform 162 Module (TPM [TPM12]), a specific Hardware Security Module (HSM) 163 providing, e.g., Platform Configuration Registers (PCR), restricted 164 signing keys, and a source of (relative) time (i.e. a tick-counter). 166 Both the attestation and the verification activity of TUDA also 167 require a trusted Time Stamp Authority (TSA) as an additional third 168 party next to the attestee and the verifier. The current protocol 169 instantiaton uses a Time Stamp Authority based on [RFC3161]. The 170 combination of the local source of time provided by the TPM (located 171 on the attestee) and the Time Stamp Tokens provided by the TSA (to 172 both the attestee and the verifier) enable the attestation and 173 verification of an appropriate freshness of the evidence conveyed by 174 the attestee -- without requiring a challenge/response interaction 175 model that uses a nonce to ensure the freshness. 177 The verification activity also requires declarative guidance 178 (representing desired or compliant endpoint configuration and state) 179 evidence conveyed by the attestee can be evaluated against. The 180 acquisition or representation of declarative guidance as well as the 181 corresponding evaluation methods are out of the scope of this 182 document. 184 1.3. Information Elements and Conveyance 186 TUDA defines a set of information elements (IE) that are created or 187 stored on the attestee and are intended to be transferred to the 188 verifier in order to enable appraisal. 190 Each TUDA IE is encoded in the Concise Binary Object Representation 191 (CBOR [RFC7049]) to minimize the volume of data in motion. In this 192 document, the composition of the CBOR data items that represent IE is 193 described using the CBOR Data Definition Language, CDDL 194 [I-D.greevenbosch-appsawg-cbor-cddl]. 196 Each TUDA IE that requires a certain freshness is only created/ 197 updated when out-dated, which reduces the overall resources required 198 from the attestee, including the utilization of the TPM. The IE that 199 have to be created are determined by their age or by specific state 200 changes on the attestee (e.g. state changes due to a reboot-cycle). 202 Each TUDA IE is only transferred when required, which reduces the 203 amount of data in motion necessary to conduct remote attestation 204 significantly. Only IE that have changed since their last conveyance 205 have to be transferred. 207 Each TUDA IE that requires a certain freshness can be reused for 208 multiple remote attestation procedures in the limits of its 209 corresponding freshness-window, further reducing the load imposed on 210 the attestee and its corresponding TPM. 212 1.4. TUDA Objectives 214 The Time-Based Uni-directional Attestation family of protocols is 215 designed to: 217 o increase the confidence in authentication and authorization 218 procedures, 220 o address the requirements of constrained-node networks, 222 o support interaction models that do not maintain connection-state 223 over time, such as REST architectures [REST], 225 o be able to leverage existing management interfaces, such as SNMP 226 [RFC3411]. RESTCONF [RFC8040] or CoMI [I-D.ietf-core-comi] -- and 227 corresponding bindings, 229 o support broadcast and multicast schemes (e.g. [IEEE1609]), 231 o be able to cope with temporary loss of connectivity, and to 233 o provide trustworthy audit logs of past endpoint states. 235 1.5. Hardware Dependencies 237 The binding of the attestation scheme used by TUDA to generate the 238 TUDA IE is specific to the methods provided by the HSM used. As a 239 reference, this document includes pseudo-code that illustrates the 240 production of TUDA IE using a TPM 1.2 and the corresponding TPM 241 commands specified in [TPM12] as an example. The references to TPM 242 1.2 commands and corresponding pseudo-code only serve as guidance to 243 enable a better understanding of the attestation scheme and is 244 intended to encourages the use of any appropriate HSM or equivalent 245 set of Trust-Zone functions. 247 1.6. Requirements Notation 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 251 "OPTIONAL" in this document are to be interpreted as described in RFC 252 2119, BCP 14 [RFC2119]. 254 2. TUDA Core Concept 256 There are significant differences between conventional bi-directional 257 attestation and TUDA regarding both the information elements conveyed 258 between attestee and verifier and the time-frame, in which an 259 attestation can be considered to be fresh (and therefore 260 trustworthy). 262 In general, remote attestation using a bi-directional communication 263 scheme includes sending a nonce-challenge within a signed attestation 264 token. Using the TPM 1.2 as an example, a corresponding nonce- 265 challenge would be included within the signature created by the 266 TPM_Quote command in order to prove the freshness of the attestation 267 response, see e.g. [PTS]. 269 In contrast, the TUDA protocol would use a combination output of 270 TPM_CertifyInfo and TPM_TickStampBlob. The former provides a proof 271 about the platform's state by attesting that a certain key is bound 272 to said state. The latter provides proof that the platform was in 273 the specified state by using the bound key in a time operation. This 274 combination enables a time-based attestation scheme. This approach 275 is based on the concepts introduced in [SCALE] and [SFKE2008]. 277 The payload of information elements transmitted is based on different 278 methods, because the time-frame, in which an attestation is 279 considered to be fresh (and therefore trustworthy), is defined 280 differently. 282 The freshness properties of a challenge-response based protocol 283 define the point-of-time of attestation between: 285 o the time of transmission of the nonce, and 287 o the reception of the response 288 Given the time-based attestation scheme, the freshness property of 289 TUDA is equivalent to that of bi-directional challenge response 290 attestation, if the point-in-time of attestation lies between: 292 o the transmission of a TUDA time-synchronization token, and 294 o the typical round-trip time between the verifier and the attestee, 296 The accuracy of this time-frame is defined by two factors: 298 o the time-synchronization between the attestee and the TSA. The 299 time between the two TPM tickstamps give the maximum drift (left 300 and right) to the TSA timestamp, and 302 o the drift of local TPM clocks. 304 Since TUDA attestations do not rely upon a verifier provided value 305 (i.e. the nonce), the security guarantees of the protocol only 306 incorporate the TSA and the TPM. As a consequence TUDA attestations 307 can even serve as proof of integrity in audit logs with point in time 308 guarantees, in contrast to classical attestations. 310 Appendix A contains guidance on how to utilize a REST architecture. 312 Appendix B contains guidance on how to create an SNMP binding and a 313 corresponding TUDA-MIB. 315 Appendix C contains a corrresponding YANG module that supports both 316 RESTCONF and CoMI. 318 Appendix D contains a realization of TUDA using TPM 1.2 primitives. 319 A realization of TUDA using TPM 2.0 primitives will be added with the 320 next iteration of this document. 322 2.1. Terminology 324 This document introduces roles, information elements and types 325 required to conduct TUDA and uses terminology (e.g. specific 326 certificate names) typically seen in the context of attestation or 327 hardware security modules. 329 2.1.1. Universal Terms 331 Attestation Identity Key (AIK): a special purpose signature 332 (therefore asymmetric) key that supports identity related 333 operations. The private portion of the key pair is maintained 334 confidential to the entity via appropriate measures (that have an 335 impact on the scope of confidence). The public portion of the key 336 pair may be included in AIK credentials that provide a claim about 337 the entity. 339 Claim: an attribute value pair that is intended to be related to a 340 statement [I-D.ietf-sacm-terminology]. 342 Endpoint Attestation: the creation of evidence on the attestee that 343 provides proof of a set of the endpoints's integrity measurements. 344 This is done by digitally signing a set of PCRs using an AIK in 345 the TPM. 347 Endpoint Characteristics: the composition, configuration and state 348 of an endpoint. 350 Evidence: a trustworthy set of claims about an endpoint's 351 characteristics. 353 Identity: a set of claims that is intended to be related to an 354 entity. 356 Integrity Measurements: Metrics of endpoint characteristics (i.e. 357 composition, configuration and state) that affect the confidence 358 in the trustworthiness of an endpoint. Digests of integrity 359 measurements can be stored in shielded locations (i.e. PCR of a 360 TPM). 362 Reference Integrity Measurements: Signed measurements about the 363 characteristics of an endpoint's characteristics that are provided 364 by a vendor and are intended to be used as declarative guidance 365 [I-D.ietf-sacm-terminology] (e.g. a signed CoSWID). 367 Trustworthy: the qualities of an endpoint that guarantee a specific 368 behavior and/or endpoint characteristics defined by declarative 369 guidance. Analogously, trustworthiness is the quality of being 370 trustworthy with respect to declarative guidance. Trustworthiness 371 is not an absolute property but defined with respect to an entity, 372 corresponding declarative guidance, and has a scope of confidence. 374 Trustworthy Endpoint: an endpoint that guarantees trustworthy 375 behavior and/or composition (with respect to certain declarative 376 guidance and a scope of confidence). 378 Trustworthy Statement: evidence that is trustworthy conveyed by an 379 endpoint that is not necessarily trustworthy. 381 2.1.2. Roles 383 Attestee: the endpoint that is the subject of the attestation to 384 another endpoint. 386 Verifier: the endpoint that consumes the attestation of another 387 endpoint to conduct a verification. 389 TSA: a Time Stamp Authority [RFC3161] 391 2.1.3. General Types 393 Byte: the now customary synonym for octet 395 Cert: an X.509 certificate represented as a byte-string 397 2.1.4. TPM-Specific Terms 399 PCR: a Platform Configuration Register that is part of a TPM and is 400 used to securely store and report measurements about security 401 posture 403 PCR-Hash: a hash value of the security posture measurements stored 404 in a TPM PCR (e.g. regarding running software instances) 405 represented as a byte-string 407 2.1.5. Certificates 409 TSA-CA: the Certificate Authority that provides the certificate for 410 the TSA represented as a Cert 412 AIK-CA: the Certificate Authority that provides the certificate for 413 the attestation identity key of the TPM. This is the client 414 platform credential for this protocol. It is a placeholder for a 415 specific CA and AIK-Cert is a placeholder for the corresponding 416 certificate, depending on what protocol was used. The specific 417 protocols are out of scope for this document, see also 418 [AIK-Enrollment] and [IEEE802.1AR]. 420 3. Time-Based Uni-Directional Attestation 422 A Time-Based Uni-Directional Attestation (TUDA) consists of the 423 following seven information elements. They are used to gain 424 assurance of the Attestee's platform configuration at a certain point 425 in time: 427 TSA Certificate: The certificate of the Time Stamp Authority that is 428 used in a subsequent synchronization protocol token. This 429 certificate is signed by the TSA-CA. 431 AIK Certificate: A certificate about the Attestation Identity Key 432 (AIK) used. This may or may not also be an [IEEE802.1AR] IDevID 433 or LDevID, depending on their setting of the corresponding 434 identity property. ([AIK-Credential], [AIK-Enrollment]; see 435 Appendix D.2.1.) 437 Synchronization Token: The reference for Attestations are the Tick- 438 Sessions of the TPM. In order to put Attestations into relation 439 with a Real Time Clock (RTC), it is necessary to provide a 440 cryptographic synchronization between the tick session and the 441 RTC. To do so, a synchronization protocol is run with a Time 442 Stamp Authority (TSA). 444 Restriction Info: The attestation relies on the capability of the 445 TPM to operate on restricted keys. Whenever the PCR values for 446 the machine to be attested change, a new restricted key is created 447 that can only be operated as long as the PCRs remain in their 448 current state. 450 In order to prove to the Verifier that this restricted temporary 451 key actually has these properties and also to provide the PCR 452 value that it is restricted, the TPM command TPM_CertifyInfo is 453 used. It creates a signed certificate using the AIK about the 454 newly created restricted key. 456 Measurement Log: Similarly to regular attestations, the Verifier 457 needs a way to reconstruct the PCRs' values in order to estimate 458 the trustworthiness of the device. As such, a list of those 459 elements that were extended into the PCRs is reported. Note 460 though that for certain environments, this step may be optional if 461 a list of valid PCR configurations exists and no measurement log 462 is required. 464 Implicit Attestation: The actual attestation is then based upon a 465 TPM_TickStampBlob operation using the restricted temporary key 466 that was certified in the steps above. The TPM_TickStampBlob is 467 executed and thereby provides evidence that at this point in time 468 (with respect to the TPM internal tick-session) a certain 469 configuration existed (namely the PCR values associated with the 470 restricted key). Together with the synchronization token this 471 tick-related timing can then be related to the real-time clock. 473 Concise SWID tags: As an option to better assess the trustworthiness 474 of an Attestee, a Verifier can request the reference hashes (often 475 referred to as golden measurements) of all started software 476 components to compare them with the entries in the measurement 477 log. References hashes regarding installed (and therefore 478 running) software can be provided by the manufacturer via SWID 479 tags. SWID tags are provided by the Attestee using the Concise 480 SWID representation [I-D.ietf-sacm-coswid] and bundled into a CBOR 481 array. Ideally, the reference hashes include a signature created 482 by the manufacturer of the software. 484 These information elements could be sent en bloc, but it is 485 recommended to retrieve them separately to save bandwidth, since 486 these elements have different update cycles. In most cases, 487 retransmitting all seven information elements would result in 488 unnecessary redundancy. 490 Furthermore, in some scenarios it might be feasible not to store all 491 elements on the Attestee endpoint, but instead they could be 492 retrieved from another location or pre-deployed to the Verifier. It 493 is also feasible to only store public keys at the Verifier and skip 494 the whole certificate provisioning completely in order to save 495 bandwidth and computation time for certificate verification. 497 3.1. TUDA Information Elements Update Cycles 499 An endpoint can be in various states and have various information 500 associated with it during its life cycle. For TUDA, a subset of the 501 states (which can include associated information) that an endpoint 502 and its TPM can be in, is important to the attestation process. 504 o Some states are persistent, even after reboot. This includes 505 certificates that are associated with the endpoint itself or with 506 services it relies on. 508 o Some states are more volatile and change at the beginning of each 509 boot cycle. This includes the TPM-internal Tick-Session which 510 provides the basis for the synchronization token and implicit 511 attestation. 513 o Some states are even more volatile and change during an uptime 514 cycle (the period of time an endpoint is powered on, starting with 515 its boot). This includes the content of PCRs of a TPM and thereby 516 also the PCR-restricted keys used during attestation. 518 Depending on this "lifetime of state", data has to be transported 519 over the wire, or not. E.g. information that does not change due to 520 a reboot typically has to be transported only once between the 521 Attestee and the Verifier. 523 There are three kinds of events that require a renewed attestation: 525 o The Attestee completes a boot-cycle 527 o A relevant PCR changes 529 o Too much time has passed since the last attestation statement 531 The third event listed above is variable per application use case and 532 can therefore be set appropriately. For usage scenarios, in which 533 the device would periodically push information to be used in an 534 audit-log, a time-frame of approximately one update per minute should 535 be sufficient in most cases. For those usage scenarios, where 536 verifiers request (pull) a fresh attestation statement, an 537 implementation could use the TPM continuously to always present the 538 most freshly created results. To save some utilization of the TPM 539 for other purposes, however, a time-frame of once per ten seconds is 540 recommended, which would leave 80% of utilization for applications. 542 Attestee Verifier 543 | | 544 Boot | 545 | | 546 Create Sync-Token | 547 | | 548 Create Restricted Key | 549 Certify Restricted Key | 550 | | 551 | AIK-Cert ---------------------------------------------> | 552 | Sync-Token -------------------------------------------> | 553 | Certify-Info -----------------------------------------> | 554 | Measurement Log --------------------------------------> | 555 | Attestation ------------------------------------------> | 556 | Verify Attestation 557 | | 558 |