idnits 2.17.1 draft-birkholz-rats-tuda-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (January 13, 2021) is 1200 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 3253, but not defined == Missing Reference: 'TSA-Cert' is mentioned on line 3253, but not defined == Unused Reference: 'RFC7519' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'RFC8639' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'RFC8640' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFC8641' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sacm-terminology' is defined on line 1002, but no explicit reference was found in the text == Unused Reference: 'IEEE802.11P' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: 'TEE' is defined on line 1099, 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-01 == Outdated reference: A later version (-03) exists of draft-birkholz-rats-uccs-02 == 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-08 == Outdated reference: A later version (-09) exists of draft-ietf-rats-reference-interaction-models-01 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-16 Summary: 6 errors (**), 0 flaws (~~), 16 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: July 17, 2021 I. McDonald 6 High North Inc 7 C. Bormann 8 Universitaet Bremen TZI 9 January 13, 2021 11 Time-Based Uni-Directional Attestation 12 draft-birkholz-rats-tuda-04 14 Abstract 16 This document defines the method and bindings used to convey Evidence 17 via Time-based Uni-Directional Attestation (TUDA) in Remote 18 ATtestation procedureS (RATS). TUDA does not require a challenge- 19 response handshake and thereby does not rely on the conveyance of a 20 nonce to prove freshness of remote attestation Evidence. TUDA 21 enables the creation of Secure Audit Logs that can constitute 22 believable Evidence about both current and past operational states of 23 an Attester. In TUDA, RATS entities require access to a Handle 24 Distributor to which a trustable and synchronized time-source is 25 available. The Handle Distributor takes on the role of a Time Stamp 26 Authority (TSA) to distribute Handles incorporating Time Stamp Tokens 27 (TST) to the RATS entities. RATS require an Attesting Environment 28 that generates believable Evidence. While a TPM is used as the 29 corresponding root of trust in this specification, any other type of 30 root of trust can be used with TUDA. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 17, 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Forward Authenticity . . . . . . . . . . . . . . . . . . 4 68 1.2. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 5 69 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Remote Attestation Principles . . . . . . . . . . . . . . . . 6 71 2.1. Authenticity of Evidence . . . . . . . . . . . . . . . . 6 72 2.2. Generating Evidence about Software Component Integrity . 7 73 2.3. Measurements and Digests Generated by an Attester . . . . 7 74 2.4. Attesting Environments and Roots of Trust . . . . . . . . 8 75 2.5. Indeterministic Measurements . . . . . . . . . . . . . . 9 76 3. TUDA Principles and Requirements . . . . . . . . . . . . . . 10 77 3.1. Attesting Environment Requirements . . . . . . . . . . . 11 78 3.2. Handle Distributor Requirements: Time Stamp Authority . . 11 79 4. Information Elements and Conveyance . . . . . . . . . . . . . 11 80 5. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 12 81 5.1. TPM Specific Terms . . . . . . . . . . . . . . . . . . . 13 82 5.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 13 83 6. The TUDA Protocol Family . . . . . . . . . . . . . . . . . . 14 84 6.1. TUDA Information Elements Update Cycles . . . . . . . . . 15 85 7. Sync Base Protocol . . . . . . . . . . . . . . . . . . . . . 18 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 88 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 91 11.2. Informative References . . . . . . . . . . . . . . . . . 21 92 Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 24 93 Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 24 94 B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 25 95 B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 25 96 B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 26 97 B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 26 98 B.2. Relationship to Host Resources MIB . . . . . . . . . . . 26 99 B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 26 100 B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 27 101 B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 27 102 Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 43 103 Appendix D. Realization with TPM functions . . . . . . . . . . . 59 104 D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 59 105 D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 59 106 D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 59 107 D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 60 108 D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 60 109 D.2. IE Generation Procedures for TPM 1.2 . . . . . . . . . . 60 110 D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 60 111 D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 61 112 D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 63 113 D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 65 114 D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 66 115 D.2.6. Attestation Verification Approach . . . . . . . . . . 67 116 D.3. IE Generation Procedures for TPM 2.0 . . . . . . . . . . 69 117 D.3.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 69 118 D.3.2. Synchronization Token . . . . . . . . . . . . . . . . 70 119 D.3.3. Measurement Log . . . . . . . . . . . . . . . . . . . 70 120 D.3.4. Explicit time-based Attestation . . . . . . . . . . . 71 121 D.3.5. Sync Proof . . . . . . . . . . . . . . . . . . . . . 71 122 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 72 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 125 1. Introduction 127 Remote ATtestation procedureS (RATS) describe the attempt to 128 determine and appraise system properties, such as integrity and 129 trustworthiness, of a remote peer - the Attester - by the use of a 130 Verifier in support of Relying Parties that intend to interact with 131 the Attester. The Verifier carries the burden of appraisal of 132 detailed Evidence about an Attester's trustworthiness. Evidence is 133 generated by the Attester and consumed by the Verifier. To support 134 security decisions, the Verifier generates digestable Attestation 135 Results that can be easily consumed by Relying Parties. The RATS 136 architecture specifies the corresponding concepts and terms 137 [I-D.ietf-rats-architecture]. 139 TUDA uses the architectural constituents of the RATS Architecture, 140 such as the roles Attester and Verifier, and defines a method to 141 convey Conceptual Messages between them. TUDA uses the Uni- 142 Directional Remote Attestation interaction model described in 143 [I-D.ietf-rats-reference-interaction-models]. While the Conceptual 144 Message focussed on in this document is RATS Evidence, any type of 145 Conceptual Message content that requires a believable indication 146 about the message's content freshness can be conveyed with TUDA (e.g. 147 Attestation Results). 149 The conveyance of Evidence in RATS must ensure that Evidence always 150 remains integrity protected, tamper-evident, originates from a 151 trustable entity (or group of entities), and is accompanied by a 152 proof of its freshness. 154 In contrast to bi-directional interactions as described by Challenge/ 155 Response Remote Attestation in 156 [I-D.ietf-rats-reference-interaction-models], TUDA enables uni- 157 directional conveyance in the interactions between Attester and 158 Verifier. TUDA allows a Verifier to receive Evidence from an 159 Attester without solicitation. Conversely, it allows a Verifier to 160 retrieve Evidence from an Attester without it being generated ad-hoc. 161 Exemplary applications of TUDA are the creation of beacons in 162 vehicular environments [IEEE1609] or authentication mechanisms based 163 on EAP [RFC5247]. 165 The generation of Evidence in RATS requires an Attesting Environment. 166 In this specification, the root of trust acting as an Attesting 167 Environment is a Trusted Platform Module (TPM, see [TPM12] and 168 [TPM2]). The Protected Capabilities [TCGGLOSS] provided by a TPM 169 support various activities in RATS, e.g., Claims collection and 170 Evidence generation. 172 A trusted coupling of Evidence generation with a global timescale is 173 enabled via a Handle Distributor. Handles generated by a Handle 174 Distributor can include nonces, signed timestamps, or other 175 structured or opaque content used as qualifying data in Evidence 176 generation. In TUDA, all RATS entities, such as the entities taking 177 on the roles of Attester and Verifier, can receive signed timestamps 178 from the Handle Distributor. These trusted timestamps replace nonces 179 in Evidence generation and Evidence appraisal 180 [I-D.ietf-rats-reference-interaction-models]. 182 1.1. Forward Authenticity 184 Nonces enable an implicit time-keeping in which the freshness of 185 Evidence is inferred by recentness. Recentness is estimated via the 186 time interval between sending a nonce as part of a challenge for 187 Evidence and the reception of Evidence based on that nonce (as 188 outlined in the interaction model depicted in section 8.1 in 189 [I-D.ietf-rats-reference-interaction-models]). Conversely, the 190 omission of nonces in TUDA allows for explicit time-keeping where 191 freshness is not inferred from recentness. Instead, a cryptographic 192 binding of a trusted synchronization to a global timescale in the 193 Evidence itself allows for Evidence that can prove past operational 194 states of an Attester. To capture and support this concept, this 195 document introduces the term Forward Authenticity. 197 Forward Authenticity: A property of secure communication protocols, 198 in which later compromise of the long-term keys of a data origin 199 does not compromise past authentication of data from that origin. 200 Forward Authenticity is achieved by timely recording of 201 authenticity Claims from Target Environments (via "audit logs" 202 during "audit sessions") that are authorized for this purpose and 203 trustworthy (via endorsed roots of trusts, for example), in a 204 time-frame much shorter than that expected for the compromise of 205 the long-term keys. 207 Forward Authenticity enables new levels of assurance and can be 208 included in basically every protocol, such as ssh, YANG Push, 209 router advertisements, link layer neighbor discovery, or even ICMP 210 echo requests. 212 1.2. TUDA Objectives 214 Time-Based Uni-directional Attestation is designed to: 216 o increase the confidence in authentication and authorization 217 procedures, 219 o address the requirements of constrained-node networks, 221 o support interaction models that do not maintain connection-state 222 over time, such as REST architectures [REST], 224 o be able to leverage existing management interfaces, such as SNMP 225 [RFC3411]. RESTCONF [RFC8040] or CoMI [I-D.ietf-core-comi] -- and 226 corresponding bindings, 228 o support broadcast and multicast schemes (e.g. [IEEE1609]), 230 o be able to cope with temporary loss of connectivity, and to 232 o provide trustworthy audit logs of past endpoint states. 234 1.3. Terminology 236 This document uses the terms defined in the RATS Architecture 237 [I-D.ietf-rats-architecture] and by the RATS Reference Interaction 238 Models [I-D.ietf-rats-reference-interaction-models]. 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 242 "OPTIONAL" in this document are to be interpreted as described in 243 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 244 capitals, as shown here. 246 2. Remote Attestation Principles 248 Based on the RATS Architecture, the processing of TPM generated 249 Evidence can be separated in three activities. 251 Evidence Generation: The retrieval of signed digests from an RTR 252 based on a sequence of collected Claims about software component 253 integrity (measurements). 255 Evidence Conveyance: The transfer of Evidence from the Attester to 256 the Verifier via the Internet. 258 Evidence Appraisal: The validation of Evidence signatures as well as 259 the assessment of Claim values in Evidence by comparing them with 260 Reference Values. 262 TUDA is specified in support of these RATS activities that align with 263 the definitions presented in [PRIRA] and [TCGGLOSS]. 265 2.1. Authenticity of Evidence 267 Remote attestation Evidence is composed of a set of Claims 268 (assertions about the trustworthiness of an Attester's Target 269 Environments) that is accompanied by a proof of its veracity - 270 typically a signature based on shielded, private, and potentially 271 use-restricted key material used as an Authentication Secret as 272 specified in section 6 of 273 [I-D.ietf-rats-reference-interaction-models] (or a secure channel as 274 illustrated in [I-D.birkholz-rats-uccs]). As key material alone is 275 typically not self-descriptive with respect to its intended use (its 276 semantics), the Evidence created via TUDA MUST be accompanied by two 277 kinds of certificates that are cryptographically associated with a 278 trust anchor (TA) [RFC4949] via certification paths: 280 o an Attestation Key (AK) Certificate (AK-Cert) that represents the 281 attestation provenance of the Attesting Environment (see section 282 4.2. in [I-D.ietf-rats-architecture]) that generates Evidence, and 284 o an Endorsement Key (EK) Certificate (EK-Cert) that represents the 285 Protection Capabilities of an Attesting Environment the AK is 286 stored in. 288 If a Verifier decides to trust the TA of both an AK-Cert and an EK- 289 Cert presented by an Attester - and thereby the included Claims about 290 the trustworthiness of an Attester's Target Environments - the 291 Evidence generated by the Attester can be considered trustable and 292 believable. Ultimately, all trustable and believable Evidence MUST 293 be appraised by a Verifier in order to assess the trustworthiness of 294 the corresponding Attester. Assertions represented via Claims MUST 295 NOT be considered believable by themselves. 297 In this document, Evidence is generated via TPMs that come with an 298 AK-Cert and a EK-Cert as a basis for believable Evidence generation. 300 2.2. Generating Evidence about Software Component Integrity 302 Evidence generated by a TPM for TUDA is based on measured hash values 303 of all software components deployed in Target Environments (see 304 section 4.2. in [I-D.ietf-rats-architecture]) before they are 305 executed ("measure then execute"). The underlying concept of 306 "Attestation Logs" is elaborated on in Section 2.4.2. of 307 [I-D.fedorkow-rats-network-device-attestation]. This concept is 308 implemented, for example, in the Linux kernel where it is called the 309 Linux Integrity Measurement Architecture (IMA) [Safford] and used to 310 generates such a sequence of hash values. A representation for 311 conveyance of corresponding event logs is described in the Canonical 312 Event Log [CEL] specification. Open source solutions, for example, 313 based on [RFC5209] use an IMA log to enable remote attestation 314 [Steffens]. 316 An Attester MUST generate such an event/measurement log. 318 2.3. Measurements and Digests Generated by an Attester 320 A hash value of a software component is created before it is executed 321 by Attesters. These hash values are typically represented as event 322 log entries referred to as measurements, which often occur in large 323 quantities. Capabilities such as Linux IMA can be used to generate 324 these measurements on an Attester. Measurements are chained by 325 Attesters using a rolling hash function. A TPM acts as a root of 326 trust for storage (RTS) by providing an Extend ([TPM12], [TPM2]) 327 operation to feed hash values in a rolling hash function. Each 328 measurement added to the sequence of all measurements results in a 329 new current digest hash value. A TPM acts as a root of trust for 330 reporting (RTR) by providing Quote ([TPM12], [TPM2]) operations to 331 generate a digest of all currently extended hash values as Evidence. 333 TUDA requirements on TPM primitive operations and the information 334 elements processed by them are illustrated using pseudo code in 335 Appendix C and D. 337 2.4. Attesting Environments and Roots of Trust 339 The primitive operations used to generate an initial set of 340 measurements at the beginning of an Attester's boot sequence MUST be 341 provided by a Root of Trust for Measurement (RTM) that is a system 342 component of the Attester. An RTM MUST be trusted via trust- 343 relationships to TAs enabled by appropriate Endorsements (e.g.,EK- 344 Certs). If a Verifier cannot trust an RTM, measurements based on 345 values generated by the RTM MUST be considered invalid. At least one 346 RTM MUST be accessible to the first Attesting Environment in Attester 347 conducting Layered Attestation (see section 4.3. in 348 [I-D.ietf-rats-architecture]). An RTM MAY aggregate and retain 349 measurements until the first RTS becomes available in a Layered 350 Attestation procedure - instead of feeding measurements into an RTS, 351 instantly. The Protection Capabilities of an RTM to also act as a 352 temporary RTS MUST be trusted via trust-relationships to TAs enabled 353 by appropriate Endorsements. System components supporting the use of 354 a TPM typically include such an appropriate RTM. In general, feeding 355 measurements from an initial RTM into a TPM is automated and 356 separated from Protected Capabilities that provide Claims collection 357 from Target Environments that are regular execution environments. A 358 TPM providing the Protection Capabilities for an isolated and 359 shielded location to feed measurements into (integrity and 360 confidentiality) is an appropriate RTS for TUDA. 362 The primitive operations used to store and chain measurements via a 363 rolling hash function MUST be provided by an appropriate root of 364 trust for storage (RTS) that is a system component of the Attester. 365 An RTS MUST be trusted via trust-relationships to TAs enabled by 366 appropriate Endorsements (e.g.,EK-Certs). If a Verifier cannot trust 367 an RTS, Evidence generated based on digest values acquired from the 368 RTS MUST be considered invalid. An RTS MUST be accessible to all 369 Attesting Environments that are chained in a Layered Attestation 370 procedure. A TPM providing the primitive operation for Extend is an 371 appropriate RTM for TUDA. 373 The primitive operations used to generate Evidence based on digests 374 MUST be provided by roots of trust for reporting (RTR) that are 375 system components of the Attester. An RTR MUST be be trusted via 376 trust-relationships to TAs enabled by appropriate Endorsements 377 (e.g.,EK-Certs). If a Verifier cannot trust an RTR, Evidence 378 generated by the RTR MUST be considered invalid. A TPM providing the 379 primitive operations for Quote is an appropriate RTR for TUDA. In a 380 Composite Device (see Section 3.5. in [I-D.ietf-rats-architecture] 381 conducting a Layered Attestation procedure, Attesting Environments 382 MAY not be TPMs. At least one Attesting Environment MUST be a TPM. 383 At least one TPM MUST act as an RTR. Attesting Environments that are 384 not TPMs MUST NOT act as an RTR. 386 A concise definition of the terms RTM, RTS, and RTR can be found in 387 the Trusted Computing Group (TCG) Glossary [TCGGLOSS]. An RTS and an 388 RTR are often tightly coupled. In TUDA, a Trusted Platform Module 389 (TPM, see [TPM12] and [TPM2]) takes on the roles of an RTS and an 390 RTR. The specification in this document requires the use of a TPM as 391 a component of the Attester. The protocol part of this specification 392 can also be used with other RTS and RTR as long as essential 393 functional requirements are satisfied (e.g., a trusted relative 394 source of time, such as a tick-counter). A sequence of Layered 395 Attestation using at least an RTM, RTS, and RTR enables an 396 authenticated boot sequence typically referred to as Secure Boot. 398 2.5. Indeterministic Measurements 400 The sequence of measurements that is extended into the RTS provided 401 by a TPM may not be deterministic due to race conditions that are 402 side-effects of parallelization. Parallelization occurs, for 403 example, between different isolated execution environments or 404 separate software components started in a execution environment. In 405 order to enable the appraisal of Evidence in cases where sequence of 406 measurement varies, a corresponding event log that records all 407 measurements in sequence, such as the IMA log, has to be conveyed 408 next to the Evidence as depicted in section 8.2. in 409 [I-D.ietf-rats-reference-interaction-models]. 411 In contrast to Evidence, event logs do not necessarily have to be 412 integrity protected or tamper-evident. Event logs are conveyed to a 413 Verifier in order to compute the reference values required for 414 comparison with digest values (output of TPM Quote operations). 415 While digest values MUST constitute Evidence, measurements in event 416 logs MAY be part of Evidence, but do not have to be MAY be conveyed 417 separately. If the values in event logs or their sequence are 418 tampered with before or during conveyance from an Attester to a 419 Verifier, the corresponding Evidence Appraisal fails. While this 420 dependency reflects the intended behavior of RATS, integrity 421 protected or tamper-evident can be beneficial or convenient in some 422 usage scenarios. Additionally, event logs my allow insights into the 423 composition of an Attester and typically come with confidentiality 424 requirements. 426 In order to compute reference values to compare digest Claims in 427 Evidence with, a Verifier MUST be able to replay the rolling hash 428 function of the Extend operation provided by a TPM (see 429 Section 2.4.2. in [I-D.fedorkow-rats-network-device-attestation]). 431 A Verifier has to replay the event log using its own extend operation 432 with an identical rolling hash function in order to generate 433 reference values as outlined in section 2.4.1. of 435 [I-D.fedorkow-rats-network-device-attestation]. During reply, the 436 validity of each event log record MUST be appraised individually by 437 the Verifier in order to infer if each started software component 438 satisfies integrity requirements. These appraisal procedures require 439 Reference Integrity Measurements/Manifests (RIM) as are provided via 440 [I-D.birkholz-rats-coswid-rim] or [TCGRIM]. Each RIM includes 441 Reference Values that are nominal reference hash values for sets of 442 software components. The Reference Values can be compared with hash 443 values about executed software components included in an event log. 444 A Verifier requires an appropriate set of RIMs to compare every 445 record in an event log successfully. RIMs or other sets Reverence 446 Value are supplied by Reference Value Providers as defined in the 447 RATS Architecture [I-D.ietf-rats-architecture]. Corresponding 448 procedures that enable a Verifier to acquire Reference Values are 449 out-of-scope of this document. 451 3. TUDA Principles and Requirements 453 Traditional remote attestation protocols typically use bi-directional 454 challenge/response interaction models. Examples include the Platform 455 Trust Service protocol [PTS] or CAVES [PRIRA], where one entity sends 456 a challenge that is included inside the response to prove the 457 freshness of Evidence via recentness. The corresponding interaction 458 model depicted in Section 8.1. of 459 [I-D.ietf-rats-reference-interaction-models] tightly couples the 460 three RATS activities of generating, conveying and appraising 461 Evidence. 463 Time-Based Uni-directional Attestation can decouple these three 464 activities. As a result, TUDA provides additional capabilities, such 465 as: 467 o remote attestation for Attesters that might not always be able to 468 reach the Internet by enabling the appraisal of past states, 470 o secure audit logs by combining the Evidence generated with 471 integrity measurement logs (e.g. IMA logs) that represent a 472 detailed record of corresponding past states, 474 o the use of the uni-directional interaction model 475 [I-D.ietf-rats-reference-interaction-models] that can traverse 476 "diode-like" network security functions (NSF) or can be leveraged 477 RESTful telemetry as enabled by the CoAP Observe option 478 [RFC7252]). 480 3.1. Attesting Environment Requirements 482 An Attesting Environment that generates Evidence in TUDA MUST support 483 three specific Protected Capabilities: 485 o Platform Configuration Registers (PCR) that can extend 486 measurements consecutively and represent the sequence of 487 measurements as a single digest, 489 o Restricted Signing Keys (RSK) that can only be accessed, if a 490 specific signature about a set of measurements can be provided as 491 authentication, and 493 o a dedicated source of (relative) time, e.g. a tick counter (a tick 494 being a specific time interval, for example 10 ms). 496 A TPM is capable of providing these Protected Capabilities for TUDA. 498 3.2. Handle Distributor Requirements: Time Stamp Authority 500 Both Evidence generation and Evidence appraisal require a Handle 501 Distributor that can take on the role of a trusted Time Stamp 502 Authority (TSA) as an additional third party. Time Stamp Tokens 503 (TST) included in Handles MUST be generated by Time Stamp Authority 504 based on [RFC3161] that acts as the Handle Distributor. The 505 combination of a local source of time provided by a TPM (on the 506 Attester) and the TST provided by the Handle Distributor (to both the 507 Attester and the Verifier) enable an appropriate proof of freshness. 509 4. Information Elements and Conveyance 511 TUDA defines a set of information elements (IE) that represent a set 512 of Claims, are generated and stored on the Attester, and are intended 513 to be transferred to the Verifier in order to enable the appraisal of 514 Evidence. Each TUDA IE: 516 o MUST be encoded in the Concise Binary Object Representation (CBOR 517 [RFC7049]) to minimize the volume of data in motion. In this 518 document, the composition of the CBOR data items that represent IE 519 is described using the Concise Data Definition Language, CDDL 520 [RFC8610] 522 o that requires a certain freshness SHOULD only be re-generated when 523 out-dated (not fresh, but stale), which reduces the overall 524 resources required from the Attester, including the usage of a 525 TPM's resources (re-generation of IE is determined by their age or 526 by specific state changes on the Attester, e.g., due to a reboot- 527 cycle) 529 o SHOULD only be transferred when required, which reduces the amount 530 of data in motion necessary to conduct remote attestation 531 significantly (only IE that have changed since their last 532 conveyance have to be transferred) 534 o that requires a certain freshness SHOULD be reused for multiple 535 remote attestation procedures in the limits of its corresponding 536 freshness-window, further reducing the load imposed on the 537 Attester and corresponding TPMs. 539 5. TUDA Core Concept 541 Traditional Challenge/Response Remote Attestation 542 [I-D.ietf-rats-reference-interaction-models] includes sending a nonce 543 in the challenge to be used in ad-hoc Evidence generation. Using the 544 TPM 1.2 as an example, a corresponding nonce-challenge would be 545 included within the signature created by the TPM_Quote command in 546 order to prove the freshness of a response containing evidence, see 547 e.g. [PTS]. 549 In contrast, the TUDA protocol uses the combined output of 550 TPM_CertifyInfo and TPM_TickStampBlob. The former provides a proof 551 about the Attester's state by creating Evidence that a certain key is 552 bound to that state. The latter provides proof that the Attester was 553 in the specified state by using the bound key in a time operation. 554 This combination enables a time-based attestation scheme. The 555 approach is based on the concepts introduced in [SCALE] and 556 [SFKE2008]. 558 Each TUDA IE has an individual time-frame, in which it is considered 559 to be fresh (and therefore valid and trustworthy). In consequence, 560 each TUDA IE that composes data in motion is based on different 561 methods of creation. 563 As highlighted above, the freshness properties of a challenge- 564 response based protocol enable implicit time-keeping via a time 565 window between: 567 o the time of transmission of the nonce, and 569 o the reception of the corresponding response. 571 Given the time-based attestation scheme, the freshness property of 572 TUDA is equivalent to that of bi-directional challenge response 573 attestation, if the point-in-time of attestation lies between: 575 o the transmission of a TUDA time-synchronization token, and 576 o the typical round-trip time between the Verifier and the Attester. 578 The accuracy of this time-frame is defined by two factors: 580 o the time-synchronization between the Attester and the Handle 581 Distributor. The time between the two tickstamps acquired via the 582 RoT define the scope of the maximum drift (time "left" and time 583 "right" in respect to the timeline) to the handle including the 584 signed timestamp, and 586 o the drift of clocks included in the RoT. 588 Since the conveyance of TUDA Evidence does not rely upon a Verifier 589 provided value (i.e. the nonce), the security guarantees of the 590 protocol only incorporate the Handle Distributor and the RoT used. 591 In consequence, TUDA Evidence can even serve as proof of integrity in 592 audit logs with precise point-in-time guarantees. 594 Appendix A contains guidance on how to utilize a REST architecture. 596 Appendix B contains guidance on how to create an SNMP binding and a 597 corresponding TUDA-MIB. 599 Appendix C contains a corresponding YANG module that supports both 600 RESTCONF and CoREDONF. 602 Appendix D.2 contains a realization of TUDA using TPM 1.2 primitives. 604 Appendix D.3 contains a realization of TUDA using TPM 2.0 primitives. 606 5.1. TPM Specific Terms 608 PCR: A Platform Configuration Register that is part of the TPM and 609 is used to securely store and report measurements about security 610 posture 612 PCR-Hash: A hash value of the security posture measurements stored 613 in a TPM PCR (e.g. regarding running software instances) 614 represented as a byte-string 616 5.2. Certificates 618 HD-CA: The Certificate Authority that provides the certificate for 619 the TSA role of a Handle Distributor (HD) 621 AIK-CA: The Certificate Authority that provides the certificate for 622 the AK of the TPM. This is the client platform credential for 623 this protocol. It is a placeholder for a specific CA and AK-Cert 624 is a placeholder for the corresponding certificate, depending on 625 what protocol was used. The specific protocols are out of scope 626 for this document, see also [AIK-Enrollment] and [IEEE802.1AR]. 628 6. The TUDA Protocol Family 630 Time-Based Uni-Directional Attestation consists of the following 631 seven information elements: 633 Handle Distributor Certificate: The certificate of the Handle 634 Distributor that takes on the role of TSA. The Handle Distributor 635 certificate is used in a subsequent synchronization protocol 636 tokens. This certificate is signed by the HD-CA. 638 AK Certificate: A certificate about the Attestation Key (AIK) used. 639 An AK-Cert may be an [IEEE802.1AR] IDevID or LDevID, depending on 640 their setting of the corresponding identity property 641 ([AIK-Credential], [AIK-Enrollment]; see Appendix D.2.1). 643 Synchronization Token: The reference frame for Evidence is provided 644 by the relative timestanps generated by the TPM. In order to put 645 Evidence into relation with a Real Time Clock (RTC), it is 646 necessary to provide a cryptographic synchronization between these 647 trusted relative timestamps and the regular RTC that is a hardware 648 component of the Attester. To do so, trustable timesamps are 649 acquired from a Handle Distributor. 651 Restriction Info: Evidence Generation relies on the capability of 652 the Rot to operate on restricted keys. Whenever the PCR values of 653 an Attesting Environment change, a new restricted key is created 654 that can only be operated as long as the PCRs remain in their 655 current state. 657 In order to prove to the Verifier that this restricted temporary 658 key actually has these properties and also to provide the PCR 659 value that it is restricted, the corresponding signing 660 capabilities of the RoT are used. The TPM creates a signed 661 certificate using the AK about the newly created restricted key. 663 Measurement Log: A Verifier requires the means to derive the PCRs' 664 values in order to appraise the trustworthiness of an Attester. 665 As such, a list of those elements that were extended into the PCRs 666 is reported. For certain environments, this step may be optional 667 if a list of valid PCR configurations (in the form of RIM 668 available to the Verifier) exists and no measurement log is 669 required. 671 Implicit Evidence: The actual Evidence is then based on a signed 672 timestamp provided by the RoT using the restricted temporary key 673 that was certified in the steps above. The signed timestamp 674 generated provides the trustable assertion that at this point in 675 time (with respect to the relative time of the TPM s tick counter) 676 a certain configuration existed (namely the PCR values associated 677 with the restricted key). In combination with the synchronization 678 token this timestamp represented in relative time can then be 679 related to the real-time clock. 681 Concise SWID tags: As an option to better assess the trustworthiness 682 of an Attester, a Verifier can request the reference hashes (RIM, 683 sometimes called golden measurements, known-good-values, or 684 nominal values) of all started software components to compare them 685 with the entries in a measurement log. References hashes 686 regarding installed (and therefore running) software can be 687 provided by the manufacturer via SWID tags. SWID tags are 688 provided by the Attester using the Concise SWID representation 689 [I-D.ietf-sacm-coswid] and bundled into a collection (a RIM 690 Manifest [I-D.birkholz-rats-coswid-rim]). 692 These information elements can be sent en bloc, but it is recommended 693 to retrieve them separately to save bandwidth, since these elements 694 have different update cycles. In most cases, retransmitting all 695 seven information elements would result in unnecessary redundancy. 697 Furthermore, in some scenarios it might be feasible not to store all 698 elements on the Attester, but instead they could be retrieved from 699 another location or be pre-deployed to the Verifier. It is also 700 feasible to only store public keys on the Verifier and skip 701 certificate provisioning completely in order to save bandwidth and 702 computation time for certificate verification. 704 6.1. TUDA Information Elements Update Cycles 706 An Attester can be in various states during its uptime cycles. For 707 TUDA, a subset of these states (which imply associated information) 708 are important to the Evidence Generation. The specific states 709 defined are: 711 o persistent, even after a hard reboot: includes certificates that 712 are associated with the endpoint itself or with services it relies 713 on. 715 o volatile to a degree: may change at the beginning of each boot 716 cycle. This includes the capability of a TPM to provide relative 717 time which provides the basis for the synchronization token and 718 implicit attestation - and which can reset after an Attester is 719 powered off. 721 o very volatile: can change during any time of an uptime cycle 722 (periods of time an Attester is powered on, starting with its boot 723 sequence). This includes the content of PCRs of a hardware RoT 724 and thereby also the PCR-restricted signing keys used for 725 attestation. 727 Depending on this "lifetime of state", data has to be transported 728 over the wire, or not. E.g. information that does not change due to 729 a reboot typically has to be transported only once between the 730 Attester and the Verifier. 732 There are three kinds of events that require fresh Evidence to be 733 generated: 735 o The Attester completes a boot-cycle 737 o A relevant PCR changes 739 o Too much time has passed since the Evidence Generation 741 The third event listed above is variable per application use case and 742 also depends on the precision of the clock included in the RoT. For 743 usage scenarios, in which the Attester would periodically push 744 information to be used in an audit-log, a time-frame of approximately 745 one update per minute should be sufficient. For those usage 746 scenarios, where Verifiers request (pull) fresh Evidence, an 747 implementation could potentially use a TPM continuously to always 748 present the most freshly created Evidence. This kind of utilization 749 can result in a bottle-neck with respect to other purposes: if 750 unavoidable, a periodic interval of once per ten seconds is 751 recommended, which typically leaves about 80% of available TPM 752 resource for other applications. 754 The following diagram is based on the reference interaction model 755 found in section 8.1. of [I-D.ietf-rats-reference-interaction-models] 756 and is enriched with the IE update cycles defined in this section. 758 .----------. .----------. 759 | Attester | | Verifier | 760 '----------' '----------' 761 | | 762 boot | 763 | | 764 valueGeneration(targetEnvironment) | 765 | => claims | 766 | .--------------------. | 767 | <----------handle | | | 768 | | Handle Distributor | | 769 | | | handle----------> | 770 | '--------------------' | 771 syncTokenGeneration | 772 | => syncToken | 773 | | 774 restrictedKeyGeneration | 775 restrictedKeyCertify | 776 | | 777 evidenceGeneration(handle, authSecIDs, collectedClaims) | 778 | => evidence | 779 | | 780 | pushAKCert ----------------------------------------------> | 781 | pushSyncToken -------------------------------------------> | 782 | pushCertifyInfo -----------------------------------------> | 783 | pushEventLog --------------------------------------------> | 784 | pushEvidenceon ------------------------------------------> | 785 | | 786 | evidenceAppraisal(evidence, eventLog, refClaims) 787 | attestationResult <= | 788 ~ ~ 789 pcr-change | 790 | | 791 restrictedKeyGeneration | 792 restrictedKeyCertify | 793 | | 794 evidenceGeneration(handle, authSecIDs, collectedClaims) | 795 | => evidence | 796 | | 797 | pushCertifyInfo -----------------------------------------> | 798 | pushEventLog --------------------------------------------> | 799 | pushEvidenceon ------------------------------------------> | 800 | | 801 | evidenceAppraisal(evidence, eventLog, refClaims) 802 | attestationResult <= | 803 | | 805 Figure 1: Example sequence of events 807 7. Sync Base Protocol 809 The uni-directional approach of TUDA requires evidence on how the TPM 810 time represented in ticks (relative time since boot of the TPM) 811 relates to the standard time provided by the TSA. The Sync Base 812 Protocol (SBP) creates evidence that binds the TPM tick time to the 813 TSA timestamp. The binding information is used by and conveyed via 814 the Sync Token (TUDA IE). There are three actions required to create 815 the content of a Sync Token: 817 o At a given point in time (called "left"), a signed tickstamp 818 counter value is acquired from the hardware RoT. The hash of 819 counter and signature is used as a nonce in the request directed 820 at the TSA. 822 o The corresponding response includes a data-structure incorporating 823 the trusted timestamp token and its signature created by the TSA. 825 o At the point-in-time the response arrives (called "right"), a 826 signed tickstamp counter value is acquired from the hardware RoT 827 again, using a hash of the signed TSA timestamp as a nonce. 829 The three time-related values -- the relative timestamps provided by 830 the hardware RoT ("left" and "right") and the TSA timestamp -- and 831 their corresponding signatures are aggregated in order to create a 832 corresponding Sync Token to be used as a TUDA Information Element 833 that can be conveyed as evidence to a Verifier. 835 The drift of a clock incorporated in the hardware RoT that drives the 836 increments of the tick counter constitutes one of the triggers that 837 can initiate a TUDA Information Element Update Cycle in respect to 838 the freshness of the available Sync Token. 840 8. IANA Considerations 842 This memo includes requests to IANA, including registrations for 843 media type definitions. 845 TBD 847 9. Security Considerations 849 There are Security Considerations. TBD 851 10. Contributors 853 TBD 855 11. References 857 11.1. Normative References 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, 861 DOI 10.17487/RFC2119, March 1997, 862 . 864 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 865 "Internet X.509 Public Key Infrastructure Time-Stamp 866 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 867 2001, . 869 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 870 Architecture for Describing Simple Network Management 871 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 872 DOI 10.17487/RFC3411, December 2002, 873 . 875 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 876 Tardo, "Network Endpoint Assessment (NEA): Overview and 877 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 878 . 880 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 881 Authentication Protocol (EAP) Key Management Framework", 882 RFC 5247, DOI 10.17487/RFC5247, August 2008, 883 . 885 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 886 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 887 . 889 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 890 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 891 October 2013, . 893 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 894 Protocol (HTTP/1.1): Message Syntax and Routing", 895 RFC 7230, DOI 10.17487/RFC7230, June 2014, 896 . 898 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 899 Application Protocol (CoAP)", RFC 7252, 900 DOI 10.17487/RFC7252, June 2014, 901 . 903 [RFC7320] Nottingham, M., "URI Design and Ownership", RFC 7320, 904 DOI 10.17487/RFC7320, July 2014, 905 . 907 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 908 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 909 . 911 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 912 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 913 DOI 10.17487/RFC7540, May 2015, 914 . 916 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 917 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 918 . 920 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 921 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 922 May 2017, . 924 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 925 Definition Language (CDDL): A Notational Convention to 926 Express Concise Binary Object Representation (CBOR) and 927 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 928 June 2019, . 930 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 931 E., and A. Tripathy, "Subscription to YANG Notifications", 932 RFC 8639, DOI 10.17487/RFC8639, September 2019, 933 . 935 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 936 E., and A. Tripathy, "Dynamic Subscription to YANG Events 937 and Datastores over NETCONF", RFC 8640, 938 DOI 10.17487/RFC8640, September 2019, 939 . 941 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 942 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 943 September 2019, . 945 11.2. Informative References 947 [AIK-Credential] 948 TCG Infrastructure Working Group, "TCG Credential 949 Profile", 2007, . 952 [AIK-Enrollment] 953 TCG Infrastructure Working Group, "A CMC Profile for AIK 954 Certificate Enrollment", 2011, 955 . 958 [CEL] TCG TNC Working Group, "DRAFT Canonical Event Log Format 959 Version: 1.0, Revision: .12", 2018. 961 [I-D.birkholz-rats-coswid-rim] 962 Birkholz, H., Uiterwijk, P., Smith, N., Fitzgerald-McKay, 963 J., Waltermire, D., and S. Bhandari, "Reference Integrity 964 Measurement Extension for Concise Software Identities", 965 draft-birkholz-rats-coswid-rim-01 (work in progress), July 966 2020. 968 [I-D.birkholz-rats-uccs] 969 Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. 970 Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", 971 draft-birkholz-rats-uccs-02 (work in progress), December 972 2020. 974 [I-D.fedorkow-rats-network-device-attestation] 975 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 976 based Network Device Remote Integrity Verification", 977 draft-fedorkow-rats-network-device-attestation-05 (work in 978 progress), April 2020. 980 [I-D.ietf-core-comi] 981 Veillette, M., Stok, P., Pelov, A., Bierman, A., and I. 982 Petrov, "CoAP Management Interface (CORECONF)", draft- 983 ietf-core-comi-10 (work in progress), July 2020. 985 [I-D.ietf-rats-architecture] 986 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 987 W. Pan, "Remote Attestation Procedures Architecture", 988 draft-ietf-rats-architecture-08 (work in progress), 989 December 2020. 991 [I-D.ietf-rats-reference-interaction-models] 992 Birkholz, H., Eckel, M., Newton, C., and L. Chen, 993 "Reference Interaction Models for Remote Attestation 994 Procedures", draft-ietf-rats-reference-interaction- 995 models-01 (work in progress), October 2020. 997 [I-D.ietf-sacm-coswid] 998 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 999 Waltermire, "Concise Software Identification Tags", draft- 1000 ietf-sacm-coswid-16 (work in progress), November 2020. 1002 [I-D.ietf-sacm-terminology] 1003 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 1004 A. Montville, "Security Automation and Continuous 1005 Monitoring (SACM) Terminology", draft-ietf-sacm- 1006 terminology-16 (work in progress), December 2018. 1008 [IEEE1609] 1009 IEEE Computer Society, "1609.4-2016 - IEEE Standard for 1010 Wireless Access in Vehicular Environments (WAVE) -- Multi- 1011 Channel Operation", IEEE Std 1609.4, 2016. 1013 [IEEE802.11P] 1014 IEEE Computer Society, "802.11P-2010 - IEEE Standard for 1015 Information technology-- Local and metropolitan area 1016 networks-- Specific requirements-- Part 11: Wireless LAN 1017 Medium Access Control (MAC) and Physical Layer (PHY) 1018 Specifications Amendment 6: Wireless Access in Vehicular 1019 Environments", IEEE Std 802.11P, 2010. 1021 [IEEE802.1AR] 1022 IEEE Computer Society, "802.1AR-2009 - IEEE Standard for 1023 Local and metropolitan area networks - Secure Device 1024 Identity", IEEE Std 802.1AR, 2009. 1026 [PRIRA] Coker, G., Guttman, J., Loscocco, P., Herzog, A., Millen, 1027 J., O'Hanlon, B., Ramsdell, J., Segall, A., Sheehy, J., 1028 and B. Sniffen, "Principles of Remote Attestation", 1029 Springer International Journal of Information Security, 1030 Vol. 10, pp. 63-81, DOI 10.1007/s10207-011-0124-7, April 1031 2011. 1033 [PTS] TCG TNC Working Group, "TCG Attestation PTS Protocol 1034 Binding to TNC IF-M", 2011, 1035 . 1038 [REST] Fielding, R., "Architectural Styles and the Design of 1039 Network-based Software Architectures", Ph.D. Dissertation, 1040 University of California, Irvine, 2000, 1041 . 1044 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1045 for Network Management of TCP/IP-based internets: MIB-II", 1046 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 1047 . 1049 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", 1050 RFC 2790, DOI 10.17487/RFC2790, March 2000, 1051 . 1053 [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for 1054 the Simple Network Management Protocol (SNMP)", STD 62, 1055 RFC 3418, DOI 10.17487/RFC3418, December 2002, 1056 . 1058 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1059 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1060 . 1062 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1063 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1064 DOI 10.17487/RFC6933, May 2013, 1065 . 1067 [Safford] Safford, D., Zohar, M., and R. Sailer, "Using IMA for 1068 Integrity Measurement and Attestation", Linux Plumbers 1069 Conference 2009 , 2009. 1071 [SCALE] Fuchs, A., "Improving Scalability for Remote Attestation", 1072 Master Thesis (Diplomarbeit), Technische Universitaet 1073 Darmstadt, Germany, 2008. 1075 [SFKE2008] 1076 Stumpf, F., Fuchs, A., Katzenbeisser, S., and C. Eckert, 1077 "Improving the scalability of platform attestation", 1078 ACM Proceedings of the 3rd ACM workshop on Scalable 1079 trusted computing - STC '08 , page 1-10, 1080 DOI 10.1145/1456455.1456457, 2008. 1082 [STD62] "Internet Standard 62", STD 62, RFCs 3411 to 3418, 1083 December 2002. 1085 [Steffens] 1086 Steffen, A., "The linux Integrity Measurement Architecture 1087 and TPM-based Network Endpoint Assessment", Linux Security 1088 Summit , 2012. 1090 [TCGGLOSS] 1091 TCG, "TCG Glossary", 2012, 1092 . 1095 [TCGRIM] TCG, "TCG Reference Integrity Manifest (RIM) Information 1096 Model", 2019, . 1099 [TEE] Global Platform, "TEE System Architecture v1.1, 1100 GPD_SPE_009", 2017. 1102 [TPM12] "Information technology -- Trusted Platform Module -- Part 1103 1: Overview", ISO/IEC 11889-1, 2009. 1105 [TPM2] Trusted Computing Group, "Trusted Platform Module Library 1106 Specification, Family 2.0, Level 00, Revision 01.16 ed.", 1107 2014. 1109 Appendix A. REST Realization 1111 Each of the seven data items is defined as a media type (Section 8). 1112 Representations of resources for each of these media types can be 1113 retrieved from URIs that are defined by the respective servers 1114 [RFC7320]. As can be derived from the URI, the actual retrieval is 1115 via one of the HTTPs ([RFC7230], [RFC7540]) or CoAP [RFC7252]. How a 1116 client obtains these URIs is dependent on the application; e.g., CoRE 1117 Web links [RFC6690] can be used to obtain the relevant URIs from the 1118 self-description of a server, or they could be prescribed by a 1119 RESTCONF data model [RFC8040]. 1121 Appendix B. SNMP Realization 1123 SNMPv3 [STD62] [RFC3411] is widely available on computers and also 1124 constrained devices. To transport the TUDA information elements, an 1125 SNMP MIB is defined below which encodes each of the seven TUDA 1126 information elements into a table. Each row in a table contains a 1127 single read-only columnar SNMP object of datatype OCTET-STRING. The 1128 values of a set of rows in each table can be concatenated to 1129 reconstitute a CBOR-encoded TUDA information element. The Verifier 1130 can retrieve the values for each CBOR fragment by using SNMP GetNext 1131 requests to "walk" each table and can decode each of the CBOR-encoded 1132 data items based on the corresponding CDDL [RFC8610] definition. 1134 Design Principles: 1136 1. Over time, TUDA attestation values age and should no longer be 1137 used. Every table in the TUDA MIB has a primary index with the 1138 value of a separate scalar cycle counter object that 1139 disambiguates the transition from one attestation cycle to the 1140 next. 1142 2. Over time, the measurement log information (for example) may grow 1143 large. Therefore, read-only cycle counter scalar objects in all 1144 TUDA MIB object groups facilitate more efficient access with SNMP 1145 GetNext requests. 1147 3. Notifications are supported by an SNMP trap definition with all 1148 of the cycle counters as bindings, to alert a Verifier that a new 1149 attestation cycle has occurred (e.g., synchronization data, 1150 measurement log, etc. have been updated by adding new rows and 1151 possibly deleting old rows). 1153 B.1. Structure of TUDA MIB 1155 The following table summarizes the object groups, tables and their 1156 indexes, and conformance requirements for the TUDA MIB: 1158 |-------------|-------|----------|----------|----------| 1159 | Group/Table | Cycle | Instance | Fragment | Required | 1160 |-------------|-------|----------|----------|----------| 1161 | General | | | | x | 1162 | AIKCert | x | x | x | | 1163 | TSACert | x | x | x | | 1164 | SyncToken | x | | x | x | 1165 | Restrict | x | | | x | 1166 | Measure | x | x | | | 1167 | VerifyToken | x | | | x | 1168 | SWIDTag | x | x | x | | 1169 |-------------|-------|----------|----------|----------| 1171 B.1.1. Cycle Index 1173 A tudaV1CycleIndex is the: 1175 1. first index of a row (element instance or element fragment) in 1176 the tudaV1Table; 1178 2. identifier of an update cycle on the table, when rows were added 1179 and/or deleted from the table (bounded by tudaV1Cycles); 1180 and 1182 3. binding in the tudaV1TrapV2Cycles notification for directed 1183 polling. 1185 B.1.2. Instance Index 1187 A tudaV1InstanceIndex is the: 1189 1. second index of a row (element instance or element fragment) in 1190 the tudaV1Table; except for 1192 2. a row in the tudaV1SyncTokenTable (that has only one instance per 1193 cycle). 1195 B.1.3. Fragment Index 1197 A tudaV1FragmentIndex is the: 1199 1. last index of a row (always an element fragment) in the 1200 tudaV1Table; and 1202 2. accomodation for SNMP transport mapping restrictions for large 1203 string elements that require fragmentation. 1205 B.2. Relationship to Host Resources MIB 1207 The General group in the TUDA MIB is analogous to the System group in 1208 the Host Resources MIB [RFC2790] and provides context information for 1209 the TUDA attestation process. 1211 The Verify Token group in the TUDA MIB is analogous to the Device 1212 group in the Host MIB and represents the verifiable state of a TPM 1213 device and its associated system. 1215 The SWID Tag group (containing a Concise SWID reference hash profile 1216 [I-D.ietf-sacm-coswid]) in the TUDA MIB is analogous to the Software 1217 Installed and Software Running groups in the Host Resources MIB 1218 [RFC2790]. 1220 B.3. Relationship to Entity MIB 1222 The General group in the TUDA MIB is analogous to the Entity General 1223 group in the Entity MIB v4 [RFC6933] and provides context information 1224 for the TUDA attestation process. 1226 The SWID Tag group in the TUDA MIB is analogous to the Entity Logical 1227 group in the Entity MIB v4 [RFC6933]. 1229 B.4. Relationship to Other MIBs 1231 The General group in the TUDA MIB is analogous to the System group in 1232 MIB-II [RFC1213] and the System group in the SNMPv2 MIB [RFC3418] and 1233 provides context information for the TUDA attestation process. 1235 B.5. Definition of TUDA MIB 1237 1238 TUDA-V1-ATTESTATION-MIB DEFINITIONS ::= BEGIN 1240 IMPORTS 1241 MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, 1242 enterprises, NOTIFICATION-TYPE 1243 FROM SNMPv2-SMI -- RFC 2578 1244 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 1245 FROM SNMPv2-CONF -- RFC 2580 1246 SnmpAdminString 1247 FROM SNMP-FRAMEWORK-MIB; -- RFC 3411 1249 tudaV1MIB MODULE-IDENTITY 1250 LAST-UPDATED "202101130000Z" -- 13 January 2021 1251 ORGANIZATION 1252 "Fraunhofer SIT" 1253 CONTACT-INFO 1254 "Andreas Fuchs 1255 Fraunhofer Institute for Secure Information Technology 1256 Email: andreas.fuchs@sit.fraunhofer.de 1258 Henk Birkholz 1259 Fraunhofer Institute for Secure Information Technology 1260 Email: henk.birkholz@sit.fraunhofer.de 1262 Ira E McDonald 1263 High North Inc 1264 Email: blueroofmusic@gmail.com 1266 Carsten Bormann 1267 Universitaet Bremen TZI 1268 Email: cabo@tzi.org" 1270 DESCRIPTION 1271 "The MIB module for monitoring of time-based unidirectional 1272 attestation information from a network endpoint system, 1273 based on the Trusted Computing Group TPM 1.2 definition. 1275 Copyright (C) High North Inc (2021)." 1277 REVISION "202101130000Z" -- 13 January 2021 1278 DESCRIPTION 1279 "Twelfth version, published as draft-birkholz-rats-tuda-04." 1281 REVISION "202007130000Z" -- 13 July 2020 1282 DESCRIPTION 1283 "Eleventh version, published as draft-birkholz-rats-tuda-03." 1285 REVISION "202003090000Z" -- 09 March 2020 1286 DESCRIPTION 1287 "Tenth version, published as draft-birkholz-rats-tuda-02." 1289 REVISION "201909110000Z" -- 11 September 2019 1290 DESCRIPTION 1291 "Ninth version, published as draft-birkholz-rats-tuda-01." 1293 REVISION "201903120000Z" -- 12 March 2019 1294 DESCRIPTION 1295 "Eighth version, published as draft-birkholz-rats-tuda-00." 1297 REVISION "201805030000Z" -- 03 May 2018 1298 DESCRIPTION 1299 "Seventh version, published as draft-birkholz-i2nsf-tuda-03." 1301 REVISION "201805020000Z" -- 02 May 2018 1302 DESCRIPTION 1303 "Sixth version, published as draft-birkholz-i2nsf-tuda-02." 1305 REVISION "201710300000Z" -- 30 October 2017 1306 DESCRIPTION 1307 "Fifth version, published as draft-birkholz-i2nsf-tuda-01." 1309 REVISION "201701090000Z" -- 09 January 2017 1310 DESCRIPTION 1311 "Fourth version, published as draft-birkholz-i2nsf-tuda-00." 1313 REVISION "201607080000Z" -- 08 July 2016 1314 DESCRIPTION 1315 "Third version, published as draft-birkholz-tuda-02." 1317 REVISION "201603210000Z" -- 21 March 2016 1318 DESCRIPTION 1319 "Second version, published as draft-birkholz-tuda-01." 1321 REVISION "201510180000Z" -- 18 October 2015 1322 DESCRIPTION 1323 "Initial version, published as draft-birkholz-tuda-00." 1324 ::= { enterprises fraunhofersit(21616) mibs(1) tudaV1MIB(1) } 1326 tudaV1MIBNotifications OBJECT IDENTIFIER ::= { tudaV1MIB 0 } 1327 tudaV1MIBObjects OBJECT IDENTIFIER ::= { tudaV1MIB 1 } 1328 tudaV1MIBConformance OBJECT IDENTIFIER ::= { tudaV1MIB 2 } 1330 -- 1331 -- General 1332 -- 1333 tudaV1General OBJECT IDENTIFIER ::= { tudaV1MIBObjects 1 } 1335 tudaV1GeneralCycles OBJECT-TYPE 1336 SYNTAX Counter32 1337 MAX-ACCESS read-only 1338 STATUS current 1339 DESCRIPTION 1340 "Count of TUDA update cycles that have occurred, i.e., 1341 sum of all the individual group cycle counters. 1343 DEFVAL intentionally omitted - counter object." 1344 ::= { tudaV1General 1 } 1346 tudaV1GeneralVersionInfo OBJECT-TYPE 1347 SYNTAX SnmpAdminString (SIZE(0..255)) 1348 MAX-ACCESS read-only 1349 STATUS current 1350 DESCRIPTION 1351 "Version information for TUDA MIB, e.g., specific release 1352 version of TPM 1.2 base specification and release version 1353 of TPM 1.2 errata specification and manufacturer and model 1354 TPM module itself." 1355 DEFVAL { "" } 1356 ::= { tudaV1General 2 } 1358 -- 1359 -- AIK Cert 1360 -- 1361 tudaV1AIKCert OBJECT IDENTIFIER ::= { tudaV1MIBObjects 2 } 1363 tudaV1AIKCertCycles OBJECT-TYPE 1364 SYNTAX Counter32 1365 MAX-ACCESS read-only 1366 STATUS current 1367 DESCRIPTION 1368 "Count of AIK Certificate chain update cycles that have 1369 occurred. 1371 DEFVAL intentionally omitted - counter object." 1373 ::= { tudaV1AIKCert 1 } 1375 tudaV1AIKCertTable OBJECT-TYPE 1376 SYNTAX SEQUENCE OF TudaV1AIKCertEntry 1377 MAX-ACCESS not-accessible 1378 STATUS current 1379 DESCRIPTION 1380 "A table of fragments of AIK Certificate data." 1381 ::= { tudaV1AIKCert 2 } 1383 tudaV1AIKCertEntry OBJECT-TYPE 1384 SYNTAX TudaV1AIKCertEntry 1385 MAX-ACCESS not-accessible 1386 STATUS current 1387 DESCRIPTION 1388 "An entry for one fragment of AIK Certificate data." 1389 INDEX { tudaV1AIKCertCycleIndex, 1390 tudaV1AIKCertInstanceIndex, 1391 tudaV1AIKCertFragmentIndex } 1392 ::= { tudaV1AIKCertTable 1 } 1394 TudaV1AIKCertEntry ::= 1395 SEQUENCE { 1396 tudaV1AIKCertCycleIndex Integer32, 1397 tudaV1AIKCertInstanceIndex Integer32, 1398 tudaV1AIKCertFragmentIndex Integer32, 1399 tudaV1AIKCertData OCTET STRING 1400 } 1402 tudaV1AIKCertCycleIndex OBJECT-TYPE 1403 SYNTAX Integer32 (1..2147483647) 1404 MAX-ACCESS not-accessible 1405 STATUS current 1406 DESCRIPTION 1407 "High-order index of this AIK Certificate fragment. 1408 Index of an AIK Certificate chain update cycle that has 1409 occurred (bounded by the value of tudaV1AIKCertCycles). 1411 DEFVAL intentionally omitted - index object." 1412 ::= { tudaV1AIKCertEntry 1 } 1414 tudaV1AIKCertInstanceIndex OBJECT-TYPE 1415 SYNTAX Integer32 (1..2147483647) 1416 MAX-ACCESS not-accessible 1417 STATUS current 1418 DESCRIPTION 1419 "Middle index of this AIK Certificate fragment. 1420 Ordinal of this AIK Certificate in this chain, where the AIK 1421 Certificate itself has an ordinal of '1' and higher ordinals 1422 go *up* the certificate chain to the Root CA. 1424 DEFVAL intentionally omitted - index object." 1425 ::= { tudaV1AIKCertEntry 2 } 1427 tudaV1AIKCertFragmentIndex OBJECT-TYPE 1428 SYNTAX Integer32 (1..2147483647) 1429 MAX-ACCESS not-accessible 1430 STATUS current 1431 DESCRIPTION 1432 "Low-order index of this AIK Certificate fragment. 1434 DEFVAL intentionally omitted - index object." 1435 ::= { tudaV1AIKCertEntry 3 } 1437 tudaV1AIKCertData OBJECT-TYPE 1438 SYNTAX OCTET STRING (SIZE(0..1024)) 1439 MAX-ACCESS read-only 1440 STATUS current 1441 DESCRIPTION 1442 "A fragment of CBOR encoded AIK Certificate data." 1443 DEFVAL { "" } 1444 ::= { tudaV1AIKCertEntry 4 } 1446 -- 1447 -- TSA Cert 1448 -- 1449 tudaV1TSACert OBJECT IDENTIFIER ::= { tudaV1MIBObjects 3 } 1451 tudaV1TSACertCycles OBJECT-TYPE 1452 SYNTAX Counter32 1453 MAX-ACCESS read-only 1454 STATUS current 1455 DESCRIPTION 1456 "Count of TSA Certificate chain update cycles that have 1457 occurred. 1459 DEFVAL intentionally omitted - counter object." 1460 ::= { tudaV1TSACert 1 } 1462 tudaV1TSACertTable OBJECT-TYPE 1463 SYNTAX SEQUENCE OF TudaV1TSACertEntry 1464 MAX-ACCESS not-accessible 1465 STATUS current 1466 DESCRIPTION 1467 "A table of fragments of TSA Certificate data." 1468 ::= { tudaV1TSACert 2 } 1470 tudaV1TSACertEntry OBJECT-TYPE 1471 SYNTAX TudaV1TSACertEntry 1472 MAX-ACCESS not-accessible 1473 STATUS current 1474 DESCRIPTION 1475 "An entry for one fragment of TSA Certificate data." 1476 INDEX { tudaV1TSACertCycleIndex, 1477 tudaV1TSACertInstanceIndex, 1478 tudaV1TSACertFragmentIndex } 1479 ::= { tudaV1TSACertTable 1 } 1481 TudaV1TSACertEntry ::= 1482 SEQUENCE { 1483 tudaV1TSACertCycleIndex Integer32, 1484 tudaV1TSACertInstanceIndex Integer32, 1485 tudaV1TSACertFragmentIndex Integer32, 1486 tudaV1TSACertData OCTET STRING 1487 } 1489 tudaV1TSACertCycleIndex OBJECT-TYPE 1490 SYNTAX Integer32 (1..2147483647) 1491 MAX-ACCESS not-accessible 1492 STATUS current 1493 DESCRIPTION 1494 "High-order index of this TSA Certificate fragment. 1495 Index of a TSA Certificate chain update cycle that has 1496 occurred (bounded by the value of tudaV1TSACertCycles). 1498 DEFVAL intentionally omitted - index object." 1499 ::= { tudaV1TSACertEntry 1 } 1501 tudaV1TSACertInstanceIndex OBJECT-TYPE 1502 SYNTAX Integer32 (1..2147483647) 1503 MAX-ACCESS not-accessible 1504 STATUS current 1505 DESCRIPTION 1506 "Middle index of this TSA Certificate fragment. 1507 Ordinal of this TSA Certificate in this chain, where the TSA 1508 Certificate itself has an ordinal of '1' and higher ordinals 1509 go *up* the certificate chain to the Root CA. 1511 DEFVAL intentionally omitted - index object." 1512 ::= { tudaV1TSACertEntry 2 } 1514 tudaV1TSACertFragmentIndex OBJECT-TYPE 1515 SYNTAX Integer32 (1..2147483647) 1516 MAX-ACCESS not-accessible 1517 STATUS current 1518 DESCRIPTION 1519 "Low-order index of this TSA Certificate fragment. 1521 DEFVAL intentionally omitted - index object." 1522 ::= { tudaV1TSACertEntry 3 } 1524 tudaV1TSACertData OBJECT-TYPE 1525 SYNTAX OCTET STRING (SIZE(0..1024)) 1526 MAX-ACCESS read-only 1527 STATUS current 1528 DESCRIPTION 1529 "A fragment of CBOR encoded TSA Certificate data." 1530 DEFVAL { "" } 1531 ::= { tudaV1TSACertEntry 4 } 1533 -- 1534 -- Sync Token 1535 -- 1536 tudaV1SyncToken OBJECT IDENTIFIER ::= { tudaV1MIBObjects 4 } 1538 tudaV1SyncTokenCycles OBJECT-TYPE 1539 SYNTAX Counter32 1540 MAX-ACCESS read-only 1541 STATUS current 1542 DESCRIPTION 1543 "Count of Sync Token update cycles that have 1544 occurred. 1546 DEFVAL intentionally omitted - counter object." 1547 ::= { tudaV1SyncToken 1 } 1549 tudaV1SyncTokenInstances OBJECT-TYPE 1550 SYNTAX Counter32 1551 MAX-ACCESS read-only 1552 STATUS current 1553 DESCRIPTION 1554 "Count of Sync Token instance entries that have 1555 been recorded (some entries MAY have been pruned). 1557 DEFVAL intentionally omitted - counter object." 1558 ::= { tudaV1SyncToken 2 } 1560 tudaV1SyncTokenTable OBJECT-TYPE 1561 SYNTAX SEQUENCE OF TudaV1SyncTokenEntry 1562 MAX-ACCESS not-accessible 1563 STATUS current 1564 DESCRIPTION 1565 "A table of fragments of Sync Token data." 1567 ::= { tudaV1SyncToken 3 } 1569 tudaV1SyncTokenEntry OBJECT-TYPE 1570 SYNTAX TudaV1SyncTokenEntry 1571 MAX-ACCESS not-accessible 1572 STATUS current 1573 DESCRIPTION 1574 "An entry for one fragment of Sync Token data." 1575 INDEX { tudaV1SyncTokenCycleIndex, 1576 tudaV1SyncTokenInstanceIndex, 1577 tudaV1SyncTokenFragmentIndex } 1578 ::= { tudaV1SyncTokenTable 1 } 1580 TudaV1SyncTokenEntry ::= 1581 SEQUENCE { 1582 tudaV1SyncTokenCycleIndex Integer32, 1583 tudaV1SyncTokenInstanceIndex Integer32, 1584 tudaV1SyncTokenFragmentIndex Integer32, 1585 tudaV1SyncTokenData OCTET STRING 1586 } 1588 tudaV1SyncTokenCycleIndex OBJECT-TYPE 1589 SYNTAX Integer32 (1..2147483647) 1590 MAX-ACCESS not-accessible 1591 STATUS current 1592 DESCRIPTION 1593 "High-order index of this Sync Token fragment. 1594 Index of a Sync Token update cycle that has 1595 occurred (bounded by the value of tudaV1SyncTokenCycles). 1597 DEFVAL intentionally omitted - index object." 1598 ::= { tudaV1SyncTokenEntry 1 } 1600 tudaV1SyncTokenInstanceIndex OBJECT-TYPE 1601 SYNTAX Integer32 (1..2147483647) 1602 MAX-ACCESS not-accessible 1603 STATUS current 1604 DESCRIPTION 1605 "Middle index of this Sync Token fragment. 1606 Ordinal of this instance of Sync Token data 1607 (NOT bounded by the value of tudaV1SyncTokenInstances). 1609 DEFVAL intentionally omitted - index object." 1610 ::= { tudaV1SyncTokenEntry 2 } 1612 tudaV1SyncTokenFragmentIndex OBJECT-TYPE 1613 SYNTAX Integer32 (1..2147483647) 1614 MAX-ACCESS not-accessible 1615 STATUS current 1616 DESCRIPTION 1617 "Low-order index of this Sync Token fragment. 1619 DEFVAL intentionally omitted - index object." 1620 ::= { tudaV1SyncTokenEntry 3 } 1622 tudaV1SyncTokenData OBJECT-TYPE 1623 SYNTAX OCTET STRING (SIZE(0..1024)) 1624 MAX-ACCESS read-only 1625 STATUS current 1626 DESCRIPTION 1627 "A fragment of CBOR encoded Sync Token data." 1628 DEFVAL { "" } 1629 ::= { tudaV1SyncTokenEntry 4 } 1631 -- 1632 -- Restriction Info 1633 -- 1634 tudaV1Restrict OBJECT IDENTIFIER ::= { tudaV1MIBObjects 5 } 1636 tudaV1RestrictCycles OBJECT-TYPE 1637 SYNTAX Counter32 1638 MAX-ACCESS read-only 1639 STATUS current 1640 DESCRIPTION 1641 "Count of Restriction Info update cycles that have 1642 occurred. 1644 DEFVAL intentionally omitted - counter object." 1645 ::= { tudaV1Restrict 1 } 1647 tudaV1RestrictTable OBJECT-TYPE 1648 SYNTAX SEQUENCE OF TudaV1RestrictEntry 1649 MAX-ACCESS not-accessible 1650 STATUS current 1651 DESCRIPTION 1652 "A table of instances of Restriction Info data." 1653 ::= { tudaV1Restrict 2 } 1655 tudaV1RestrictEntry OBJECT-TYPE 1656 SYNTAX TudaV1RestrictEntry 1657 MAX-ACCESS not-accessible 1658 STATUS current 1659 DESCRIPTION 1660 "An entry for one instance of Restriction Info data." 1661 INDEX { tudaV1RestrictCycleIndex } 1662 ::= { tudaV1RestrictTable 1 } 1664 TudaV1RestrictEntry ::= 1665 SEQUENCE { 1666 tudaV1RestrictCycleIndex Integer32, 1667 tudaV1RestrictData OCTET STRING 1668 } 1670 tudaV1RestrictCycleIndex OBJECT-TYPE 1671 SYNTAX Integer32 (1..2147483647) 1672 MAX-ACCESS not-accessible 1673 STATUS current 1674 DESCRIPTION 1675 "Index of this Restriction Info entry. 1676 Index of a Restriction Info update cycle that has 1677 occurred (bounded by the value of tudaV1RestrictCycles). 1679 DEFVAL intentionally omitted - index object." 1680 ::= { tudaV1RestrictEntry 1 } 1682 tudaV1RestrictData OBJECT-TYPE 1683 SYNTAX OCTET STRING (SIZE(0..1024)) 1684 MAX-ACCESS read-only 1685 STATUS current 1686 DESCRIPTION 1687 "An instance of CBOR encoded Restriction Info data." 1688 DEFVAL { "" } 1689 ::= { tudaV1RestrictEntry 2 } 1691 -- 1692 -- Measurement Log 1693 -- 1694 tudaV1Measure OBJECT IDENTIFIER ::= { tudaV1MIBObjects 6 } 1696 tudaV1MeasureCycles OBJECT-TYPE 1697 SYNTAX Counter32 1698 MAX-ACCESS read-only 1699 STATUS current 1700 DESCRIPTION 1701 "Count of Measurement Log update cycles that have 1702 occurred. 1704 DEFVAL intentionally omitted - counter object." 1705 ::= { tudaV1Measure 1 } 1707 tudaV1MeasureInstances OBJECT-TYPE 1708 SYNTAX Counter32 1709 MAX-ACCESS read-only 1710 STATUS current 1711 DESCRIPTION 1712 "Count of Measurement Log instance entries that have 1713 been recorded (some entries MAY have been pruned). 1715 DEFVAL intentionally omitted - counter object." 1716 ::= { tudaV1Measure 2 } 1718 tudaV1MeasureTable OBJECT-TYPE 1719 SYNTAX SEQUENCE OF TudaV1MeasureEntry 1720 MAX-ACCESS not-accessible 1721 STATUS current 1722 DESCRIPTION 1723 "A table of instances of Measurement Log data." 1724 ::= { tudaV1Measure 3 } 1726 tudaV1MeasureEntry OBJECT-TYPE 1727 SYNTAX TudaV1MeasureEntry 1728 MAX-ACCESS not-accessible 1729 STATUS current 1730 DESCRIPTION 1731 "An entry for one instance of Measurement Log data." 1732 INDEX { tudaV1MeasureCycleIndex, 1733 tudaV1MeasureInstanceIndex } 1734 ::= { tudaV1MeasureTable 1 } 1736 TudaV1MeasureEntry ::= 1737 SEQUENCE { 1738 tudaV1MeasureCycleIndex Integer32, 1739 tudaV1MeasureInstanceIndex Integer32, 1740 tudaV1MeasureData OCTET STRING 1741 } 1743 tudaV1MeasureCycleIndex OBJECT-TYPE 1744 SYNTAX Integer32 (1..2147483647) 1745 MAX-ACCESS not-accessible 1746 STATUS current 1747 DESCRIPTION 1748 "High-order index of this Measurement Log entry. 1749 Index of a Measurement Log update cycle that has 1750 occurred (bounded by the value of tudaV1MeasureCycles). 1752 DEFVAL intentionally omitted - index object." 1753 ::= { tudaV1MeasureEntry 1 } 1755 tudaV1MeasureInstanceIndex OBJECT-TYPE 1756 SYNTAX Integer32 (1..2147483647) 1757 MAX-ACCESS not-accessible 1758 STATUS current 1759 DESCRIPTION 1760 "Low-order index of this Measurement Log entry. 1761 Ordinal of this instance of Measurement Log data 1762 (NOT bounded by the value of tudaV1MeasureInstances). 1764 DEFVAL intentionally omitted - index object." 1765 ::= { tudaV1MeasureEntry 2 } 1767 tudaV1MeasureData OBJECT-TYPE 1768 SYNTAX OCTET STRING (SIZE(0..1024)) 1769 MAX-ACCESS read-only 1770 STATUS current 1771 DESCRIPTION 1772 "A instance of CBOR encoded Measurement Log data." 1773 DEFVAL { "" } 1774 ::= { tudaV1MeasureEntry 3 } 1776 -- 1777 -- Verify Token 1778 -- 1779 tudaV1VerifyToken OBJECT IDENTIFIER ::= { tudaV1MIBObjects 7 } 1781 tudaV1VerifyTokenCycles OBJECT-TYPE 1782 SYNTAX Counter32 1783 MAX-ACCESS read-only 1784 STATUS current 1785 DESCRIPTION 1786 "Count of Verify Token update cycles that have 1787 occurred. 1789 DEFVAL intentionally omitted - counter object." 1790 ::= { tudaV1VerifyToken 1 } 1792 tudaV1VerifyTokenTable OBJECT-TYPE 1793 SYNTAX SEQUENCE OF TudaV1VerifyTokenEntry 1794 MAX-ACCESS not-accessible 1795 STATUS current 1796 DESCRIPTION 1797 "A table of instances of Verify Token data." 1798 ::= { tudaV1VerifyToken 2 } 1800 tudaV1VerifyTokenEntry OBJECT-TYPE 1801 SYNTAX TudaV1VerifyTokenEntry 1802 MAX-ACCESS not-accessible 1803 STATUS current 1804 DESCRIPTION 1805 "An entry for one instance of Verify Token data." 1806 INDEX { tudaV1VerifyTokenCycleIndex } 1807 ::= { tudaV1VerifyTokenTable 1 } 1809 TudaV1VerifyTokenEntry ::= 1810 SEQUENCE { 1811 tudaV1VerifyTokenCycleIndex Integer32, 1812 tudaV1VerifyTokenData OCTET STRING 1813 } 1815 tudaV1VerifyTokenCycleIndex OBJECT-TYPE 1816 SYNTAX Integer32 (1..2147483647) 1817 MAX-ACCESS not-accessible 1818 STATUS current 1819 DESCRIPTION 1820 "Index of this instance of Verify Token data. 1821 Index of a Verify Token update cycle that has 1822 occurred (bounded by the value of tudaV1VerifyTokenCycles). 1824 DEFVAL intentionally omitted - index object." 1825 ::= { tudaV1VerifyTokenEntry 1 } 1827 tudaV1VerifyTokenData OBJECT-TYPE 1828 SYNTAX OCTET STRING (SIZE(0..1024)) 1829 MAX-ACCESS read-only 1830 STATUS current 1831 DESCRIPTION 1832 "A instance of CBOR encoded Verify Token data." 1833 DEFVAL { "" } 1834 ::= { tudaV1VerifyTokenEntry 2 } 1836 -- 1837 -- SWID Tag 1838 -- 1839 tudaV1SWIDTag OBJECT IDENTIFIER ::= { tudaV1MIBObjects 8 } 1841 tudaV1SWIDTagCycles OBJECT-TYPE 1842 SYNTAX Counter32 1843 MAX-ACCESS read-only 1844 STATUS current 1845 DESCRIPTION 1846 "Count of SWID Tag update cycles that have occurred. 1848 DEFVAL intentionally omitted - counter object." 1849 ::= { tudaV1SWIDTag 1 } 1851 tudaV1SWIDTagTable OBJECT-TYPE 1852 SYNTAX SEQUENCE OF TudaV1SWIDTagEntry 1853 MAX-ACCESS not-accessible 1854 STATUS current 1855 DESCRIPTION 1856 "A table of fragments of SWID Tag data." 1857 ::= { tudaV1SWIDTag 2 } 1859 tudaV1SWIDTagEntry OBJECT-TYPE 1860 SYNTAX TudaV1SWIDTagEntry 1861 MAX-ACCESS not-accessible 1862 STATUS current 1863 DESCRIPTION 1864 "An entry for one fragment of SWID Tag data." 1865 INDEX { tudaV1SWIDTagCycleIndex, 1866 tudaV1SWIDTagInstanceIndex, 1867 tudaV1SWIDTagFragmentIndex } 1868 ::= { tudaV1SWIDTagTable 1 } 1870 TudaV1SWIDTagEntry ::= 1871 SEQUENCE { 1872 tudaV1SWIDTagCycleIndex Integer32, 1873 tudaV1SWIDTagInstanceIndex Integer32, 1874 tudaV1SWIDTagFragmentIndex Integer32, 1875 tudaV1SWIDTagData OCTET STRING 1876 } 1878 tudaV1SWIDTagCycleIndex OBJECT-TYPE 1879 SYNTAX Integer32 (1..2147483647) 1880 MAX-ACCESS not-accessible 1881 STATUS current 1882 DESCRIPTION 1883 "High-order index of this SWID Tag fragment. 1884 Index of an SWID Tag update cycle that has 1885 occurred (bounded by the value of tudaV1SWIDTagCycles). 1887 DEFVAL intentionally omitted - index object." 1888 ::= { tudaV1SWIDTagEntry 1 } 1890 tudaV1SWIDTagInstanceIndex OBJECT-TYPE 1891 SYNTAX Integer32 (1..2147483647) 1892 MAX-ACCESS not-accessible 1893 STATUS current 1894 DESCRIPTION 1895 "Middle index of this SWID Tag fragment. 1896 Ordinal of this SWID Tag instance in this update cycle. 1898 DEFVAL intentionally omitted - index object." 1899 ::= { tudaV1SWIDTagEntry 2 } 1901 tudaV1SWIDTagFragmentIndex OBJECT-TYPE 1902 SYNTAX Integer32 (1..2147483647) 1903 MAX-ACCESS not-accessible 1904 STATUS current 1905 DESCRIPTION 1906 "Low-order index of this SWID Tag fragment. 1908 DEFVAL intentionally omitted - index object." 1909 ::= { tudaV1SWIDTagEntry 3 } 1911 tudaV1SWIDTagData OBJECT-TYPE 1912 SYNTAX OCTET STRING (SIZE(0..1024)) 1913 MAX-ACCESS read-only 1914 STATUS current 1915 DESCRIPTION 1916 "A fragment of CBOR encoded SWID Tag data." 1917 DEFVAL { "" } 1918 ::= { tudaV1SWIDTagEntry 4 } 1920 -- 1921 -- Trap Cycles 1922 -- 1923 tudaV1TrapV2Cycles NOTIFICATION-TYPE 1924 OBJECTS { 1925 tudaV1GeneralCycles, 1926 tudaV1AIKCertCycles, 1927 tudaV1TSACertCycles, 1928 tudaV1SyncTokenCycles, 1929 tudaV1SyncTokenInstances, 1930 tudaV1RestrictCycles, 1931 tudaV1MeasureCycles, 1932 tudaV1MeasureInstances, 1933 tudaV1VerifyTokenCycles, 1934 tudaV1SWIDTagCycles 1935 } 1936 STATUS current 1937 DESCRIPTION 1938 "This trap is sent when the value of any cycle or instance 1939 counter changes (i.e., one or more tables are updated). 1941 Note: The value of sysUpTime in IETF MIB-II (RFC 1213) is 1942 always included in SNMPv2 traps, per RFC 3416." 1943 ::= { tudaV1MIBNotifications 1 } 1945 -- 1946 -- Conformance Information 1947 -- 1948 tudaV1Compliances OBJECT IDENTIFIER 1949 ::= { tudaV1MIBConformance 1 } 1951 tudaV1ObjectGroups OBJECT IDENTIFIER 1952 ::= { tudaV1MIBConformance 2 } 1954 tudaV1NotificationGroups OBJECT IDENTIFIER 1955 ::= { tudaV1MIBConformance 3 } 1957 -- 1958 -- Compliance Statements 1959 -- 1960 tudaV1BasicCompliance MODULE-COMPLIANCE 1961 STATUS current 1962 DESCRIPTION 1963 "An implementation that complies with this module MUST 1964 implement all of the objects defined in the mandatory 1965 group tudaV1BasicGroup." 1966 MODULE -- this module 1967 MANDATORY-GROUPS { tudaV1BasicGroup } 1969 GROUP tudaV1OptionalGroup 1970 DESCRIPTION 1971 "The optional TUDA MIB objects. 1972 An implementation MAY implement this group." 1974 GROUP tudaV1TrapGroup 1975 DESCRIPTION 1976 "The TUDA MIB traps. 1977 An implementation SHOULD implement this group." 1978 ::= { tudaV1Compliances 1 } 1980 -- 1981 -- Compliance Groups 1982 -- 1983 tudaV1BasicGroup OBJECT-GROUP 1984 OBJECTS { 1985 tudaV1GeneralCycles, 1986 tudaV1GeneralVersionInfo, 1987 tudaV1SyncTokenCycles, 1988 tudaV1SyncTokenInstances, 1989 tudaV1SyncTokenData, 1990 tudaV1RestrictCycles, 1991 tudaV1RestrictData, 1992 tudaV1VerifyTokenCycles, 1993 tudaV1VerifyTokenData 1994 } 1995 STATUS current 1996 DESCRIPTION 1997 "The basic mandatory TUDA MIB objects." 1998 ::= { tudaV1ObjectGroups 1 } 2000 tudaV1OptionalGroup OBJECT-GROUP 2001 OBJECTS { 2002 tudaV1AIKCertCycles, 2003 tudaV1AIKCertData, 2004 tudaV1TSACertCycles, 2005 tudaV1TSACertData, 2006 tudaV1MeasureCycles, 2007 tudaV1MeasureInstances, 2008 tudaV1MeasureData, 2009 tudaV1SWIDTagCycles, 2010 tudaV1SWIDTagData 2011 } 2012 STATUS current 2013 DESCRIPTION 2014 "The optional TUDA MIB objects." 2015 ::= { tudaV1ObjectGroups 2 } 2017 tudaV1TrapGroup NOTIFICATION-GROUP 2018 NOTIFICATIONS { tudaV1TrapV2Cycles } 2019 STATUS current 2020 DESCRIPTION 2021 "The recommended TUDA MIB traps - notifications." 2022 ::= { tudaV1NotificationGroups 1 } 2024 END 2025 2027 Appendix C. YANG Realization 2029 2030 module TUDA-V1-ATTESTATION-MIB { 2032 namespace "urn:ietf:params:xml:ns:yang:smiv2:TUDA-V1-ATTESTATION-MIB"; 2033 prefix "tuda-v1"; 2035 import SNMP-FRAMEWORK-MIB { prefix "snmp-framework"; } 2036 import yang-types { prefix "yang"; } 2038 organization 2039 "Fraunhofer SIT"; 2041 contact 2042 "Andreas Fuchs 2043 Fraunhofer Institute for Secure Information Technology 2044 Email: andreas.fuchs@sit.fraunhofer.de 2046 Henk Birkholz 2047 Fraunhofer Institute for Secure Information Technology 2048 Email: henk.birkholz@sit.fraunhofer.de 2050 Ira E McDonald 2051 High North Inc 2052 Email: blueroofmusic@gmail.com 2054 Carsten Bormann 2055 Universitaet Bremen TZI 2056 Email: cabo@tzi.org"; 2058 description 2059 "The MIB module for monitoring of time-based unidirectional 2060 attestation information from a network endpoint system, 2061 based on the Trusted Computing Group TPM 1.2 definition. 2063 Copyright (C) High North Inc (2021)."; 2065 revision "2021-01-13" { 2066 description 2067 "Twelfth version, published as draft-birkholz-rats-tuda-04."; 2068 reference 2069 "draft-birkholz-rats-tuda-04"; 2070 } 2071 revision "2020-07-13" { 2072 description 2073 "Eleventh version, published as draft-birkholz-rats-tuda-03."; 2074 reference 2075 "draft-birkholz-rats-tuda-03"; 2076 } 2077 revision "2020-03-09" { 2078 description 2079 "Tenth version, published as draft-birkholz-rats-tuda-02."; 2080 reference 2081 "draft-birkholz-rats-tuda-02"; 2082 } 2083 revision "2019-09-11" { 2084 description 2085 "Ninth version, published as draft-birkholz-rats-tuda-01."; 2086 reference 2087 "draft-birkholz-rats-tuda-01"; 2088 } 2089 revision "2019-03-12" { 2090 description 2091 "Eighth version, published as draft-birkholz-rats-tuda-00."; 2092 reference 2093 "draft-birkholz-rats-tuda-00"; 2094 } 2095 revision "2018-05-03" { 2096 description 2097 "Seventh version, published as draft-birkholz-i2nsf-tuda-03."; 2098 reference 2099 "draft-birkholz-i2nsf-tuda-03"; 2100 } 2101 revision "2018-05-02" { 2102 description 2103 "Sixth version, published as draft-birkholz-i2nsf-tuda-02."; 2104 reference 2105 "draft-birkholz-i2nsf-tuda-02"; 2106 } 2107 revision "2017-10-30" { 2108 description 2109 "Fifth version, published as draft-birkholz-i2nsf-tuda-01."; 2110 reference 2111 "draft-birkholz-i2nsf-tuda-01"; 2112 } 2113 revision "2017-01-09" { 2114 description 2115 "Fourth version, published as draft-birkholz-i2nsf-tuda-00."; 2116 reference 2117 "draft-birkholz-i2nsf-tuda-00"; 2118 } 2119 revision "2016-07-08" { 2120 description 2121 "Third version, published as draft-birkholz-tuda-02."; 2122 reference 2123 "draft-birkholz-tuda-02"; 2124 } 2125 revision "2016-03-21" { 2126 description 2127 "Second version, published as draft-birkholz-tuda-01."; 2128 reference 2129 "draft-birkholz-tuda-01"; 2130 } 2131 revision "2015-10-18" { 2132 description 2133 "Initial version, published as draft-birkholz-tuda-00."; 2134 reference 2135 "draft-birkholz-tuda-00"; 2136 } 2138 container tudaV1General { 2139 description 2140 "TBD"; 2142 leaf tudaV1GeneralCycles { 2143 type yang:counter32; 2144 config false; 2145 description 2146 "Count of TUDA update cycles that have occurred, i.e., 2147 sum of all the individual group cycle counters. 2149 DEFVAL intentionally omitted - counter object."; 2150 } 2152 leaf tudaV1GeneralVersionInfo { 2153 type snmp-framework:SnmpAdminString { 2154 length "0..255"; 2155 } 2156 config false; 2157 description 2158 "Version information for TUDA MIB, e.g., specific release 2159 version of TPM 1.2 base specification and release version 2160 of TPM 1.2 errata specification and manufacturer and model 2161 TPM module itself."; 2162 } 2163 } 2165 container tudaV1AIKCert { 2166 description 2167 "TBD"; 2169 leaf tudaV1AIKCertCycles { 2170 type yang:counter32; 2171 config false; 2172 description 2173 "Count of AIK Certificate chain update cycles that have 2174 occurred. 2176 DEFVAL intentionally omitted - counter object."; 2177 } 2179 /* XXX table comments here XXX */ 2181 list tudaV1AIKCertEntry { 2183 key "tudaV1AIKCertCycleIndex tudaV1AIKCertInstanceIndex 2184 tudaV1AIKCertFragmentIndex"; 2185 config false; 2186 description 2187 "An entry for one fragment of AIK Certificate data."; 2189 leaf tudaV1AIKCertCycleIndex { 2190 type int32 { 2191 range "1..2147483647"; 2192 } 2193 config false; 2194 description 2195 "High-order index of this AIK Certificate fragment. 2196 Index of an AIK Certificate chain update cycle that has 2197 occurred (bounded by the value of tudaV1AIKCertCycles). 2199 DEFVAL intentionally omitted - index object."; 2200 } 2202 leaf tudaV1AIKCertInstanceIndex { 2203 type int32 { 2204 range "1..2147483647"; 2205 } 2206 config false; 2207 description 2208 "Middle index of this AIK Certificate fragment. 2209 Ordinal of this AIK Certificate in this chain, where the AIK 2210 Certificate itself has an ordinal of '1' and higher ordinals 2211 go *up* the certificate chain to the Root CA. 2213 DEFVAL intentionally omitted - index object."; 2214 } 2216 leaf tudaV1AIKCertFragmentIndex { 2217 type int32 { 2218 range "1..2147483647"; 2219 } 2220 config false; 2221 description 2222 "Low-order index of this AIK Certificate fragment. 2224 DEFVAL intentionally omitted - index object."; 2225 } 2227 leaf tudaV1AIKCertData { 2228 type binary { 2229 length "0..1024"; 2230 } 2231 config false; 2232 description 2233 "A fragment of CBOR encoded AIK Certificate data."; 2234 } 2235 } 2236 } 2238 container tudaV1TSACert { 2239 description 2240 "TBD"; 2242 leaf tudaV1TSACertCycles { 2243 type yang:counter32; 2244 config false; 2245 description 2246 "Count of TSA Certificate chain update cycles that have 2247 occurred. 2249 DEFVAL intentionally omitted - counter object."; 2250 } 2252 /* XXX table comments here XXX */ 2254 list tudaV1TSACertEntry { 2256 key "tudaV1TSACertCycleIndex tudaV1TSACertInstanceIndex 2257 tudaV1TSACertFragmentIndex"; 2258 config false; 2259 description 2260 "An entry for one fragment of TSA Certificate data."; 2262 leaf tudaV1TSACertCycleIndex { 2263 type int32 { 2264 range "1..2147483647"; 2265 } 2266 config false; 2267 description 2268 "High-order index of this TSA Certificate fragment. 2269 Index of a TSA Certificate chain update cycle that has 2270 occurred (bounded by the value of tudaV1TSACertCycles). 2272 DEFVAL intentionally omitted - index object."; 2273 } 2275 leaf tudaV1TSACertInstanceIndex { 2276 type int32 { 2277 range "1..2147483647"; 2278 } 2279 config false; 2280 description 2281 "Middle index of this TSA Certificate fragment. 2282 Ordinal of this TSA Certificate in this chain, where the TSA 2283 Certificate itself has an ordinal of '1' and higher ordinals 2284 go *up* the certificate chain to the Root CA. 2286 DEFVAL intentionally omitted - index object."; 2287 } 2289 leaf tudaV1TSACertFragmentIndex { 2290 type int32 { 2291 range "1..2147483647"; 2292 } 2293 config false; 2294 description 2295 "Low-order index of this TSA Certificate fragment. 2297 DEFVAL intentionally omitted - index object."; 2298 } 2300 leaf tudaV1TSACertData { 2301 type binary { 2302 length "0..1024"; 2303 } 2304 config false; 2305 description 2306 "A fragment of CBOR encoded TSA Certificate data."; 2307 } 2308 } 2309 } 2311 container tudaV1SyncToken { 2312 description 2313 "TBD"; 2315 leaf tudaV1SyncTokenCycles { 2316 type yang:counter32; 2317 config false; 2318 description 2319 "Count of Sync Token update cycles that have 2320 occurred. 2322 DEFVAL intentionally omitted - counter object."; 2323 } 2325 leaf tudaV1SyncTokenInstances { 2326 type yang:counter32; 2327 config false; 2328 description 2329 "Count of Sync Token instance entries that have 2330 been recorded (some entries MAY have been pruned). 2332 DEFVAL intentionally omitted - counter object."; 2333 } 2334 list tudaV1SyncTokenEntry { 2336 key "tudaV1SyncTokenCycleIndex 2337 tudaV1SyncTokenInstanceIndex 2338 tudaV1SyncTokenFragmentIndex"; 2339 config false; 2340 description 2341 "An entry for one fragment of Sync Token data."; 2343 leaf tudaV1SyncTokenCycleIndex { 2344 type int32 { 2345 range "1..2147483647"; 2346 } 2347 config false; 2348 description 2349 "High-order index of this Sync Token fragment. 2350 Index of a Sync Token update cycle that has 2351 occurred (bounded by the value of tudaV1SyncTokenCycles). 2353 DEFVAL intentionally omitted - index object."; 2354 } 2356 leaf tudaV1SyncTokenInstanceIndex { 2357 type int32 { 2358 range "1..2147483647"; 2359 } 2360 config false; 2361 description 2362 "Middle index of this Sync Token fragment. 2363 Ordinal of this instance of Sync Token data 2364 (NOT bounded by the value of tudaV1SyncTokenInstances). 2366 DEFVAL intentionally omitted - index object."; 2367 } 2369 leaf tudaV1SyncTokenFragmentIndex { 2370 type int32 { 2371 range "1..2147483647"; 2372 } 2373 config false; 2374 description 2375 "Low-order index of this Sync Token fragment. 2377 DEFVAL intentionally omitted - index object."; 2378 } 2380 leaf tudaV1SyncTokenData { 2381 type binary { 2382 length "0..1024"; 2383 } 2384 config false; 2385 description 2386 "A fragment of CBOR encoded Sync Token data."; 2387 } 2388 } 2389 } 2391 container tudaV1Restrict { 2392 description 2393 "TBD"; 2395 leaf tudaV1RestrictCycles { 2396 type yang:counter32; 2397 config false; 2398 description 2399 "Count of Restriction Info update cycles that have 2400 occurred. 2402 DEFVAL intentionally omitted - counter object."; 2403 } 2405 /* XXX table comments here XXX */ 2407 list tudaV1RestrictEntry { 2409 key "tudaV1RestrictCycleIndex"; 2410 config false; 2411 description 2412 "An entry for one instance of Restriction Info data."; 2414 leaf tudaV1RestrictCycleIndex { 2415 type int32 { 2416 range "1..2147483647"; 2417 } 2418 config false; 2419 description 2420 "Index of this Restriction Info entry. 2421 Index of a Restriction Info update cycle that has 2422 occurred (bounded by the value of tudaV1RestrictCycles). 2424 DEFVAL intentionally omitted - index object."; 2425 } 2426 leaf tudaV1RestrictData { 2427 type binary { 2428 length "0..1024"; 2429 } 2430 config false; 2431 description 2432 "An instance of CBOR encoded Restriction Info data."; 2433 } 2434 } 2435 } 2437 container tudaV1Measure { 2438 description 2439 "TBD"; 2441 leaf tudaV1MeasureCycles { 2442 type yang:counter32; 2443 config false; 2444 description 2445 "Count of Measurement Log update cycles that have 2446 occurred. 2448 DEFVAL intentionally omitted - counter object."; 2449 } 2451 leaf tudaV1MeasureInstances { 2452 type yang:counter32; 2453 config false; 2454 description 2455 "Count of Measurement Log instance entries that have 2456 been recorded (some entries MAY have been pruned). 2458 DEFVAL intentionally omitted - counter object."; 2459 } 2461 list tudaV1MeasureEntry { 2463 key "tudaV1MeasureCycleIndex tudaV1MeasureInstanceIndex"; 2464 config false; 2465 description 2466 "An entry for one instance of Measurement Log data."; 2468 leaf tudaV1MeasureCycleIndex { 2469 type int32 { 2470 range "1..2147483647"; 2471 } 2472 config false; 2473 description 2474 "High-order index of this Measurement Log entry. 2475 Index of a Measurement Log update cycle that has 2476 occurred (bounded by the value of tudaV1MeasureCycles). 2478 DEFVAL intentionally omitted - index object."; 2479 } 2481 leaf tudaV1MeasureInstanceIndex { 2482 type int32 { 2483 range "1..2147483647"; 2484 } 2485 config false; 2486 description 2487 "Low-order index of this Measurement Log entry. 2488 Ordinal of this instance of Measurement Log data 2489 (NOT bounded by the value of tudaV1MeasureInstances). 2491 DEFVAL intentionally omitted - index object."; 2492 } 2494 leaf tudaV1MeasureData { 2495 type binary { 2496 length "0..1024"; 2497 } 2498 config false; 2499 description 2500 "A instance of CBOR encoded Measurement Log data."; 2501 } 2502 } 2503 } 2505 container tudaV1VerifyToken { 2506 description 2507 "TBD"; 2509 leaf tudaV1VerifyTokenCycles { 2510 type yang:counter32; 2511 config false; 2512 description 2513 "Count of Verify Token update cycles that have 2514 occurred. 2516 DEFVAL intentionally omitted - counter object."; 2517 } 2519 /* XXX table comments here XXX */ 2520 list tudaV1VerifyTokenEntry { 2522 key "tudaV1VerifyTokenCycleIndex"; 2523 config false; 2524 description 2525 "An entry for one instance of Verify Token data."; 2527 leaf tudaV1VerifyTokenCycleIndex { 2528 type int32 { 2529 range "1..2147483647"; 2530 } 2531 config false; 2532 description 2533 "Index of this instance of Verify Token data. 2534 Index of a Verify Token update cycle that has 2535 occurred (bounded by the value of tudaV1VerifyTokenCycles). 2537 DEFVAL intentionally omitted - index object."; 2538 } 2540 leaf tudaV1VerifyTokenData { 2541 type binary { 2542 length "0..1024"; 2543 } 2544 config false; 2545 description 2546 "A instanc-V1-ATTESTATION-MIB.yang 2547 } 2548 } 2549 } 2551 container tudaV1SWIDTag { 2552 description 2553 "see CoSWID and YANG SIWD module for now" 2555 leaf tudaV1SWIDTagCycles { 2556 type yang:counter32; 2557 config false; 2558 description 2559 "Count of SWID Tag update cycles that have occurred. 2561 DEFVAL intentionally omitted - counter object."; 2562 } 2564 list tudaV1SWIDTagEntry { 2566 key "tudaV1SWIDTagCycleIndex tudaV1SWIDTagInstanceIndex 2567 tudaV1SWIDTagFragmentIndex"; 2568 config false; 2569 description 2570 "An entry for one fragment of SWID Tag data."; 2572 leaf tudaV1SWIDTagCycleIndex { 2573 type int32 { 2574 range "1..2147483647"; 2575 } 2576 config false; 2577 description 2578 "High-order index of this SWID Tag fragment. 2579 Index of an SWID Tag update cycle that has 2580 occurred (bounded by the value of tudaV1SWIDTagCycles). 2582 DEFVAL intentionally omitted - index object."; 2583 } 2585 leaf tudaV1SWIDTagInstanceIndex { 2586 type int32 { 2587 range "1..2147483647"; 2588 } 2589 config false; 2590 description 2591 "Middle index of this SWID Tag fragment. 2592 Ordinal of this SWID Tag instance in this update cycle. 2594 DEFVAL intentionally omitted - index object."; 2595 } 2597 leaf tudaV1SWIDTagFragmentIndex { 2598 type int32 { 2599 range "1..2147483647"; 2600 } 2601 config false; 2602 description 2603 "Low-order index of this SWID Tag fragment. 2605 DEFVAL intentionally omitted - index object."; 2606 } 2608 leaf tudaV1SWIDTagData { 2609 type binary { 2610 length "0..1024"; 2611 } 2612 config false; 2613 description 2614 "A fragment of CBOR encoded SWID Tag data."; 2615 } 2616 } 2617 } 2619 notification tudaV1TrapV2Cycles { 2620 description 2621 "This trap is sent when the value of any cycle or instance 2622 counter changes (i.e., one or more tables are updated). 2624 Note: The value of sysUpTime in IETF MIB-II (RFC 1213) is 2625 always included in SNMPv2 traps, per RFC 3416."; 2627 container tudaV1TrapV2Cycles-tudaV1GeneralCycles { 2628 description 2629 "TPD" 2630 leaf tudaV1GeneralCycles { 2631 type yang:counter32; 2632 description 2633 "Count of TUDA update cycles that have occurred, i.e., 2634 sum of all the individual group cycle counters. 2636 DEFVAL intentionally omitted - counter object."; 2637 } 2638 } 2640 container tudaV1TrapV2Cycles-tudaV1AIKCertCycles { 2641 description 2642 "TPD" 2643 leaf tudaV1AIKCertCycles { 2644 type yang:counter32; 2645 description 2646 "Count of AIK Certificate chain update cycles that have 2647 occurred. 2649 DEFVAL intentionally omitted - counter object."; 2650 } 2651 } 2653 container tudaV1TrapV2Cycles-tudaV1TSACertCycles { 2654 description 2655 "TPD" 2656 leaf tudaV1TSACertCycles { 2657 type yang:counter32; 2658 description 2659 "Count of TSA Certificate chain update cycles that have 2660 occurred. 2662 DEFVAL intentionally omitted - counter object."; 2663 } 2664 } 2666 container tudaV1TrapV2Cycles-tudaV1SyncTokenCycles { 2667 description 2668 "TPD" 2669 leaf tudaV1SyncTokenCycles { 2670 type yang:counter32; 2671 description 2672 "Count of Sync Token update cycles that have 2673 occurred. 2675 DEFVAL intentionally omitted - counter object."; 2676 } 2677 } 2679 container tudaV1TrapV2Cycles-tudaV1SyncTokenInstances { 2680 description 2681 "TPD" 2682 leaf tudaV1SyncTokenInstances { 2683 type yang:counter32; 2684 description 2685 "Count of Sync Token instance entries that have 2686 been recorded (some entries MAY have been pruned). 2688 DEFVAL intentionally omitted - counter object."; 2689 } 2690 } 2692 container tudaV1TrapV2Cycles-tudaV1RestrictCycles { 2693 description 2694 "TPD" 2695 leaf tudaV1RestrictCycles { 2696 type yang:counter32; 2697 description 2698 "Count of Restriction Info update cycles that have 2699 occurred. 2701 DEFVAL intentionally omitted - counter object."; 2702 } 2703 } 2705 container tudaV1TrapV2Cycles-tudaV1MeasureCycles { 2706 description 2707 "TPD" 2708 leaf tudaV1MeasureCycles { 2709 type yang:counter32; 2710 description 2711 "Count of Measurement Log update cycles that have 2712 occurred. 2714 DEFVAL intentionally omitted - counter object."; 2715 } 2716 } 2718 container tudaV1TrapV2Cycles-tudaV1MeasureInstances { 2719 description 2720 "TPD" 2721 leaf tudaV1MeasureInstances { 2722 type yang:counter32; 2723 description 2724 "Count of Measurement Log instance entries that have 2725 been recorded (some entries MAY have been pruned). 2727 DEFVAL intentionally omitted - counter object."; 2728 } 2729 } 2731 container tudaV1TrapV2Cycles-tudaV1VerifyTokenCycles { 2732 description 2733 "TPD" 2734 leaf tudaV1VerifyTokenCycles { 2735 type yang:counter32; 2736 description 2737 "Count of Verify Token update cycles that have 2738 occurred. 2740 DEFVAL intentionally omitted - counter object."; 2741 } 2742 } 2744 container tudaV1TrapV2Cycles-tudaV1SWIDTagCycles { 2745 description 2746 "TPD" 2747 leaf tudaV1SWIDTagCycles { 2748 type yang:counter32; 2749 description 2750 "Count of SWID Tag update cycles that have occurred. 2752 DEFVAL intentionally omitted - counter object."; 2753 } 2754 } 2756 } 2757 } 2758 2760 Appendix D. Realization with TPM functions 2762 D.1. TPM Functions 2764 The following TPM structures, resources and functions are used within 2765 this approach. They are based upon the TPM specifications [TPM12] 2766 and [TPM2]. 2768 D.1.1. Tick-Session and Tick-Stamp 2770 On every boot, the TPM initializes a new Tick-Session. Such a tick- 2771 session consists of a nonce that is randomly created upon each boot 2772 to identify the current boot-cycle - the phase between boot-time of 2773 the device and shutdown or power-off - and prevent replaying of old 2774 tick-session values. The TPM uses its internal entropy source that 2775 guarantees virtually no collisions of the nonce values between two of 2776 such boot cycles. 2778 It further includes an internal timer that is being initialize to 2779 Zero on each reboot. From this point on, the TPM increments this 2780 timer continuously based upon its internal secure clocking 2781 information until the device is powered down or set to sleep. By its 2782 hardware design, the TPM will detect attacks on any of those 2783 properties. 2785 The TPM offers the function TPM_TickStampBlob, which allows the TPM 2786 to create a signature over the current tick-session and two 2787 externally provided input values. These input values are designed to 2788 serve as a nonce and as payload data to be included in a 2789 TickStampBlob: TickstampBlob := sig(TPM-key, currentTicks || nonce || 2790 externalData). 2792 As a result, one is able to proof that at a certain point in time 2793 (relative to the tick-session) after the provisioning of a certain 2794 nonce, some certain externalData was known and provided to the TPM. 2795 If an approach however requires no input values or only one input 2796 value (such as the use in this document) the input values can be set 2797 to well-known value. The convention used within TCG specifications 2798 and within this document is to use twenty bytes of zero 2799 h'0000000000000000000000000000000000000000' as well-known value. 2801 D.1.2. Platform Configuration Registers (PCRs) 2803 The TPM is a secure cryptoprocessor that provides the ability to 2804 store measurements and metrics about an endpoint's configuration and 2805 state in a secure, tamper-proof environment. Each of these security 2806 relevant metrics can be stored in a volatile Platform Configuration 2807 Register (PCR) inside the TPM. These measurements can be conducted 2808 at any point in time, ranging from an initial BIOS boot-up sequence 2809 to measurements taken after hundreds of hours of uptime. 2811 The initial measurement is triggered by the Platforms so-called pre- 2812 BIOS or ROM-code. It will conduct a measurement of the first 2813 loadable pieces of code; i.e.\ the BIOS. The BIOS will in turn 2814 measure its Option ROMs and the BootLoader, which measures the OS- 2815 Kernel, which in turn measures its applications. This describes a 2816 so-called measurement chain. This typically gets recorded in a so- 2817 called measurement log, such that the values of the PCRs can be 2818 reconstructed from the individual measurements for validation. 2820 Via its PCRs, a TPM provides a Root of Trust that can, for example, 2821 support secure boot or remote attestation. The attestation of an 2822 endpoint's identity or security posture is based on the content of an 2823 TPM's PCRs (platform integrity measurements). 2825 D.1.3. PCR restricted Keys 2827 Every key inside the TPM can be restricted in such a way that it can 2828 only be used if a certain set of PCRs are in a predetermined state. 2829 For key creation the desired state for PCRs are defined via the 2830 PCRInfo field inside the keyInfo parameter. Whenever an operation 2831 using this key is performed, the TPM first checks whether the PCRs 2832 are in the correct state. Otherwise the operation is denied by the 2833 TPM. 2835 D.1.4. CertifyInfo 2837 The TPM offers a command to certify the properties of a key by means 2838 of a signature using another key. This includes especially the 2839 keyInfo which in turn includes the PCRInfo information used during 2840 key creation. This way, a third party can be assured about the fact 2841 that a key is only usable if the PCRs are in a certain state. 2843 D.2. IE Generation Procedures for TPM 1.2 2845 D.2.1. AIK and AIK Certificate 2847 Attestations are based upon a cryptographic signature performed by 2848 the TPM using a so-called Attestation Identity Key (AIK). An AIK has 2849 the properties that it cannot be exported from a TPM and is used for 2850 attestations. Trust in the AIK is established by an X.509 2851 Certificate emitted by a Certificate Authority. The AIK certificate 2852 is either provided directly or via a so-called PrivacyCA 2853 [AIK-Enrollment]. 2855 This element consists of the AIK certificate that includes the AIK's 2856 public key used during verification as well as the certificate chain 2857 up to the Root CA for validation of the AIK certificate itself. 2859 TUDA-Cert = [AIK-Cert, TSA-Cert]; maybe split into two for SNMP 2860 AIK-Cert = Cert 2861 TSA-Cert = Cert 2863 Figure 2: TUDA-Cert element in CDDL 2865 The TSA-Cert is a standard certificate of the TSA. 2867 The AIK-Cert may be provisioned in a secure environment using 2868 standard means or it may follow the PrivacyCA protocols. Figure 3 2869 gives a rough sketch of this protocol. See [AIK-Enrollment] for more 2870 information. 2872 The X.509 Certificate is built from the AIK public key and the 2873 corresponding PKCS #7 certificate chain, as shown in Figure 3. 2875 Required TPM functions: 2877 | create_AIK_Cert(...) = { 2878 | AIK = TPM_MakeIdentity() 2879 | IdReq = CollateIdentityRequest(AIK,EK) 2880 | IdRes = Call(AIK-CA, IdReq) 2881 | AIK-Cert = TPM_ActivateIdentity(AIK, IdRes) 2882 | } 2883 | 2884 | /* Alternative */ 2885 | 2886 | create_AIK_Cert(...) = { 2887 | AIK = TPM_CreateWrapKey(Identity) 2888 | AIK-Cert = Call(AIK-CA, AIK.pubkey) 2889 | } 2891 Figure 3: Creating the TUDA-Cert element 2893 D.2.2. Synchronization Token 2895 The reference for Attestations are the Tick-Sessions of the TPM. In 2896 order to put Attestations into relation with a Real Time Clock (RTC), 2897 it is necessary to provide a cryptographic synchronization between 2898 the tick session and the RTC. To do so, a synchronization protocol 2899 is run with a Time Stamp Authority (TSA) that consists of three 2900 steps: 2902 o The TPM creates a TickStampBlob using the AIK 2903 o This TickstampBlob is used as nonce to the Timestamp of the TSA 2905 o Another TickStampBlob with the AIK is created using the TSA's 2906 Timestamp a nonce 2908 The first TickStampBlob is called "left" and the second "right" in a 2909 reference to their position on a time-axis. 2911 These three elements, with the TSA's certificate factored out, form 2912 the synchronization token 2914 TUDA-Synctoken = [ 2915 left: TickStampBlob-Output, 2916 timestamp: TimeStampToken, 2917 right: TickStampBlob-Output, 2918 ] 2920 TimeStampToken = bytes ; RFC 3161 2922 TickStampBlob-Output = [ 2923 currentTicks: TPM-CURRENT-TICKS, 2924 sig: bytes, 2925 ] 2927 TPM-CURRENT-TICKS = [ 2928 currentTicks: uint 2929 ? ( 2930 tickRate: uint 2931 tickNonce: TPM-NONCE 2932 ) 2933 ] 2934 ; Note that TickStampBlob-Output "right" can omit the values for 2935 ; tickRate and tickNonce since they are the same as in "left" 2937 TPM-NONCE = bytes .size 20 2939 Figure 4: TUDA-Sync element in CDDL 2941 Required TPM functions: 2943 | dummyDigest = h'0000000000000000000000000000000000000000' 2944 | dummyNonce = dummyDigest 2945 | 2946 | create_sync_token(AIKHandle, TSA) = { 2947 | ts_left = TPM_TickStampBlob( 2948 | keyHandle = AIK_Handle, /*TPM_KEY_HANDLE*/ 2949 | antiReplay = dummyNonce, /*TPM_NONCE*/ 2950 | digestToStamp = dummyDigest /*TPM_DIGEST*/) 2951 | 2952 | ts = TSA_Timestamp(TSA, nonce = hash(ts_left)) 2953 | 2954 | ts_right = TPM_TickStampBlob( 2955 | keyHandle = AIK_Handle, /*TPM_KEY_HANDLE*/ 2956 | antiReplay = dummyNonce, /*TPM_NONCE*/ 2957 | digestToStamp = hash(ts)) /*TPM_DIGEST*/ 2958 | 2959 | TUDA-SyncToken = [[ts_left.ticks, ts_left.sig], ts, 2960 | [ts_right.ticks.currentTicks, ts_right.sig]] 2961 | /* Note: skip the nonce and tickRate field for ts_right.ticks */ 2962 | } 2964 Figure 5: Creating the Sync-Token element 2966 D.2.3. RestrictionInfo 2968 The attestation relies on the capability of the TPM to operate on 2969 restricted keys. Whenever the PCR values for the machine to be 2970 attested change, a new restricted key is created that can only be 2971 operated as long as the PCRs remain in their current state. 2973 In order to prove to the Verifier that this restricted temporary key 2974 actually has these properties and also to provide the PCR value that 2975 it is restricted, the TPM command TPM_CertifyInfo is used. It 2976 creates a signed certificate using the AIK about the newly created 2977 restricted key. 2979 This token is formed from the list of: 2981 o PCR list, 2983 o the newly created restricted public key, and 2985 o the certificate. 2987 TUDA-RestrictionInfo = [Composite, 2988 restrictedKey_Pub: Pubkey, 2989 CertifyInfo] 2991 PCRSelection = bytes .size (2..4) ; used as bit string 2993 Composite = [ 2994 bitmask: PCRSelection, 2995 values: [*PCR-Hash], 2996 ] 2998 Pubkey = bytes ; may be extended to COSE pubkeys 3000 CertifyInfo = [ 3001 TPM-CERTIFY-INFO, 3002 sig: bytes, 3003 ] 3005 TPM-CERTIFY-INFO = [ 3006 ; we don't encode TPM-STRUCT-VER: 3007 ; these are 4 bytes always equal to h'01010000' 3008 keyUsage: uint, ; 4byte? 2byte? 3009 keyFlags: bytes .size 4, ; 4byte 3010 authDataUsage: uint, ; 1byte (enum) 3011 algorithmParms: TPM-KEY-PARMS, 3012 pubkeyDigest: Hash, 3013 ; we don't encode TPM-NONCE data, which is 20 bytes, all zero 3014 parentPCRStatus: bool, 3015 ; no need to encode pcrinfosize 3016 pcrinfo: TPM-PCR-INFO, ; we have exactly one 3017 ] 3019 TPM-PCR-INFO = [ 3020 pcrSelection: PCRSelection; /* TPM_PCR_SELECTION */ 3021 digestAtRelease: PCR-Hash; /* TPM_COMPOSITE_HASH */ 3022 digestAtCreation: PCR-Hash; /* TPM_COMPOSITE_HASH */ 3023 ] 3025 TPM-KEY-PARMS = [ 3026 ; algorithmID: uint, ; <= 4 bytes -- not encoded, constant for TPM1.2 3027 encScheme: uint, ; <= 2 bytes 3028 sigScheme: uint, ; <= 2 bytes 3029 parms: TPM-RSA-KEY-PARMS, 3030 ] 3032 TPM-RSA-KEY-PARMS = [ 3033 ; "size of the RSA key in bits": 3034 keyLength: uint 3035 ; "number of prime factors used by this RSA key": 3036 numPrimes: uint 3037 ; "This SHALL be the size of the exponent": 3038 exponentSize: null / uint / biguint 3039 ; "If the key is using the default exponent then the exponentSize 3040 ; MUST be 0" -> we represent this case as null 3041 ] 3043 Figure 6: TUDA-Key element in CDDL 3045 Required TPM functions: 3047 | dummyDigest = h'0000000000000000000000000000000000000000' 3048 | dummyNonce = dummyDigest 3049 | 3050 | create_Composite 3051 | 3052 | create_restrictedKey_Pub(pcrsel) = { 3053 | PCRInfo = {pcrSelection = pcrsel, 3054 | digestAtRelease = hash(currentValues(pcrSelection)) 3055 | digestAtCreation = dummyDigest} 3056 | / * PCRInfo is a TPM_PCR_INFO and thus also a TPM_KEY */ 3057 | 3058 | wk = TPM_CreateWrapKey(keyInfo = PCRInfo) 3059 | wk.keyInfo.pubKey 3060 | } 3061 | 3062 | create_TPM-Certify-Info = { 3063 | CertifyInfo = TPM_CertifyKey( 3064 | certHandle = AIK, /* TPM_KEY_HANDLE */ 3065 | keyHandle = wk, /* TPM_KEY_HANDLE */ 3066 | antiReply = dummyNonce) /* TPM_NONCE */ 3067 | 3068 | CertifyInfo.strip() 3069 | /* Remove those values that are not needed */ 3070 | } 3072 Figure 7: Creating the pubkey 3074 D.2.4. Measurement Log 3076 Similarly to regular attestations, the Verifier needs a way to 3077 reconstruct the PCRs' values in order to estimate the trustworthiness 3078 of the device. As such, a list of those elements that were extended 3079 into the PCRs is reported. Note though that for certain 3080 environments, this step may be optional if a list of valid PCR 3081 configurations exists and no measurement log is required. 3083 TUDA-Measurement-Log = [*PCR-Event] 3084 PCR-Event = [ 3085 type: PCR-Event-Type, 3086 pcr: uint, 3087 template-hash: PCR-Hash, 3088 filedata-hash: tagged-hash, 3089 pathname: text; called filename-hint in ima (non-ng) 3090 ] 3092 PCR-Event-Type = &( 3093 bios: 0 3094 ima: 1 3095 ima-ng: 2 3096 ) 3098 ; might want to make use of COSE registry here 3099 ; however, that might never define a value for sha1 3100 tagged-hash /= [sha1: 0, bytes .size 20] 3101 tagged-hash /= [sha256: 1, bytes .size 32] 3103 D.2.5. Implicit Attestation 3105 The actual attestation is then based upon a TickStampBlob using the 3106 restricted temporary key that was certified in the steps above. The 3107 TPM-Tickstamp is executed and thereby provides evidence that at this 3108 point in time (with respect to the TPM internal tick-session) a 3109 certain configuration existed (namely the PCR values associated with 3110 the restricted key). Together with the synchronization token this 3111 tick-related timing can then be related to the real-time clock. 3113 This element consists only of the TPM_TickStampBlock with no nonce. 3115 TUDA-Verifytoken = TickStampBlob-Output 3117 Figure 8: TUDA-Verify element in CDDL 3119 Required TPM functions: 3121 | imp_att = TPM_TickStampBlob( 3122 | keyHandle = restrictedKey_Handle, /*TPM_KEY_HANDLE*/ 3123 | antiReplay = dummyNonce, /*TPM_NONCE*/ 3124 | digestToStamp = dummyDigest) /*TPM_DIGEST*/ 3125 | 3126 | VerifyToken = imp_att 3128 Figure 9: Creating the Verify Token 3130 D.2.6. Attestation Verification Approach 3132 The seven TUDA information elements transport the essential content 3133 that is required to enable verification of the attestation statement 3134 at the Verifier. The following listings illustrate the verification 3135 algorithm to be used at the Verifier in pseudocode. The pseudocode 3136 provided covers the entire verification task. If only a subset of 3137 TUDA elements changed (see Section 6.1), only the corresponding code 3138 listings need to be re-executed. 3140 | TSA_pub = verifyCert(TSA-CA, Cert.TSA-Cert) 3141 | AIK_pub = verifyCert(AIK-CA, Cert.AIK-Cert) 3143 Figure 10: Verification of Certificates 3145 | ts_left = Synctoken.left 3146 | ts_right = Synctoken.right 3147 | 3148 | /* Reconstruct ts_right's omitted values; Alternatively assert == */ 3149 | ts_right.currentTicks.tickRate = ts_left.currentTicks.tickRate 3150 | ts_right.currentTicks.tickNonce = ts_left.currentTicks.tickNonce 3151 | 3152 | ticks_left = ts_left.currentTicks 3153 | ticks_right = ts_right.currentTicks 3154 | 3155 | /* Verify Signatures */ 3156 | verifySig(AIK_pub, dummyNonce || dummyDigest || ticks_left) 3157 | verifySig(TSA_pub, hash(ts_left) || timestamp.time) 3158 | verifySig(AIK_pub, dummyNonce || hash(timestamp) || ticks_right) 3159 | 3160 | delta_left = timestamp.time - 3161 | ticks_left.currentTicks * ticks_left.tickRate / 1000 3162 | 3163 | delta_right = timestamp.time - 3164 | ticks_right.currentTicks * ticks_right.tickRate / 1000 3166 Figure 11: Verification of Synchronization Token 3168 | compositeHash = hash_init() 3169 | for value in Composite.values: 3170 | hash_update(compositeHash, value) 3171 | compositeHash = hash_finish(compositeHash) 3172 | 3173 | certInfo = reconstruct_static(TPM-CERTIFY-INFO) 3174 | 3175 | assert(Composite.bitmask == ExpectedPCRBitmask) 3176 | assert(certInfo.pcrinfo.PCRSelection == Composite.bitmask) 3177 | assert(certInfo.pcrinfo.digestAtRelease == compositeHash) 3178 | assert(certInfo.pubkeyDigest == hash(restrictedKey_Pub)) 3179 | 3180 | verifySig(AIK_pub, dummyNonce || certInfo) 3182 Figure 12: Verification of Restriction Info 3184 | for event in Measurement-Log: 3185 | if event.pcr not in ExpectedPCRBitmask: 3186 | continue 3187 | if event.type == BIOS: 3188 | assert_whitelist-bios(event.pcr, event.template-hash) 3189 | if event.type == ima: 3190 | assert(event.pcr == 10) 3191 | assert_whitelist(event.pathname, event.filedata-hash) 3192 | assert(event.template-hash == 3193 | hash(event.pathname || event.filedata-hash)) 3194 | if event.type == ima-ng: 3195 | assert(event.pcr == 10) 3196 | assert_whitelist-ng(event.pathname, event.filedata-hash) 3197 | assert(event.template-hash == 3198 | hash(event.pathname || event.filedata-hash)) 3199 | 3200 | virtPCR[event.pcr] = hash_extend(virtPCR[event.pcr], 3201 | event.template-hash) 3202 | 3203 | for pcr in ExpectedPCRBitmask: 3204 | assert(virtPCR[pcr] == Composite.values[i++] 3206 Figure 13: Verification of Measurement Log 3208 | ts = Verifytoken 3209 | 3210 | /* Reconstruct ts's omitted values; Alternatively assert == */ 3211 | ts.currentTicks.tickRate = ts_left.currentTicks.tickRate 3212 | ts.currentTicks.tickNonce = ts_left.currentTicks.tickNonce 3213 | 3214 | verifySig(restrictedKey_pub, dummyNonce || dummyDigest || ts) 3215 | 3216 | ticks = ts.currentTicks 3217 | 3218 | time_left = delta_right + ticks.currentTicks * ticks.tickRate / 1000 3219 | time_right = delta_left + ticks.currentTicks * ticks.tickRate / 1000 3220 | 3221 | [time_left, time_right] 3223 Figure 14: Verification of Attestation Token 3225 D.3. IE Generation Procedures for TPM 2.0 3227 The pseudo code below includes general operations that are conducted 3228 as specific TPM commands: 3230 o hash() : description TBD 3232 o sig() : description TBD 3234 o X.509-Certificate() : description TBD 3236 These represent the output structure of that command in the form of a 3237 byte string value. 3239 D.3.1. AIK and AIK Certificate 3241 Attestations are based upon a cryptographic signature performed by 3242 the TPM using a so-called Attestation Identity Key (AIK). An AIK has 3243 the properties that it cannot be exported from a TPM and is used for 3244 attestations. Trust in the AIK is established by an X.509 3245 Certificate emitted by a Certificate Authority. The AIK certificate 3246 is either provided directly or via a so-called PrivacyCA 3247 [AIK-Enrollment]. 3249 This element consists of the AIK certificate that includes the AIK's 3250 public key used during verification as well as the certificate chain 3251 up to the Root CA for validation of the AIK certificate itself. 3253 TUDA-Cert = [AIK-Cert, TSA-Cert]; maybe split into two for SNMP 3254 AIK-Certificate = X.509-Certificate(AIK-Key,Restricted-Flag) 3255 TSA-Certificate = X.509-Certificate(TSA-Key, TSA-Flag) 3257 Figure 15: TUDA-Cert element for TPM 2.0 3259 D.3.2. Synchronization Token 3261 The synchronization token uses a different TPM command, TPM2 3262 GetTime() instead of TPM TickStampBlob(). The TPM2 GetTime() command 3263 contains the clock and time information of the TPM. The clock 3264 information is the equivalent of TUDA v1's tickSession information. 3266 TUDA-SyncToken = [ 3267 left_GetTime = sig(AIK-Key, 3268 TimeInfo = [ 3269 time, 3270 resetCount, 3271 restartCount 3272 ] 3273 ), 3274 middle_TimeStamp = sig(TSA-Key, 3275 hash(left_TickStampBlob), 3276 UTC-localtime 3277 ), 3278 right_TickStampBlob = sig(AIK-Key, 3279 hash(middle_TimeStamp), 3280 TimeInfo = [ 3281 time, 3282 resetCount, 3283 restartCount 3284 ] 3285 ) 3286 ] 3288 Figure 16: TUDA-Sync element for TPM 2.0 3290 D.3.3. Measurement Log 3292 The creation procedure is identical to Appendix D.2.4. 3294 Measurement-Log = [ 3295 * [ EventName, 3296 PCR-Num, 3297 Event-Hash ] 3298 ] 3300 Figure 17: TUDA-Log element for TPM 2.0 3302 D.3.4. Explicit time-based Attestation 3304 The TUDA attestation token consists of the result of TPM2_Quote() or 3305 a set of TPM2_PCR_READ followed by a TPM2_GetSessionAuditDigest. It 3306 proves that -- at a certain point-in-time with respect to the TPM's 3307 internal clock -- a certain configuration of PCRs was present, as 3308 denoted in the keys restriction information. 3310 TUDA-AttestationToken = TUDA-AttestationToken_quote / TUDA-AttestationToken_audit 3312 TUDA-AttestationToken_quote = sig(AIK-Key, 3313 TimeInfo = [ 3314 time, 3315 resetCount, 3316 restartCount 3317 ], 3318 PCR-Selection = [ * PCR], 3319 PCR-Digest := PCRDigest 3320 ) 3322 TUDA-AttestationToken_audit = sig(AIK-key, 3323 TimeInfo = [ 3324 time, 3325 resetCount, 3326 restartCount 3327 ], 3328 Session-Digest := PCRDigest 3329 ) 3331 Figure 18: TUDA-Attest element for TPM 2.0 3333 D.3.5. Sync Proof 3335 In order to proof to the Verifier that the TPM's clock was not 'fast- 3336 forwarded' the result of a TPM2_GetTime() is sent after the TUDA- 3337 AttestationToken. 3339 TUDA-SyncProof = sig(AIK-Key, 3340 TimeInfo = [ 3341 time, 3342 resetCount, 3343 restartCount 3344 ] 3345 ), 3347 Figure 19: TUDA-Proof element for TPM 2.0 3349 Acknowledgements 3351 Authors' Addresses 3353 Andreas Fuchs 3354 Fraunhofer Institute for Secure Information Technology 3355 Rheinstrasse 75 3356 Darmstadt 64295 3357 Germany 3359 Email: andreas.fuchs@sit.fraunhofer.de 3361 Henk Birkholz 3362 Fraunhofer Institute for Secure Information Technology 3363 Rheinstrasse 75 3364 Darmstadt 64295 3365 Germany 3367 Email: henk.birkholz@sit.fraunhofer.de 3369 Ira E McDonald 3370 High North Inc 3371 PO Box 221 3372 Grand Marais 49839 3373 US 3375 Email: blueroofmusic@gmail.com 3377 Carsten Bormann 3378 Universitaet Bremen TZI 3379 Bibliothekstr. 1 3380 Bremen D-28359 3381 Germany 3383 Phone: +49-421-218-63921 3384 Email: cabo@tzi.org