idnits 2.17.1 draft-birkholz-rats-tuda-03.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 (July 13, 2020) is 1380 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AIK-Cert' is mentioned on line 3147, but not defined == Missing Reference: 'TSA-Cert' is mentioned on line 3147, but not defined == Unused Reference: 'RFC7519' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sacm-terminology' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'IEEE802.11P' is defined on line 952, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5209 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-02) exists of draft-birkholz-rats-coswid-rim-00 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-10 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-05 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-15 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group A. Fuchs 3 Internet-Draft H. Birkholz 4 Intended status: Standards Track Fraunhofer SIT 5 Expires: January 14, 2021 I. McDonald 6 High North Inc 7 C. Bormann 8 Universitaet Bremen TZI 9 July 13, 2020 11 Time-Based Uni-Directional Attestation 12 draft-birkholz-rats-tuda-03 14 Abstract 16 This documents defines the method and bindings used to conduct Time- 17 based Uni-Directional Attestation (TUDA) between two RATS (Remote 18 ATtestation procedureS) entities over the Internet. TUDA does not 19 require a challenge-response handshake and thereby does not rely on 20 the conveyance of a nonce to prove freshness of remote attestation 21 Evidence. Conversely, TUDA enables the creation of Secure Audit Logs 22 that can constitute Evidence about current and past operational 23 states of an Attester. Every RATS entity requires access to a 24 trustable and synchronized time-source. A Handle Distributor takes 25 on the corresponding role of a Time Stamp Authority (TSA) to provide 26 Time Stamp Tokens (TST) to all RATS entities. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 14, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Forward Authenticity . . . . . . . . . . . . . . . . . . 4 64 1.2. Handle Distributor . . . . . . . . . . . . . . . . . . . 5 65 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Evidence in TUDA . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Generating Evidence about Software Component Integrity . . . 6 68 3.1. Measurements and Digests Generated by an Attester . . . . 6 69 3.2. Attesting Environments and Roots of Trust . . . . . . . . 6 70 3.3. Primitive Operations for Remote Attestation . . . . . . . 7 71 4. Remote Attestation Principles . . . . . . . . . . . . . . . . 7 72 4.1. Indeterministic Measurements . . . . . . . . . . . . . . 8 73 4.2. Principles of Uni-Directional and Time-Based Attestation 8 74 4.3. TUDA Attesting Environment Requirements . . . . . . . . . 9 75 4.4. TUDA Handle Distributor: Time Stamp Authority . . . . . . 9 76 4.5. Information Elements and Conveyance . . . . . . . . . . . 10 77 4.6. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 10 78 4.7. Hardware Dependencies . . . . . . . . . . . . . . . . . . 11 79 5. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. TPM Specific Terms . . . . . . . . . . . . . . . . . . . 12 81 5.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 13 82 6. The TUDA Protocol Family . . . . . . . . . . . . . . . . . . 13 83 6.1. TUDA Information Elements Update Cycles . . . . . . . . . 15 84 7. Sync Base Protocol . . . . . . . . . . . . . . . . . . . . . 18 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 11.2. Informative References . . . . . . . . . . . . . . . . . 20 91 Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 24 92 Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 24 93 B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 25 94 B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 25 95 B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 25 96 B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 26 97 B.2. Relationship to Host Resources MIB . . . . . . . . . . . 26 98 B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 26 99 B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 26 100 B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 26 101 Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 43 102 Appendix D. Realization with TPM functions . . . . . . . . . . . 57 103 D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 57 104 D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 58 105 D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 58 106 D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 59 107 D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 59 108 D.2. IE Generation Procedures for TPM 1.2 . . . . . . . . . . 59 109 D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 59 110 D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 60 111 D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 62 112 D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 64 113 D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 65 114 D.2.6. Attestation Verification Approach . . . . . . . . . . 66 115 D.3. IE Generation Procedures for TPM 2.0 . . . . . . . . . . 68 116 D.3.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 68 117 D.3.2. Synchronization Token . . . . . . . . . . . . . . . . 69 118 D.3.3. Measurement Log . . . . . . . . . . . . . . . . . . . 69 119 D.3.4. Explicit time-based Attestation . . . . . . . . . . . 70 120 D.3.5. Sync Proof . . . . . . . . . . . . . . . . . . . . . 70 121 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71 124 1. Introduction 126 Remote ATtestation procedureS (RATS) describe the attempt to 127 determine and appraise system properties, such as integrity and 128 trustworthiness, of a communication partner - the Attester - over the 129 Internet to another communication partner - the Verifier - without 130 direct access. TUDA uses the architectural constituents of the RATS 131 Architecture [I-D.ietf-rats-architecture] that defines the roles 132 Attester and Verifier in detail. The RATS Architecture also defines 133 Conceptual Messages conveyed between these roles. 135 TUDA creates and conveys a specific type of Conceptual Message called 136 Evidence: an integrity protected and tamper-evident composition of 137 trustworthiness Claims that are collected from an Attester's Target 138 Environments (defined in section 4.2. of 139 [I-D.ietf-rats-architecture]). Evidence is consumed and appraised by 140 a Verifier in order to eventually create Attestation Results. 142 Attestation Results are the output of RATS to support security 143 decisions made by Relying Parties. 145 In contrast to traditional bi-directional challenge-response 146 protocols (as defined in section 8.1 of 147 [I-D.birkholz-rats-reference-interaction-model]), TUDA enables a uni- 148 directional conveyance of attestation Evidence that allows for 149 providing attestation information without solicitation (as defined in 150 section 8.2 of [I-D.birkholz-rats-reference-interaction-model]). 151 Exemplary applications of TUDA protocol family are the creation of 152 beacons in vehicular environments ([IEEE1609]) or the notification 153 content of event streams created by YANG Push ([RFC8641], [RFC8640], 154 [RFC8639]). 156 1.1. Forward Authenticity 158 Nonces enable an implicit time-keeping in which the freshness of 159 evidence is inferred by recentness. Recentness is estimated via the 160 time interval between sending a nonce as part of a challenge for 161 Evidence and the reception of Evidence based on that nonce as 162 outlined in the interaction model depicted in section 8.1 in 163 [I-D.birkholz-rats-reference-interaction-model]. Conversely, the 164 omission of nonces in TUDA allows for explicit time-keeping where 165 freshness is not inferred from recentness. Instead, a cryptographic 166 binding of a trusted synchronization to a global timescale in the 167 Evidence itself allows for Evidence that can prove past operational 168 states of an Attester. To capture and support this concept, this 169 document introduces the term Forward Authenticity. 171 Forward Authenticity: A property of secure communication protocols, 172 in which later compromise of the long-term keys of a data origin 173 does not compromise past authentication of data from that origin. 174 FA is achieved by timely recording of assessments of the 175 authenticity from Target Environments (via "audit logs" during 176 "audit sessions") that are authorized for this purpose and 177 trustworthy (e.g via endorsed Roots of Trusts), in a time frame 178 much shorter than that expected for the compromise of the long- 179 term keys. 181 Forward Authenticity enables new levels of assurance and can be 182 included in basically every protocol, such as ssh, YANG Push, 183 router advertisements, link layer neighbor discovery, or even ICMP 184 echo requests. 186 1.2. Handle Distributor 188 A trusted binding of a global timescale with Evidence is enabled in 189 TUDA via a third party: the Handle Distributor. A Handle Distributor 190 can provide centrally generated nonces, signed timestamps, or other 191 handles used as qualifying data in Evidence generation. In TUDA, 192 both the Attester and the Verifier receive signed timestamps from the 193 Handle Distributor. These trusted timestamps replace nonces in 194 Evidence generation and Evidence appraisal as specified in the 195 remainder of this document. 197 1.3. Terminology 199 This document uses the terms defined in the RATS architecture 200 [I-D.ietf-rats-architecture] and RATS Reference Interaction Models 201 [I-D.birkholz-rats-reference-interaction-model]. 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in 206 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 207 capitals, as shown here. 209 2. Evidence in TUDA 211 Remote attestation Evidence is a set of trustworthiness claims 212 (assertions about the Target Environments of an Attester) that are 213 accompanied by a proof of their veracity - typically a signature 214 based on shielded, private and potentially restricted key material 215 (used as an Authentication Secret as specified in section 6 of 216 [I-D.birkholz-rats-reference-interaction-model]). As key material 217 alone is typically not self-descriptive with respect to its intended 218 use (its semantics), the Evidence created via TUDA is accompanied by 219 two kinds of certificates that are cryptographically associated with 220 a Trust Anchor (TA) [RFC4949] via a certification path: 222 o an Attestation Key (AK) Certificate (AK-Cert) that represents the 223 attestation provenance of the Attesting Environment (see section 224 4.2. in [I-D.ietf-rats-architecture]) that creates Evidence, and 226 o an Endorsement Key (EK) Certificate (EK-Cert) that represents the 227 protection characteristics of an Attesting Environment the AK is 228 stored in. 230 If a Verifier decides to trust the TA of both an AK-Cert and an EK- 231 Cert presented by an Attester - and thereby the included assertions 232 about the system characteristics describing the Attester's Target 233 Environments - the Evidence created via TUDA by the Attester is 234 considered trustable and believable. Ultimately, all trustable and 235 believable Evidence is appraised by a Verifier in order to assess the 236 trustworthiness of the corresponding Attester. 238 3. Generating Evidence about Software Component Integrity 240 The TUDA protocol family uses hash values of all started software 241 components as a basis to provide and create Evidence about the 242 integrity of the software components of an Attester's Target 243 Environments (see section 4.2. in [I-D.ietf-rats-architecture]). 244 This concept is implemented, for example, in the Linux kernel and is 245 called the Linux Integrity Measurement Architecture (IMA) [Safford]. 246 Open source solutions, for example, based on [RFC5209] use IMA to 247 enable remote attestation [Steffens]. This section defines the 248 processed data items, the requirements for system components, and 249 corresponding operations to enable the generation of Evidence about 250 software component integrity for TUDA. 252 3.1. Measurements and Digests Generated by an Attester 254 A hash value of a software component is created before it is executed 255 by Attesters. These hash values represent Claims that typically 256 occur in large quantities and are referred to as a measurements. The 257 Linux IMA feature is one way to generate these measurements on an 258 Attester. Measurements are chained by Attesters using a rolling hash 259 function. Each measurement added to the sequence of all measurements 260 results in a new current hash value. The most recent (i.e., up-to- 261 date) output of the rolling hash function that is chaining the 262 created measurements is referred to as a digest. 264 3.2. Attesting Environments and Roots of Trust 266 The primitive operations used to generate the initial set of 267 measurements at the beginning of an Attester's boot sequence MUST be 268 provided by a Root of Trust for Measurement (RTM) that is a system 269 component of the Attester. An RTM MUST be trusted via trust- 270 relationships to TAs enabled by appropriate Endorsements (e.g.,EK- 271 Certs). If a Verifier cannot trust an RTM, Evidence based on values 272 generated by the RTM is considered invalid. RTMs MUST be accessible 273 to the first Attesting Environment in Layered Attestation (see 274 section 4.3. in [I-D.ietf-rats-architecture]). A RTM MAY retain 275 measurements until the first RTS becomes available in a Layered 276 Attestation procedure. 278 The primitive operations used to store and chain measurements via a 279 rolling hash function MUST be provided by Roots of Trust for Storage 280 (RTS) that are system components of the Attester. An RTS MUST be 281 trusted via trust-relationships to TAs enabled by appropriate 282 Endorsements (e.g.,EK-Certs). If a Verifier cannot trust an RTS, 283 Evidence generated based on digest values acquired from the RTS is 284 considered invalid. RTS MUST be accessible to all Attesting 285 Environments that are chained in a Layered Attestation procedure. 287 The primitive operations used to generate Evidence based on digests 288 MUST be provided by Roots of Trust for Reporting (RTR) that are 289 system components of the Attester. An RTR MUST be be trusted via 290 trust-relationships to TAs enabled by appropriate Endorsements 291 (e.g.,EK-Certs). If a Verifier cannot trust an RTR, Evidence 292 generated by the RTR is considered invalid. All Attesting 293 Environments of an Attester MUST be RTRs. 295 A concise definition of the terms RTM, RTS, and RTR can be found in 296 the Trusted Computing Group (TCG) Glossary [TCGGLOSS]. An RTS and an 297 RTR are often tightly coupled. Analogously, a Trusted Platform 298 Module (TPM, see [TPM12] and [TPM2]) takes on the roles of an RTS and 299 an RTR. The specification in this document is based on the use of a 300 TPM. The protocol part of this specification can also be used with 301 other RTS and RTR as long as essential requirements are satisfied 302 (e.g. a trusted relative source of time, such as a tick-counter). A 303 sequence of Layered Attestation using at least an RTM, RTS, and RTR 304 enables an authenticated boot sequence typically referred to as 305 Secure Boot. 307 3.3. Primitive Operations for Remote Attestation 309 The primitive operation for processing measurements and adding them 310 to a chain of measurements via a rolling hash function is called 311 extend. Analogously, extend operations are provided by an RTS. 313 The primitive operation for retrieving the current available digest 314 value that is the result of the rolling hash function including a 315 signature based on an Attestation Key is called quote. Analogously, 316 quote operations are provided by an RTR. 318 TUDA requirements on (primitive) operations and the information 319 elements processed by them are illustrated using pseudo code in 320 Appendix C and D. 322 4. Remote Attestation Principles 324 In essence, the TUDA protocol family is composed of three operations 325 that are defined in [I-D.birkholz-rats-reference-interaction-model]. 326 These generic definitions align with the definitions presented in 327 [PRIRA] and [TCGGLOSS]. 329 Evidence Generation: The retrieval of signed digests from an RTR 330 based on a sequence of collected Claims about software component 331 integrity (measurements). 333 Evidence Conveyance: The transfer of Evidence from the Attester to 334 the Verifier via the Internet. 336 Evidence Appraisal: The validation of Evidence signatures as well as 337 the assessment of Claim values in Evidence by comparing them with 338 Reference Integrity Measurements (RIM). 340 4.1. Indeterministic Measurements 342 The sequence of measurements that is extended into the RTS may not be 343 deterministic (e.g., due to parallelization of or race conditions 344 between starting software components in user space). In order to 345 enable appraisal in these case, a corresponding event log that 346 records all measurements in sequence, such as the IMA log, has to be 347 conveyed next to the Evidence as depicted in section 8.2. in 348 [I-D.birkholz-rats-reference-interaction-model]. The Verifier has to 349 replay the event log using its own extend operation with an identical 350 rolling hash function in order to generate reference value as 351 outlined in section 2.4.1. of 352 [I-D.fedorkow-rats-network-device-attestation]. The validity of each 353 event log record must be appraised individually by the Verifier in 354 order to infer if each started software component satisfies integrity 355 requirements. This appraisal process requires Reference Integrity 356 Measurements as are provided via [I-D.birkholz-rats-coswid-rim] or 357 [TCGRIM]. Each RIM includes the information required to associate 358 hash values of software components included in an event log with 359 nominal reference hash values in the RIM. A Verifier requires an 360 appropriate set of RIMs to compare every record in an event log 361 successfully. The acquisition of RIMs and corresponding procedures 362 are out-of-scope of this document. 364 4.2. Principles of Uni-Directional and Time-Based Attestation 366 Traditional remote attestation protocols typically use bi-directional 367 challenge/response interaction models. Examples include the Platform 368 Trust Service protocol [PTS] or CAVES [PRIRA], where one entity sends 369 a challenge that is included inside the response to prove the 370 freshness of Evidence via recentness. The corresponding interaction 371 model depicted in section 8.1. of 372 [I-D.birkholz-rats-reference-interaction-model] tightly couples the 373 three operations of generating, conveying and appraising Evidence. 375 The Time-Based Uni-directional Attestation family of protocols can 376 decouple these three operations. As a result, TUDA provides 377 additional capabilities, such as: 379 o remote attestation for Attesters that might not always be able to 380 reach the Internet by enabling the appraisal of past states, 382 o secure audit logs by combining the Evidence generated with 383 integrity measurement logs (e.g. IMA logs) that represent a 384 detailed record of corresponding past states, 386 o the use of the uni-directional interaction model 387 [I-D.birkholz-rats-reference-interaction-model] that can traverse 388 "diode-like" network security functions (NSF) or can be leveraged 389 RESTful telemetry as enabled by the CoAP Observe option 390 [RFC7252]). 392 4.3. TUDA Attesting Environment Requirements 394 Evidence generation in TUDA requires certain features implemented by 395 theTarget Environment 397 TUDA is a family of protocols that bundles results from specific 398 attestation activities. The attestation activities of TUDA are based 399 on roots of trust that provide the following specific capabilities: 401 o Platform Configuration Registers (PCR) that can extend 402 measurements consecutively and represent the sequence of 403 measurements as a single digest, 405 o Restricted Signing Keys (RSK) that can only be accessed, if a 406 specific signature about a set of measurements can be provided as 407 authentication, and 409 o a dedicated source of (relative) time, e.g. a tick counter (a tick 410 being a specific time interval, for example 10 ms). 412 4.4. TUDA Handle Distributor: Time Stamp Authority 414 Both Evidence Generation and Evidence Appraisal of TUDA require a 415 Handle Distributor that can take on the role of a trusted Time Stamp 416 Authority (TSA) as an additional third party. This TUDA 417 specification uses a Time Stamp Authority based on [RFC3161]. The 418 combination of the local source of time provided by a RoT (located on 419 the Attester) and the Time Stamp Tokens provided by the Handle 420 Distributor (to both the Attester and the Verifier) enable an 421 appropriate assertion of freshness. 423 4.5. Information Elements and Conveyance 425 TUDA defines a set of information elements (IE) that are created and 426 stored on the Attester and are intended to be transferred to the 427 Verifier in order to enable the appraisal of Evidence. Each TUDA IE: 429 o is encoded in the Concise Binary Object Representation (CBOR 430 [RFC7049]) to minimize the volume of data in motion. In this 431 document, the composition of the CBOR data items that represent IE 432 is described using the Concise Data Definition Language, CDDL 433 [RFC8610] 435 o that requires a certain freshness is only created/updated when 436 out-dated, which reduces the overall resources required from the 437 Attester, including the use of RoTs. The IE that have to be 438 created are determined by their age or by specific state changes 439 on the Attester (e.g. state changes due to a reboot-cycle) 441 o is only transferred when required, which reduces the amount of 442 data in motion necessary to conduct remote attestation 443 significantly. Only IE that have changed since their last 444 conveyance have to be transferred 446 o that requires a certain freshness can be reused for multiple 447 remote attestation procedures in the limits of its corresponding 448 freshness-window, further reducing the load imposed on the 449 Attester and its corresponding RoT. 451 4.6. TUDA Objectives 453 The Time-Based Uni-directional Attestation family of protocols is 454 designed to: 456 o increase the confidence in authentication and authorization 457 procedures, 459 o address the requirements of constrained-node networks, 461 o support interaction models that do not maintain connection-state 462 over time, such as REST architectures [REST], 464 o be able to leverage existing management interfaces, such as SNMP 465 [RFC3411]. RESTCONF [RFC8040] or CoMI [I-D.ietf-core-comi] -- and 466 corresponding bindings, 468 o support broadcast and multicast schemes (e.g. [IEEE1609]), 470 o be able to cope with temporary loss of connectivity, and to 471 o provide trustworthy audit logs of past endpoint states. 473 4.7. Hardware Dependencies 475 The binding of the attestation scheme used by TUDA to generate the 476 TUDA IE is specific to the methods provided by the RoT used (see 477 above). In this document, expositional text and pseudo-code that is 478 based on TPM 1.2 and TPM 2.0 operations. The corresponding TPM 479 commands are specified in [TPM12] and [TPM2]. The references to TPM 480 commands and corresponding pseudo-code only serve as guidance to 481 enable a better understanding of the attestation scheme and is 482 intended to encourage the use of any appropriate RoT, for example, an 483 equivalent set of functions available to an embedded Secure Element 484 or Trusted Execution Environment [TEE]. 486 5. TUDA Core Concept 488 There are significant differences between conventional bi-directional 489 attestation and TUDA regarding both the information elements conveyed 490 between Attester and Verifier and the time-frame, in which an 491 attestation can be considered to be fresh (and therefore 492 trustworthy). 494 In general, remote attestation using a bi-directional communication 495 scheme includes sending a nonce-challenge within a signed Evidence 496 token. Using the TPM 1.2 as an example, a corresponding nonce- 497 challenge would be included within the signature created by the 498 TPM_Quote command in order to prove the freshness of a response 499 containing evidence, see e.g. [PTS]. 501 In contrast, the TUDA protocol uses the combined output of 502 TPM_CertifyInfo and TPM_TickStampBlob. The former provides a proof 503 about the Attester's state by creating Evidence that a certain key is 504 bound to that state. The latter provides proof that the Attester was 505 in the specified state by using the bound key in a time operation. 506 This combination enables a time-based attestation scheme. The 507 approach is based on the concepts introduced in [SCALE] and 508 [SFKE2008]. 510 Each TUDA IE has an individual time-frame, in which it is considered 511 to be fresh (and therefore valid and trustworthy). In consequence, 512 each TUDA IE that composes data in motion is based on different 513 methods of creation. 515 As highlighted above, the freshness properties of a challenge- 516 response based protocol enable implicit time-keeping via a time 517 window between: 519 o the time of transmission of the nonce, and 521 o the reception of the corresponding response. 523 Given the time-based attestation scheme, the freshness property of 524 TUDA is equivalent to that of bi-directional challenge response 525 attestation, if the point-in-time of attestation lies between: 527 o the transmission of a TUDA time-synchronization token, and 529 o the typical round-trip time between the Verifier and the Attester. 531 The accuracy of this time-frame is defined by two factors: 533 o the time-synchronization between the Attester and the Handle 534 Distributor. The time between the two tickstamps acquired via the 535 RoT define the scope of the maximum drift (time "left" and time 536 "right" in respect to the timeline) to the handle including the 537 signed timestamp, and 539 o the drift of clocks included in the RoT. 541 Since the conveyance of TUDA Evidence does not rely upon a Verifier 542 provided value (i.e. the nonce), the security guarantees of the 543 protocol only incorporate the Handle Distributor and the RoT used. 544 In consequence, TUDA Evidence can even serve as proof of integrity in 545 audit logs with precise point-in-time guarantees. 547 Appendix A contains guidance on how to utilize a REST architecture. 549 Appendix B contains guidance on how to create an SNMP binding and a 550 corresponding TUDA-MIB. 552 Appendix C contains a corresponding YANG module that supports both 553 RESTCONF and CoREDONF. 555 Appendix D.2 contains a realization of TUDA using TPM 1.2 primitives. 557 Appendix D.3 contains a realization of TUDA using TPM 2.0 primitives. 559 5.1. TPM Specific Terms 561 PCR: A Platform Configuration Register that is part of the TPM and 562 is used to securely store and report measurements about security 563 posture 565 PCR-Hash: A hash value of the security posture measurements stored 566 in a TPM PCR (e.g. regarding running software instances) 567 represented as a byte-string 569 5.2. Certificates 571 HD-CA: The Certificate Authority that provides the certificate for 572 the TSA role of a Handle Distributor (HD) 574 AIK-CA: The Certificate Authority that provides the certificate for 575 the AK of the TPM. This is the client platform credential for 576 this protocol. It is a placeholder for a specific CA and AK-Cert 577 is a placeholder for the corresponding certificate, depending on 578 what protocol was used. The specific protocols are out of scope 579 for this document, see also [AIK-Enrollment] and [IEEE802.1AR]. 581 6. The TUDA Protocol Family 583 Time-Based Uni-Directional Attestation consists of the following 584 seven information elements: 586 Handle Distributor Certificate: The certificate of the Handle 587 Distributor that takes on the role of TSA. The Handle Distributor 588 certificate is used in a subsequent synchronization protocol 589 tokens. This certificate is signed by the HD-CA. 591 AK Certificate: A certificate about the Attestation Key (AIK) used. 592 An AK-Cert may be an [IEEE802.1AR] IDevID or LDevID, depending on 593 their setting of the corresponding identity property 594 ([AIK-Credential], [AIK-Enrollment]; see Appendix D.2.1). 596 Synchronization Token: The reference frame for Evidence is provided 597 by the relative timestanps generated by the TPM. In order to put 598 Evidence into relation with a Real Time Clock (RTC), it is 599 necessary to provide a cryptographic synchronization between these 600 trusted relative timestamps and the regular RTC that is a hardware 601 component of the Attester. To do so, trustable timesamps are 602 acquired from a Handle Distributor. 604 Restriction Info: Evidence Generation relies on the capability of 605 the Rot to operate on restricted keys. Whenever the PCR values of 606 an Attesting Environment change, a new restricted key is created 607 that can only be operated as long as the PCRs remain in their 608 current state. 610 In order to prove to the Verifier that this restricted temporary 611 key actually has these properties and also to provide the PCR 612 value that it is restricted, the corresponding signing 613 capabilities of the RoT are used. The TPM creates a signed 614 certificate using the AK about the newly created restricted key. 616 Measurement Log: A Verifier requires the means to derive the PCRs' 617 values in order to appraise the trustworthiness of an Attester. 618 As such, a list of those elements that were extended into the PCRs 619 is reported. For certain environments, this step may be optional 620 if a list of valid PCR configurations (in the form of RIM 621 available to the Verifier) exists and no measurement log is 622 required. 624 Implicit Evidence: The actual Evidence is then based on a signed 625 timestamp provided by the RoT using the restricted temporary key 626 that was certified in the steps above. The signed timestamp 627 generated provides the trustable assertion that at this point in 628 time (with respect to the relative time of the TPM s tick counter) 629 a certain configuration existed (namely the PCR values associated 630 with the restricted key). In combination with the synchronization 631 token this timestamp represented in relative time can then be 632 related to the real-time clock. 634 Concise SWID tags: As an option to better assess the trustworthiness 635 of an Attester, a Verifier can request the reference hashes (RIM, 636 sometimes called golden measurements, known-good-values, or 637 nominal values) of all started software components to compare them 638 with the entries in a measurement log. References hashes 639 regarding installed (and therefore running) software can be 640 provided by the manufacturer via SWID tags. SWID tags are 641 provided by the Attester using the Concise SWID representation 642 [I-D.ietf-sacm-coswid] and bundled into a collection (a RIM 643 Manifest [I-D.birkholz-rats-coswid-rim]). 645 These information elements can be sent en bloc, but it is recommended 646 to retrieve them separately to save bandwidth, since these elements 647 have different update cycles. In most cases, retransmitting all 648 seven information elements would result in unnecessary redundancy. 650 Furthermore, in some scenarios it might be feasible not to store all 651 elements on the Attester, but instead they could be retrieved from 652 another location or be pre-deployed to the Verifier. It is also 653 feasible to only store public keys on the Verifier and skip 654 certificate provisioning completely in order to save bandwidth and 655 computation time for certificate verification. 657 6.1. TUDA Information Elements Update Cycles 659 An Attester can be in various states during its uptime cycles. For 660 TUDA, a subset of these states (which imply associated information) 661 are important to the Evidence Generation. The specific states 662 defined are: 664 o persistent, even after a hard reboot: includes certificates that 665 are associated with the endpoint itself or with services it relies 666 on. 668 o volatile to a degree: may change at the beginning of each boot 669 cycle. This includes the capability of a TPM to provide relative 670 time which provides the basis for the synchronization token and 671 implicit attestation - and which can reset after an Attester is 672 powered off. 674 o very volatile: can change during any time of an uptime cycle 675 (periods of time an Attester is powered on, starting with its boot 676 sequence). This includes the content of PCRs of a hardware RoT 677 and thereby also the PCR-restricted signing keys used for 678 attestation. 680 Depending on this "lifetime of state", data has to be transported 681 over the wire, or not. E.g. information that does not change due to 682 a reboot typically has to be transported only once between the 683 Attester and the Verifier. 685 There are three kinds of events that require fresh Evidence to be 686 generated: 688 o The Attester completes a boot-cycle 690 o A relevant PCR changes 692 o Too much time has passed since the Evidence Generation 694 The third event listed above is variable per application use case and 695 also depends on the precision of the clock included in the RoT. For 696 usage scenarios, in which the Attester would periodically push 697 information to be used in an audit-log, a time-frame of approximately 698 one update per minute should be sufficient. For those usage 699 scenarios, where Verifiers request (pull) fresh Evidence, an 700 implementation could potentially use a TPM continuously to always 701 present the most freshly created Evidence. This kind of utilization 702 can result in a bottle-neck with respect to other purposes: if 703 unavoidable, a periodic interval of once per ten seconds is 704 recommended, which typically leaves about 80% of available TPM 705 resource for other applications. 707 The following diagram is based on the reference interaction model 708 found in section 8.1. of 709 [I-D.birkholz-rats-reference-interaction-model] and is enriched with 710 the IE update cycles defined in this section. 712 .----------. .----------. 713 | Attester | | Verifier | 714 '----------' '----------' 715 | | 716 boot | 717 | | 718 valueGeneration(targetEnvironment) | 719 | => claims | 720 | .--------------------. | 721 | <----------handle | | | 722 | | Handle Distributor | | 723 | | | handle----------> | 724 | '--------------------' | 725 syncTokenGeneration | 726 | => syncToken | 727 | | 728 restrictedKeyGeneration | 729 restrictedKeyCertify | 730 | | 731 evidenceGeneration(handle, authSecIDs, collectedClaims) | 732 | => evidence | 733 | | 734 | pushAKCert ----------------------------------------------> | 735 | pushSyncToken -------------------------------------------> | 736 | pushCertifyInfo -----------------------------------------> | 737 | pushEventLog --------------------------------------------> | 738 | pushEvidenceon ------------------------------------------> | 739 | | 740 | evidenceAppraisal(evidence, eventLog, refClaims) 741 | attestationResult <= | 742 ~ ~ 743 pcr-change | 744 | | 745 restrictedKeyGeneration | 746 restrictedKeyCertify | 747 | | 748 evidenceGeneration(handle, authSecIDs, collectedClaims) | 749 | => evidence | 750 | | 751 | pushCertifyInfo -----------------------------------------> | 752 | pushEventLog --------------------------------------------> | 753 | pushEvidenceon ------------------------------------------> | 754 | | 755 | evidenceAppraisal(evidence, eventLog, refClaims) 756 | attestationResult <= | 757 | | 759 Figure 1: Example sequence of events 761 7. Sync Base Protocol 763 The uni-directional approach of TUDA requires evidence on how the TPM 764 time represented in ticks (relative time since boot of the TPM) 765 relates to the standard time provided by the TSA. The Sync Base 766 Protocol (SBP) creates evidence that binds the TPM tick time to the 767 TSA timestamp. The binding information is used by and conveyed via 768 the Sync Token (TUDA IE). There are three actions required to create 769 the content of a Sync Token: 771 o At a given point in time (called "left"), a signed tickstamp 772 counter value is acquired from the hardware RoT. The hash of 773 counter and signature is used as a nonce in the request directed 774 at the TSA. 776 o The corresponding response includes a data-structure incorporating 777 the trusted timestamp token and its signature created by the TSA. 779 o At the point-in-time the response arrives (called "right"), a 780 signed tickstamp counter value is acquired from the hardware RoT 781 again, using a hash of the signed TSA timestamp as a nonce. 783 The three time-related values -- the relative timestamps provided by 784 the hardware RoT ("left" and "right") and the TSA timestamp -- and 785 their corresponding signatures are aggregated in order to create a 786 corresponding Sync Token to be used as a TUDA Information Element 787 that can be conveyed as evidence to a Verifier. 789 The drift of a clock incorporated in the hardware RoT that drives the 790 increments of the tick counter constitutes one of the triggers that 791 can initiate a TUDA Information Element Update Cycle in respect to 792 the freshness of the available Sync Token. 794 8. IANA Considerations 796 This memo includes requests to IANA, including registrations for 797 media type definitions. 799 TBD 801 9. Security Considerations 803 There are Security Considerations. TBD 805 10. Contributors 807 TBD 809 11. References 811 11.1. Normative References 813 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 814 Requirement Levels", BCP 14, RFC 2119, 815 DOI 10.17487/RFC2119, March 1997, 816 . 818 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 819 "Internet X.509 Public Key Infrastructure Time-Stamp 820 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 821 2001, . 823 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 824 Architecture for Describing Simple Network Management 825 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 826 DOI 10.17487/RFC3411, December 2002, 827 . 829 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 830 Tardo, "Network Endpoint Assessment (NEA): Overview and 831 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 832 . 834 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 835 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 836 . 838 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 839 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 840 October 2013, . 842 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 843 Protocol (HTTP/1.1): Message Syntax and Routing", 844 RFC 7230, DOI 10.17487/RFC7230, June 2014, 845 . 847 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 848 Application Protocol (CoAP)", RFC 7252, 849 DOI 10.17487/RFC7252, June 2014, 850 . 852 [RFC7320] Nottingham, M., "URI Design and Ownership", RFC 7320, 853 DOI 10.17487/RFC7320, July 2014, 854 . 856 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 857 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 858 . 860 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 861 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 862 DOI 10.17487/RFC7540, May 2015, 863 . 865 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 866 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 867 . 869 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 870 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 871 May 2017, . 873 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 874 Definition Language (CDDL): A Notational Convention to 875 Express Concise Binary Object Representation (CBOR) and 876 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 877 June 2019, . 879 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 880 E., and A. Tripathy, "Subscription to YANG Notifications", 881 RFC 8639, DOI 10.17487/RFC8639, September 2019, 882 . 884 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 885 E., and A. Tripathy, "Dynamic Subscription to YANG Events 886 and Datastores over NETCONF", RFC 8640, 887 DOI 10.17487/RFC8640, September 2019, 888 . 890 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 891 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 892 September 2019, . 894 11.2. Informative References 896 [AIK-Credential] 897 TCG Infrastructure Working Group, "TCG Credential 898 Profile", 2007, . 901 [AIK-Enrollment] 902 TCG Infrastructure Working Group, "A CMC Profile for AIK 903 Certificate Enrollment", 2011, 904 . 907 [I-D.birkholz-rats-coswid-rim] 908 Birkholz, H., Uiterwijk, P., Fitzgerald-McKay, J., and D. 909 Waltermire, "Reference Integrity Measurement Extension for 910 Concise Software Identities", draft-birkholz-rats-coswid- 911 rim-00 (work in progress), March 2020. 913 [I-D.birkholz-rats-reference-interaction-model] 914 Birkholz, H., Eckel, M., Newton, C., and L. Chen, 915 "Reference Interaction Models for Remote Attestation 916 Procedures", draft-birkholz-rats-reference-interaction- 917 model-03 (work in progress), July 2020. 919 [I-D.fedorkow-rats-network-device-attestation] 920 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 921 based Network Device Remote Integrity Verification", 922 draft-fedorkow-rats-network-device-attestation-05 (work in 923 progress), April 2020. 925 [I-D.ietf-core-comi] 926 Veillette, M., Stok, P., Pelov, A., Bierman, A., and I. 927 Petrov, "CoAP Management Interface (CORECONF)", draft- 928 ietf-core-comi-10 (work in progress), July 2020. 930 [I-D.ietf-rats-architecture] 931 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 932 W. Pan, "Remote Attestation Procedures Architecture", 933 draft-ietf-rats-architecture-05 (work in progress), July 934 2020. 936 [I-D.ietf-sacm-coswid] 937 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 938 Waltermire, "Concise Software Identification Tags", draft- 939 ietf-sacm-coswid-15 (work in progress), May 2020. 941 [I-D.ietf-sacm-terminology] 942 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 943 A. Montville, "Security Automation and Continuous 944 Monitoring (SACM) Terminology", draft-ietf-sacm- 945 terminology-16 (work in progress), December 2018. 947 [IEEE1609] 948 IEEE Computer Society, "1609.4-2016 - IEEE Standard for 949 Wireless Access in Vehicular Environments (WAVE) -- Multi- 950 Channel Operation", IEEE Std 1609.4, 2016. 952 [IEEE802.11P] 953 IEEE Computer Society, "802.11P-2010 - IEEE Standard for 954 Information technology-- Local and metropolitan area 955 networks-- Specific requirements-- Part 11: Wireless LAN 956 Medium Access Control (MAC) and Physical Layer (PHY) 957 Specifications Amendment 6: Wireless Access in Vehicular 958 Environments", IEEE Std 802.11P, 2010. 960 [IEEE802.1AR] 961 IEEE Computer Society, "802.1AR-2009 - IEEE Standard for 962 Local and metropolitan area networks - Secure Device 963 Identity", IEEE Std 802.1AR, 2009. 965 [PRIRA] Coker, G., Guttman, J., Loscocco, P., Herzog, A., Millen, 966 J., O'Hanlon, B., Ramsdell, J., Segall, A., Sheehy, J., 967 and B. Sniffen, "Principles of Remote Attestation", 968 Springer International Journal of Information Security, 969 Vol. 10, pp. 63-81, DOI 10.1007/s10207-011-0124-7, April 970 2011. 972 [PTS] TCG TNC Working Group, "TCG Attestation PTS Protocol 973 Binding to TNC IF-M", 2011, 974 . 977 [REST] Fielding, R., "Architectural Styles and the Design of 978 Network-based Software Architectures", Ph.D. Dissertation, 979 University of California, Irvine, 2000, 980 . 983 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 984 for Network Management of TCP/IP-based internets: MIB-II", 985 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 986 . 988 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", 989 RFC 2790, DOI 10.17487/RFC2790, March 2000, 990 . 992 [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for 993 the Simple Network Management Protocol (SNMP)", STD 62, 994 RFC 3418, DOI 10.17487/RFC3418, December 2002, 995 . 997 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 998 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 999 . 1001 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1002 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1003 DOI 10.17487/RFC6933, May 2013, 1004 . 1006 [Safford] Safford, D., Zohar, M., and R. Sailer, "Using IMA for 1007 Integrity Measurement and Attestation", Linux Plumbers 1008 Conference 2009 , 2009. 1010 [SCALE] Fuchs, A., "Improving Scalability for Remote Attestation", 1011 Master Thesis (Diplomarbeit), Technische Universitaet 1012 Darmstadt, Germany, 2008. 1014 [SFKE2008] 1015 Stumpf, F., Fuchs, A., Katzenbeisser, S., and C. Eckert, 1016 "Improving the scalability of platform attestation", 1017 ACM Proceedings of the 3rd ACM workshop on Scalable 1018 trusted computing - STC '08 , page 1-10, 1019 DOI 10.1145/1456455.1456457, 2008. 1021 [STD62] "Internet Standard 62", STD 62, RFCs 3411 to 3418, 1022 December 2002. 1024 [Steffens] 1025 Steffen, A., "The linux Integrity Measurement Architecture 1026 and TPM-based Network Endpoint Assessment", Linux Security 1027 Summit , 2012. 1029 [TCGGLOSS] 1030 TCG, "TCG Glossary", 2012, 1031 . 1034 [TCGRIM] TCG, "TCG Reference Integrity Manifest (RIM) Information 1035 Model", 2019, . 1038 [TEE] Global Platform, "TEE System Architecture v1.1, 1039 GPD_SPE_009", 2017. 1041 [TPM12] "Information technology -- Trusted Platform Module -- Part 1042 1: Overview", ISO/IEC 11889-1, 2009. 1044 [TPM2] "Trusted Platform Module Library Specification, Family 1045 2.0, Level 00, Revision 01.16 ed., Trusted Computing 1046 Group", 2014. 1048 Appendix A. REST Realization 1050 Each of the seven data items is defined as a media type (Section 8). 1051 Representations of resources for each of these media types can be 1052 retrieved from URIs that are defined by the respective servers 1053 [RFC7320]. As can be derived from the URI, the actual retrieval is 1054 via one of the HTTPs ([RFC7230], [RFC7540]) or CoAP [RFC7252]. How a 1055 client obtains these URIs is dependent on the application; e.g., CoRE 1056 Web links [RFC6690] can be used to obtain the relevant URIs from the 1057 self-description of a server, or they could be prescribed by a 1058 RESTCONF data model [RFC8040]. 1060 Appendix B. SNMP Realization 1062 SNMPv3 [STD62] [RFC3411] is widely available on computers and also 1063 constrained devices. To transport the TUDA information elements, an 1064 SNMP MIB is defined below which encodes each of the seven TUDA 1065 information elements into a table. Each row in a table contains a 1066 single read-only columnar SNMP object of datatype OCTET-STRING. The 1067 values of a set of rows in each table can be concatenated to 1068 reconstitute a CBOR-encoded TUDA information element. The Verifier 1069 can retrieve the values for each CBOR fragment by using SNMP GetNext 1070 requests to "walk" each table and can decode each of the CBOR-encoded 1071 data items based on the corresponding CDDL [RFC8610] definition. 1073 Design Principles: 1075 1. Over time, TUDA attestation values age and should no longer be 1076 used. Every table in the TUDA MIB has a primary index with the 1077 value of a separate scalar cycle counter object that 1078 disambiguates the transition from one attestation cycle to the 1079 next. 1081 2. Over time, the measurement log information (for example) may grow 1082 large. Therefore, read-only cycle counter scalar objects in all 1083 TUDA MIB object groups facilitate more efficient access with SNMP 1084 GetNext requests. 1086 3. Notifications are supported by an SNMP trap definition with all 1087 of the cycle counters as bindings, to alert a Verifier that a new 1088 attestation cycle has occurred (e.g., synchronization data, 1089 measurement log, etc. have been updated by adding new rows and 1090 possibly deleting old rows). 1092 B.1. Structure of TUDA MIB 1094 The following table summarizes the object groups, tables and their 1095 indexes, and conformance requirements for the TUDA MIB: 1097 |-------------|-------|----------|----------|----------| 1098 | Group/Table | Cycle | Instance | Fragment | Required | 1099 |-------------|-------|----------|----------|----------| 1100 | General | | | | x | 1101 | AIKCert | x | x | x | | 1102 | TSACert | x | x | x | | 1103 | SyncToken | x | | x | x | 1104 | Restrict | x | | | x | 1105 | Measure | x | x | | | 1106 | VerifyToken | x | | | x | 1107 | SWIDTag | x | x | x | | 1108 |-------------|-------|----------|----------|----------| 1110 B.1.1. Cycle Index 1112 A tudaV1CycleIndex is the: 1114 1. first index of a row (element instance or element fragment) in 1115 the tudaV1Table; 1117 2. identifier of an update cycle on the table, when rows were added 1118 and/or deleted from the table (bounded by tudaV1Cycles); 1119 and 1121 3. binding in the tudaV1TrapV2Cycles notification for directed 1122 polling. 1124 B.1.2. Instance Index 1126 A tudaV1InstanceIndex is the: 1128 1. second index of a row (element instance or element fragment) in 1129 the tudaV1Table; except for 1131 2. a row in the tudaV1SyncTokenTable (that has only one instance per 1132 cycle). 1134 B.1.3. Fragment Index 1136 A tudaV1FragmentIndex is the: 1138 1. last index of a row (always an element fragment) in the 1139 tudaV1Table; and 1141 2. accomodation for SNMP transport mapping restrictions for large 1142 string elements that require fragmentation. 1144 B.2. Relationship to Host Resources MIB 1146 The General group in the TUDA MIB is analogous to the System group in 1147 the Host Resources MIB [RFC2790] and provides context information for 1148 the TUDA attestation process. 1150 The Verify Token group in the TUDA MIB is analogous to the Device 1151 group in the Host MIB and represents the verifiable state of a TPM 1152 device and its associated system. 1154 The SWID Tag group (containing a Concise SWID reference hash profile 1155 [I-D.ietf-sacm-coswid]) in the TUDA MIB is analogous to the Software 1156 Installed and Software Running groups in the Host Resources MIB 1157 [RFC2790]. 1159 B.3. Relationship to Entity MIB 1161 The General group in the TUDA MIB is analogous to the Entity General 1162 group in the Entity MIB v4 [RFC6933] and provides context information 1163 for the TUDA attestation process. 1165 The SWID Tag group in the TUDA MIB is analogous to the Entity Logical 1166 group in the Entity MIB v4 [RFC6933]. 1168 B.4. Relationship to Other MIBs 1170 The General group in the TUDA MIB is analogous to the System group in 1171 MIB-II [RFC1213] and the System group in the SNMPv2 MIB [RFC3418] and 1172 provides context information for the TUDA attestation process. 1174 B.5. Definition of TUDA MIB 1176 1177 TUDA-V1-ATTESTATION-MIB DEFINITIONS ::= BEGIN 1179 IMPORTS 1180 MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, 1181 enterprises, NOTIFICATION-TYPE 1182 FROM SNMPv2-SMI -- RFC 2578 1183 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 1184 FROM SNMPv2-CONF -- RFC 2580 1185 SnmpAdminString 1186 FROM SNMP-FRAMEWORK-MIB; -- RFC 3411 1188 tudaV1MIB MODULE-IDENTITY 1189 LAST-UPDATED "202007130000Z" -- 13 July 2020 1190 ORGANIZATION 1191 "Fraunhofer SIT" 1192 CONTACT-INFO 1193 "Andreas Fuchs 1194 Fraunhofer Institute for Secure Information Technology 1195 Email: andreas.fuchs@sit.fraunhofer.de 1197 Henk Birkholz 1198 Fraunhofer Institute for Secure Information Technology 1199 Email: henk.birkholz@sit.fraunhofer.de 1201 Ira E McDonald 1202 High North Inc 1203 Email: blueroofmusic@gmail.com 1205 Carsten Bormann 1206 Universitaet Bremen TZI 1207 Email: cabo@tzi.org" 1209 DESCRIPTION 1210 "The MIB module for monitoring of time-based unidirectional 1211 attestation information from a network endpoint system, 1212 based on the Trusted Computing Group TPM 1.2 definition. 1214 Copyright (C) High North Inc (2020)." 1216 REVISION "202007130000Z" -- 13 July 2020 1217 DESCRIPTION 1218 "Eleventh version, published as draft-birkholz-rats-tuda-03." 1220 REVISION "202003090000Z" -- 09 March 2020 1221 DESCRIPTION 1222 "Tenth version, published as draft-birkholz-rats-tuda-02." 1224 REVISION "201909110000Z" -- 11 September 2019 1225 DESCRIPTION 1226 "Ninth version, published as draft-birkholz-rats-tuda-01." 1228 REVISION "201903120000Z" -- 12 March 2019 1229 DESCRIPTION 1230 "Eighth version, published as draft-birkholz-rats-tuda-00." 1232 REVISION "201805030000Z" -- 03 May 2018 1233 DESCRIPTION 1234 "Seventh version, published as draft-birkholz-i2nsf-tuda-03." 1236 REVISION "201805020000Z" -- 02 May 2018 1237 DESCRIPTION 1238 "Sixth version, published as draft-birkholz-i2nsf-tuda-02." 1240 REVISION "201710300000Z" -- 30 October 2017 1241 DESCRIPTION 1242 "Fifth version, published as draft-birkholz-i2nsf-tuda-01." 1244 REVISION "201701090000Z" -- 09 January 2017 1245 DESCRIPTION 1246 "Fourth version, published as draft-birkholz-i2nsf-tuda-00." 1248 REVISION "201607080000Z" -- 08 July 2016 1249 DESCRIPTION 1250 "Third version, published as draft-birkholz-tuda-02." 1252 REVISION "201603210000Z" -- 21 March 2016 1253 DESCRIPTION 1254 "Second version, published as draft-birkholz-tuda-01." 1256 REVISION "201510180000Z" -- 18 October 2015 1257 DESCRIPTION 1258 "Initial version, published as draft-birkholz-tuda-00." 1260 ::= { enterprises fraunhofersit(21616) mibs(1) tudaV1MIB(1) } 1262 tudaV1MIBNotifications OBJECT IDENTIFIER ::= { tudaV1MIB 0 } 1263 tudaV1MIBObjects OBJECT IDENTIFIER ::= { tudaV1MIB 1 } 1264 tudaV1MIBConformance OBJECT IDENTIFIER ::= { tudaV1MIB 2 } 1266 -- 1267 -- General 1268 -- 1269 tudaV1General OBJECT IDENTIFIER ::= { tudaV1MIBObjects 1 } 1271 tudaV1GeneralCycles OBJECT-TYPE 1272 SYNTAX Counter32 1273 MAX-ACCESS read-only 1274 STATUS current 1275 DESCRIPTION 1276 "Count of TUDA update cycles that have occurred, i.e., 1277 sum of all the individual group cycle counters. 1279 DEFVAL intentionally omitted - counter object." 1280 ::= { tudaV1General 1 } 1282 tudaV1GeneralVersionInfo OBJECT-TYPE 1283 SYNTAX SnmpAdminString (SIZE(0..255)) 1284 MAX-ACCESS read-only 1285 STATUS current 1286 DESCRIPTION 1287 "Version information for TUDA MIB, e.g., specific release 1288 version of TPM 1.2 base specification and release version 1289 of TPM 1.2 errata specification and manufacturer and model 1290 TPM module itself." 1291 DEFVAL { "" } 1292 ::= { tudaV1General 2 } 1294 -- 1295 -- AIK Cert 1296 -- 1297 tudaV1AIKCert OBJECT IDENTIFIER ::= { tudaV1MIBObjects 2 } 1299 tudaV1AIKCertCycles OBJECT-TYPE 1300 SYNTAX Counter32 1301 MAX-ACCESS read-only 1302 STATUS current 1303 DESCRIPTION 1304 "Count of AIK Certificate chain update cycles that have 1305 occurred. 1307 DEFVAL intentionally omitted - counter object." 1308 ::= { tudaV1AIKCert 1 } 1310 tudaV1AIKCertTable OBJECT-TYPE 1311 SYNTAX SEQUENCE OF TudaV1AIKCertEntry 1312 MAX-ACCESS not-accessible 1313 STATUS current 1314 DESCRIPTION 1315 "A table of fragments of AIK Certificate data." 1316 ::= { tudaV1AIKCert 2 } 1318 tudaV1AIKCertEntry OBJECT-TYPE 1319 SYNTAX TudaV1AIKCertEntry 1320 MAX-ACCESS not-accessible 1321 STATUS current 1322 DESCRIPTION 1323 "An entry for one fragment of AIK Certificate data." 1324 INDEX { tudaV1AIKCertCycleIndex, 1325 tudaV1AIKCertInstanceIndex, 1326 tudaV1AIKCertFragmentIndex } 1328 ::= { tudaV1AIKCertTable 1 } 1330 TudaV1AIKCertEntry ::= 1331 SEQUENCE { 1332 tudaV1AIKCertCycleIndex Integer32, 1333 tudaV1AIKCertInstanceIndex Integer32, 1334 tudaV1AIKCertFragmentIndex Integer32, 1335 tudaV1AIKCertData OCTET STRING 1336 } 1338 tudaV1AIKCertCycleIndex OBJECT-TYPE 1339 SYNTAX Integer32 (1..2147483647) 1340 MAX-ACCESS not-accessible 1341 STATUS current 1342 DESCRIPTION 1343 "High-order index of this AIK Certificate fragment. 1344 Index of an AIK Certificate chain update cycle that has 1345 occurred (bounded by the value of tudaV1AIKCertCycles). 1347 DEFVAL intentionally omitted - index object." 1348 ::= { tudaV1AIKCertEntry 1 } 1350 tudaV1AIKCertInstanceIndex OBJECT-TYPE 1351 SYNTAX Integer32 (1..2147483647) 1352 MAX-ACCESS not-accessible 1353 STATUS current 1354 DESCRIPTION 1355 "Middle index of this AIK Certificate fragment. 1356 Ordinal of this AIK Certificate in this chain, where the AIK 1357 Certificate itself has an ordinal of '1' and higher ordinals 1358 go *up* the certificate chain to the Root CA. 1360 DEFVAL intentionally omitted - index object." 1361 ::= { tudaV1AIKCertEntry 2 } 1363 tudaV1AIKCertFragmentIndex OBJECT-TYPE 1364 SYNTAX Integer32 (1..2147483647) 1365 MAX-ACCESS not-accessible 1366 STATUS current 1367 DESCRIPTION 1368 "Low-order index of this AIK Certificate fragment. 1370 DEFVAL intentionally omitted - index object." 1371 ::= { tudaV1AIKCertEntry 3 } 1373 tudaV1AIKCertData OBJECT-TYPE 1374 SYNTAX OCTET STRING (SIZE(0..1024)) 1375 MAX-ACCESS read-only 1376 STATUS current 1377 DESCRIPTION 1378 "A fragment of CBOR encoded AIK Certificate data." 1379 DEFVAL { "" } 1380 ::= { tudaV1AIKCertEntry 4 } 1382 -- 1383 -- TSA Cert 1384 -- 1385 tudaV1TSACert OBJECT IDENTIFIER ::= { tudaV1MIBObjects 3 } 1387 tudaV1TSACertCycles OBJECT-TYPE 1388 SYNTAX Counter32 1389 MAX-ACCESS read-only 1390 STATUS current 1391 DESCRIPTION 1392 "Count of TSA Certificate chain update cycles that have 1393 occurred. 1395 DEFVAL intentionally omitted - counter object." 1396 ::= { tudaV1TSACert 1 } 1398 tudaV1TSACertTable OBJECT-TYPE 1399 SYNTAX SEQUENCE OF TudaV1TSACertEntry 1400 MAX-ACCESS not-accessible 1401 STATUS current 1402 DESCRIPTION 1403 "A table of fragments of TSA Certificate data." 1404 ::= { tudaV1TSACert 2 } 1406 tudaV1TSACertEntry OBJECT-TYPE 1407 SYNTAX TudaV1TSACertEntry 1408 MAX-ACCESS not-accessible 1409 STATUS current 1410 DESCRIPTION 1411 "An entry for one fragment of TSA Certificate data." 1412 INDEX { tudaV1TSACertCycleIndex, 1413 tudaV1TSACertInstanceIndex, 1414 tudaV1TSACertFragmentIndex } 1415 ::= { tudaV1TSACertTable 1 } 1417 TudaV1TSACertEntry ::= 1418 SEQUENCE { 1419 tudaV1TSACertCycleIndex Integer32, 1420 tudaV1TSACertInstanceIndex Integer32, 1421 tudaV1TSACertFragmentIndex Integer32, 1422 tudaV1TSACertData OCTET STRING 1423 } 1425 tudaV1TSACertCycleIndex OBJECT-TYPE 1426 SYNTAX Integer32 (1..2147483647) 1427 MAX-ACCESS not-accessible 1428 STATUS current 1429 DESCRIPTION 1430 "High-order index of this TSA Certificate fragment. 1431 Index of a TSA Certificate chain update cycle that has 1432 occurred (bounded by the value of tudaV1TSACertCycles). 1434 DEFVAL intentionally omitted - index object." 1435 ::= { tudaV1TSACertEntry 1 } 1437 tudaV1TSACertInstanceIndex OBJECT-TYPE 1438 SYNTAX Integer32 (1..2147483647) 1439 MAX-ACCESS not-accessible 1440 STATUS current 1441 DESCRIPTION 1442 "Middle index of this TSA Certificate fragment. 1443 Ordinal of this TSA Certificate in this chain, where the TSA 1444 Certificate itself has an ordinal of '1' and higher ordinals 1445 go *up* the certificate chain to the Root CA. 1447 DEFVAL intentionally omitted - index object." 1448 ::= { tudaV1TSACertEntry 2 } 1450 tudaV1TSACertFragmentIndex OBJECT-TYPE 1451 SYNTAX Integer32 (1..2147483647) 1452 MAX-ACCESS not-accessible 1453 STATUS current 1454 DESCRIPTION 1455 "Low-order index of this TSA Certificate fragment. 1457 DEFVAL intentionally omitted - index object." 1458 ::= { tudaV1TSACertEntry 3 } 1460 tudaV1TSACertData OBJECT-TYPE 1461 SYNTAX OCTET STRING (SIZE(0..1024)) 1462 MAX-ACCESS read-only 1463 STATUS current 1464 DESCRIPTION 1465 "A fragment of CBOR encoded TSA Certificate data." 1466 DEFVAL { "" } 1467 ::= { tudaV1TSACertEntry 4 } 1469 -- 1470 -- Sync Token 1471 -- 1472 tudaV1SyncToken OBJECT IDENTIFIER ::= { tudaV1MIBObjects 4 } 1473 tudaV1SyncTokenCycles OBJECT-TYPE 1474 SYNTAX Counter32 1475 MAX-ACCESS read-only 1476 STATUS current 1477 DESCRIPTION 1478 "Count of Sync Token update cycles that have 1479 occurred. 1481 DEFVAL intentionally omitted - counter object." 1482 ::= { tudaV1SyncToken 1 } 1484 tudaV1SyncTokenInstances OBJECT-TYPE 1485 SYNTAX Counter32 1486 MAX-ACCESS read-only 1487 STATUS current 1488 DESCRIPTION 1489 "Count of Sync Token instance entries that have 1490 been recorded (some entries MAY have been pruned). 1492 DEFVAL intentionally omitted - counter object." 1493 ::= { tudaV1SyncToken 2 } 1495 tudaV1SyncTokenTable OBJECT-TYPE 1496 SYNTAX SEQUENCE OF TudaV1SyncTokenEntry 1497 MAX-ACCESS not-accessible 1498 STATUS current 1499 DESCRIPTION 1500 "A table of fragments of Sync Token data." 1501 ::= { tudaV1SyncToken 3 } 1503 tudaV1SyncTokenEntry OBJECT-TYPE 1504 SYNTAX TudaV1SyncTokenEntry 1505 MAX-ACCESS not-accessible 1506 STATUS current 1507 DESCRIPTION 1508 "An entry for one fragment of Sync Token data." 1509 INDEX { tudaV1SyncTokenCycleIndex, 1510 tudaV1SyncTokenInstanceIndex, 1511 tudaV1SyncTokenFragmentIndex } 1512 ::= { tudaV1SyncTokenTable 1 } 1514 TudaV1SyncTokenEntry ::= 1515 SEQUENCE { 1516 tudaV1SyncTokenCycleIndex Integer32, 1517 tudaV1SyncTokenInstanceIndex Integer32, 1518 tudaV1SyncTokenFragmentIndex Integer32, 1519 tudaV1SyncTokenData OCTET STRING 1520 } 1522 tudaV1SyncTokenCycleIndex OBJECT-TYPE 1523 SYNTAX Integer32 (1..2147483647) 1524 MAX-ACCESS not-accessible 1525 STATUS current 1526 DESCRIPTION 1527 "High-order index of this Sync Token fragment. 1528 Index of a Sync Token update cycle that has 1529 occurred (bounded by the value of tudaV1SyncTokenCycles). 1531 DEFVAL intentionally omitted - index object." 1532 ::= { tudaV1SyncTokenEntry 1 } 1534 tudaV1SyncTokenInstanceIndex OBJECT-TYPE 1535 SYNTAX Integer32 (1..2147483647) 1536 MAX-ACCESS not-accessible 1537 STATUS current 1538 DESCRIPTION 1539 "Middle index of this Sync Token fragment. 1540 Ordinal of this instance of Sync Token data 1541 (NOT bounded by the value of tudaV1SyncTokenInstances). 1543 DEFVAL intentionally omitted - index object." 1544 ::= { tudaV1SyncTokenEntry 2 } 1546 tudaV1SyncTokenFragmentIndex OBJECT-TYPE 1547 SYNTAX Integer32 (1..2147483647) 1548 MAX-ACCESS not-accessible 1549 STATUS current 1550 DESCRIPTION 1551 "Low-order index of this Sync Token fragment. 1553 DEFVAL intentionally omitted - index object." 1554 ::= { tudaV1SyncTokenEntry 3 } 1556 tudaV1SyncTokenData OBJECT-TYPE 1557 SYNTAX OCTET STRING (SIZE(0..1024)) 1558 MAX-ACCESS read-only 1559 STATUS current 1560 DESCRIPTION 1561 "A fragment of CBOR encoded Sync Token data." 1562 DEFVAL { "" } 1563 ::= { tudaV1SyncTokenEntry 4 } 1565 -- 1566 -- Restriction Info 1567 -- 1568 tudaV1Restrict OBJECT IDENTIFIER ::= { tudaV1MIBObjects 5 } 1569 tudaV1RestrictCycles OBJECT-TYPE 1570 SYNTAX Counter32 1571 MAX-ACCESS read-only 1572 STATUS current 1573 DESCRIPTION 1574 "Count of Restriction Info update cycles that have 1575 occurred. 1577 DEFVAL intentionally omitted - counter object." 1578 ::= { tudaV1Restrict 1 } 1580 tudaV1RestrictTable OBJECT-TYPE 1581 SYNTAX SEQUENCE OF TudaV1RestrictEntry 1582 MAX-ACCESS not-accessible 1583 STATUS current 1584 DESCRIPTION 1585 "A table of instances of Restriction Info data." 1586 ::= { tudaV1Restrict 2 } 1588 tudaV1RestrictEntry OBJECT-TYPE 1589 SYNTAX TudaV1RestrictEntry 1590 MAX-ACCESS not-accessible 1591 STATUS current 1592 DESCRIPTION 1593 "An entry for one instance of Restriction Info data." 1594 INDEX { tudaV1RestrictCycleIndex } 1595 ::= { tudaV1RestrictTable 1 } 1597 TudaV1RestrictEntry ::= 1598 SEQUENCE { 1599 tudaV1RestrictCycleIndex Integer32, 1600 tudaV1RestrictData OCTET STRING 1601 } 1603 tudaV1RestrictCycleIndex OBJECT-TYPE 1604 SYNTAX Integer32 (1..2147483647) 1605 MAX-ACCESS not-accessible 1606 STATUS current 1607 DESCRIPTION 1608 "Index of this Restriction Info entry. 1609 Index of a Restriction Info update cycle that has 1610 occurred (bounded by the value of tudaV1RestrictCycles). 1612 DEFVAL intentionally omitted - index object." 1613 ::= { tudaV1RestrictEntry 1 } 1615 tudaV1RestrictData OBJECT-TYPE 1616 SYNTAX OCTET STRING (SIZE(0..1024)) 1617 MAX-ACCESS read-only 1618 STATUS current 1619 DESCRIPTION 1620 "An instance of CBOR encoded Restriction Info data." 1621 DEFVAL { "" } 1622 ::= { tudaV1RestrictEntry 2 } 1624 -- 1625 -- Measurement Log 1626 -- 1627 tudaV1Measure OBJECT IDENTIFIER ::= { tudaV1MIBObjects 6 } 1629 tudaV1MeasureCycles OBJECT-TYPE 1630 SYNTAX Counter32 1631 MAX-ACCESS read-only 1632 STATUS current 1633 DESCRIPTION 1634 "Count of Measurement Log update cycles that have 1635 occurred. 1637 DEFVAL intentionally omitted - counter object." 1638 ::= { tudaV1Measure 1 } 1640 tudaV1MeasureInstances OBJECT-TYPE 1641 SYNTAX Counter32 1642 MAX-ACCESS read-only 1643 STATUS current 1644 DESCRIPTION 1645 "Count of Measurement Log instance entries that have 1646 been recorded (some entries MAY have been pruned). 1648 DEFVAL intentionally omitted - counter object." 1649 ::= { tudaV1Measure 2 } 1651 tudaV1MeasureTable OBJECT-TYPE 1652 SYNTAX SEQUENCE OF TudaV1MeasureEntry 1653 MAX-ACCESS not-accessible 1654 STATUS current 1655 DESCRIPTION 1656 "A table of instances of Measurement Log data." 1657 ::= { tudaV1Measure 3 } 1659 tudaV1MeasureEntry OBJECT-TYPE 1660 SYNTAX TudaV1MeasureEntry 1661 MAX-ACCESS not-accessible 1662 STATUS current 1663 DESCRIPTION 1664 "An entry for one instance of Measurement Log data." 1665 INDEX { tudaV1MeasureCycleIndex, 1666 tudaV1MeasureInstanceIndex } 1667 ::= { tudaV1MeasureTable 1 } 1669 TudaV1MeasureEntry ::= 1670 SEQUENCE { 1671 tudaV1MeasureCycleIndex Integer32, 1672 tudaV1MeasureInstanceIndex Integer32, 1673 tudaV1MeasureData OCTET STRING 1674 } 1676 tudaV1MeasureCycleIndex OBJECT-TYPE 1677 SYNTAX Integer32 (1..2147483647) 1678 MAX-ACCESS not-accessible 1679 STATUS current 1680 DESCRIPTION 1681 "High-order index of this Measurement Log entry. 1682 Index of a Measurement Log update cycle that has 1683 occurred (bounded by the value of tudaV1MeasureCycles). 1685 DEFVAL intentionally omitted - index object." 1686 ::= { tudaV1MeasureEntry 1 } 1688 tudaV1MeasureInstanceIndex OBJECT-TYPE 1689 SYNTAX Integer32 (1..2147483647) 1690 MAX-ACCESS not-accessible 1691 STATUS current 1692 DESCRIPTION 1693 "Low-order index of this Measurement Log entry. 1694 Ordinal of this instance of Measurement Log data 1695 (NOT bounded by the value of tudaV1MeasureInstances). 1697 DEFVAL intentionally omitted - index object." 1698 ::= { tudaV1MeasureEntry 2 } 1700 tudaV1MeasureData OBJECT-TYPE 1701 SYNTAX OCTET STRING (SIZE(0..1024)) 1702 MAX-ACCESS read-only 1703 STATUS current 1704 DESCRIPTION 1705 "A instance of CBOR encoded Measurement Log data." 1706 DEFVAL { "" } 1707 ::= { tudaV1MeasureEntry 3 } 1709 -- 1710 -- Verify Token 1711 -- 1712 tudaV1VerifyToken OBJECT IDENTIFIER ::= { tudaV1MIBObjects 7 } 1714 tudaV1VerifyTokenCycles OBJECT-TYPE 1715 SYNTAX Counter32 1716 MAX-ACCESS read-only 1717 STATUS current 1718 DESCRIPTION 1719 "Count of Verify Token update cycles that have 1720 occurred. 1722 DEFVAL intentionally omitted - counter object." 1723 ::= { tudaV1VerifyToken 1 } 1725 tudaV1VerifyTokenTable OBJECT-TYPE 1726 SYNTAX SEQUENCE OF TudaV1VerifyTokenEntry 1727 MAX-ACCESS not-accessible 1728 STATUS current 1729 DESCRIPTION 1730 "A table of instances of Verify Token data." 1731 ::= { tudaV1VerifyToken 2 } 1733 tudaV1VerifyTokenEntry OBJECT-TYPE 1734 SYNTAX TudaV1VerifyTokenEntry 1735 MAX-ACCESS not-accessible 1736 STATUS current 1737 DESCRIPTION 1738 "An entry for one instance of Verify Token data." 1739 INDEX { tudaV1VerifyTokenCycleIndex } 1740 ::= { tudaV1VerifyTokenTable 1 } 1742 TudaV1VerifyTokenEntry ::= 1743 SEQUENCE { 1744 tudaV1VerifyTokenCycleIndex Integer32, 1745 tudaV1VerifyTokenData OCTET STRING 1746 } 1748 tudaV1VerifyTokenCycleIndex OBJECT-TYPE 1749 SYNTAX Integer32 (1..2147483647) 1750 MAX-ACCESS not-accessible 1751 STATUS current 1752 DESCRIPTION 1753 "Index of this instance of Verify Token data. 1754 Index of a Verify Token update cycle that has 1755 occurred (bounded by the value of tudaV1VerifyTokenCycles). 1757 DEFVAL intentionally omitted - index object." 1758 ::= { tudaV1VerifyTokenEntry 1 } 1760 tudaV1VerifyTokenData OBJECT-TYPE 1761 SYNTAX OCTET STRING (SIZE(0..1024)) 1762 MAX-ACCESS read-only 1763 STATUS current 1764 DESCRIPTION 1765 "A instance of CBOR encoded Verify Token data." 1766 DEFVAL { "" } 1767 ::= { tudaV1VerifyTokenEntry 2 } 1769 -- 1770 -- SWID Tag 1771 -- 1772 tudaV1SWIDTag OBJECT IDENTIFIER ::= { tudaV1MIBObjects 8 } 1774 tudaV1SWIDTagCycles OBJECT-TYPE 1775 SYNTAX Counter32 1776 MAX-ACCESS read-only 1777 STATUS current 1778 DESCRIPTION 1779 "Count of SWID Tag update cycles that have occurred. 1781 DEFVAL intentionally omitted - counter object." 1782 ::= { tudaV1SWIDTag 1 } 1784 tudaV1SWIDTagTable OBJECT-TYPE 1785 SYNTAX SEQUENCE OF TudaV1SWIDTagEntry 1786 MAX-ACCESS not-accessible 1787 STATUS current 1788 DESCRIPTION 1789 "A table of fragments of SWID Tag data." 1790 ::= { tudaV1SWIDTag 2 } 1792 tudaV1SWIDTagEntry OBJECT-TYPE 1793 SYNTAX TudaV1SWIDTagEntry 1794 MAX-ACCESS not-accessible 1795 STATUS current 1796 DESCRIPTION 1797 "An entry for one fragment of SWID Tag data." 1798 INDEX { tudaV1SWIDTagCycleIndex, 1799 tudaV1SWIDTagInstanceIndex, 1800 tudaV1SWIDTagFragmentIndex } 1801 ::= { tudaV1SWIDTagTable 1 } 1803 TudaV1SWIDTagEntry ::= 1804 SEQUENCE { 1805 tudaV1SWIDTagCycleIndex Integer32, 1806 tudaV1SWIDTagInstanceIndex Integer32, 1807 tudaV1SWIDTagFragmentIndex Integer32, 1808 tudaV1SWIDTagData OCTET STRING 1809 } 1811 tudaV1SWIDTagCycleIndex OBJECT-TYPE 1812 SYNTAX Integer32 (1..2147483647) 1813 MAX-ACCESS not-accessible 1814 STATUS current 1815 DESCRIPTION 1816 "High-order index of this SWID Tag fragment. 1817 Index of an SWID Tag update cycle that has 1818 occurred (bounded by the value of tudaV1SWIDTagCycles). 1820 DEFVAL intentionally omitted - index object." 1821 ::= { tudaV1SWIDTagEntry 1 } 1823 tudaV1SWIDTagInstanceIndex OBJECT-TYPE 1824 SYNTAX Integer32 (1..2147483647) 1825 MAX-ACCESS not-accessible 1826 STATUS current 1827 DESCRIPTION 1828 "Middle index of this SWID Tag fragment. 1829 Ordinal of this SWID Tag instance in this update cycle. 1831 DEFVAL intentionally omitted - index object." 1832 ::= { tudaV1SWIDTagEntry 2 } 1834 tudaV1SWIDTagFragmentIndex OBJECT-TYPE 1835 SYNTAX Integer32 (1..2147483647) 1836 MAX-ACCESS not-accessible 1837 STATUS current 1838 DESCRIPTION 1839 "Low-order index of this SWID Tag fragment. 1841 DEFVAL intentionally omitted - index object." 1842 ::= { tudaV1SWIDTagEntry 3 } 1844 tudaV1SWIDTagData OBJECT-TYPE 1845 SYNTAX OCTET STRING (SIZE(0..1024)) 1846 MAX-ACCESS read-only 1847 STATUS current 1848 DESCRIPTION 1849 "A fragment of CBOR encoded SWID Tag data." 1850 DEFVAL { "" } 1851 ::= { tudaV1SWIDTagEntry 4 } 1853 -- 1854 -- Trap Cycles 1855 -- 1856 tudaV1TrapV2Cycles NOTIFICATION-TYPE 1857 OBJECTS { 1858 tudaV1GeneralCycles, 1859 tudaV1AIKCertCycles, 1860 tudaV1TSACertCycles, 1861 tudaV1SyncTokenCycles, 1862 tudaV1SyncTokenInstances, 1863 tudaV1RestrictCycles, 1864 tudaV1MeasureCycles, 1865 tudaV1MeasureInstances, 1866 tudaV1VerifyTokenCycles, 1867 tudaV1SWIDTagCycles 1868 } 1869 STATUS current 1870 DESCRIPTION 1871 "This trap is sent when the value of any cycle or instance 1872 counter changes (i.e., one or more tables are updated). 1874 Note: The value of sysUpTime in IETF MIB-II (RFC 1213) is 1875 always included in SNMPv2 traps, per RFC 3416." 1876 ::= { tudaV1MIBNotifications 1 } 1878 -- 1879 -- Conformance Information 1880 -- 1881 tudaV1Compliances OBJECT IDENTIFIER 1882 ::= { tudaV1MIBConformance 1 } 1884 tudaV1ObjectGroups OBJECT IDENTIFIER 1885 ::= { tudaV1MIBConformance 2 } 1887 tudaV1NotificationGroups OBJECT IDENTIFIER 1888 ::= { tudaV1MIBConformance 3 } 1890 -- 1891 -- Compliance Statements 1892 -- 1893 tudaV1BasicCompliance MODULE-COMPLIANCE 1894 STATUS current 1895 DESCRIPTION 1896 "An implementation that complies with this module MUST 1897 implement all of the objects defined in the mandatory 1898 group tudaV1BasicGroup." 1899 MODULE -- this module 1900 MANDATORY-GROUPS { tudaV1BasicGroup } 1902 GROUP tudaV1OptionalGroup 1903 DESCRIPTION 1904 "The optional TUDA MIB objects. 1905 An implementation MAY implement this group." 1907 GROUP tudaV1TrapGroup 1908 DESCRIPTION 1909 "The TUDA MIB traps. 1910 An implementation SHOULD implement this group." 1911 ::= { tudaV1Compliances 1 } 1913 -- 1914 -- Compliance Groups 1915 -- 1916 tudaV1BasicGroup OBJECT-GROUP 1917 OBJECTS { 1918 tudaV1GeneralCycles, 1919 tudaV1GeneralVersionInfo, 1920 tudaV1SyncTokenCycles, 1921 tudaV1SyncTokenInstances, 1922 tudaV1SyncTokenData, 1923 tudaV1RestrictCycles, 1924 tudaV1RestrictData, 1925 tudaV1VerifyTokenCycles, 1926 tudaV1VerifyTokenData 1927 } 1928 STATUS current 1929 DESCRIPTION 1930 "The basic mandatory TUDA MIB objects." 1931 ::= { tudaV1ObjectGroups 1 } 1933 tudaV1OptionalGroup OBJECT-GROUP 1934 OBJECTS { 1935 tudaV1AIKCertCycles, 1936 tudaV1AIKCertData, 1937 tudaV1TSACertCycles, 1938 tudaV1TSACertData, 1939 tudaV1MeasureCycles, 1940 tudaV1MeasureInstances, 1941 tudaV1MeasureData, 1942 tudaV1SWIDTagCycles, 1943 tudaV1SWIDTagData 1944 } 1945 STATUS current 1946 DESCRIPTION 1947 "The optional TUDA MIB objects." 1948 ::= { tudaV1ObjectGroups 2 } 1950 tudaV1TrapGroup NOTIFICATION-GROUP 1951 NOTIFICATIONS { tudaV1TrapV2Cycles } 1952 STATUS current 1953 DESCRIPTION 1954 "The recommended TUDA MIB traps - notifications." 1955 ::= { tudaV1NotificationGroups 1 } 1957 END 1958 1960 Appendix C. YANG Realization 1962 1963 module TUDA-V1-ATTESTATION-MIB { 1965 namespace "urn:ietf:params:xml:ns:yang:smiv2:TUDA-V1-ATTESTATION-MIB"; 1966 prefix "tuda-v1"; 1968 import SNMP-FRAMEWORK-MIB { prefix "snmp-framework"; } 1969 import yang-types { prefix "yang"; } 1971 organization 1972 "Fraunhofer SIT"; 1974 contact 1975 "Andreas Fuchs 1976 Fraunhofer Institute for Secure Information Technology 1977 Email: andreas.fuchs@sit.fraunhofer.de 1979 Henk Birkholz 1980 Fraunhofer Institute for Secure Information Technology 1981 Email: henk.birkholz@sit.fraunhofer.de 1983 Ira E McDonald 1984 High North Inc 1985 Email: blueroofmusic@gmail.com 1987 Carsten Bormann 1988 Universitaet Bremen TZI 1989 Email: cabo@tzi.org"; 1991 description 1992 "The MIB module for monitoring of time-based unidirectional 1993 attestation information from a network endpoint system, 1994 based on the Trusted Computing Group TPM 1.2 definition. 1996 Copyright (C) High North Inc (2017)."; 1998 revision "2017-10-30" { 1999 description 2000 "Fifth version, published as draft-birkholz-tuda-04."; 2001 reference 2002 "draft-birkholz-tuda-04"; 2003 } 2004 revision "2017-01-09" { 2005 description 2006 "Fourth version, published as draft-birkholz-tuda-03."; 2007 reference 2008 "draft-birkholz-tuda-03"; 2009 } 2010 revision "2016-07-08" { 2011 description 2012 "Third version, published as draft-birkholz-tuda-02."; 2013 reference 2014 "draft-birkholz-tuda-02"; 2015 } 2016 revision "2016-03-21" { 2017 description 2018 "Second version, published as draft-birkholz-tuda-01."; 2019 reference 2020 "draft-birkholz-tuda-01"; 2021 } 2022 revision "2015-10-18" { 2023 description 2024 "Initial version, published as draft-birkholz-tuda-00."; 2025 reference 2026 "draft-birkholz-tuda-00"; 2027 } 2029 container tudaV1General { 2030 description 2031 "TBD"; 2033 leaf tudaV1GeneralCycles { 2034 type yang:counter32; 2035 config false; 2036 description 2037 "Count of TUDA update cycles that have occurred, i.e., 2038 sum of all the individual group cycle counters. 2040 DEFVAL intentionally omitted - counter object."; 2041 } 2043 leaf tudaV1GeneralVersionInfo { 2044 type snmp-framework:SnmpAdminString { 2045 length "0..255"; 2046 } 2047 config false; 2048 description 2049 "Version information for TUDA MIB, e.g., specific release 2050 version of TPM 1.2 base specification and release version 2051 of TPM 1.2 errata specification and manufacturer and model 2052 TPM module itself."; 2053 } 2054 } 2056 container tudaV1AIKCert { 2057 description 2058 "TBD"; 2060 leaf tudaV1AIKCertCycles { 2061 type yang:counter32; 2062 config false; 2063 description 2064 "Count of AIK Certificate chain update cycles that have 2065 occurred. 2067 DEFVAL intentionally omitted - counter object."; 2068 } 2070 /* XXX table comments here XXX */ 2072 list tudaV1AIKCertEntry { 2074 key "tudaV1AIKCertCycleIndex tudaV1AIKCertInstanceIndex 2075 tudaV1AIKCertFragmentIndex"; 2076 config false; 2077 description 2078 "An entry for one fragment of AIK Certificate data."; 2080 leaf tudaV1AIKCertCycleIndex { 2081 type int32 { 2082 range "1..2147483647"; 2083 } 2084 config false; 2085 description 2086 "High-order index of this AIK Certificate fragment. 2087 Index of an AIK Certificate chain update cycle that has 2088 occurred (bounded by the value of tudaV1AIKCertCycles). 2090 DEFVAL intentionally omitted - index object."; 2091 } 2093 leaf tudaV1AIKCertInstanceIndex { 2094 type int32 { 2095 range "1..2147483647"; 2096 } 2097 config false; 2098 description 2099 "Middle index of this AIK Certificate fragment. 2100 Ordinal of this AIK Certificate in this chain, where the AIK 2101 Certificate itself has an ordinal of '1' and higher ordinals 2102 go *up* the certificate chain to the Root CA. 2104 DEFVAL intentionally omitted - index object."; 2105 } 2107 leaf tudaV1AIKCertFragmentIndex { 2108 type int32 { 2109 range "1..2147483647"; 2110 } 2111 config false; 2112 description 2113 "Low-order index of this AIK Certificate fragment. 2115 DEFVAL intentionally omitted - index object."; 2116 } 2118 leaf tudaV1AIKCertData { 2119 type binary { 2120 length "0..1024"; 2121 } 2122 config false; 2123 description 2124 "A fragment of CBOR encoded AIK Certificate data."; 2125 } 2126 } 2127 } 2129 container tudaV1TSACert { 2130 description 2131 "TBD"; 2133 leaf tudaV1TSACertCycles { 2134 type yang:counter32; 2135 config false; 2136 description 2137 "Count of TSA Certificate chain update cycles that have 2138 occurred. 2140 DEFVAL intentionally omitted - counter object."; 2141 } 2142 /* XXX table comments here XXX */ 2144 list tudaV1TSACertEntry { 2146 key "tudaV1TSACertCycleIndex tudaV1TSACertInstanceIndex 2147 tudaV1TSACertFragmentIndex"; 2148 config false; 2149 description 2150 "An entry for one fragment of TSA Certificate data."; 2152 leaf tudaV1TSACertCycleIndex { 2153 type int32 { 2154 range "1..2147483647"; 2155 } 2156 config false; 2157 description 2158 "High-order index of this TSA Certificate fragment. 2159 Index of a TSA Certificate chain update cycle that has 2160 occurred (bounded by the value of tudaV1TSACertCycles). 2162 DEFVAL intentionally omitted - index object."; 2163 } 2165 leaf tudaV1TSACertInstanceIndex { 2166 type int32 { 2167 range "1..2147483647"; 2168 } 2169 config false; 2170 description 2171 "Middle index of this TSA Certificate fragment. 2172 Ordinal of this TSA Certificate in this chain, where the TSA 2173 Certificate itself has an ordinal of '1' and higher ordinals 2174 go *up* the certificate chain to the Root CA. 2176 DEFVAL intentionally omitted - index object."; 2177 } 2179 leaf tudaV1TSACertFragmentIndex { 2180 type int32 { 2181 range "1..2147483647"; 2182 } 2183 config false; 2184 description 2185 "Low-order index of this TSA Certificate fragment. 2187 DEFVAL intentionally omitted - index object."; 2188 } 2189 leaf tudaV1TSACertData { 2190 type binary { 2191 length "0..1024"; 2192 } 2193 config false; 2194 description 2195 "A fragment of CBOR encoded TSA Certificate data."; 2196 } 2197 } 2198 } 2200 container tudaV1SyncToken { 2201 description 2202 "TBD"; 2204 leaf tudaV1SyncTokenCycles { 2205 type yang:counter32; 2206 config false; 2207 description 2208 "Count of Sync Token update cycles that have 2209 occurred. 2211 DEFVAL intentionally omitted - counter object."; 2212 } 2214 leaf tudaV1SyncTokenInstances { 2215 type yang:counter32; 2216 config false; 2217 description 2218 "Count of Sync Token instance entries that have 2219 been recorded (some entries MAY have been pruned). 2221 DEFVAL intentionally omitted - counter object."; 2222 } 2224 list tudaV1SyncTokenEntry { 2226 key "tudaV1SyncTokenCycleIndex 2227 tudaV1SyncTokenInstanceIndex 2228 tudaV1SyncTokenFragmentIndex"; 2229 config false; 2230 description 2231 "An entry for one fragment of Sync Token data."; 2233 leaf tudaV1SyncTokenCycleIndex { 2234 type int32 { 2235 range "1..2147483647"; 2237 } 2238 config false; 2239 description 2240 "High-order index of this Sync Token fragment. 2241 Index of a Sync Token update cycle that has 2242 occurred (bounded by the value of tudaV1SyncTokenCycles). 2244 DEFVAL intentionally omitted - index object."; 2245 } 2247 leaf tudaV1SyncTokenInstanceIndex { 2248 type int32 { 2249 range "1..2147483647"; 2250 } 2251 config false; 2252 description 2253 "Middle index of this Sync Token fragment. 2254 Ordinal of this instance of Sync Token data 2255 (NOT bounded by the value of tudaV1SyncTokenInstances). 2257 DEFVAL intentionally omitted - index object."; 2258 } 2260 leaf tudaV1SyncTokenFragmentIndex { 2261 type int32 { 2262 range "1..2147483647"; 2263 } 2264 config false; 2265 description 2266 "Low-order index of this Sync Token fragment. 2268 DEFVAL intentionally omitted - index object."; 2269 } 2271 leaf tudaV1SyncTokenData { 2272 type binary { 2273 length "0..1024"; 2274 } 2275 config false; 2276 description 2277 "A fragment of CBOR encoded Sync Token data."; 2278 } 2279 } 2280 } 2282 container tudaV1Restrict { 2283 description 2284 "TBD"; 2285 leaf tudaV1RestrictCycles { 2286 type yang:counter32; 2287 config false; 2288 description 2289 "Count of Restriction Info update cycles that have 2290 occurred. 2292 DEFVAL intentionally omitted - counter object."; 2293 } 2295 /* XXX table comments here XXX */ 2297 list tudaV1RestrictEntry { 2299 key "tudaV1RestrictCycleIndex"; 2300 config false; 2301 description 2302 "An entry for one instance of Restriction Info data."; 2304 leaf tudaV1RestrictCycleIndex { 2305 type int32 { 2306 range "1..2147483647"; 2307 } 2308 config false; 2309 description 2310 "Index of this Restriction Info entry. 2311 Index of a Restriction Info update cycle that has 2312 occurred (bounded by the value of tudaV1RestrictCycles). 2314 DEFVAL intentionally omitted - index object."; 2315 } 2317 leaf tudaV1RestrictData { 2318 type binary { 2319 length "0..1024"; 2320 } 2321 config false; 2322 description 2323 "An instance of CBOR encoded Restriction Info data."; 2324 } 2325 } 2326 } 2328 container tudaV1Measure { 2329 description 2330 "TBD"; 2331 leaf tudaV1MeasureCycles { 2332 type yang:counter32; 2333 config false; 2334 description 2335 "Count of Measurement Log update cycles that have 2336 occurred. 2338 DEFVAL intentionally omitted - counter object."; 2339 } 2341 leaf tudaV1MeasureInstances { 2342 type yang:counter32; 2343 config false; 2344 description 2345 "Count of Measurement Log instance entries that have 2346 been recorded (some entries MAY have been pruned). 2348 DEFVAL intentionally omitted - counter object."; 2349 } 2351 list tudaV1MeasureEntry { 2353 key "tudaV1MeasureCycleIndex tudaV1MeasureInstanceIndex"; 2354 config false; 2355 description 2356 "An entry for one instance of Measurement Log data."; 2358 leaf tudaV1MeasureCycleIndex { 2359 type int32 { 2360 range "1..2147483647"; 2361 } 2362 config false; 2363 description 2364 "High-order index of this Measurement Log entry. 2365 Index of a Measurement Log update cycle that has 2366 occurred (bounded by the value of tudaV1MeasureCycles). 2368 DEFVAL intentionally omitted - index object."; 2369 } 2371 leaf tudaV1MeasureInstanceIndex { 2372 type int32 { 2373 range "1..2147483647"; 2374 } 2375 config false; 2376 description 2377 "Low-order index of this Measurement Log entry. 2379 Ordinal of this instance of Measurement Log data 2380 (NOT bounded by the value of tudaV1MeasureInstances). 2382 DEFVAL intentionally omitted - index object."; 2383 } 2385 leaf tudaV1MeasureData { 2386 type binary { 2387 length "0..1024"; 2388 } 2389 config false; 2390 description 2391 "A instance of CBOR encoded Measurement Log data."; 2392 } 2393 } 2394 } 2396 container tudaV1VerifyToken { 2397 description 2398 "TBD"; 2400 leaf tudaV1VerifyTokenCycles { 2401 type yang:counter32; 2402 config false; 2403 description 2404 "Count of Verify Token update cycles that have 2405 occurred. 2407 DEFVAL intentionally omitted - counter object."; 2408 } 2410 /* XXX table comments here XXX */ 2412 list tudaV1VerifyTokenEntry { 2414 key "tudaV1VerifyTokenCycleIndex"; 2415 config false; 2416 description 2417 "An entry for one instance of Verify Token data."; 2419 leaf tudaV1VerifyTokenCycleIndex { 2420 type int32 { 2421 range "1..2147483647"; 2422 } 2423 config false; 2424 description 2425 "Index of this instance of Verify Token data. 2426 Index of a Verify Token update cycle that has 2427 occurred (bounded by the value of tudaV1VerifyTokenCycles). 2429 DEFVAL intentionally omitted - index object."; 2430 } 2432 leaf tudaV1VerifyTokenData { 2433 type binary { 2434 length "0..1024"; 2435 } 2436 config false; 2437 description 2438 "A instanc-V1-ATTESTATION-MIB.yang 2439 } 2440 } 2441 } 2443 container tudaV1SWIDTag { 2444 description 2445 "see CoSWID and YANG SIWD module for now" 2447 leaf tudaV1SWIDTagCycles { 2448 type yang:counter32; 2449 config false; 2450 description 2451 "Count of SWID Tag update cycles that have occurred. 2453 DEFVAL intentionally omitted - counter object."; 2454 } 2456 list tudaV1SWIDTagEntry { 2458 key "tudaV1SWIDTagCycleIndex tudaV1SWIDTagInstanceIndex 2459 tudaV1SWIDTagFragmentIndex"; 2460 config false; 2461 description 2462 "An entry for one fragment of SWID Tag data."; 2464 leaf tudaV1SWIDTagCycleIndex { 2465 type int32 { 2466 range "1..2147483647"; 2467 } 2468 config false; 2469 description 2470 "High-order index of this SWID Tag fragment. 2471 Index of an SWID Tag update cycle that has 2472 occurred (bounded by the value of tudaV1SWIDTagCycles). 2474 DEFVAL intentionally omitted - index object."; 2475 } 2477 leaf tudaV1SWIDTagInstanceIndex { 2478 type int32 { 2479 range "1..2147483647"; 2480 } 2481 config false; 2482 description 2483 "Middle index of this SWID Tag fragment. 2484 Ordinal of this SWID Tag instance in this update cycle. 2486 DEFVAL intentionally omitted - index object."; 2487 } 2489 leaf tudaV1SWIDTagFragmentIndex { 2490 type int32 { 2491 range "1..2147483647"; 2492 } 2493 config false; 2494 description 2495 "Low-order index of this SWID Tag fragment. 2497 DEFVAL intentionally omitted - index object."; 2498 } 2500 leaf tudaV1SWIDTagData { 2501 type binary { 2502 length "0..1024"; 2503 } 2504 config false; 2505 description 2506 "A fragment of CBOR encoded SWID Tag data."; 2507 } 2508 } 2509 } 2511 notification tudaV1TrapV2Cycles { 2512 description 2513 "This trap is sent when the value of any cycle or instance 2514 counter changes (i.e., one or more tables are updated). 2516 Note: The value of sysUpTime in IETF MIB-II (RFC 1213) is 2517 always included in SNMPv2 traps, per RFC 3416."; 2519 container tudaV1TrapV2Cycles-tudaV1GeneralCycles { 2520 description 2521 "TPD" 2522 leaf tudaV1GeneralCycles { 2523 type yang:counter32; 2524 description 2525 "Count of TUDA update cycles that have occurred, i.e., 2526 sum of all the individual group cycle counters. 2528 DEFVAL intentionally omitted - counter object."; 2529 } 2530 } 2532 container tudaV1TrapV2Cycles-tudaV1AIKCertCycles { 2533 description 2534 "TPD" 2535 leaf tudaV1AIKCertCycles { 2536 type yang:counter32; 2537 description 2538 "Count of AIK Certificate chain update cycles that have 2539 occurred. 2541 DEFVAL intentionally omitted - counter object."; 2542 } 2543 } 2545 container tudaV1TrapV2Cycles-tudaV1TSACertCycles { 2546 description 2547 "TPD" 2548 leaf tudaV1TSACertCycles { 2549 type yang:counter32; 2550 description 2551 "Count of TSA Certificate chain update cycles that have 2552 occurred. 2554 DEFVAL intentionally omitted - counter object."; 2555 } 2556 } 2558 container tudaV1TrapV2Cycles-tudaV1SyncTokenCycles { 2559 description 2560 "TPD" 2561 leaf tudaV1SyncTokenCycles { 2562 type yang:counter32; 2563 description 2564 "Count of Sync Token update cycles that have 2565 occurred. 2567 DEFVAL intentionally omitted - counter object."; 2569 } 2570 } 2572 container tudaV1TrapV2Cycles-tudaV1SyncTokenInstances { 2573 description 2574 "TPD" 2575 leaf tudaV1SyncTokenInstances { 2576 type yang:counter32; 2577 description 2578 "Count of Sync Token instance entries that have 2579 been recorded (some entries MAY have been pruned). 2581 DEFVAL intentionally omitted - counter object."; 2582 } 2583 } 2585 container tudaV1TrapV2Cycles-tudaV1RestrictCycles { 2586 description 2587 "TPD" 2588 leaf tudaV1RestrictCycles { 2589 type yang:counter32; 2590 description 2591 "Count of Restriction Info update cycles that have 2592 occurred. 2594 DEFVAL intentionally omitted - counter object."; 2595 } 2596 } 2598 container tudaV1TrapV2Cycles-tudaV1MeasureCycles { 2599 description 2600 "TPD" 2601 leaf tudaV1MeasureCycles { 2602 type yang:counter32; 2603 description 2604 "Count of Measurement Log update cycles that have 2605 occurred. 2607 DEFVAL intentionally omitted - counter object."; 2608 } 2609 } 2611 container tudaV1TrapV2Cycles-tudaV1MeasureInstances { 2612 description 2613 "TPD" 2614 leaf tudaV1MeasureInstances { 2615 type yang:counter32; 2616 description 2617 "Count of Measurement Log instance entries that have 2618 been recorded (some entries MAY have been pruned). 2620 DEFVAL intentionally omitted - counter object."; 2621 } 2622 } 2624 container tudaV1TrapV2Cycles-tudaV1VerifyTokenCycles { 2625 description 2626 "TPD" 2627 leaf tudaV1VerifyTokenCycles { 2628 type yang:counter32; 2629 description 2630 "Count of Verify Token update cycles that have 2631 occurred. 2633 DEFVAL intentionally omitted - counter object."; 2634 } 2635 } 2637 container tudaV1TrapV2Cycles-tudaV1SWIDTagCycles { 2638 description 2639 "TPD" 2640 leaf tudaV1SWIDTagCycles { 2641 type yang:counter32; 2642 description 2643 "Count of SWID Tag update cycles that have occurred. 2645 DEFVAL intentionally omitted - counter object."; 2646 } 2647 } 2649 } 2650 } 2651 2653 Appendix D. Realization with TPM functions 2655 D.1. TPM Functions 2657 The following TPM structures, resources and functions are used within 2658 this approach. They are based upon the TPM specifications [TPM12] 2659 and [TPM2]. 2661 D.1.1. Tick-Session and Tick-Stamp 2663 On every boot, the TPM initializes a new Tick-Session. Such a tick- 2664 session consists of a nonce that is randomly created upon each boot 2665 to identify the current boot-cycle - the phase between boot-time of 2666 the device and shutdown or power-off - and prevent replaying of old 2667 tick-session values. The TPM uses its internal entropy source that 2668 guarantees virtually no collisions of the nonce values between two of 2669 such boot cycles. 2671 It further includes an internal timer that is being initialize to 2672 Zero on each reboot. From this point on, the TPM increments this 2673 timer continuously based upon its internal secure clocking 2674 information until the device is powered down or set to sleep. By its 2675 hardware design, the TPM will detect attacks on any of those 2676 properties. 2678 The TPM offers the function TPM_TickStampBlob, which allows the TPM 2679 to create a signature over the current tick-session and two 2680 externally provided input values. These input values are designed to 2681 serve as a nonce and as payload data to be included in a 2682 TickStampBlob: TickstampBlob := sig(TPM-key, currentTicks || nonce || 2683 externalData). 2685 As a result, one is able to proof that at a certain point in time 2686 (relative to the tick-session) after the provisioning of a certain 2687 nonce, some certain externalData was known and provided to the TPM. 2688 If an approach however requires no input values or only one input 2689 value (such as the use in this document) the input values can be set 2690 to well-known value. The convention used within TCG specifications 2691 and within this document is to use twenty bytes of zero 2692 h'0000000000000000000000000000000000000000' as well-known value. 2694 D.1.2. Platform Configuration Registers (PCRs) 2696 The TPM is a secure cryptoprocessor that provides the ability to 2697 store measurements and metrics about an endpoint's configuration and 2698 state in a secure, tamper-proof environment. Each of these security 2699 relevant metrics can be stored in a volatile Platform Configuration 2700 Register (PCR) inside the TPM. These measurements can be conducted 2701 at any point in time, ranging from an initial BIOS boot-up sequence 2702 to measurements taken after hundreds of hours of uptime. 2704 The initial measurement is triggered by the Platforms so-called pre- 2705 BIOS or ROM-code. It will conduct a measurement of the first 2706 loadable pieces of code; i.e.\ the BIOS. The BIOS will in turn 2707 measure its Option ROMs and the BootLoader, which measures the OS- 2708 Kernel, which in turn measures its applications. This describes a 2709 so-called measurement chain. This typically gets recorded in a so- 2710 called measurement log, such that the values of the PCRs can be 2711 reconstructed from the individual measurements for validation. 2713 Via its PCRs, a TPM provides a Root of Trust that can, for example, 2714 support secure boot or remote attestation. The attestation of an 2715 endpoint's identity or security posture is based on the content of an 2716 TPM's PCRs (platform integrity measurements). 2718 D.1.3. PCR restricted Keys 2720 Every key inside the TPM can be restricted in such a way that it can 2721 only be used if a certain set of PCRs are in a predetermined state. 2722 For key creation the desired state for PCRs are defined via the 2723 PCRInfo field inside the keyInfo parameter. Whenever an operation 2724 using this key is performed, the TPM first checks whether the PCRs 2725 are in the correct state. Otherwise the operation is denied by the 2726 TPM. 2728 D.1.4. CertifyInfo 2730 The TPM offers a command to certify the properties of a key by means 2731 of a signature using another key. This includes especially the 2732 keyInfo which in turn includes the PCRInfo information used during 2733 key creation. This way, a third party can be assured about the fact 2734 that a key is only usable if the PCRs are in a certain state. 2736 D.2. IE Generation Procedures for TPM 1.2 2738 D.2.1. AIK and AIK Certificate 2740 Attestations are based upon a cryptographic signature performed by 2741 the TPM using a so-called Attestation Identity Key (AIK). An AIK has 2742 the properties that it cannot be exported from a TPM and is used for 2743 attestations. Trust in the AIK is established by an X.509 2744 Certificate emitted by a Certificate Authority. The AIK certificate 2745 is either provided directly or via a so-called PrivacyCA 2746 [AIK-Enrollment]. 2748 This element consists of the AIK certificate that includes the AIK's 2749 public key used during verification as well as the certificate chain 2750 up to the Root CA for validation of the AIK certificate itself. 2752 TUDA-Cert = [AIK-Cert, TSA-Cert]; maybe split into two for SNMP 2753 AIK-Cert = Cert 2754 TSA-Cert = Cert 2756 Figure 2: TUDA-Cert element in CDDL 2758 The TSA-Cert is a standard certificate of the TSA. 2760 The AIK-Cert may be provisioned in a secure environment using 2761 standard means or it may follow the PrivacyCA protocols. Figure 3 2762 gives a rough sketch of this protocol. See [AIK-Enrollment] for more 2763 information. 2765 The X.509 Certificate is built from the AIK public key and the 2766 corresponding PKCS #7 certificate chain, as shown in Figure 3. 2768 Required TPM functions: 2770 | create_AIK_Cert(...) = { 2771 | AIK = TPM_MakeIdentity() 2772 | IdReq = CollateIdentityRequest(AIK,EK) 2773 | IdRes = Call(AIK-CA, IdReq) 2774 | AIK-Cert = TPM_ActivateIdentity(AIK, IdRes) 2775 | } 2776 | 2777 | /* Alternative */ 2778 | 2779 | create_AIK_Cert(...) = { 2780 | AIK = TPM_CreateWrapKey(Identity) 2781 | AIK-Cert = Call(AIK-CA, AIK.pubkey) 2782 | } 2784 Figure 3: Creating the TUDA-Cert element 2786 D.2.2. Synchronization Token 2788 The reference for Attestations are the Tick-Sessions of the TPM. In 2789 order to put Attestations into relation with a Real Time Clock (RTC), 2790 it is necessary to provide a cryptographic synchronization between 2791 the tick session and the RTC. To do so, a synchronization protocol 2792 is run with a Time Stamp Authority (TSA) that consists of three 2793 steps: 2795 o The TPM creates a TickStampBlob using the AIK 2797 o This TickstampBlob is used as nonce to the Timestamp of the TSA 2799 o Another TickStampBlob with the AIK is created using the TSA's 2800 Timestamp a nonce 2802 The first TickStampBlob is called "left" and the second "right" in a 2803 reference to their position on a time-axis. 2805 These three elements, with the TSA's certificate factored out, form 2806 the synchronization token 2808 TUDA-Synctoken = [ 2809 left: TickStampBlob-Output, 2810 timestamp: TimeStampToken, 2811 right: TickStampBlob-Output, 2812 ] 2814 TimeStampToken = bytes ; RFC 3161 2816 TickStampBlob-Output = [ 2817 currentTicks: TPM-CURRENT-TICKS, 2818 sig: bytes, 2819 ] 2821 TPM-CURRENT-TICKS = [ 2822 currentTicks: uint 2823 ? ( 2824 tickRate: uint 2825 tickNonce: TPM-NONCE 2826 ) 2827 ] 2828 ; Note that TickStampBlob-Output "right" can omit the values for 2829 ; tickRate and tickNonce since they are the same as in "left" 2831 TPM-NONCE = bytes .size 20 2833 Figure 4: TUDA-Sync element in CDDL 2835 Required TPM functions: 2837 | dummyDigest = h'0000000000000000000000000000000000000000' 2838 | dummyNonce = dummyDigest 2839 | 2840 | create_sync_token(AIKHandle, TSA) = { 2841 | ts_left = TPM_TickStampBlob( 2842 | keyHandle = AIK_Handle, /*TPM_KEY_HANDLE*/ 2843 | antiReplay = dummyNonce, /*TPM_NONCE*/ 2844 | digestToStamp = dummyDigest /*TPM_DIGEST*/) 2845 | 2846 | ts = TSA_Timestamp(TSA, nonce = hash(ts_left)) 2847 | 2848 | ts_right = TPM_TickStampBlob( 2849 | keyHandle = AIK_Handle, /*TPM_KEY_HANDLE*/ 2850 | antiReplay = dummyNonce, /*TPM_NONCE*/ 2851 | digestToStamp = hash(ts)) /*TPM_DIGEST*/ 2852 | 2853 | TUDA-SyncToken = [[ts_left.ticks, ts_left.sig], ts, 2854 | [ts_right.ticks.currentTicks, ts_right.sig]] 2855 | /* Note: skip the nonce and tickRate field for ts_right.ticks */ 2856 | } 2858 Figure 5: Creating the Sync-Token element 2860 D.2.3. RestrictionInfo 2862 The attestation relies on the capability of the TPM to operate on 2863 restricted keys. Whenever the PCR values for the machine to be 2864 attested change, a new restricted key is created that can only be 2865 operated as long as the PCRs remain in their current state. 2867 In order to prove to the Verifier that this restricted temporary key 2868 actually has these properties and also to provide the PCR value that 2869 it is restricted, the TPM command TPM_CertifyInfo is used. It 2870 creates a signed certificate using the AIK about the newly created 2871 restricted key. 2873 This token is formed from the list of: 2875 o PCR list, 2877 o the newly created restricted public key, and 2879 o the certificate. 2881 TUDA-RestrictionInfo = [Composite, 2882 restrictedKey_Pub: Pubkey, 2883 CertifyInfo] 2885 PCRSelection = bytes .size (2..4) ; used as bit string 2887 Composite = [ 2888 bitmask: PCRSelection, 2889 values: [*PCR-Hash], 2890 ] 2892 Pubkey = bytes ; may be extended to COSE pubkeys 2894 CertifyInfo = [ 2895 TPM-CERTIFY-INFO, 2896 sig: bytes, 2897 ] 2899 TPM-CERTIFY-INFO = [ 2900 ; we don't encode TPM-STRUCT-VER: 2901 ; these are 4 bytes always equal to h'01010000' 2902 keyUsage: uint, ; 4byte? 2byte? 2903 keyFlags: bytes .size 4, ; 4byte 2904 authDataUsage: uint, ; 1byte (enum) 2905 algorithmParms: TPM-KEY-PARMS, 2906 pubkeyDigest: Hash, 2907 ; we don't encode TPM-NONCE data, which is 20 bytes, all zero 2908 parentPCRStatus: bool, 2909 ; no need to encode pcrinfosize 2910 pcrinfo: TPM-PCR-INFO, ; we have exactly one 2911 ] 2913 TPM-PCR-INFO = [ 2914 pcrSelection: PCRSelection; /* TPM_PCR_SELECTION */ 2915 digestAtRelease: PCR-Hash; /* TPM_COMPOSITE_HASH */ 2916 digestAtCreation: PCR-Hash; /* TPM_COMPOSITE_HASH */ 2917 ] 2919 TPM-KEY-PARMS = [ 2920 ; algorithmID: uint, ; <= 4 bytes -- not encoded, constant for TPM1.2 2921 encScheme: uint, ; <= 2 bytes 2922 sigScheme: uint, ; <= 2 bytes 2923 parms: TPM-RSA-KEY-PARMS, 2924 ] 2926 TPM-RSA-KEY-PARMS = [ 2927 ; "size of the RSA key in bits": 2928 keyLength: uint 2929 ; "number of prime factors used by this RSA key": 2930 numPrimes: uint 2931 ; "This SHALL be the size of the exponent": 2932 exponentSize: null / uint / biguint 2933 ; "If the key is using the default exponent then the exponentSize 2934 ; MUST be 0" -> we represent this case as null 2935 ] 2937 Figure 6: TUDA-Key element in CDDL 2939 Required TPM functions: 2941 | dummyDigest = h'0000000000000000000000000000000000000000' 2942 | dummyNonce = dummyDigest 2943 | 2944 | create_Composite 2945 | 2946 | create_restrictedKey_Pub(pcrsel) = { 2947 | PCRInfo = {pcrSelection = pcrsel, 2948 | digestAtRelease = hash(currentValues(pcrSelection)) 2949 | digestAtCreation = dummyDigest} 2950 | / * PCRInfo is a TPM_PCR_INFO and thus also a TPM_KEY */ 2951 | 2952 | wk = TPM_CreateWrapKey(keyInfo = PCRInfo) 2953 | wk.keyInfo.pubKey 2954 | } 2955 | 2956 | create_TPM-Certify-Info = { 2957 | CertifyInfo = TPM_CertifyKey( 2958 | certHandle = AIK, /* TPM_KEY_HANDLE */ 2959 | keyHandle = wk, /* TPM_KEY_HANDLE */ 2960 | antiReply = dummyNonce) /* TPM_NONCE */ 2961 | 2962 | CertifyInfo.strip() 2963 | /* Remove those values that are not needed */ 2964 | } 2966 Figure 7: Creating the pubkey 2968 D.2.4. Measurement Log 2970 Similarly to regular attestations, the Verifier needs a way to 2971 reconstruct the PCRs' values in order to estimate the trustworthiness 2972 of the device. As such, a list of those elements that were extended 2973 into the PCRs is reported. Note though that for certain 2974 environments, this step may be optional if a list of valid PCR 2975 configurations exists and no measurement log is required. 2977 TUDA-Measurement-Log = [*PCR-Event] 2978 PCR-Event = [ 2979 type: PCR-Event-Type, 2980 pcr: uint, 2981 template-hash: PCR-Hash, 2982 filedata-hash: tagged-hash, 2983 pathname: text; called filename-hint in ima (non-ng) 2984 ] 2986 PCR-Event-Type = &( 2987 bios: 0 2988 ima: 1 2989 ima-ng: 2 2990 ) 2992 ; might want to make use of COSE registry here 2993 ; however, that might never define a value for sha1 2994 tagged-hash /= [sha1: 0, bytes .size 20] 2995 tagged-hash /= [sha256: 1, bytes .size 32] 2997 D.2.5. Implicit Attestation 2999 The actual attestation is then based upon a TickStampBlob using the 3000 restricted temporary key that was certified in the steps above. The 3001 TPM-Tickstamp is executed and thereby provides evidence that at this 3002 point in time (with respect to the TPM internal tick-session) a 3003 certain configuration existed (namely the PCR values associated with 3004 the restricted key). Together with the synchronization token this 3005 tick-related timing can then be related to the real-time clock. 3007 This element consists only of the TPM_TickStampBlock with no nonce. 3009 TUDA-Verifytoken = TickStampBlob-Output 3011 Figure 8: TUDA-Verify element in CDDL 3013 Required TPM functions: 3015 | imp_att = TPM_TickStampBlob( 3016 | keyHandle = restrictedKey_Handle, /*TPM_KEY_HANDLE*/ 3017 | antiReplay = dummyNonce, /*TPM_NONCE*/ 3018 | digestToStamp = dummyDigest) /*TPM_DIGEST*/ 3019 | 3020 | VerifyToken = imp_att 3022 Figure 9: Creating the Verify Token 3024 D.2.6. Attestation Verification Approach 3026 The seven TUDA information elements transport the essential content 3027 that is required to enable verification of the attestation statement 3028 at the Verifier. The following listings illustrate the verification 3029 algorithm to be used at the Verifier in pseudocode. The pseudocode 3030 provided covers the entire verification task. If only a subset of 3031 TUDA elements changed (see Section 6.1), only the corresponding code 3032 listings need to be re-executed. 3034 | TSA_pub = verifyCert(TSA-CA, Cert.TSA-Cert) 3035 | AIK_pub = verifyCert(AIK-CA, Cert.AIK-Cert) 3037 Figure 10: Verification of Certificates 3039 | ts_left = Synctoken.left 3040 | ts_right = Synctoken.right 3041 | 3042 | /* Reconstruct ts_right's omitted values; Alternatively assert == */ 3043 | ts_right.currentTicks.tickRate = ts_left.currentTicks.tickRate 3044 | ts_right.currentTicks.tickNonce = ts_left.currentTicks.tickNonce 3045 | 3046 | ticks_left = ts_left.currentTicks 3047 | ticks_right = ts_right.currentTicks 3048 | 3049 | /* Verify Signatures */ 3050 | verifySig(AIK_pub, dummyNonce || dummyDigest || ticks_left) 3051 | verifySig(TSA_pub, hash(ts_left) || timestamp.time) 3052 | verifySig(AIK_pub, dummyNonce || hash(timestamp) || ticks_right) 3053 | 3054 | delta_left = timestamp.time - 3055 | ticks_left.currentTicks * ticks_left.tickRate / 1000 3056 | 3057 | delta_right = timestamp.time - 3058 | ticks_right.currentTicks * ticks_right.tickRate / 1000 3060 Figure 11: Verification of Synchronization Token 3062 | compositeHash = hash_init() 3063 | for value in Composite.values: 3064 | hash_update(compositeHash, value) 3065 | compositeHash = hash_finish(compositeHash) 3066 | 3067 | certInfo = reconstruct_static(TPM-CERTIFY-INFO) 3068 | 3069 | assert(Composite.bitmask == ExpectedPCRBitmask) 3070 | assert(certInfo.pcrinfo.PCRSelection == Composite.bitmask) 3071 | assert(certInfo.pcrinfo.digestAtRelease == compositeHash) 3072 | assert(certInfo.pubkeyDigest == hash(restrictedKey_Pub)) 3073 | 3074 | verifySig(AIK_pub, dummyNonce || certInfo) 3076 Figure 12: Verification of Restriction Info 3078 | for event in Measurement-Log: 3079 | if event.pcr not in ExpectedPCRBitmask: 3080 | continue 3081 | if event.type == BIOS: 3082 | assert_whitelist-bios(event.pcr, event.template-hash) 3083 | if event.type == ima: 3084 | assert(event.pcr == 10) 3085 | assert_whitelist(event.pathname, event.filedata-hash) 3086 | assert(event.template-hash == 3087 | hash(event.pathname || event.filedata-hash)) 3088 | if event.type == ima-ng: 3089 | assert(event.pcr == 10) 3090 | assert_whitelist-ng(event.pathname, event.filedata-hash) 3091 | assert(event.template-hash == 3092 | hash(event.pathname || event.filedata-hash)) 3093 | 3094 | virtPCR[event.pcr] = hash_extend(virtPCR[event.pcr], 3095 | event.template-hash) 3096 | 3097 | for pcr in ExpectedPCRBitmask: 3098 | assert(virtPCR[pcr] == Composite.values[i++] 3100 Figure 13: Verification of Measurement Log 3102 | ts = Verifytoken 3103 | 3104 | /* Reconstruct ts's omitted values; Alternatively assert == */ 3105 | ts.currentTicks.tickRate = ts_left.currentTicks.tickRate 3106 | ts.currentTicks.tickNonce = ts_left.currentTicks.tickNonce 3107 | 3108 | verifySig(restrictedKey_pub, dummyNonce || dummyDigest || ts) 3109 | 3110 | ticks = ts.currentTicks 3111 | 3112 | time_left = delta_right + ticks.currentTicks * ticks.tickRate / 1000 3113 | time_right = delta_left + ticks.currentTicks * ticks.tickRate / 1000 3114 | 3115 | [time_left, time_right] 3117 Figure 14: Verification of Attestation Token 3119 D.3. IE Generation Procedures for TPM 2.0 3121 The pseudo code below includes general operations that are conducted 3122 as specific TPM commands: 3124 o hash() : description TBD 3126 o sig() : description TBD 3128 o X.509-Certificate() : description TBD 3130 These represent the output structure of that command in the form of a 3131 byte string value. 3133 D.3.1. AIK and AIK Certificate 3135 Attestations are based upon a cryptographic signature performed by 3136 the TPM using a so-called Attestation Identity Key (AIK). An AIK has 3137 the properties that it cannot be exported from a TPM and is used for 3138 attestations. Trust in the AIK is established by an X.509 3139 Certificate emitted by a Certificate Authority. The AIK certificate 3140 is either provided directly or via a so-called PrivacyCA 3141 [AIK-Enrollment]. 3143 This element consists of the AIK certificate that includes the AIK's 3144 public key used during verification as well as the certificate chain 3145 up to the Root CA for validation of the AIK certificate itself. 3147 TUDA-Cert = [AIK-Cert, TSA-Cert]; maybe split into two for SNMP 3148 AIK-Certificate = X.509-Certificate(AIK-Key,Restricted-Flag) 3149 TSA-Certificate = X.509-Certificate(TSA-Key, TSA-Flag) 3151 Figure 15: TUDA-Cert element for TPM 2.0 3153 D.3.2. Synchronization Token 3155 The synchronization token uses a different TPM command, TPM2 3156 GetTime() instead of TPM TickStampBlob(). The TPM2 GetTime() command 3157 contains the clock and time information of the TPM. The clock 3158 information is the equivalent of TUDA v1's tickSession information. 3160 TUDA-SyncToken = [ 3161 left_GetTime = sig(AIK-Key, 3162 TimeInfo = [ 3163 time, 3164 resetCount, 3165 restartCount 3166 ] 3167 ), 3168 middle_TimeStamp = sig(TSA-Key, 3169 hash(left_TickStampBlob), 3170 UTC-localtime 3171 ), 3172 right_TickStampBlob = sig(AIK-Key, 3173 hash(middle_TimeStamp), 3174 TimeInfo = [ 3175 time, 3176 resetCount, 3177 restartCount 3178 ] 3179 ) 3180 ] 3182 Figure 16: TUDA-Sync element for TPM 2.0 3184 D.3.3. Measurement Log 3186 The creation procedure is identical to Appendix D.2.4. 3188 Measurement-Log = [ 3189 * [ EventName, 3190 PCR-Num, 3191 Event-Hash ] 3192 ] 3194 Figure 17: TUDA-Log element for TPM 2.0 3196 D.3.4. Explicit time-based Attestation 3198 The TUDA attestation token consists of the result of TPM2_Quote() or 3199 a set of TPM2_PCR_READ followed by a TPM2_GetSessionAuditDigest. It 3200 proves that -- at a certain point-in-time with respect to the TPM's 3201 internal clock -- a certain configuration of PCRs was present, as 3202 denoted in the keys restriction information. 3204 TUDA-AttestationToken = TUDA-AttestationToken_quote / TUDA-AttestationToken_audit 3206 TUDA-AttestationToken_quote = sig(AIK-Key, 3207 TimeInfo = [ 3208 time, 3209 resetCount, 3210 restartCount 3211 ], 3212 PCR-Selection = [ * PCR], 3213 PCR-Digest := PCRDigest 3214 ) 3216 TUDA-AttestationToken_audit = sig(AIK-key, 3217 TimeInfo = [ 3218 time, 3219 resetCount, 3220 restartCount 3221 ], 3222 Session-Digest := PCRDigest 3223 ) 3225 Figure 18: TUDA-Attest element for TPM 2.0 3227 D.3.5. Sync Proof 3229 In order to proof to the Verifier that the TPM's clock was not 'fast- 3230 forwarded' the result of a TPM2_GetTime() is sent after the TUDA- 3231 AttestationToken. 3233 TUDA-SyncProof = sig(AIK-Key, 3234 TimeInfo = [ 3235 time, 3236 resetCount, 3237 restartCount 3238 ] 3239 ), 3241 Figure 19: TUDA-Proof element for TPM 2.0 3243 Acknowledgements 3245 Authors' Addresses 3247 Andreas Fuchs 3248 Fraunhofer Institute for Secure Information Technology 3249 Rheinstrasse 75 3250 Darmstadt 64295 3251 Germany 3253 Email: andreas.fuchs@sit.fraunhofer.de 3255 Henk Birkholz 3256 Fraunhofer Institute for Secure Information Technology 3257 Rheinstrasse 75 3258 Darmstadt 64295 3259 Germany 3261 Email: henk.birkholz@sit.fraunhofer.de 3263 Ira E McDonald 3264 High North Inc 3265 PO Box 221 3266 Grand Marais 49839 3267 US 3269 Email: blueroofmusic@gmail.com 3271 Carsten Bormann 3272 Universitaet Bremen TZI 3273 Bibliothekstr. 1 3274 Bremen D-28359 3275 Germany 3277 Phone: +49-421-218-63921 3278 Email: cabo@tzi.org