idnits 2.17.1 draft-birkholz-rats-tuda-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2019) is 1862 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 3046, but not defined == Missing Reference: 'TSA-Cert' is mentioned on line 3046, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-07 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-04 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-08 -- 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: 1 error (**), 0 flaws (~~), 6 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 13, 2019 I. McDonald 6 High North Inc 7 C. Bormann 8 Universitaet Bremen TZI 9 March 12, 2019 11 Time-Based Uni-Directional Attestation 12 draft-birkholz-rats-tuda-00 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 https://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 13, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . 4 56 1.2. Evidence Creation . . . . . . . . . . . . . . . . . . . . 5 57 1.3. Evidence Appraisal . . . . . . . . . . . . . . . . . . . 5 58 1.4. Activities and Actions . . . . . . . . . . . . . . . . . 5 59 1.5. Attestation and Verification . . . . . . . . . . . . . . 6 60 1.6. Information Elements and Conveyance . . . . . . . . . . . 6 61 1.7. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 7 62 1.8. Hardware Dependencies . . . . . . . . . . . . . . . . . . 7 63 1.9. Requirements Notation . . . . . . . . . . . . . . . . . . 7 64 2. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 8 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Universal Terms . . . . . . . . . . . . . . . . . . . . . 9 67 3.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.2.1. General Types . . . . . . . . . . . . . . . . . . . . 11 69 3.2.2. RoT specific terms . . . . . . . . . . . . . . . . . 11 70 3.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 11 71 4. Time-Based Uni-Directional Attestation . . . . . . . . . . . 11 72 4.1. TUDA Information Elements Update Cycles . . . . . . . . . 13 73 5. Sync Base Protocol . . . . . . . . . . . . . . . . . . . . . 15 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 80 10.2. Informative References . . . . . . . . . . . . . . . . . 17 81 Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 21 82 Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 21 83 B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 22 84 B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 22 85 B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 22 86 B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 22 87 B.2. Relationship to Host Resources MIB . . . . . . . . . . . 23 88 B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 23 89 B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 23 90 B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 23 91 Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 39 92 Appendix D. Realization with TPM functions . . . . . . . . . . . 54 93 D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 54 94 D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 54 95 D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 55 96 D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 55 97 D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 56 98 D.2. IE Generation Procedures for TPM 1.2 . . . . . . . . . . 56 99 D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 56 100 D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 57 101 D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 59 102 D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 61 103 D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 62 104 D.2.6. Attestation Verification Approach . . . . . . . . . . 63 105 D.3. IE Generation Procedures for TPM 2.0 . . . . . . . . . . 65 106 D.3.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 65 107 D.3.2. Synchronization Token . . . . . . . . . . . . . . . . 66 108 D.3.3. Measurement Log . . . . . . . . . . . . . . . . . . . 66 109 D.3.4. Explicit time-based Attestation . . . . . . . . . . . 67 110 D.3.5. Sync Proof . . . . . . . . . . . . . . . . . . . . . 67 111 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 68 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 114 1. Introduction 116 Remote attestation (RA) describes the attempt to determine and 117 appraise properties, such as integrity and trustworthiness, of an 118 endpoint -- the Attestor -- over a network to another endpoint -- the 119 Verifier -- without direct access. Typically, this kind of appraisal 120 is based on integrity measurements of software components right 121 before they are loaded as software instances on the Attestor. In 122 general, attestation procedures are utilizing a hardware root of 123 trust (RoT). The TUDA protocol family uses hash values of all 124 started software components that are stored (extended into) a Trust- 125 Anchor (the RoT) implemented as a Hardware Security Module (e.g. a 126 Trusted Platform Module or similar) and are reported via a signature 127 over those measurements. 129 This draft introduces the concept of including the exchange of 130 evidence -- created via a hardware RoT containing a shielded secret 131 that is inaccessible to the user -- in order to increase the 132 confidence in a communication peer that is supposed to be a Trusted 133 System [RFC4949]. In consequence, this document introduces the term 134 forward authenticity. 136 Forward Authenticity (FA): A property of secure communication 137 protocols, in which later compromise of the long-term keys of a 138 data origin does not compromise past authentication of data from 139 that origin. FA is achieved by timely recording of assessments of 140 the authenticity from entities (via "audit logs" during "audit 141 sessions") that are authorized for this purpose, in a time frame 142 much shorter than that expected for the compromise of the long- 143 term keys. 145 Forward Authenticity enables new level of guarantee and can be 146 included in the basically every protocol, such as ssh, router 147 advertisements, link layer neighbor discover, or even ICMP echo. 149 1.1. Remote Attestation 151 In essence, remote attestation (RA) is composed of three activities. 152 The following definitions are derived from the definitions presented 153 in [PRIRA] and [TCGGLOSS]. 155 Attestation: The creation of one ore more claims about the 156 properties of an Attestor, such that the claims can be used as 157 evidence. 159 Conveyance: The transfer of evidence from the Attestor to the 160 Verifier via an interconnect. 162 Verification: The appraisal of evidence by evaluating it against 163 declarative guidance. 165 With TUDA, the claims that compose the evidence are signatures over 166 trustworthy integrity measurements created by leveraging a hardware 167 RoT. The evidence is appraised via corresponding signatures over 168 reference integrity measurements (RIM, represented, for example via 169 [I-D.ietf-sacm-coswid]). 171 Protocols that facilitate Trust-Anchor based signatures in order to 172 provide RATS are usually bi-directional challenge/response protocols, 173 such as the Platform Trust Service protocol [PTS] or CAVES [PRIRA], 174 where one entity sends a challenge that is included inside the 175 response to prove the recentness -- the freshness (see fresh in 176 [RFC4949]) -- of the attestation information. The corresponding 177 interaction model tightly couples the three activities of creating, 178 transferring and appraising evidence. 180 The Time-Based Uni-directional Attestation family of protocols -- 181 TUDA -- described in this document can decouple the three activities 182 RATS are composed of. As a result, TUDA provides additional 183 capabilities, such as: 185 o remote attestation for Attestors that might not always be able to 186 reach the Internet by enabling the verification of past states, 188 o secure audit logs by combining the evidence created via TUDA with 189 integrity measurement logs that represent a detailed record of 190 corresponding past states, 192 o an uni-directional interaction model that can traverse "diode- 193 like" network security functions (NSF) or can be leveraged in 194 RESTful architectures (e.g. CoAP [RFC7252]), analogously. 196 1.2. Evidence Creation 198 TUDA is a family of protocols that bundles results from specific 199 attestation activities. The attestation activities of TUDA are based 200 on a hardware Root of Trust that provides the following capabilities: 202 o Platform Configuration Registers (PCR) that store measurements 203 consecutively (corresponding terminology: "to extend a PCR") and 204 represent the chain of measurements as a single measurement value 205 ("PCR value"), 207 o Restricted Signing Keys (RSK) that can only be accessed, if a 208 specific signature about measurements can be provided as 209 authentication, and 211 o a dedicated source of (relative) time, e.g. a tick counter. 213 1.3. Evidence Appraisal 215 To appraise the evidence created by an Attestor, the Verifier 216 requires corresponding Reference Integrity Measurements (RIM). 217 Typically, a set of RIM are bundled in a RIM-Manifest (RIMM). The 218 scope of a manifest encompasses, e.g., a platform, a device, a 219 computing context, or a virtualised function. In order to be 220 comparable, the hashing algorithms used by the Attestor to create the 221 integrity measurements have to match the hashing algorithms used to 222 create the corresponding RIM that are used by the Verifier to 223 appraise the integrity evidence. 225 1.4. Activities and Actions 227 Depending on the platform (i.e. one or more computing contexts 228 including a dedicated hardware RoT), a generic RA activity results in 229 platform-specific actions that have to be conducted. In consequence, 230 there are multiple specific operations and data models (defining the 231 input and output of operations). Hence, specific actions are are not 232 covered by this document. Instead, the requirements on operations 233 and the information elements that are the input and output to these 234 operations are illustrated using pseudo code in Appendix C and D. 236 1.5. Attestation and Verification 238 Both the attestation and the verification activity of TUDA also 239 require a trusted Time Stamp Authority (TSA) as an additional third 240 party next to the Attestor and the Verifier. The protocol uses a 241 Time Stamp Authority based on [RFC3161]. The combination of the 242 local source of time provided by the hardware RoT (located on the 243 Attestor) and the Time Stamp Tokens provided by the TSA (to both the 244 Attestor and the Verifier) enable the attestation and verification of 245 an appropriate freshness of the evidence conveyed by the Attestor -- 246 without requiring a challenge/response interaction model that uses a 247 nonce to ensure the freshness. 249 Typically, the verification activity requires declarative guidance 250 (representing desired or compliant endpoint characteristics in the 251 form of RIM, see above) to appraise the individual integrity 252 measurements the conveyed evidence is composed on. The acquisition 253 or representation (data models) of declarative guidance as well as 254 the corresponding evaluation methods are out of the scope of this 255 document. 257 1.6. Information Elements and Conveyance 259 TUDA defines a set of information elements (IE) that are created and 260 stored on the Attestor and are intended to be transferred to the 261 Verifier in order to enable appraisal. Each TUDA IE: 263 o is encoded in the Concise Binary Object Representation (CBOR 264 [RFC7049]) to minimize the volume of data in motion. In this 265 document, the composition of the CBOR data items that represent IE 266 is described using the Concise Data Definition Language, CDDL 267 [I-D.ietf-cbor-cddl] 269 o that requires a certain freshness is only created/updated when 270 out-dated, which reduces the overall resources required from the 271 Attestor, including the utilization of the hardware root of trust. 272 The IE that have to be created are determined by their age or by 273 specific state changes on the Attestor (e.g. state changes due to 274 a reboot-cycle) 276 o is only transferred when required, which reduces the amount of 277 data in motion necessary to conduct remote attestation 278 significantly. Only IE that have changed since their last 279 conveyance have to be transferred 281 o that requires a certain freshness can be reused for multiple 282 remote attestation procedures in the limits of its corresponding 283 freshness-window, further reducing the load imposed on the 284 Attestor and its corresponding hardware RoT. 286 1.7. TUDA Objectives 288 The Time-Based Uni-directional Attestation family of protocols is 289 designed to: 291 o increase the confidence in authentication and authorization 292 procedures, 294 o address the requirements of constrained-node networks, 296 o support interaction models that do not maintain connection-state 297 over time, such as REST architectures [REST], 299 o be able to leverage existing management interfaces, such as SNMP 300 [RFC3411]. RESTCONF [RFC8040] or CoMI [I-D.ietf-core-comi] -- and 301 corresponding bindings, 303 o support broadcast and multicast schemes (e.g. [IEEE1609]), 305 o be able to cope with temporary loss of connectivity, and to 307 o provide trustworthy audit logs of past endpoint states. 309 1.8. Hardware Dependencies 311 The binding of the attestation scheme used by TUDA to generate the 312 TUDA IE is specific to the methods provided by the hardware RoT used 313 (see above). In this document,expositional text and pseudo-code that 314 is provided as a reference to instantiate the TUDA IE is based on TPM 315 1.2 and TPM 2.0 operations. The corresponding TPM commands are 316 specified in [TPM12] and [TPM2]. The references to TPM commands and 317 corresponding pseudo-code only serve as guidance to enable a better 318 understanding of the attestation scheme and is intended to encourage 319 the use of any appropriate hardware RoT or equivalent set of 320 functions available to a CPU or Trusted Execution Environment [TEE]. 322 1.9. Requirements Notation 324 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 325 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 326 "OPTIONAL" in this document are to be interpreted as described in RFC 327 2119, BCP 14 [RFC2119]. 329 2. TUDA Core Concept 331 There are significant differences between conventional bi-directional 332 attestation and TUDA regarding both the information elements conveyed 333 between Attestor and Verifier and the time-frame, in which an 334 attestation can be considered to be fresh (and therefore 335 trustworthy). 337 In general, remote attestation using a bi-directional communication 338 scheme includes sending a nonce-challenge within a signed attestation 339 token. Using the TPM 1.2 as an example, a corresponding nonce- 340 challenge would be included within the signature created by the 341 TPM_Quote command in order to prove the freshness of the attestation 342 response, see e.g. [PTS]. 344 In contrast, the TUDA protocol uses the combined output of 345 TPM_CertifyInfo and TPM_TickStampBlob. The former provides a proof 346 about the platform's state by creating evidence that a certain key is 347 bound to that state. The latter provides proof that the platform was 348 in the specified state by using the bound key in a time operation. 349 This combination enables a time-based attestation scheme. The 350 approach is based on the concepts introduced in [SCALE] and 351 [SFKE2008]. 353 Each TUDA IE has an individual time-frame, in which it is considered 354 to be fresh (and therefore trustworthy). In consequence, each TUDA 355 IE that composes data in motion is based on different methods of 356 creation. 358 The freshness properties of a challenge-response based protocol 359 define the point-of-time of attestation between: 361 o the time of transmission of the nonce, and 363 o the reception of the corresponding response. 365 Given the time-based attestation scheme, the freshness property of 366 TUDA is equivalent to that of bi-directional challenge response 367 attestation, if the point-in-time of attestation lies between: 369 o the transmission of a TUDA time-synchronization token, and 371 o the typical round-trip time between the Verifier and the Attestor. 373 The accuracy of this time-frame is defined by two factors: 375 o the time-synchronization between the Attestor and the TSA. The 376 time between the two tickstamps acquired via the hardware RoT 377 define the scope of the maximum drift ("left" and "right" in 378 respect to the timeline) to the TSA timestamp, and 380 o the drift of clocks included in the hardware RoT. 382 Since the conveyance of TUDA evidence does not rely upon a Verifier 383 provided value (i.e. the nonce), the security guarantees of the 384 protocol only incorporate the TSA and the hardware RoT. In 385 consequence, TUDA evidence can even serve as proof of integrity in 386 audit logs with precise point-in-time guarantees, in contrast to 387 classical attestations. 389 Appendix A contains guidance on how to utilize a REST architecture. 391 Appendix B contains guidance on how to create an SNMP binding and a 392 corresponding TUDA-MIB. 394 Appendix C contains a corresponding YANG module that supports both 395 RESTCONF and CoMI. 397 Appendix D.2 contains a realization of TUDA using TPM 1.2 primitives. 399 Appendix D.3 contains a realization of TUDA using TPM 2.0 primitives. 401 3. Terminology 403 This document introduces roles, information elements and types 404 required to conduct TUDA and uses terminology (e.g. specific 405 certificate names) typically seen in the context of attestation or 406 hardware security modules. 408 3.1. Universal Terms 410 Attestation Identity Key (AIK): a special purpose signature 411 (therefore asymmetric) key that supports identity related 412 operations. The private portion of the key pair is maintained 413 confidential to the entity via appropriate measures (that have an 414 impact on the scope of confidence). The public portion of the key 415 pair may be included in AIK credentials that provide a claim about 416 the entity. 418 Claim: A piece of information asserted about a subject [RFC4949]. A 419 claim is represented as a name/value pair consisting of a Claim 420 Name and a Claim Value [RFC7519]. 422 In the context of SACM, a claim is also specialized as an 423 attribute/value pair that is intended to be related to a statement 424 [I-D.ietf-sacm-terminology]. 426 Endpoint Attestation: the creation of evidence on the Attestor that 427 provides proof of a set of the endpoints's integrity measurements. 428 This is done by digitally signing a set of PCRs using an AIK 429 shielded by the hardware RoT. 431 Endpoint Characteristics: the context, composition, configuration, 432 state, and behavior of an endpoint. 434 Evidence: a trustworthy set of claims about an endpoint's 435 characteristics. 437 Identity: a set of claims that is intended to be related to an 438 entity. 440 Integrity Measurements: Metrics of endpoint characteristics (i.e. 441 composition, configuration and state) that affect the confidence 442 in the trustworthiness of an endpoint. Digests of integrity 443 measurements can be stored in shielded locations (i.e. PCR of a 444 TPM). 446 Reference Integrity Measurements: Signed measurements about the 447 characteristics of an endpoint's characteristics that are provided 448 by a vendor and are intended to be used as declarative guidance 449 [I-D.ietf-sacm-terminology] (e.g. a signed CoSWID). 451 Trustworthy: the qualities of an endpoint that guarantee a specific 452 behavior and/or endpoint characteristics defined by declarative 453 guidance. Analogously, trustworthiness is the quality of being 454 trustworthy with respect to declarative guidance. Trustworthiness 455 is not an absolute property but defined with respect to an entity, 456 corresponding declarative guidance, and has a scope of confidence. 458 Trustworthy Endpoint: an endpoint that guarantees trustworthy 459 behavior and/or composition (with respect to certain declarative 460 guidance and a scope of confidence). 462 Trustworthy Statement: evidence that is trustworthy conveyed by an 463 endpoint that is not necessarily trustworthy. 465 3.2. Roles 467 Attestor: the endpoint that is the subject of the attestation to 468 another endpoint. 470 Verifier: the endpoint that consumes the attestation of another 471 endpoint to conduct a verification. 473 TSA: a Time Stamp Authority [RFC3161] 475 3.2.1. General Types 477 Byte: the now customary synonym for octet 479 Cert: an X.509 certificate represented as a byte-string 481 3.2.2. RoT specific terms 483 PCR: a Platform Configuration Register that is part of a hardware 484 root of trust and is used to securely store and report 485 measurements about security posture 487 PCR-Hash: a hash value of the security posture measurements stored 488 in a TPM PCR (e.g. regarding running software instances) 489 represented as a byte-string 491 3.3. Certificates 493 TSA-CA: the Certificate Authority that provides the certificate for 494 the TSA represented as a Cert 496 AIK-CA: the Certificate Authority that provides the certificate for 497 the attestation identity key of the TPM. This is the client 498 platform credential for this protocol. It is a placeholder for a 499 specific CA and AIK-Cert is a placeholder for the corresponding 500 certificate, depending on what protocol was used. The specific 501 protocols are out of scope for this document, see also 502 [AIK-Enrollment] and [IEEE802.1AR]. 504 4. Time-Based Uni-Directional Attestation 506 A Time-Based Uni-Directional Attestation (TUDA) consists of the 507 following seven information elements. They are used to gain 508 assurance of the Attestor's platform configuration at a certain point 509 in time: 511 TSA Certificate: The certificate of the Time Stamp Authority that is 512 used in a subsequent synchronization protocol token. This 513 certificate is signed by the TSA-CA. 515 AIK Certificate: A certificate about the Attestation Identity Key 516 (AIK) used. This may or may not also be an [IEEE802.1AR] IDevID 517 or LDevID, depending on their setting of the corresponding 518 identity property. ([AIK-Credential], [AIK-Enrollment]; see 519 Appendix D.2.1.) 521 Synchronization Token: The reference for attestations are the 522 relative timestanps provided by the hardware RoT. In order to put 523 attestations into relation with a Real Time Clock (RTC), it is 524 necessary to provide a cryptographic synchronization between these 525 trusted relative timestamps and the regular RTC that is a hardware 526 component of the Attestor. To do so, a synchronization protocol 527 is run with a Time Stamp Authority (TSA). 529 Restriction Info: The attestation relies on the capability of the 530 hardware RoT to operate on restricted keys. Whenever the PCR 531 values for the machine to be attested change, a new restricted key 532 is created that can only be operated as long as the PCRs remain in 533 their current state. 535 In order to prove to the Verifier that this restricted temporary 536 key actually has these properties and also to provide the PCR 537 value that it is restricted, the corresponding signing 538 capabilities of the hardware RoT are used. It creates a signed 539 certificate using the AIK about the newly created restricted key. 541 Measurement Log: Similarly to regular attestations, the Verifier 542 needs a way to reconstruct the PCRs' values in order to estimate 543 the trustworthiness of the device. As such, a list of those 544 elements that were extended into the PCRs is reported. Note 545 though that for certain environments, this step may be optional if 546 a list of valid PCR configurations (in the form of RIM available 547 to the Verifier) exists and no measurement log is required. 549 Implicit Attestation: The actual attestation is then based upon a 550 signed timestamp provided by the hardware RoT using the restricted 551 temporary key that was certified in the steps above. The signed 552 timestamp provides evidence that at this point in time (with 553 respect to the relative time of the hardware RoT) a certain 554 configuration existed (namely the PCR values associated with the 555 restricted key). Together with the synchronization token this 556 timestamp represented in relative time can then be related to the 557 real-time clock. 559 Concise SWID tags: As an option to better assess the trustworthiness 560 of an Attestor, a Verifier can request the reference hashes (RIM, 561 which are often referred to as golden measurements) of all started 562 software components to compare them with the entries in the 563 measurement log. References hashes regarding installed (and 564 therefore running) software can be provided by the manufacturer 565 via SWID tags. SWID tags are provided by the Attestor using the 566 Concise SWID representation [I-D.ietf-sacm-coswid] and bundled 567 into a CBOR array (a RIM Manifest). Ideally, the reference hashes 568 include a signature created by the manufacturer of the software to 569 prove their integrity. 571 These information elements could be sent en bloc, but it is 572 recommended to retrieve them separately to save bandwidth, since 573 these elements have different update cycles. In most cases, 574 retransmitting all seven information elements would result in 575 unnecessary redundancy. 577 Furthermore, in some scenarios it might be feasible not to store all 578 elements on the Attestor endpoint, but instead they could be 579 retrieved from another location or be pre-deployed to the Verifier. 580 It is also feasible to only store public keys on the Verifier and 581 skip the whole certificate provisioning completely in order to save 582 bandwidth and computation time for certificate verification. 584 4.1. TUDA Information Elements Update Cycles 586 An endpoint can be in various states and have various information 587 associated with it during its life cycle. For TUDA, a subset of the 588 states (which can include associated information) that an endpoint 589 and its hardware root of trust can be in, is important to the 590 attestation process. States can be: 592 o persistent, even after a hard reboot. This includes certificates 593 that are associated with the endpoint itself or with services it 594 relies on. 596 o volatile to a degree, because they change at the beginning of each 597 boot cycle. This includes the capability of a hardware RoT to 598 provide relative time which provides the basis for the 599 synchronization token and implicit attestation--and which can 600 reset after an endpoint is powered off. 602 o very volatile, because they change during an uptime cycle (the 603 period of time an endpoint is powered on, starting with its boot). 604 This includes the content of PCRs of a hardware RoT and thereby 605 also the PCR-restricted signing keys used for attestation. 607 Depending on this "lifetime of state", data has to be transported 608 over the wire, or not. E.g. information that does not change due to 609 a reboot typically has to be transported only once between the 610 Attestor and the Verifier. 612 There are three kinds of events that require a renewed attestation: 614 o The Attestor completes a boot-cycle 616 o A relevant PCR changes 618 o Too much time has passed since the last attestation statement 619 The third event listed above is variable per application use case and 620 also depends on the precision of the clock included in the hardware 621 RoT. For usage scenarios, in which the device would periodically 622 push information to be used in an audit-log, a time-frame of 623 approximately one update per minute should be sufficient in most 624 cases. For those usage scenarios, where Verifiers request (pull) a 625 fresh attestation statement, an implementation could use the hardware 626 RoT continuously to always present the most freshly created results. 627 To save some utilization of the hardware RoT for other purposes, 628 however, a time-frame of once per ten seconds is recommended, which 629 would typically leave about 80% of utilization for other 630 applications. 632 Attestor Verifier 633 | | 634 Boot | 635 | | 636 Create Sync-Token | 637 | | 638 Create Restricted Key | 639 Certify Restricted Key | 640 | | 641 | AIK-Cert ---------------------------------------------> | 642 | Sync-Token -------------------------------------------> | 643 | Certify-Info -----------------------------------------> | 644 | Measurement Log --------------------------------------> | 645 | Attestation ------------------------------------------> | 646 | Verify Attestation 647 | | 648 |