idnits 2.17.1 draft-birkholz-rats-tuda-06.txt: -(8): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 12 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 (12 January 2022) is 833 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 3271, but not defined == Missing Reference: 'TSA-Cert' is mentioned on line 3271, but not defined ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-11 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-14 == Outdated reference: A later version (-09) exists of draft-ietf-rats-reference-interaction-models-04 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-19 Summary: 3 errors (**), 0 flaws (~~), 8 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: 16 July 2022 I. McDonald 6 High North Inc 7 C. Bormann 8 Universität Bremen TZI 9 12 January 2022 11 Time-Based Uni-Directional Attestation 12 draft-birkholz-rats-tuda-06 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 About This Document 34 This note is to be removed before publishing as an RFC. 36 Status information for this document may be found at 37 https://datatracker.ietf.org/doc/draft-birkholz-rats-tuda/. 39 Discussion of this document takes place on the Remote ATtestation 40 ProcedureS (rats) Working Group mailing list (mailto:rats@ietf.org), 41 which is archived at https://mailarchive.ietf.org/arch/browse/rats/. 43 Source for this draft and an issue tracker can be found at 44 https://github.com/ietf-rats/draft-birkholz-rats-tuda. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on 16 July 2022. 63 Copyright Notice 65 Copyright (c) 2022 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 70 license-info) in effect on the date of publication of this document. 71 Please review these documents carefully, as they describe your rights 72 and restrictions with respect to this document. Code Components 73 extracted from this document must include Revised BSD License text as 74 described in Section 4.e of the Trust Legal Provisions and are 75 provided without warranty as described in the Revised BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Forward Authenticity . . . . . . . . . . . . . . . . . . 5 81 1.2. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 5 82 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 83 2. Remote Attestation Principles . . . . . . . . . . . . . . . . 6 84 2.1. Authenticity of Evidence . . . . . . . . . . . . . . . . 7 85 2.2. Generating Evidence about Software Component Integrity . 7 86 2.3. Measurements and Digests Generated by an Attester . . . . 8 87 2.4. Attesting Environments and Roots of Trust . . . . . . . . 8 88 2.5. Indeterministic Measurements . . . . . . . . . . . . . . 9 89 3. TUDA Principles and Requirements . . . . . . . . . . . . . . 10 90 3.1. Attesting Environment Requirements . . . . . . . . . . . 11 91 3.2. Handle Distributor Requirements: Time Stamp Authority . . 11 92 4. Information Elements and Conveyance . . . . . . . . . . . . . 12 93 5. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 12 94 5.1. TPM Specific Terms . . . . . . . . . . . . . . . . . . . 14 95 5.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 14 96 6. The TUDA Protocol Family . . . . . . . . . . . . . . . . . . 14 97 6.1. TUDA Information Elements Update Cycles . . . . . . . . . 16 98 7. Sync Base Protocol . . . . . . . . . . . . . . . . . . . . . 19 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 101 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 104 11.2. Informative References . . . . . . . . . . . . . . . . . 21 105 Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 25 106 Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 25 107 B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 26 108 B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 26 109 B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 27 110 B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 27 111 B.2. Relationship to Host Resources MIB . . . . . . . . . . . 27 112 B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 27 113 B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 28 114 B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 28 115 Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 44 116 Appendix D. Realization with TPM functions . . . . . . . . . . . 60 117 D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 60 118 D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 60 119 D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 61 120 D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 61 121 D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 61 122 D.2. IE Generation Procedures for TPM 1.2 . . . . . . . . . . 61 123 D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 62 124 D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 63 125 D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 64 126 D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 66 127 D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 67 128 D.2.6. Attestation Verification Approach . . . . . . . . . . 68 129 D.3. IE Generation Procedures for TPM 2.0 . . . . . . . . . . 70 130 D.3.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 70 131 D.3.2. Synchronization Token . . . . . . . . . . . . . . . . 71 132 D.3.3. Measurement Log . . . . . . . . . . . . . . . . . . . 71 133 D.3.4. Explicit time-based Attestation . . . . . . . . . . . 72 134 D.3.5. Sync Proof . . . . . . . . . . . . . . . . . . . . . 72 135 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 73 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 138 1. Introduction 140 Remote ATtestation procedureS (RATS) describe the attempt to 141 determine and appraise system properties, such as integrity and 142 trustworthiness, of a remote peer -- the Attester -- by the use of a 143 Verifier in support of Relying Parties that intend to interact with 144 the Attester. The Verifier carries the burden of appraisal of 145 detailed Evidence about an Attester's trustworthiness. Evidence is 146 generated by the Attester and consumed by the Verifier. To support 147 security decisions, the Verifier generates digestable Attestation 148 Results that can be easily consumed by Relying Parties. The RATS 149 architecture specifies the corresponding concepts and terms 150 [I-D.ietf-rats-architecture]. 152 TUDA uses the architectural constituents of the RATS Architecture, 153 such as the roles Attester and Verifier, and defines a method to 154 convey Conceptual Messages between them. TUDA uses the Uni- 155 Directional Remote Attestation interaction model described in 156 [I-D.ietf-rats-reference-interaction-models]. While the Conceptual 157 Message focused on in this document is RATS Evidence, any type of 158 Conceptual Message content that requires a believable indication 159 about the message's content freshness can be conveyed with TUDA (e.g. 160 Attestation Results). 162 The conveyance of Evidence in RATS must ensure that Evidence always 163 remains integrity protected, tamper-evident, originates from a 164 trustable entity (or group of entities), and is accompanied by a 165 proof of its freshness. 167 In contrast to bi-directional interactions as described by Challenge/ 168 Response Remote Attestation in 169 [I-D.ietf-rats-reference-interaction-models], TUDA enables uni- 170 directional conveyance in the interactions between Attester and 171 Verifier. TUDA allows a Verifier to receive Evidence from an 172 Attester without solicitation. Conversely, it allows a Verifier to 173 retrieve Evidence from an Attester without it being generated ad-hoc. 174 Exemplary applications of TUDA are the creation of beacons in 175 vehicular environments [IEEE1609] or authentication mechanisms based 176 on EAP [RFC5247]. 178 The generation of Evidence in RATS requires an Attesting Environment. 179 In this specification, the root of trust acting as an Attesting 180 Environment is a Trusted Platform Module (TPM, see [TPM12] and 181 [TPM2]). The Protected Capabilities [TCGGLOSS] provided by a TPM 182 support various activities in RATS, e.g., Claims collection and 183 Evidence generation. 185 A trusted coupling of Evidence generation with a global timescale is 186 enabled via a Handle Distributor. Handles generated by a Handle 187 Distributor can include nonces, signed timestamps, or other 188 structured or opaque content used as qualifying data in Evidence 189 generation. In TUDA, all RATS entities, such as the entities taking 190 on the roles of Attester and Verifier, can receive signed timestamps 191 from the Handle Distributor. These trusted timestamps replace nonces 192 in Evidence generation and Evidence appraisal 193 [I-D.ietf-rats-reference-interaction-models]. 195 1.1. Forward Authenticity 197 Nonces enable an implicit time-keeping in which the freshness of 198 Evidence is inferred by recentness. Recentness is estimated via the 199 time interval between sending a nonce as part of a challenge for 200 Evidence and the reception of Evidence based on that nonce (as 201 outlined in the interaction model depicted in section 8.1 in 202 [I-D.ietf-rats-reference-interaction-models]). Conversely, the 203 omission of nonces in TUDA allows for explicit time-keeping where 204 freshness is not inferred from recentness. Instead, a cryptographic 205 binding of a trusted synchronization to a global timescale in the 206 Evidence itself allows for Evidence that can prove past operational 207 states of an Attester. To capture and support this concept, this 208 document introduces the term Forward Authenticity. 210 Forward Authenticity: A property of secure communication protocols, 211 in which later compromise of the long-term keys of a data origin 212 does not compromise past authentication of data from that origin. 213 Forward Authenticity is achieved by timely recording of 214 authenticity Claims from Target Environments (via "audit logs" 215 during "audit sessions") that are authorized for this purpose and 216 trustworthy (via endorsed roots of trusts, for example), in a 217 time-frame much shorter than that expected for the compromise of 218 the long-term keys. 220 Forward Authenticity enables new levels of assurance and can be 221 included in basically every protocol, such as ssh, YANG Push, 222 router advertisements, link layer neighbor discovery, or even ICMP 223 echo requests. 225 1.2. TUDA Objectives 227 Time-Based Uni-directional Attestation is designed to: 229 * increase the confidence in authentication and authorization 230 procedures, 232 * address the requirements of constrained-node networks, 233 * support interaction models that do not maintain connection-state 234 over time, such as REST architectures [REST], 236 * be able to leverage existing management interfaces, such as SNMP 237 (RFC 3411, [STD62]). RESTCONF [RFC8040] or CoMI 238 [I-D.ietf-core-comi] --- and corresponding bindings, 240 * support broadcast and multicast schemes (e.g. [IEEE1609]), 242 * be able to cope with temporary loss of connectivity, and to 244 * provide trustworthy audit logs of past endpoint states. 246 1.3. Terminology 248 This document uses the terms defined in the RATS Architecture 249 [I-D.ietf-rats-architecture] and by the RATS Reference Interaction 250 Models [I-D.ietf-rats-reference-interaction-models]. 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 254 "OPTIONAL" in this document are to be interpreted as described in 255 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 256 capitals, as shown here. 258 2. Remote Attestation Principles 260 Based on the RATS Architecture, the processing of TPM generated 261 Evidence can be separated in three activities. 263 Evidence Generation: The retrieval of signed digests from an RTR 264 based on a sequence of collected Claims about software component 265 integrity (measurements). 267 Evidence Conveyance: The transfer of Evidence from the Attester to 268 the Verifier via the Internet. 270 Evidence Appraisal: The validation of Evidence signatures as well as 271 the assessment of Claim values in Evidence by comparing them with 272 Reference Values. 274 TUDA is specified in support of these RATS activities that align with 275 the definitions presented in [PRIRA] and [TCGGLOSS]. 277 2.1. Authenticity of Evidence 279 Remote attestation Evidence is composed of a set of Claims 280 (assertions about the trustworthiness of an Attester's Target 281 Environments) that is accompanied by a proof of its veracity -- 282 typically a signature based on shielded, private, and potentially 283 use-restricted key material used as an Authentication Secret as 284 specified in section 6 of 285 [I-D.ietf-rats-reference-interaction-models] (or a secure channel as 286 illustrated in [I-D.birkholz-rats-uccs]). As key material alone is 287 typically not self-descriptive with respect to its intended use (its 288 semantics), the Evidence created via TUDA MUST be accompanied by two 289 kinds of certificates that are cryptographically associated with a 290 trust anchor (TA) [RFC4949] via certification paths: 292 * an Attestation Key (AK) Certificate (AK-Cert) that represents the 293 attestation provenance of the Attesting Environment (see section 294 4.2. in [I-D.ietf-rats-architecture]) that generates Evidence, and 296 * an Endorsement Key (EK) Certificate (EK-Cert) that represents the 297 Protection Capabilities of an Attesting Environment the AK is 298 stored in. 300 If a Verifier decides to trust the TA of both an AK-Cert and an EK- 301 Cert presented by an Attester -- and thereby the included Claims 302 about the trustworthiness of an Attester's Target Environments -- the 303 Evidence generated by the Attester can be considered trustable and 304 believable. Ultimately, all trustable and believable Evidence MUST 305 be appraised by a Verifier in order to assess the trustworthiness of 306 the corresponding Attester. Assertions represented via Claims MUST 307 NOT be considered believable by themselves. 309 In this document, Evidence is generated via TPMs that come with an 310 AK-Cert and a EK-Cert as a basis for believable Evidence generation. 312 2.2. Generating Evidence about Software Component Integrity 314 Evidence generated by a TPM for TUDA is based on measured hash values 315 of all software components deployed in Target Environments (see 316 section 4.2. in [I-D.ietf-rats-architecture]) before they are 317 executed ("measure then execute"). The underlying concept of 318 "Attestation Logs" is elaborated on in Section 2.4.2. of 319 [I-D.fedorkow-rats-network-device-attestation]. This concept is 320 implemented, for example, in the Linux kernel where it is called the 321 Linux Integrity Measurement Architecture (IMA) [Safford] and used to 322 generates such a sequence of hash values. A representation for 323 conveyance of corresponding event logs is described in the Canonical 324 Event Log [CEL] specification. Open source solutions, for example, 325 based on [RFC5209] use an IMA log to enable remote attestation 326 [Steffens]. 328 An Attester MUST generate such an event/measurement log. 330 2.3. Measurements and Digests Generated by an Attester 332 A hash value of a software component is created before it is executed 333 by Attesters. These hash values are typically represented as event 334 log entries referred to as measurements, which often occur in large 335 quantities. Capabilities such as Linux IMA can be used to generate 336 these measurements on an Attester. Measurements are chained by 337 Attesters using a rolling hash function. A TPM acts as a root of 338 trust for storage (RTS) by providing an Extend ([TPM12], [TPM2]) 339 operation to feed hash values in a rolling hash function. Each 340 measurement added to the sequence of all measurements results in a 341 new current digest hash value. A TPM acts as a root of trust for 342 reporting (RTR) by providing Quote ([TPM12], [TPM2]) operations to 343 generate a digest of all currently extended hash values as Evidence. 345 TUDA requirements on TPM primitive operations and the information 346 elements processed by them are illustrated using pseudocode in 347 Appendix C and D. 349 2.4. Attesting Environments and Roots of Trust 351 The primitive operations used to generate an initial set of 352 measurements at the beginning of an Attester's boot sequence MUST be 353 provided by a Root of Trust for Measurement (RTM) that is a system 354 component of the Attester. An RTM MUST be trusted via trust- 355 relationships to TAs enabled by appropriate Endorsements (e.g.,EK- 356 Certs). If a Verifier cannot trust an RTM, measurements based on 357 values generated by the RTM MUST be considered invalid. At least one 358 RTM MUST be accessible to the first Attesting Environment in Attester 359 conducting Layered Attestation (see section 4.3. in 360 [I-D.ietf-rats-architecture]). An RTM MAY aggregate and retain 361 measurements until the first RTS becomes available in a Layered 362 Attestation procedure -- instead of feeding measurements into an RTS, 363 instantly. The Protection Capabilities of an RTM to also act as a 364 temporary RTS MUST be trusted via trust-relationships to TAs enabled 365 by appropriate Endorsements. System components supporting the use of 366 a TPM typically include such an appropriate RTM. In general, feeding 367 measurements from an initial RTM into a TPM is automated and 368 separated from Protected Capabilities that provide Claims collection 369 from Target Environments that are regular execution environments. A 370 TPM providing the Protection Capabilities for an isolated and 371 shielded location to feed measurements into (integrity and 372 confidentiality) is an appropriate RTS for TUDA. 374 The primitive operations used to store and chain measurements via a 375 rolling hash function MUST be provided by an appropriate root of 376 trust for storage (RTS) that is a system component of the Attester. 377 An RTS MUST be trusted via trust-relationships to TAs enabled by 378 appropriate Endorsements (e.g.,EK-Certs). If a Verifier cannot trust 379 an RTS, Evidence generated based on digest values acquired from the 380 RTS MUST be considered invalid. An RTS MUST be accessible to all 381 Attesting Environments that are chained in a Layered Attestation 382 procedure. A TPM providing the primitive operation for Extend is an 383 appropriate RTM for TUDA. 385 The primitive operations used to generate Evidence based on digests 386 MUST be provided by roots of trust for reporting (RTR) that are 387 system components of the Attester. An RTR MUST be be trusted via 388 trust-relationships to TAs enabled by appropriate Endorsements 389 (e.g.,EK-Certs). If a Verifier cannot trust an RTR, Evidence 390 generated by the RTR MUST be considered invalid. A TPM providing the 391 primitive operations for Quote is an appropriate RTR for TUDA. In a 392 Composite Device (see Section 3.5. in [I-D.ietf-rats-architecture] 393 conducting a Layered Attestation procedure, Attesting Environments 394 MAY not be TPMs. At least one Attesting Environment MUST be a TPM. 395 At least one TPM MUST act as an RTR. Attesting Environments that are 396 not TPMs MUST NOT act as an RTR. 398 A concise definition of the terms RTM, RTS, and RTR can be found in 399 the Trusted Computing Group (TCG) Glossary [TCGGLOSS]. An RTS and an 400 RTR are often tightly coupled. In TUDA, a Trusted Platform Module 401 (TPM, see [TPM12] and [TPM2]) takes on the roles of an RTS and an 402 RTR. The specification in this document requires the use of a TPM as 403 a component of the Attester. The protocol part of this specification 404 can also be used with other RTS and RTR as long as essential 405 functional requirements are satisfied (e.g., a trusted relative 406 source of time, such as a tick-counter). A sequence of Layered 407 Attestation using at least an RTM, RTS, and RTR enables an 408 authenticated boot sequence typically referred to as Secure Boot. 410 2.5. Indeterministic Measurements 412 The sequence of measurements that is extended into the RTS provided 413 by a TPM may not be deterministic due to race conditions that are 414 side-effects of parallelization. Parallelization occurs, for 415 example, between different isolated execution environments or 416 separate software components started in a execution environment. In 417 order to enable the appraisal of Evidence in cases where sequence of 418 measurement varies, a corresponding event log that records all 419 measurements in sequence, such as the IMA log, has to be conveyed 420 next to the Evidence as depicted in section 8.2. in 421 [I-D.ietf-rats-reference-interaction-models]. 423 In contrast to Evidence, event logs do not necessarily have to be 424 integrity protected or tamper-evident. Event logs are conveyed to a 425 Verifier in order to compute the reference values required for 426 comparison with digest values (output of TPM Quote operations). 427 While digest values MUST constitute Evidence, measurements in event 428 logs MAY be part of Evidence, but do not have to be MAY be conveyed 429 separately. If the values in event logs or their sequence are 430 tampered with before or during conveyance from an Attester to a 431 Verifier, the corresponding Evidence Appraisal fails. While this 432 dependency reflects the intended behavior of RATS, integrity 433 protected or tamper-evident can be beneficial or convenient in some 434 usage scenarios. Additionally, event logs my allow insights into the 435 composition of an Attester and typically come with confidentiality 436 requirements. 438 In order to compute reference values to compare digest Claims in 439 Evidence with, a Verifier MUST be able to replay the rolling hash 440 function of the Extend operation provided by a TPM (see 441 Section 2.4.2. in [I-D.fedorkow-rats-network-device-attestation]). 443 A Verifier has to replay the event log using its own extend operation 444 with an identical rolling hash function in order to generate 445 reference values as outlined in section 2.4.1. of 446 [I-D.fedorkow-rats-network-device-attestation]. During reply, the 447 validity of each event log record MUST be appraised individually by 448 the Verifier in order to infer if each started software component 449 satisfies integrity requirements. These appraisal procedures require 450 Reference Integrity Measurements/Manifests (RIM) as are provided via 451 [I-D.birkholz-rats-coswid-rim] or [TCGRIM]. Each RIM includes 452 Reference Values that are nominal reference hash values for sets of 453 software components. The Reference Values can be compared with hash 454 values about executed software components included in an event log. 455 A Verifier requires an appropriate set of RIMs to compare every 456 record in an event log successfully. RIMs or other sets Reverence 457 Value are supplied by Reference Value Providers as defined in the 458 RATS Architecture [I-D.ietf-rats-architecture]. Corresponding 459 procedures that enable a Verifier to acquire Reference Values are 460 out-of-scope of this document. 462 3. TUDA Principles and Requirements 464 Traditional remote attestation protocols typically use bi-directional 465 challenge/response interaction models. Examples include the Platform 466 Trust Service protocol [PTS] or CAVES [PRIRA], where one entity sends 467 a challenge that is included inside the response to prove the 468 freshness of Evidence via recentness. The corresponding interaction 469 model depicted in Section 8.1. of 470 [I-D.ietf-rats-reference-interaction-models] tightly couples the 471 three RATS activities of generating, conveying and appraising 472 Evidence. 474 Time-Based Uni-directional Attestation can decouple these three 475 activities. As a result, TUDA provides additional capabilities, such 476 as: 478 * remote attestation for Attesters that might not always be able to 479 reach the Internet by enabling the appraisal of past states, 481 * secure audit logs by combining the Evidence generated with 482 integrity measurement logs (e.g. IMA logs) that represent a 483 detailed record of corresponding past states, 485 * the use of the uni-directional interaction model 486 [I-D.ietf-rats-reference-interaction-models] that can traverse 487 "diode-like" network security functions (NSF) or can be leveraged 488 RESTful telemetry as enabled by the CoAP Observe option 489 [RFC7252]). 491 3.1. Attesting Environment Requirements 493 An Attesting Environment that generates Evidence in TUDA MUST support 494 three specific Protected Capabilities: 496 * Platform Configuration Registers (PCR) that can extend 497 measurements consecutively and represent the sequence of 498 measurements as a single digest, 500 * Restricted Signing Keys (RSK) that can only be accessed, if a 501 specific signature about a set of measurements can be provided as 502 authentication, and 504 * a dedicated source of (relative) time, e.g. a tick counter (a tick 505 being a specific time interval, for example 10 ms). 507 A TPM is capable of providing these Protected Capabilities for TUDA. 509 3.2. Handle Distributor Requirements: Time Stamp Authority 511 Both Evidence generation and Evidence appraisal require a Handle 512 Distributor that can take on the role of a trusted Time Stamp 513 Authority (TSA) as an additional third party. Time Stamp Tokens 514 (TST) included in Handles MUST be generated by Time Stamp Authority 515 based on [RFC3161] that acts as the Handle Distributor. The 516 combination of a local source of time provided by a TPM (on the 517 Attester) and the TST provided by the Handle Distributor (to both the 518 Attester and the Verifier) enable an appropriate proof of freshness. 520 4. Information Elements and Conveyance 522 TUDA defines a set of information elements (IE) that represent a set 523 of Claims, are generated and stored on the Attester, and are intended 524 to be transferred to the Verifier in order to enable the appraisal of 525 Evidence. Each TUDA IE: 527 * MUST be encoded in the Concise Binary Object Representation (CBOR 528 [RFC8949]) to minimize the volume of data in motion. In this 529 document, the composition of the CBOR data items that represent IE 530 is described using the Concise Data Definition Language, CDDL 531 [RFC8610]. 533 * that requires a certain freshness SHOULD only be re-generated when 534 out-dated (not fresh, but stale), which reduces the overall 535 resources required from the Attester, including the usage of a 536 TPM's resources (re-generation of IE is determined by their age or 537 by specific state changes on the Attester, e.g., due to a reboot- 538 cycle) 540 * SHOULD only be transferred when required, which reduces the amount 541 of data in motion necessary to conduct remote attestation 542 significantly (only IE that have changed since their last 543 conveyance have to be transferred) 545 * that requires a certain freshness SHOULD be reused for multiple 546 remote attestation procedures in the limits of its corresponding 547 freshness-window, further reducing the load imposed on the 548 Attester and corresponding TPMs. 550 5. TUDA Core Concept 552 Traditional Challenge/Response Remote Attestation 553 [I-D.ietf-rats-reference-interaction-models] includes sending a nonce 554 in the challenge to be used in ad-hoc Evidence generation. Using the 555 TPM 1.2 as an example, a corresponding nonce-challenge would be 556 included within the signature created by the TPM_Quote command in 557 order to prove the freshness of a response containing evidence, see 558 e.g. [PTS]. 560 In contrast, the TUDA protocol uses the combined output of 561 TPM_CertifyInfo and TPM_TickStampBlob. The former provides a proof 562 about the Attester's state by creating Evidence that a certain key is 563 bound to that state. The latter provides proof that the Attester was 564 in the specified state by using the bound key in a time operation. 565 This combination enables a time-based attestation scheme. The 566 approach is based on the concepts introduced in [SCALE] and 567 [SFKE2008]. 569 Each TUDA IE has an individual time-frame, in which it is considered 570 to be fresh (and therefore valid and trustworthy). In consequence, 571 each TUDA IE that composes data in motion is based on different 572 methods of creation. 574 As highlighted above, the freshness properties of a challenge- 575 response based protocol enable implicit time-keeping via a time 576 window between: 578 * the time of transmission of the nonce, and 580 * the reception of the corresponding response. 582 Given the time-based attestation scheme, the freshness property of 583 TUDA is equivalent to that of bi-directional challenge response 584 attestation, if the point-in-time of attestation lies between: 586 * the transmission of a TUDA time-synchronization token, and 588 * the typical round-trip time between the Verifier and the Attester. 590 The accuracy of this time-frame is defined by two factors: 592 * the time-synchronization between the Attester and the Handle 593 Distributor. The time between the two tickstamps acquired via the 594 RoT define the scope of the maximum drift (time "left" and time 595 "right" in respect to the timeline) to the handle including the 596 signed timestamp, and 598 * the drift of clocks included in the RoT. 600 Since the conveyance of TUDA Evidence does not rely upon a Verifier 601 provided value (i.e. the nonce), the security guarantees of the 602 protocol only incorporate the Handle Distributor and the RoT used. 603 In consequence, TUDA Evidence can even serve as proof of integrity in 604 audit logs with precise point-in-time guarantees. 606 Appendix A contains guidance on how to utilize a REST architecture. 608 Appendix B contains guidance on how to create an SNMP binding and a 609 corresponding TUDA-MIB. 611 Appendix C contains a corresponding YANG module that supports both 612 RESTCONF and CoREDONF. 614 Appendix D.2 contains a realization of TUDA using TPM 1.2 primitives. 616 Appendix D.3 contains a realization of TUDA using TPM 2.0 primitives. 618 5.1. TPM Specific Terms 620 PCR: A Platform Configuration Register that is part of the TPM and 621 is used to securely store and report measurements about security 622 posture 624 PCR-Hash: A hash value of the security posture measurements stored 625 in a TPM PCR (e.g. regarding running software instances) 626 represented as a byte-string 628 5.2. Certificates 630 HD-CA: The Certificate Authority that provides the certificate for 631 the TSA role of a Handle Distributor (HD) 633 AIK-CA: The Certificate Authority that provides the certificate for 634 the AK of the TPM. This is the client platform credential for 635 this protocol. It is a placeholder for a specific CA and AK-Cert 636 is a placeholder for the corresponding certificate, depending on 637 what protocol was used. The specific protocols are out of scope 638 for this document, see also [AIK-Enrollment] and [IEEE802.1AR]. 640 6. The TUDA Protocol Family 642 Time-Based Uni-Directional Attestation consists of the following 643 seven information elements: 645 Handle Distributor Certificate: The certificate of the Handle 646 Distributor that takes on the role of TSA. The Handle Distributor 647 certificate is used in a subsequent synchronization protocol 648 tokens. This certificate is signed by the HD-CA. 650 AK Certificate: A certificate about the Attestation Key (AIK) used. 651 An AK-Cert may be an [IEEE802.1AR] IDevID or LDevID, depending on 652 their setting of the corresponding identity property 653 ([AIK-Credential], [AIK-Enrollment]; see Appendix D.2.1). 655 Synchronization Token: The reference frame for Evidence is provided 656 by the relative timestamps generated by the TPM. In order to put 657 Evidence into relation with a Real Time Clock (RTC), it is 658 necessary to provide a cryptographic synchronization between these 659 trusted relative timestamps and the regular RTC that is a hardware 660 component of the Attester. To do so, trustable timestamps are 661 acquired from a Handle Distributor. 663 Restriction Info: Evidence Generation relies on the capability of 664 the Rot to operate on restricted keys. Whenever the PCR values of 665 an Attesting Environment change, a new restricted key is created 666 that can only be operated as long as the PCRs remain in their 667 current state. 669 In order to prove to the Verifier that this restricted temporary 670 key actually has these properties and also to provide the PCR 671 value that it is restricted, the corresponding signing 672 capabilities of the RoT are used. The TPM creates a signed 673 certificate using the AK about the newly created restricted key. 675 Measurement Log: A Verifier requires the means to derive the PCRs' 676 values in order to appraise the trustworthiness of an Attester. 677 As such, a list of those elements that were extended into the PCRs 678 is reported. For certain environments, this step may be optional 679 if a list of valid PCR configurations (in the form of RIM 680 available to the Verifier) exists and no measurement log is 681 required. 683 Implicit Evidence: The actual Evidence is then based on a signed 684 timestamp provided by the RoT using the restricted temporary key 685 that was certified in the steps above. The signed timestamp 686 generated provides the trustable assertion that at this point in 687 time (with respect to the relative time of the TPM s tick counter) 688 a certain configuration existed (namely the PCR values associated 689 with the restricted key). In combination with the synchronization 690 token this timestamp represented in relative time can then be 691 related to the real-time clock. 693 Concise SWID tags: As an option to better assess the trustworthiness 694 of an Attester, a Verifier can request the reference hashes (RIM, 695 sometimes called golden measurements, known-good-values, or 696 nominal values) of all started software components to compare them 697 with the entries in a measurement log. References hashes 698 regarding installed (and therefore running) software can be 699 provided by the manufacturer via SWID tags. SWID tags are 700 provided by the Attester using the Concise SWID representation 701 [I-D.ietf-sacm-coswid] and bundled into a collection (a RIM 702 Manifest [I-D.birkholz-rats-coswid-rim]). 704 These information elements can be sent en bloc, but it is recommended 705 to retrieve them separately to save bandwidth, since these elements 706 have different update cycles. In most cases, retransmitting all 707 seven information elements would result in unnecessary redundancy. 709 Furthermore, in some scenarios it might be feasible not to store all 710 elements on the Attester, but instead they could be retrieved from 711 another location or be pre-deployed to the Verifier. It is also 712 feasible to only store public keys on the Verifier and skip 713 certificate provisioning completely in order to save bandwidth and 714 computation time for certificate verification. 716 6.1. TUDA Information Elements Update Cycles 718 An Attester can be in various states during its uptime cycles. For 719 TUDA, a subset of these states (which imply associated information) 720 are important to the Evidence Generation. The specific states 721 defined are: 723 * persistent, even after a hard reboot: includes certificates that 724 are associated with the endpoint itself or with services it relies 725 on. 727 * volatile to a degree: may change at the beginning of each boot 728 cycle. This includes the capability of a TPM to provide relative 729 time which provides the basis for the synchronization token and 730 implicit attestation -- and which can reset after an Attester is 731 powered off. 733 * very volatile: can change during any time of an uptime cycle 734 (periods of time an Attester is powered on, starting with its boot 735 sequence). This includes the content of PCRs of a hardware RoT 736 and thereby also the PCR-restricted signing keys used for 737 attestation. 739 Depending on this "lifetime of state", data has to be transported 740 over the wire, or not. E.g. information that does not change due to 741 a reboot typically has to be transported only once between the 742 Attester and the Verifier. 744 There are three kinds of events that require fresh Evidence to be 745 generated: 747 * The Attester completes a boot-cycle 749 * A relevant PCR changes 751 * Too much time has passed since the Evidence Generation 753 The third event listed above is variable per application use case and 754 also depends on the precision of the clock included in the RoT. For 755 usage scenarios, in which the Attester would periodically push 756 information to be used in an audit-log, a time-frame of approximately 757 one update per minute should be sufficient. For those usage 758 scenarios, where Verifiers request (pull) fresh Evidence, an 759 implementation could potentially use a TPM continuously to always 760 present the most freshly created Evidence. This kind of utilization 761 can result in a bottle-neck with respect to other purposes: if 762 unavoidable, a periodic interval of once per ten seconds is 763 recommended, which typically leaves about 80% of available TPM 764 resource for other applications. 766 The following diagram is based on the reference interaction model 767 found in section 8.1. of [I-D.ietf-rats-reference-interaction-models] 768 and is enriched with the IE update cycles defined in this section. 770 .----------. .----------. 771 | Attester | | Verifier | 772 '----------' '----------' 773 | | 774 boot | 775 | | 776 valueGeneration(targetEnvironment) | 777 | => claims | 778 | .--------------------. | 779 | <----------handle | | | 780 | | Handle Distributor | | 781 | | | handle----------> | 782 | '--------------------' | 783 syncTokenGeneration | 784 | => syncToken | 785 | | 786 restrictedKeyGeneration | 787 restrictedKeyCertify | 788 | | 789 evidenceGeneration(handle, authSecIDs, collectedClaims) | 790 | => evidence | 791 | | 792 | pushAKCert ----------------------------------------------> | 793 | pushSyncToken -------------------------------------------> | 794 | pushCertifyInfo -----------------------------------------> | 795 | pushEventLog --------------------------------------------> | 796 | pushEvidenceon ------------------------------------------> | 797 | | 798 | evidenceAppraisal(evidence, eventLog, refClaims) 799 | attestationResult <= | 800 ~ ~ 801 pcr-change | 802 | | 803 restrictedKeyGeneration | 804 restrictedKeyCertify | 805 | | 806 evidenceGeneration(handle, authSecIDs, collectedClaims) | 807 | => evidence | 808 | | 809 | pushCertifyInfo -----------------------------------------> | 810 | pushEventLog --------------------------------------------> | 811 | pushEvidenceon ------------------------------------------> | 812 | | 813 | evidenceAppraisal(evidence, eventLog, refClaims) 814 | attestationResult <= | 815 | | 817 Figure 1: Example sequence of events 819 7. Sync Base Protocol 821 The uni-directional approach of TUDA requires evidence on how the TPM 822 time represented in ticks (relative time since boot of the TPM) 823 relates to the standard time provided by the TSA. The Sync Base 824 Protocol (SBP) creates evidence that binds the TPM tick time to the 825 TSA timestamp. The binding information is used by and conveyed via 826 the Sync Token (TUDA IE). There are three actions required to create 827 the content of a Sync Token: 829 * At a given point in time (called "left"), a signed tickstamp 830 counter value is acquired from the hardware RoT. The hash of 831 counter and signature is used as a nonce in the request directed 832 at the TSA. 834 * The corresponding response includes a data-structure incorporating 835 the trusted timestamp token and its signature created by the TSA. 837 * At the point-in-time the response arrives (called "right"), a 838 signed tickstamp counter value is acquired from the hardware RoT 839 again, using a hash of the signed TSA timestamp as a nonce. 841 The three time-related values --- the relative timestamps provided by 842 the hardware RoT ("left" and "right") and the TSA timestamp --- and 843 their corresponding signatures are aggregated in order to create a 844 corresponding Sync Token to be used as a TUDA Information Element 845 that can be conveyed as evidence to a Verifier. 847 The drift of a clock incorporated in the hardware RoT that drives the 848 increments of the tick counter constitutes one of the triggers that 849 can initiate a TUDA Information Element Update Cycle in respect to 850 the freshness of the available Sync Token. 852 8. IANA Considerations 854 This memo includes requests to IANA, including registrations for 855 media type definitions. 857 TBD 859 9. Security Considerations 861 There are Security Considerations. TBD 863 10. Contributors 865 TBD 867 11. References 869 11.1. Normative References 871 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 872 Requirement Levels", BCP 14, RFC 2119, 873 DOI 10.17487/RFC2119, March 1997, 874 . 876 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 877 "Internet X.509 Public Key Infrastructure Time-Stamp 878 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 879 2001, . 881 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 882 Authentication Protocol (EAP) Key Management Framework", 883 RFC 5247, DOI 10.17487/RFC5247, August 2008, 884 . 886 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 887 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 888 . 890 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 891 Protocol (HTTP/1.1): Message Syntax and Routing", 892 RFC 7230, DOI 10.17487/RFC7230, June 2014, 893 . 895 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 896 Application Protocol (CoAP)", RFC 7252, 897 DOI 10.17487/RFC7252, June 2014, 898 . 900 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 901 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 902 DOI 10.17487/RFC7540, May 2015, 903 . 905 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 906 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 907 . 909 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 910 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 911 May 2017, . 913 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 914 Definition Language (CDDL): A Notational Convention to 915 Express Concise Binary Object Representation (CBOR) and 916 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 917 June 2019, . 919 [RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190, 920 RFC 8820, DOI 10.17487/RFC8820, June 2020, 921 . 923 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 924 Representation (CBOR)", STD 94, RFC 8949, 925 DOI 10.17487/RFC8949, December 2020, 926 . 928 11.2. Informative References 930 [AIK-Credential] 931 TCG Infrastructure Working Group, "TCG Credential 932 Profile", 2007, . 935 [AIK-Enrollment] 936 TCG Infrastructure Working Group, "A CMC Profile for AIK 937 Certificate Enrollment", 2011, 938 . 941 [CEL] TCG TNC Working Group, "DRAFT Canonical Event Log Format 942 Version: 1.0, Revision: .12", 2018. 944 [I-D.birkholz-rats-coswid-rim] 945 Birkholz, H., Uiterwijk, P., Waltermire, D., Bhandari, S., 946 and J. Fitzgerald-McKay, "Reference Integrity Measurement 947 Extension for Concise Software Identities", Work in 948 Progress, Internet-Draft, draft-birkholz-rats-coswid-rim- 949 02, 13 January 2021, . 952 [I-D.birkholz-rats-uccs] 953 Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. 954 Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", 955 Work in Progress, Internet-Draft, draft-birkholz-rats- 956 uccs-03, 8 March 2021, . 959 [I-D.fedorkow-rats-network-device-attestation] 960 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 961 based Network Device Remote Integrity Verification", Work 962 in Progress, Internet-Draft, draft-fedorkow-rats-network- 963 device-attestation-05, 16 April 2020, 964 . 967 [I-D.ietf-core-comi] 968 Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and 969 I. Petrov, "CoAP Management Interface (CORECONF)", Work in 970 Progress, Internet-Draft, draft-ietf-core-comi-11, 17 971 January 2021, . 974 [I-D.ietf-rats-architecture] 975 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 976 W. Pan, "Remote Attestation Procedures Architecture", Work 977 in Progress, Internet-Draft, draft-ietf-rats-architecture- 978 14, 9 December 2021, . 981 [I-D.ietf-rats-reference-interaction-models] 982 Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference 983 Interaction Models for Remote Attestation Procedures", 984 Work in Progress, Internet-Draft, draft-ietf-rats- 985 reference-interaction-models-04, 26 July 2021, 986 . 989 [I-D.ietf-sacm-coswid] 990 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 991 Waltermire, "Concise Software Identification Tags", Work 992 in Progress, Internet-Draft, draft-ietf-sacm-coswid-19, 20 993 October 2021, . 996 [IEEE1609] IEEE Computer Society, "1609.4-2016 - IEEE Standard for 997 Wireless Access in Vehicular Environments (WAVE) -- Multi- 998 Channel Operation", IEEE Std 1609.4, 2016. 1000 [IEEE802.1AR] 1001 IEEE Computer Society, "802.1AR-2009 - IEEE Standard for 1002 Local and metropolitan area networks - Secure Device 1003 Identity", IEEE Std 802.1AR, 2009. 1005 [PRIRA] Coker, G., Guttman, J., Loscocco, P., Herzog, A., Millen, 1006 J., O'Hanlon, B., Ramsdell, J., Segall, A., Sheehy, J., 1007 and B. Sniffen, "Principles of Remote Attestation", 1008 Springer International Journal of Information Security, 1009 Vol. 10, pp. 63-81, DOI 10.1007/s10207-011-0124-7, 23 1010 April 2011, . 1012 [PTS] TCG TNC Working Group, "TCG Attestation PTS Protocol 1013 Binding to TNC IF-M", 2011, 1014 . 1017 [REST] Fielding, R., "Architectural Styles and the Design of 1018 Network-based Software Architectures", Ph.D. Dissertation, 1019 University of California, Irvine, 2000, 1020 . 1023 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1024 for Network Management of TCP/IP-based internets: MIB-II", 1025 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 1026 . 1028 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", 1029 RFC 2790, DOI 10.17487/RFC2790, March 2000, 1030 . 1032 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1033 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1034 . 1036 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1037 Tardo, "Network Endpoint Assessment (NEA): Overview and 1038 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1039 . 1041 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1042 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1043 DOI 10.17487/RFC6933, May 2013, 1044 . 1046 [Safford] Safford, D., Zohar, M., and R. Sailer, "Using IMA for 1047 Integrity Measurement and Attestation", Linux Plumbers 1048 Conference 2009 , 2009. 1050 [SCALE] Fuchs, A., "Improving Scalability for Remote Attestation", 1051 Master Thesis (Diplomarbeit), Technische Universitaet 1052 Darmstadt, Germany, 2008. 1054 [SFKE2008] Stumpf, F., Fuchs, A., Katzenbeisser, S., and C. Eckert, 1055 "Improving the scalability of platform attestation", 1056 ACM Proceedings of the 3rd ACM workshop on Scalable 1057 trusted computing - STC '08, page 1-10, 1058 DOI 10.1145/1456455.1456457, 2008, 1059 . 1061 [STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An 1062 Architecture for Describing Simple Network Management 1063 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1064 December 2002. 1066 Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1067 "Message Processing and Dispatching for the Simple Network 1068 Management Protocol (SNMP)", STD 62, RFC 3412, December 1069 2002. 1071 Levi, D., Meyer, P., and B. Stewart, "Simple Network 1072 Management Protocol (SNMP) Applications", STD 62, 1073 RFC 3413, December 2002. 1075 Blumenthal, U. and B. Wijnen, "User-based Security Model 1076 (USM) for version 3 of the Simple Network Management 1077 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1079 Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 1080 Access Control Model (VACM) for the Simple Network 1081 Management Protocol (SNMP)", STD 62, RFC 3415, December 1082 2002. 1084 Presuhn, R., Ed., "Version 2 of the Protocol Operations 1085 for the Simple Network Management Protocol (SNMP)", 1086 STD 62, RFC 3416, December 2002. 1088 Presuhn, R., Ed., "Transport Mappings for the Simple 1089 Network Management Protocol (SNMP)", STD 62, RFC 3417, 1090 December 2002. 1092 Presuhn, R., Ed., "Management Information Base (MIB) for 1093 the Simple Network Management Protocol (SNMP)", STD 62, 1094 RFC 3418, December 2002. 1096 1098 [Steffens] Steffen, A., "The linux Integrity Measurement Architecture 1099 and TPM-based Network Endpoint Assessment", Linux Security 1100 Summit , 2012. 1102 [TCGGLOSS] TCG, "TCG Glossary", 2012, 1103 . 1106 [TCGRIM] TCG, "TCG Reference Integrity Manifest (RIM) Information 1107 Model", 2019, . 1110 [TPM12] "Information technology -- Trusted Platform Module -- Part 1111 1: Overview", ISO/IEC 11889-1, 2009. 1113 [TPM2] Trusted Computing Group, "Trusted Platform Module Library 1114 Specification, Family 2.0, Level 00, Revision 01.16 ed.", 1115 2014. 1117 Appendix A. REST Realization 1119 Each of the seven data items is defined as a media type (Section 8). 1120 Representations of resources for each of these media types can be 1121 retrieved from URIs that are defined by the respective servers 1122 [RFC8820]. As can be derived from the URI, the actual retrieval is 1123 via one of the HTTPs ([RFC7230], [RFC7540]) or CoAP [RFC7252]. How a 1124 client obtains these URIs is dependent on the application; e.g., CoRE 1125 Web links [RFC6690] can be used to obtain the relevant URIs from the 1126 self-description of a server, or they could be prescribed by a 1127 RESTCONF data model [RFC8040]. 1129 Appendix B. SNMP Realization 1131 SNMPv3 (RFC 3411, [STD62]) is widely available on computers and also 1132 constrained devices. To transport the TUDA information elements, an 1133 SNMP MIB is defined below which encodes each of the seven TUDA 1134 information elements into a table. Each row in a table contains a 1135 single read-only columnar SNMP object of datatype OCTET-STRING. The 1136 values of a set of rows in each table can be concatenated to 1137 reconstitute a CBOR-encoded TUDA information element. The Verifier 1138 can retrieve the values for each CBOR fragment by using SNMP GetNext 1139 requests to "walk" each table and can decode each of the CBOR-encoded 1140 data items based on the corresponding CDDL [RFC8610] definition. 1142 Design Principles: 1144 1. Over time, TUDA attestation values age and should no longer be 1145 used. Every table in the TUDA MIB has a primary index with the 1146 value of a separate scalar cycle counter object that 1147 disambiguates the transition from one attestation cycle to the 1148 next. 1150 2. Over time, the measurement log information (for example) may grow 1151 large. Therefore, read-only cycle counter scalar objects in all 1152 TUDA MIB object groups facilitate more efficient access with SNMP 1153 GetNext requests. 1155 3. Notifications are supported by an SNMP trap definition with all 1156 of the cycle counters as bindings, to alert a Verifier that a new 1157 attestation cycle has occurred (e.g., synchronization data, 1158 measurement log, etc. have been updated by adding new rows and 1159 possibly deleting old rows). 1161 B.1. Structure of TUDA MIB 1163 The following table summarizes the object groups, tables and their 1164 indexes, and conformance requirements for the TUDA MIB: 1166 +=============+=======+==========+==========+==========+ 1167 | Group/Table | Cycle | Instance | Fragment | Required | 1168 +=============+=======+==========+==========+==========+ 1169 | General | | | | x | 1170 +-------------+-------+----------+----------+----------+ 1171 | AIKCert | x | x | x | | 1172 +-------------+-------+----------+----------+----------+ 1173 | TSACert | x | x | x | | 1174 +-------------+-------+----------+----------+----------+ 1175 | SyncToken | x | | x | x | 1176 +-------------+-------+----------+----------+----------+ 1177 | Restrict | x | | | x | 1178 +-------------+-------+----------+----------+----------+ 1179 | Measure | x | x | | | 1180 +-------------+-------+----------+----------+----------+ 1181 | VerifyToken | x | | | x | 1182 +-------------+-------+----------+----------+----------+ 1183 | SWIDTag | x | x | x | | 1184 +-------------+-------+----------+----------+----------+ 1186 Table 1 1188 B.1.1. Cycle Index 1190 A tudaV1CycleIndex is the: 1192 1. first index of a row (element instance or element fragment) in 1193 the tudaV1Table; 1195 2. identifier of an update cycle on the table, when rows were added 1196 and/or deleted from the table (bounded by tudaV1Cycles); 1197 and 1199 3. binding in the tudaV1TrapV2Cycles notification for directed 1200 polling. 1202 B.1.2. Instance Index 1204 A tudaV1InstanceIndex is the: 1206 1. second index of a row (element instance or element fragment) in 1207 the tudaV1Table; except for 1209 2. a row in the tudaV1SyncTokenTable (that has only one instance per 1210 cycle). 1212 B.1.3. Fragment Index 1214 A tudaV1FragmentIndex is the: 1216 1. last index of a row (always an element fragment) in the 1217 tudaV1Table; and 1219 2. accomodation for SNMP transport mapping restrictions for large 1220 string elements that require fragmentation. 1222 B.2. Relationship to Host Resources MIB 1224 The General group in the TUDA MIB is analogous to the System group in 1225 the Host Resources MIB [RFC2790] and provides context information for 1226 the TUDA attestation process. 1228 The Verify Token group in the TUDA MIB is analogous to the Device 1229 group in the Host MIB and represents the verifiable state of a TPM 1230 device and its associated system. 1232 The SWID Tag group (containing a Concise SWID reference hash profile 1233 [I-D.ietf-sacm-coswid]) in the TUDA MIB is analogous to the Software 1234 Installed and Software Running groups in the Host Resources MIB 1235 [RFC2790]. 1237 B.3. Relationship to Entity MIB 1239 The General group in the TUDA MIB is analogous to the Entity General 1240 group in the Entity MIB v4 [RFC6933] and provides context information 1241 for the TUDA attestation process. 1243 The SWID Tag group in the TUDA MIB is analogous to the Entity Logical 1244 group in the Entity MIB v4 [RFC6933]. 1246 B.4. Relationship to Other MIBs 1248 The General group in the TUDA MIB is analogous to the System group in 1249 MIB-II [RFC1213] and the System group in the SNMPv2 MIB (RFC 3418, 1250 [STD62]) and provides context information for the TUDA attestation 1251 process. 1253 B.5. Definition of TUDA MIB 1255 1256 TUDA-V1-ATTESTATION-MIB DEFINITIONS ::= BEGIN 1258 IMPORTS 1259 MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, 1260 enterprises, NOTIFICATION-TYPE 1261 FROM SNMPv2-SMI -- RFC 2578 1262 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 1263 FROM SNMPv2-CONF -- RFC 2580 1264 SnmpAdminString 1265 FROM SNMP-FRAMEWORK-MIB; -- RFC 3411 1267 tudaV1MIB MODULE-IDENTITY 1268 LAST-UPDATED "202101130000Z" -- 13 January 2021 1269 ORGANIZATION 1270 "Fraunhofer SIT" 1271 CONTACT-INFO 1272 "Andreas Fuchs 1273 Fraunhofer Institute for Secure Information Technology 1274 Email: andreas.fuchs@sit.fraunhofer.de 1276 Henk Birkholz 1277 Fraunhofer Institute for Secure Information Technology 1278 Email: henk.birkholz@sit.fraunhofer.de 1280 Ira E McDonald 1281 High North Inc 1282 Email: blueroofmusic@gmail.com 1284 Carsten Bormann 1285 Universitaet Bremen TZI 1286 Email: cabo@tzi.org" 1288 DESCRIPTION 1289 "The MIB module for monitoring of time-based unidirectional 1290 attestation information from a network endpoint system, 1291 based on the Trusted Computing Group TPM 1.2 definition. 1293 Copyright (C) High North Inc (2021)." 1295 REVISION "202101130000Z" -- 13 January 2021 1296 DESCRIPTION 1297 "Twelfth version, published as draft-birkholz-rats-tuda-04." 1299 REVISION "202007130000Z" -- 13 July 2020 1300 DESCRIPTION 1301 "Eleventh version, published as draft-birkholz-rats-tuda-03." 1303 REVISION "202003090000Z" -- 09 March 2020 1304 DESCRIPTION 1305 "Tenth version, published as draft-birkholz-rats-tuda-02." 1307 REVISION "201909110000Z" -- 11 September 2019 1308 DESCRIPTION 1309 "Ninth version, published as draft-birkholz-rats-tuda-01." 1311 REVISION "201903120000Z" -- 12 March 2019 1312 DESCRIPTION 1313 "Eighth version, published as draft-birkholz-rats-tuda-00." 1315 REVISION "201805030000Z" -- 03 May 2018 1316 DESCRIPTION 1317 "Seventh version, published as draft-birkholz-i2nsf-tuda-03." 1319 REVISION "201805020000Z" -- 02 May 2018 1320 DESCRIPTION 1321 "Sixth version, published as draft-birkholz-i2nsf-tuda-02." 1323 REVISION "201710300000Z" -- 30 October 2017 1324 DESCRIPTION 1325 "Fifth version, published as draft-birkholz-i2nsf-tuda-01." 1327 REVISION "201701090000Z" -- 09 January 2017 1328 DESCRIPTION 1329 "Fourth version, published as draft-birkholz-i2nsf-tuda-00." 1331 REVISION "201607080000Z" -- 08 July 2016 1332 DESCRIPTION 1333 "Third version, published as draft-birkholz-tuda-02." 1335 REVISION "201603210000Z" -- 21 March 2016 1336 DESCRIPTION 1337 "Second version, published as draft-birkholz-tuda-01." 1339 REVISION "201510180000Z" -- 18 October 2015 1340 DESCRIPTION 1341 "Initial version, published as draft-birkholz-tuda-00." 1342 ::= { enterprises fraunhofersit(21616) mibs(1) tudaV1MIB(1) } 1344 tudaV1MIBNotifications OBJECT IDENTIFIER ::= { tudaV1MIB 0 } 1345 tudaV1MIBObjects OBJECT IDENTIFIER ::= { tudaV1MIB 1 } 1346 tudaV1MIBConformance OBJECT IDENTIFIER ::= { tudaV1MIB 2 } 1348 -- 1349 -- General 1350 -- 1351 tudaV1General OBJECT IDENTIFIER ::= { tudaV1MIBObjects 1 } 1353 tudaV1GeneralCycles OBJECT-TYPE 1354 SYNTAX Counter32 1355 MAX-ACCESS read-only 1356 STATUS current 1357 DESCRIPTION 1358 "Count of TUDA update cycles that have occurred, i.e., 1359 sum of all the individual group cycle counters. 1361 DEFVAL intentionally omitted - counter object." 1362 ::= { tudaV1General 1 } 1364 tudaV1GeneralVersionInfo OBJECT-TYPE 1365 SYNTAX SnmpAdminString (SIZE(0..255)) 1366 MAX-ACCESS read-only 1367 STATUS current 1368 DESCRIPTION 1369 "Version information for TUDA MIB, e.g., specific release 1370 version of TPM 1.2 base specification and release version 1371 of TPM 1.2 errata specification and manufacturer and model 1372 TPM module itself." 1373 DEFVAL { "" } 1374 ::= { tudaV1General 2 } 1376 -- 1377 -- AIK Cert 1378 -- 1379 tudaV1AIKCert OBJECT IDENTIFIER ::= { tudaV1MIBObjects 2 } 1381 tudaV1AIKCertCycles OBJECT-TYPE 1382 SYNTAX Counter32 1383 MAX-ACCESS read-only 1384 STATUS current 1385 DESCRIPTION 1386 "Count of AIK Certificate chain update cycles that have 1387 occurred. 1389 DEFVAL intentionally omitted - counter object." 1391 ::= { tudaV1AIKCert 1 } 1393 tudaV1AIKCertTable OBJECT-TYPE 1394 SYNTAX SEQUENCE OF TudaV1AIKCertEntry 1395 MAX-ACCESS not-accessible 1396 STATUS current 1397 DESCRIPTION 1398 "A table of fragments of AIK Certificate data." 1399 ::= { tudaV1AIKCert 2 } 1401 tudaV1AIKCertEntry OBJECT-TYPE 1402 SYNTAX TudaV1AIKCertEntry 1403 MAX-ACCESS not-accessible 1404 STATUS current 1405 DESCRIPTION 1406 "An entry for one fragment of AIK Certificate data." 1407 INDEX { tudaV1AIKCertCycleIndex, 1408 tudaV1AIKCertInstanceIndex, 1409 tudaV1AIKCertFragmentIndex } 1410 ::= { tudaV1AIKCertTable 1 } 1412 TudaV1AIKCertEntry ::= 1413 SEQUENCE { 1414 tudaV1AIKCertCycleIndex Integer32, 1415 tudaV1AIKCertInstanceIndex Integer32, 1416 tudaV1AIKCertFragmentIndex Integer32, 1417 tudaV1AIKCertData OCTET STRING 1418 } 1420 tudaV1AIKCertCycleIndex OBJECT-TYPE 1421 SYNTAX Integer32 (1..2147483647) 1422 MAX-ACCESS not-accessible 1423 STATUS current 1424 DESCRIPTION 1425 "High-order index of this AIK Certificate fragment. 1426 Index of an AIK Certificate chain update cycle that has 1427 occurred (bounded by the value of tudaV1AIKCertCycles). 1429 DEFVAL intentionally omitted - index object." 1430 ::= { tudaV1AIKCertEntry 1 } 1432 tudaV1AIKCertInstanceIndex OBJECT-TYPE 1433 SYNTAX Integer32 (1..2147483647) 1434 MAX-ACCESS not-accessible 1435 STATUS current 1436 DESCRIPTION 1437 "Middle index of this AIK Certificate fragment. 1438 Ordinal of this AIK Certificate in this chain, where the AIK 1439 Certificate itself has an ordinal of '1' and higher ordinals 1440 go *up* the certificate chain to the Root CA. 1442 DEFVAL intentionally omitted - index object." 1443 ::= { tudaV1AIKCertEntry 2 } 1445 tudaV1AIKCertFragmentIndex OBJECT-TYPE 1446 SYNTAX Integer32 (1..2147483647) 1447 MAX-ACCESS not-accessible 1448 STATUS current 1449 DESCRIPTION 1450 "Low-order index of this AIK Certificate fragment. 1452 DEFVAL intentionally omitted - index object." 1453 ::= { tudaV1AIKCertEntry 3 } 1455 tudaV1AIKCertData OBJECT-TYPE 1456 SYNTAX OCTET STRING (SIZE(0..1024)) 1457 MAX-ACCESS read-only 1458 STATUS current 1459 DESCRIPTION 1460 "A fragment of CBOR encoded AIK Certificate data." 1461 DEFVAL { "" } 1462 ::= { tudaV1AIKCertEntry 4 } 1464 -- 1465 -- TSA Cert 1466 -- 1467 tudaV1TSACert OBJECT IDENTIFIER ::= { tudaV1MIBObjects 3 } 1469 tudaV1TSACertCycles OBJECT-TYPE 1470 SYNTAX Counter32 1471 MAX-ACCESS read-only 1472 STATUS current 1473 DESCRIPTION 1474 "Count of TSA Certificate chain update cycles that have 1475 occurred. 1477 DEFVAL intentionally omitted - counter object." 1478 ::= { tudaV1TSACert 1 } 1480 tudaV1TSACertTable OBJECT-TYPE 1481 SYNTAX SEQUENCE OF TudaV1TSACertEntry 1482 MAX-ACCESS not-accessible 1483 STATUS current 1484 DESCRIPTION 1485 "A table of fragments of TSA Certificate data." 1486 ::= { tudaV1TSACert 2 } 1488 tudaV1TSACertEntry OBJECT-TYPE 1489 SYNTAX TudaV1TSACertEntry 1490 MAX-ACCESS not-accessible 1491 STATUS current 1492 DESCRIPTION 1493 "An entry for one fragment of TSA Certificate data." 1494 INDEX { tudaV1TSACertCycleIndex, 1495 tudaV1TSACertInstanceIndex, 1496 tudaV1TSACertFragmentIndex } 1497 ::= { tudaV1TSACertTable 1 } 1499 TudaV1TSACertEntry ::= 1500 SEQUENCE { 1501 tudaV1TSACertCycleIndex Integer32, 1502 tudaV1TSACertInstanceIndex Integer32, 1503 tudaV1TSACertFragmentIndex Integer32, 1504 tudaV1TSACertData OCTET STRING 1505 } 1507 tudaV1TSACertCycleIndex OBJECT-TYPE 1508 SYNTAX Integer32 (1..2147483647) 1509 MAX-ACCESS not-accessible 1510 STATUS current 1511 DESCRIPTION 1512 "High-order index of this TSA Certificate fragment. 1513 Index of a TSA Certificate chain update cycle that has 1514 occurred (bounded by the value of tudaV1TSACertCycles). 1516 DEFVAL intentionally omitted - index object." 1517 ::= { tudaV1TSACertEntry 1 } 1519 tudaV1TSACertInstanceIndex OBJECT-TYPE 1520 SYNTAX Integer32 (1..2147483647) 1521 MAX-ACCESS not-accessible 1522 STATUS current 1523 DESCRIPTION 1524 "Middle index of this TSA Certificate fragment. 1525 Ordinal of this TSA Certificate in this chain, where the TSA 1526 Certificate itself has an ordinal of '1' and higher ordinals 1527 go *up* the certificate chain to the Root CA. 1529 DEFVAL intentionally omitted - index object." 1530 ::= { tudaV1TSACertEntry 2 } 1532 tudaV1TSACertFragmentIndex OBJECT-TYPE 1533 SYNTAX Integer32 (1..2147483647) 1534 MAX-ACCESS not-accessible 1535 STATUS current 1536 DESCRIPTION 1537 "Low-order index of this TSA Certificate fragment. 1539 DEFVAL intentionally omitted - index object." 1540 ::= { tudaV1TSACertEntry 3 } 1542 tudaV1TSACertData OBJECT-TYPE 1543 SYNTAX OCTET STRING (SIZE(0..1024)) 1544 MAX-ACCESS read-only 1545 STATUS current 1546 DESCRIPTION 1547 "A fragment of CBOR encoded TSA Certificate data." 1548 DEFVAL { "" } 1549 ::= { tudaV1TSACertEntry 4 } 1551 -- 1552 -- Sync Token 1553 -- 1554 tudaV1SyncToken OBJECT IDENTIFIER ::= { tudaV1MIBObjects 4 } 1556 tudaV1SyncTokenCycles OBJECT-TYPE 1557 SYNTAX Counter32 1558 MAX-ACCESS read-only 1559 STATUS current 1560 DESCRIPTION 1561 "Count of Sync Token update cycles that have 1562 occurred. 1564 DEFVAL intentionally omitted - counter object." 1565 ::= { tudaV1SyncToken 1 } 1567 tudaV1SyncTokenInstances OBJECT-TYPE 1568 SYNTAX Counter32 1569 MAX-ACCESS read-only 1570 STATUS current 1571 DESCRIPTION 1572 "Count of Sync Token instance entries that have 1573 been recorded (some entries MAY have been pruned). 1575 DEFVAL intentionally omitted - counter object." 1576 ::= { tudaV1SyncToken 2 } 1578 tudaV1SyncTokenTable OBJECT-TYPE 1579 SYNTAX SEQUENCE OF TudaV1SyncTokenEntry 1580 MAX-ACCESS not-accessible 1581 STATUS current 1582 DESCRIPTION 1583 "A table of fragments of Sync Token data." 1585 ::= { tudaV1SyncToken 3 } 1587 tudaV1SyncTokenEntry OBJECT-TYPE 1588 SYNTAX TudaV1SyncTokenEntry 1589 MAX-ACCESS not-accessible 1590 STATUS current 1591 DESCRIPTION 1592 "An entry for one fragment of Sync Token data." 1593 INDEX { tudaV1SyncTokenCycleIndex, 1594 tudaV1SyncTokenInstanceIndex, 1595 tudaV1SyncTokenFragmentIndex } 1596 ::= { tudaV1SyncTokenTable 1 } 1598 TudaV1SyncTokenEntry ::= 1599 SEQUENCE { 1600 tudaV1SyncTokenCycleIndex Integer32, 1601 tudaV1SyncTokenInstanceIndex Integer32, 1602 tudaV1SyncTokenFragmentIndex Integer32, 1603 tudaV1SyncTokenData OCTET STRING 1604 } 1606 tudaV1SyncTokenCycleIndex OBJECT-TYPE 1607 SYNTAX Integer32 (1..2147483647) 1608 MAX-ACCESS not-accessible 1609 STATUS current 1610 DESCRIPTION 1611 "High-order index of this Sync Token fragment. 1612 Index of a Sync Token update cycle that has 1613 occurred (bounded by the value of tudaV1SyncTokenCycles). 1615 DEFVAL intentionally omitted - index object." 1616 ::= { tudaV1SyncTokenEntry 1 } 1618 tudaV1SyncTokenInstanceIndex OBJECT-TYPE 1619 SYNTAX Integer32 (1..2147483647) 1620 MAX-ACCESS not-accessible 1621 STATUS current 1622 DESCRIPTION 1623 "Middle index of this Sync Token fragment. 1624 Ordinal of this instance of Sync Token data 1625 (NOT bounded by the value of tudaV1SyncTokenInstances). 1627 DEFVAL intentionally omitted - index object." 1628 ::= { tudaV1SyncTokenEntry 2 } 1630 tudaV1SyncTokenFragmentIndex OBJECT-TYPE 1631 SYNTAX Integer32 (1..2147483647) 1632 MAX-ACCESS not-accessible 1633 STATUS current 1634 DESCRIPTION 1635 "Low-order index of this Sync Token fragment. 1637 DEFVAL intentionally omitted - index object." 1638 ::= { tudaV1SyncTokenEntry 3 } 1640 tudaV1SyncTokenData OBJECT-TYPE 1641 SYNTAX OCTET STRING (SIZE(0..1024)) 1642 MAX-ACCESS read-only 1643 STATUS current 1644 DESCRIPTION 1645 "A fragment of CBOR encoded Sync Token data." 1646 DEFVAL { "" } 1647 ::= { tudaV1SyncTokenEntry 4 } 1649 -- 1650 -- Restriction Info 1651 -- 1652 tudaV1Restrict OBJECT IDENTIFIER ::= { tudaV1MIBObjects 5 } 1654 tudaV1RestrictCycles OBJECT-TYPE 1655 SYNTAX Counter32 1656 MAX-ACCESS read-only 1657 STATUS current 1658 DESCRIPTION 1659 "Count of Restriction Info update cycles that have 1660 occurred. 1662 DEFVAL intentionally omitted - counter object." 1663 ::= { tudaV1Restrict 1 } 1665 tudaV1RestrictTable OBJECT-TYPE 1666 SYNTAX SEQUENCE OF TudaV1RestrictEntry 1667 MAX-ACCESS not-accessible 1668 STATUS current 1669 DESCRIPTION 1670 "A table of instances of Restriction Info data." 1671 ::= { tudaV1Restrict 2 } 1673 tudaV1RestrictEntry OBJECT-TYPE 1674 SYNTAX TudaV1RestrictEntry 1675 MAX-ACCESS not-accessible 1676 STATUS current 1677 DESCRIPTION 1678 "An entry for one instance of Restriction Info data." 1679 INDEX { tudaV1RestrictCycleIndex } 1680 ::= { tudaV1RestrictTable 1 } 1682 TudaV1RestrictEntry ::= 1683 SEQUENCE { 1684 tudaV1RestrictCycleIndex Integer32, 1685 tudaV1RestrictData OCTET STRING 1686 } 1688 tudaV1RestrictCycleIndex OBJECT-TYPE 1689 SYNTAX Integer32 (1..2147483647) 1690 MAX-ACCESS not-accessible 1691 STATUS current 1692 DESCRIPTION 1693 "Index of this Restriction Info entry. 1694 Index of a Restriction Info update cycle that has 1695 occurred (bounded by the value of tudaV1RestrictCycles). 1697 DEFVAL intentionally omitted - index object." 1698 ::= { tudaV1RestrictEntry 1 } 1700 tudaV1RestrictData OBJECT-TYPE 1701 SYNTAX OCTET STRING (SIZE(0..1024)) 1702 MAX-ACCESS read-only 1703 STATUS current 1704 DESCRIPTION 1705 "An instance of CBOR encoded Restriction Info data." 1706 DEFVAL { "" } 1707 ::= { tudaV1RestrictEntry 2 } 1709 -- 1710 -- Measurement Log 1711 -- 1712 tudaV1Measure OBJECT IDENTIFIER ::= { tudaV1MIBObjects 6 } 1714 tudaV1MeasureCycles OBJECT-TYPE 1715 SYNTAX Counter32 1716 MAX-ACCESS read-only 1717 STATUS current 1718 DESCRIPTION 1719 "Count of Measurement Log update cycles that have 1720 occurred. 1722 DEFVAL intentionally omitted - counter object." 1723 ::= { tudaV1Measure 1 } 1725 tudaV1MeasureInstances OBJECT-TYPE 1726 SYNTAX Counter32 1727 MAX-ACCESS read-only 1728 STATUS current 1729 DESCRIPTION 1730 "Count of Measurement Log instance entries that have 1731 been recorded (some entries MAY have been pruned). 1733 DEFVAL intentionally omitted - counter object." 1734 ::= { tudaV1Measure 2 } 1736 tudaV1MeasureTable OBJECT-TYPE 1737 SYNTAX SEQUENCE OF TudaV1MeasureEntry 1738 MAX-ACCESS not-accessible 1739 STATUS current 1740 DESCRIPTION 1741 "A table of instances of Measurement Log data." 1742 ::= { tudaV1Measure 3 } 1744 tudaV1MeasureEntry OBJECT-TYPE 1745 SYNTAX TudaV1MeasureEntry 1746 MAX-ACCESS not-accessible 1747 STATUS current 1748 DESCRIPTION 1749 "An entry for one instance of Measurement Log data." 1750 INDEX { tudaV1MeasureCycleIndex, 1751 tudaV1MeasureInstanceIndex } 1752 ::= { tudaV1MeasureTable 1 } 1754 TudaV1MeasureEntry ::= 1755 SEQUENCE { 1756 tudaV1MeasureCycleIndex Integer32, 1757 tudaV1MeasureInstanceIndex Integer32, 1758 tudaV1MeasureData OCTET STRING 1759 } 1761 tudaV1MeasureCycleIndex OBJECT-TYPE 1762 SYNTAX Integer32 (1..2147483647) 1763 MAX-ACCESS not-accessible 1764 STATUS current 1765 DESCRIPTION 1766 "High-order index of this Measurement Log entry. 1767 Index of a Measurement Log update cycle that has 1768 occurred (bounded by the value of tudaV1MeasureCycles). 1770 DEFVAL intentionally omitted - index object." 1771 ::= { tudaV1MeasureEntry 1 } 1773 tudaV1MeasureInstanceIndex OBJECT-TYPE 1774 SYNTAX Integer32 (1..2147483647) 1775 MAX-ACCESS not-accessible 1776 STATUS current 1777 DESCRIPTION 1778 "Low-order index of this Measurement Log entry. 1779 Ordinal of this instance of Measurement Log data 1780 (NOT bounded by the value of tudaV1MeasureInstances). 1782 DEFVAL intentionally omitted - index object." 1783 ::= { tudaV1MeasureEntry 2 } 1785 tudaV1MeasureData OBJECT-TYPE 1786 SYNTAX OCTET STRING (SIZE(0..1024)) 1787 MAX-ACCESS read-only 1788 STATUS current 1789 DESCRIPTION 1790 "A instance of CBOR encoded Measurement Log data." 1791 DEFVAL { "" } 1792 ::= { tudaV1MeasureEntry 3 } 1794 -- 1795 -- Verify Token 1796 -- 1797 tudaV1VerifyToken OBJECT IDENTIFIER ::= { tudaV1MIBObjects 7 } 1799 tudaV1VerifyTokenCycles OBJECT-TYPE 1800 SYNTAX Counter32 1801 MAX-ACCESS read-only 1802 STATUS current 1803 DESCRIPTION 1804 "Count of Verify Token update cycles that have 1805 occurred. 1807 DEFVAL intentionally omitted - counter object." 1808 ::= { tudaV1VerifyToken 1 } 1810 tudaV1VerifyTokenTable OBJECT-TYPE 1811 SYNTAX SEQUENCE OF TudaV1VerifyTokenEntry 1812 MAX-ACCESS not-accessible 1813 STATUS current 1814 DESCRIPTION 1815 "A table of instances of Verify Token data." 1816 ::= { tudaV1VerifyToken 2 } 1818 tudaV1VerifyTokenEntry OBJECT-TYPE 1819 SYNTAX TudaV1VerifyTokenEntry 1820 MAX-ACCESS not-accessible 1821 STATUS current 1822 DESCRIPTION 1823 "An entry for one instance of Verify Token data." 1824 INDEX { tudaV1VerifyTokenCycleIndex } 1825 ::= { tudaV1VerifyTokenTable 1 } 1827 TudaV1VerifyTokenEntry ::= 1828 SEQUENCE { 1829 tudaV1VerifyTokenCycleIndex Integer32, 1830 tudaV1VerifyTokenData OCTET STRING 1831 } 1833 tudaV1VerifyTokenCycleIndex OBJECT-TYPE 1834 SYNTAX Integer32 (1..2147483647) 1835 MAX-ACCESS not-accessible 1836 STATUS current 1837 DESCRIPTION 1838 "Index of this instance of Verify Token data. 1839 Index of a Verify Token update cycle that has 1840 occurred (bounded by the value of tudaV1VerifyTokenCycles). 1842 DEFVAL intentionally omitted - index object." 1843 ::= { tudaV1VerifyTokenEntry 1 } 1845 tudaV1VerifyTokenData OBJECT-TYPE 1846 SYNTAX OCTET STRING (SIZE(0..1024)) 1847 MAX-ACCESS read-only 1848 STATUS current 1849 DESCRIPTION 1850 "A instance of CBOR encoded Verify Token data." 1851 DEFVAL { "" } 1852 ::= { tudaV1VerifyTokenEntry 2 } 1854 -- 1855 -- SWID Tag 1856 -- 1857 tudaV1SWIDTag OBJECT IDENTIFIER ::= { tudaV1MIBObjects 8 } 1859 tudaV1SWIDTagCycles OBJECT-TYPE 1860 SYNTAX Counter32 1861 MAX-ACCESS read-only 1862 STATUS current 1863 DESCRIPTION 1864 "Count of SWID Tag update cycles that have occurred. 1866 DEFVAL intentionally omitted - counter object." 1867 ::= { tudaV1SWIDTag 1 } 1869 tudaV1SWIDTagTable OBJECT-TYPE 1870 SYNTAX SEQUENCE OF TudaV1SWIDTagEntry 1871 MAX-ACCESS not-accessible 1872 STATUS current 1873 DESCRIPTION 1874 "A table of fragments of SWID Tag data." 1875 ::= { tudaV1SWIDTag 2 } 1877 tudaV1SWIDTagEntry OBJECT-TYPE 1878 SYNTAX TudaV1SWIDTagEntry 1879 MAX-ACCESS not-accessible 1880 STATUS current 1881 DESCRIPTION 1882 "An entry for one fragment of SWID Tag data." 1883 INDEX { tudaV1SWIDTagCycleIndex, 1884 tudaV1SWIDTagInstanceIndex, 1885 tudaV1SWIDTagFragmentIndex } 1886 ::= { tudaV1SWIDTagTable 1 } 1888 TudaV1SWIDTagEntry ::= 1889 SEQUENCE { 1890 tudaV1SWIDTagCycleIndex Integer32, 1891 tudaV1SWIDTagInstanceIndex Integer32, 1892 tudaV1SWIDTagFragmentIndex Integer32, 1893 tudaV1SWIDTagData OCTET STRING 1894 } 1896 tudaV1SWIDTagCycleIndex OBJECT-TYPE 1897 SYNTAX Integer32 (1..2147483647) 1898 MAX-ACCESS not-accessible 1899 STATUS current 1900 DESCRIPTION 1901 "High-order index of this SWID Tag fragment. 1902 Index of an SWID Tag update cycle that has 1903 occurred (bounded by the value of tudaV1SWIDTagCycles). 1905 DEFVAL intentionally omitted - index object." 1906 ::= { tudaV1SWIDTagEntry 1 } 1908 tudaV1SWIDTagInstanceIndex OBJECT-TYPE 1909 SYNTAX Integer32 (1..2147483647) 1910 MAX-ACCESS not-accessible 1911 STATUS current 1912 DESCRIPTION 1913 "Middle index of this SWID Tag fragment. 1914 Ordinal of this SWID Tag instance in this update cycle. 1916 DEFVAL intentionally omitted - index object." 1917 ::= { tudaV1SWIDTagEntry 2 } 1919 tudaV1SWIDTagFragmentIndex OBJECT-TYPE 1920 SYNTAX Integer32 (1..2147483647) 1921 MAX-ACCESS not-accessible 1922 STATUS current 1923 DESCRIPTION 1924 "Low-order index of this SWID Tag fragment. 1926 DEFVAL intentionally omitted - index object." 1927 ::= { tudaV1SWIDTagEntry 3 } 1929 tudaV1SWIDTagData OBJECT-TYPE 1930 SYNTAX OCTET STRING (SIZE(0..1024)) 1931 MAX-ACCESS read-only 1932 STATUS current 1933 DESCRIPTION 1934 "A fragment of CBOR encoded SWID Tag data." 1935 DEFVAL { "" } 1936 ::= { tudaV1SWIDTagEntry 4 } 1938 -- 1939 -- Trap Cycles 1940 -- 1941 tudaV1TrapV2Cycles NOTIFICATION-TYPE 1942 OBJECTS { 1943 tudaV1GeneralCycles, 1944 tudaV1AIKCertCycles, 1945 tudaV1TSACertCycles, 1946 tudaV1SyncTokenCycles, 1947 tudaV1SyncTokenInstances, 1948 tudaV1RestrictCycles, 1949 tudaV1MeasureCycles, 1950 tudaV1MeasureInstances, 1951 tudaV1VerifyTokenCycles, 1952 tudaV1SWIDTagCycles 1953 } 1954 STATUS current 1955 DESCRIPTION 1956 "This trap is sent when the value of any cycle or instance 1957 counter changes (i.e., one or more tables are updated). 1959 Note: The value of sysUpTime in IETF MIB-II (RFC 1213) is 1960 always included in SNMPv2 traps, per RFC 3416." 1961 ::= { tudaV1MIBNotifications 1 } 1963 -- 1964 -- Conformance Information 1965 -- 1966 tudaV1Compliances OBJECT IDENTIFIER 1967 ::= { tudaV1MIBConformance 1 } 1969 tudaV1ObjectGroups OBJECT IDENTIFIER 1970 ::= { tudaV1MIBConformance 2 } 1972 tudaV1NotificationGroups OBJECT IDENTIFIER 1973 ::= { tudaV1MIBConformance 3 } 1975 -- 1976 -- Compliance Statements 1977 -- 1978 tudaV1BasicCompliance MODULE-COMPLIANCE 1979 STATUS current 1980 DESCRIPTION 1981 "An implementation that complies with this module MUST 1982 implement all of the objects defined in the mandatory 1983 group tudaV1BasicGroup." 1984 MODULE -- this module 1985 MANDATORY-GROUPS { tudaV1BasicGroup } 1987 GROUP tudaV1OptionalGroup 1988 DESCRIPTION 1989 "The optional TUDA MIB objects. 1990 An implementation MAY implement this group." 1992 GROUP tudaV1TrapGroup 1993 DESCRIPTION 1994 "The TUDA MIB traps. 1995 An implementation SHOULD implement this group." 1996 ::= { tudaV1Compliances 1 } 1998 -- 1999 -- Compliance Groups 2000 -- 2001 tudaV1BasicGroup OBJECT-GROUP 2002 OBJECTS { 2003 tudaV1GeneralCycles, 2004 tudaV1GeneralVersionInfo, 2005 tudaV1SyncTokenCycles, 2006 tudaV1SyncTokenInstances, 2007 tudaV1SyncTokenData, 2008 tudaV1RestrictCycles, 2009 tudaV1RestrictData, 2010 tudaV1VerifyTokenCycles, 2011 tudaV1VerifyTokenData 2012 } 2013 STATUS current 2014 DESCRIPTION 2015 "The basic mandatory TUDA MIB objects." 2016 ::= { tudaV1ObjectGroups 1 } 2018 tudaV1OptionalGroup OBJECT-GROUP 2019 OBJECTS { 2020 tudaV1AIKCertCycles, 2021 tudaV1AIKCertData, 2022 tudaV1TSACertCycles, 2023 tudaV1TSACertData, 2024 tudaV1MeasureCycles, 2025 tudaV1MeasureInstances, 2026 tudaV1MeasureData, 2027 tudaV1SWIDTagCycles, 2028 tudaV1SWIDTagData 2029 } 2030 STATUS current 2031 DESCRIPTION 2032 "The optional TUDA MIB objects." 2033 ::= { tudaV1ObjectGroups 2 } 2035 tudaV1TrapGroup NOTIFICATION-GROUP 2036 NOTIFICATIONS { tudaV1TrapV2Cycles } 2037 STATUS current 2038 DESCRIPTION 2039 "The recommended TUDA MIB traps - notifications." 2040 ::= { tudaV1NotificationGroups 1 } 2042 END 2043 2045 Appendix C. YANG Realization 2047 2048 module TUDA-V1-ATTESTATION-MIB { 2050 namespace "urn:ietf:params:xml:ns:yang:smiv2:TUDA-V1-ATTESTATION-MIB"; 2051 prefix "tuda-v1"; 2053 import SNMP-FRAMEWORK-MIB { prefix "snmp-framework"; } 2054 import yang-types { prefix "yang"; } 2056 organization 2057 "Fraunhofer SIT"; 2059 contact 2060 "Andreas Fuchs 2061 Fraunhofer Institute for Secure Information Technology 2062 Email: andreas.fuchs@sit.fraunhofer.de 2064 Henk Birkholz 2065 Fraunhofer Institute for Secure Information Technology 2066 Email: henk.birkholz@sit.fraunhofer.de 2068 Ira E McDonald 2069 High North Inc 2070 Email: blueroofmusic@gmail.com 2072 Carsten Bormann 2073 Universitaet Bremen TZI 2074 Email: cabo@tzi.org"; 2076 description 2077 "The MIB module for monitoring of time-based unidirectional 2078 attestation information from a network endpoint system, 2079 based on the Trusted Computing Group TPM 1.2 definition. 2081 Copyright (C) High North Inc (2021)."; 2083 revision "2021-01-13" { 2084 description 2085 "Twelfth version, published as draft-birkholz-rats-tuda-04."; 2086 reference 2087 "draft-birkholz-rats-tuda-04"; 2088 } 2089 revision "2020-07-13" { 2090 description 2091 "Eleventh version, published as draft-birkholz-rats-tuda-03."; 2092 reference 2093 "draft-birkholz-rats-tuda-03"; 2094 } 2095 revision "2020-03-09" { 2096 description 2097 "Tenth version, published as draft-birkholz-rats-tuda-02."; 2098 reference 2099 "draft-birkholz-rats-tuda-02"; 2100 } 2101 revision "2019-09-11" { 2102 description 2103 "Ninth version, published as draft-birkholz-rats-tuda-01."; 2104 reference 2105 "draft-birkholz-rats-tuda-01"; 2106 } 2107 revision "2019-03-12" { 2108 description 2109 "Eighth version, published as draft-birkholz-rats-tuda-00."; 2110 reference 2111 "draft-birkholz-rats-tuda-00"; 2112 } 2113 revision "2018-05-03" { 2114 description 2115 "Seventh version, published as draft-birkholz-i2nsf-tuda-03."; 2116 reference 2117 "draft-birkholz-i2nsf-tuda-03"; 2118 } 2119 revision "2018-05-02" { 2120 description 2121 "Sixth version, published as draft-birkholz-i2nsf-tuda-02."; 2122 reference 2123 "draft-birkholz-i2nsf-tuda-02"; 2124 } 2125 revision "2017-10-30" { 2126 description 2127 "Fifth version, published as draft-birkholz-i2nsf-tuda-01."; 2128 reference 2129 "draft-birkholz-i2nsf-tuda-01"; 2130 } 2131 revision "2017-01-09" { 2132 description 2133 "Fourth version, published as draft-birkholz-i2nsf-tuda-00."; 2134 reference 2135 "draft-birkholz-i2nsf-tuda-00"; 2136 } 2137 revision "2016-07-08" { 2138 description 2139 "Third version, published as draft-birkholz-tuda-02."; 2140 reference 2141 "draft-birkholz-tuda-02"; 2142 } 2143 revision "2016-03-21" { 2144 description 2145 "Second version, published as draft-birkholz-tuda-01."; 2146 reference 2147 "draft-birkholz-tuda-01"; 2148 } 2149 revision "2015-10-18" { 2150 description 2151 "Initial version, published as draft-birkholz-tuda-00."; 2152 reference 2153 "draft-birkholz-tuda-00"; 2154 } 2156 container tudaV1General { 2157 description 2158 "TBD"; 2160 leaf tudaV1GeneralCycles { 2161 type yang:counter32; 2162 config false; 2163 description 2164 "Count of TUDA update cycles that have occurred, i.e., 2165 sum of all the individual group cycle counters. 2167 DEFVAL intentionally omitted - counter object."; 2168 } 2170 leaf tudaV1GeneralVersionInfo { 2171 type snmp-framework:SnmpAdminString { 2172 length "0..255"; 2173 } 2174 config false; 2175 description 2176 "Version information for TUDA MIB, e.g., specific release 2177 version of TPM 1.2 base specification and release version 2178 of TPM 1.2 errata specification and manufacturer and model 2179 TPM module itself."; 2180 } 2181 } 2183 container tudaV1AIKCert { 2184 description 2185 "TBD"; 2187 leaf tudaV1AIKCertCycles { 2188 type yang:counter32; 2189 config false; 2190 description 2191 "Count of AIK Certificate chain update cycles that have 2192 occurred. 2194 DEFVAL intentionally omitted - counter object."; 2195 } 2197 /* XXX table comments here XXX */ 2199 list tudaV1AIKCertEntry { 2201 key "tudaV1AIKCertCycleIndex tudaV1AIKCertInstanceIndex 2202 tudaV1AIKCertFragmentIndex"; 2203 config false; 2204 description 2205 "An entry for one fragment of AIK Certificate data."; 2207 leaf tudaV1AIKCertCycleIndex { 2208 type int32 { 2209 range "1..2147483647"; 2210 } 2211 config false; 2212 description 2213 "High-order index of this AIK Certificate fragment. 2214 Index of an AIK Certificate chain update cycle that has 2215 occurred (bounded by the value of tudaV1AIKCertCycles). 2217 DEFVAL intentionally omitted - index object."; 2218 } 2220 leaf tudaV1AIKCertInstanceIndex { 2221 type int32 { 2222 range "1..2147483647"; 2223 } 2224 config false; 2225 description 2226 "Middle index of this AIK Certificate fragment. 2227 Ordinal of this AIK Certificate in this chain, where the AIK 2228 Certificate itself has an ordinal of '1' and higher ordinals 2229 go *up* the certificate chain to the Root CA. 2231 DEFVAL intentionally omitted - index object."; 2232 } 2234 leaf tudaV1AIKCertFragmentIndex { 2235 type int32 { 2236 range "1..2147483647"; 2237 } 2238 config false; 2239 description 2240 "Low-order index of this AIK Certificate fragment. 2242 DEFVAL intentionally omitted - index object."; 2243 } 2245 leaf tudaV1AIKCertData { 2246 type binary { 2247 length "0..1024"; 2248 } 2249 config false; 2250 description 2251 "A fragment of CBOR encoded AIK Certificate data."; 2252 } 2253 } 2254 } 2256 container tudaV1TSACert { 2257 description 2258 "TBD"; 2260 leaf tudaV1TSACertCycles { 2261 type yang:counter32; 2262 config false; 2263 description 2264 "Count of TSA Certificate chain update cycles that have 2265 occurred. 2267 DEFVAL intentionally omitted - counter object."; 2268 } 2270 /* XXX table comments here XXX */ 2272 list tudaV1TSACertEntry { 2274 key "tudaV1TSACertCycleIndex tudaV1TSACertInstanceIndex 2275 tudaV1TSACertFragmentIndex"; 2276 config false; 2277 description 2278 "An entry for one fragment of TSA Certificate data."; 2280 leaf tudaV1TSACertCycleIndex { 2281 type int32 { 2282 range "1..2147483647"; 2283 } 2284 config false; 2285 description 2286 "High-order index of this TSA Certificate fragment. 2287 Index of a TSA Certificate chain update cycle that has 2288 occurred (bounded by the value of tudaV1TSACertCycles). 2290 DEFVAL intentionally omitted - index object."; 2291 } 2293 leaf tudaV1TSACertInstanceIndex { 2294 type int32 { 2295 range "1..2147483647"; 2296 } 2297 config false; 2298 description 2299 "Middle index of this TSA Certificate fragment. 2300 Ordinal of this TSA Certificate in this chain, where the TSA 2301 Certificate itself has an ordinal of '1' and higher ordinals 2302 go *up* the certificate chain to the Root CA. 2304 DEFVAL intentionally omitted - index object."; 2305 } 2307 leaf tudaV1TSACertFragmentIndex { 2308 type int32 { 2309 range "1..2147483647"; 2310 } 2311 config false; 2312 description 2313 "Low-order index of this TSA Certificate fragment. 2315 DEFVAL intentionally omitted - index object."; 2316 } 2318 leaf tudaV1TSACertData { 2319 type binary { 2320 length "0..1024"; 2321 } 2322 config false; 2323 description 2324 "A fragment of CBOR encoded TSA Certificate data."; 2325 } 2326 } 2327 } 2329 container tudaV1SyncToken { 2330 description 2331 "TBD"; 2333 leaf tudaV1SyncTokenCycles { 2334 type yang:counter32; 2335 config false; 2336 description 2337 "Count of Sync Token update cycles that have 2338 occurred. 2340 DEFVAL intentionally omitted - counter object."; 2341 } 2343 leaf tudaV1SyncTokenInstances { 2344 type yang:counter32; 2345 config false; 2346 description 2347 "Count of Sync Token instance entries that have 2348 been recorded (some entries MAY have been pruned). 2350 DEFVAL intentionally omitted - counter object."; 2351 } 2352 list tudaV1SyncTokenEntry { 2354 key "tudaV1SyncTokenCycleIndex 2355 tudaV1SyncTokenInstanceIndex 2356 tudaV1SyncTokenFragmentIndex"; 2357 config false; 2358 description 2359 "An entry for one fragment of Sync Token data."; 2361 leaf tudaV1SyncTokenCycleIndex { 2362 type int32 { 2363 range "1..2147483647"; 2364 } 2365 config false; 2366 description 2367 "High-order index of this Sync Token fragment. 2368 Index of a Sync Token update cycle that has 2369 occurred (bounded by the value of tudaV1SyncTokenCycles). 2371 DEFVAL intentionally omitted - index object."; 2372 } 2374 leaf tudaV1SyncTokenInstanceIndex { 2375 type int32 { 2376 range "1..2147483647"; 2377 } 2378 config false; 2379 description 2380 "Middle index of this Sync Token fragment. 2381 Ordinal of this instance of Sync Token data 2382 (NOT bounded by the value of tudaV1SyncTokenInstances). 2384 DEFVAL intentionally omitted - index object."; 2385 } 2387 leaf tudaV1SyncTokenFragmentIndex { 2388 type int32 { 2389 range "1..2147483647"; 2390 } 2391 config false; 2392 description 2393 "Low-order index of this Sync Token fragment. 2395 DEFVAL intentionally omitted - index object."; 2396 } 2398 leaf tudaV1SyncTokenData { 2399 type binary { 2400 length "0..1024"; 2401 } 2402 config false; 2403 description 2404 "A fragment of CBOR encoded Sync Token data."; 2405 } 2406 } 2407 } 2409 container tudaV1Restrict { 2410 description 2411 "TBD"; 2413 leaf tudaV1RestrictCycles { 2414 type yang:counter32; 2415 config false; 2416 description 2417 "Count of Restriction Info update cycles that have 2418 occurred. 2420 DEFVAL intentionally omitted - counter object."; 2421 } 2423 /* XXX table comments here XXX */ 2425 list tudaV1RestrictEntry { 2427 key "tudaV1RestrictCycleIndex"; 2428 config false; 2429 description 2430 "An entry for one instance of Restriction Info data."; 2432 leaf tudaV1RestrictCycleIndex { 2433 type int32 { 2434 range "1..2147483647"; 2435 } 2436 config false; 2437 description 2438 "Index of this Restriction Info entry. 2439 Index of a Restriction Info update cycle that has 2440 occurred (bounded by the value of tudaV1RestrictCycles). 2442 DEFVAL intentionally omitted - index object."; 2443 } 2444 leaf tudaV1RestrictData { 2445 type binary { 2446 length "0..1024"; 2447 } 2448 config false; 2449 description 2450 "An instance of CBOR encoded Restriction Info data."; 2451 } 2452 } 2453 } 2455 container tudaV1Measure { 2456 description 2457 "TBD"; 2459 leaf tudaV1MeasureCycles { 2460 type yang:counter32; 2461 config false; 2462 description 2463 "Count of Measurement Log update cycles that have 2464 occurred. 2466 DEFVAL intentionally omitted - counter object."; 2467 } 2469 leaf tudaV1MeasureInstances { 2470 type yang:counter32; 2471 config false; 2472 description 2473 "Count of Measurement Log instance entries that have 2474 been recorded (some entries MAY have been pruned). 2476 DEFVAL intentionally omitted - counter object."; 2477 } 2479 list tudaV1MeasureEntry { 2481 key "tudaV1MeasureCycleIndex tudaV1MeasureInstanceIndex"; 2482 config false; 2483 description 2484 "An entry for one instance of Measurement Log data."; 2486 leaf tudaV1MeasureCycleIndex { 2487 type int32 { 2488 range "1..2147483647"; 2489 } 2490 config false; 2491 description 2492 "High-order index of this Measurement Log entry. 2493 Index of a Measurement Log update cycle that has 2494 occurred (bounded by the value of tudaV1MeasureCycles). 2496 DEFVAL intentionally omitted - index object."; 2497 } 2499 leaf tudaV1MeasureInstanceIndex { 2500 type int32 { 2501 range "1..2147483647"; 2502 } 2503 config false; 2504 description 2505 "Low-order index of this Measurement Log entry. 2506 Ordinal of this instance of Measurement Log data 2507 (NOT bounded by the value of tudaV1MeasureInstances). 2509 DEFVAL intentionally omitted - index object."; 2510 } 2512 leaf tudaV1MeasureData { 2513 type binary { 2514 length "0..1024"; 2515 } 2516 config false; 2517 description 2518 "A instance of CBOR encoded Measurement Log data."; 2519 } 2520 } 2521 } 2523 container tudaV1VerifyToken { 2524 description 2525 "TBD"; 2527 leaf tudaV1VerifyTokenCycles { 2528 type yang:counter32; 2529 config false; 2530 description 2531 "Count of Verify Token update cycles that have 2532 occurred. 2534 DEFVAL intentionally omitted - counter object."; 2535 } 2537 /* XXX table comments here XXX */ 2538 list tudaV1VerifyTokenEntry { 2540 key "tudaV1VerifyTokenCycleIndex"; 2541 config false; 2542 description 2543 "An entry for one instance of Verify Token data."; 2545 leaf tudaV1VerifyTokenCycleIndex { 2546 type int32 { 2547 range "1..2147483647"; 2548 } 2549 config false; 2550 description 2551 "Index of this instance of Verify Token data. 2552 Index of a Verify Token update cycle that has 2553 occurred (bounded by the value of tudaV1VerifyTokenCycles). 2555 DEFVAL intentionally omitted - index object."; 2556 } 2558 leaf tudaV1VerifyTokenData { 2559 type binary { 2560 length "0..1024"; 2561 } 2562 config false; 2563 description 2564 "A instanc-V1-ATTESTATION-MIB.yang 2565 } 2566 } 2567 } 2569 container tudaV1SWIDTag { 2570 description 2571 "see CoSWID and YANG SIWD module for now" 2573 leaf tudaV1SWIDTagCycles { 2574 type yang:counter32; 2575 config false; 2576 description 2577 "Count of SWID Tag update cycles that have occurred. 2579 DEFVAL intentionally omitted - counter object."; 2580 } 2582 list tudaV1SWIDTagEntry { 2584 key "tudaV1SWIDTagCycleIndex tudaV1SWIDTagInstanceIndex 2585 tudaV1SWIDTagFragmentIndex"; 2586 config false; 2587 description 2588 "An entry for one fragment of SWID Tag data."; 2590 leaf tudaV1SWIDTagCycleIndex { 2591 type int32 { 2592 range "1..2147483647"; 2593 } 2594 config false; 2595 description 2596 "High-order index of this SWID Tag fragment. 2597 Index of an SWID Tag update cycle that has 2598 occurred (bounded by the value of tudaV1SWIDTagCycles). 2600 DEFVAL intentionally omitted - index object."; 2601 } 2603 leaf tudaV1SWIDTagInstanceIndex { 2604 type int32 { 2605 range "1..2147483647"; 2606 } 2607 config false; 2608 description 2609 "Middle index of this SWID Tag fragment. 2610 Ordinal of this SWID Tag instance in this update cycle. 2612 DEFVAL intentionally omitted - index object."; 2613 } 2615 leaf tudaV1SWIDTagFragmentIndex { 2616 type int32 { 2617 range "1..2147483647"; 2618 } 2619 config false; 2620 description 2621 "Low-order index of this SWID Tag fragment. 2623 DEFVAL intentionally omitted - index object."; 2624 } 2626 leaf tudaV1SWIDTagData { 2627 type binary { 2628 length "0..1024"; 2629 } 2630 config false; 2631 description 2632 "A fragment of CBOR encoded SWID Tag data."; 2633 } 2634 } 2635 } 2637 notification tudaV1TrapV2Cycles { 2638 description 2639 "This trap is sent when the value of any cycle or instance 2640 counter changes (i.e., one or more tables are updated). 2642 Note: The value of sysUpTime in IETF MIB-II (RFC 1213) is 2643 always included in SNMPv2 traps, per RFC 3416."; 2645 container tudaV1TrapV2Cycles-tudaV1GeneralCycles { 2646 description 2647 "TPD" 2648 leaf tudaV1GeneralCycles { 2649 type yang:counter32; 2650 description 2651 "Count of TUDA update cycles that have occurred, i.e., 2652 sum of all the individual group cycle counters. 2654 DEFVAL intentionally omitted - counter object."; 2655 } 2656 } 2658 container tudaV1TrapV2Cycles-tudaV1AIKCertCycles { 2659 description 2660 "TPD" 2661 leaf tudaV1AIKCertCycles { 2662 type yang:counter32; 2663 description 2664 "Count of AIK Certificate chain update cycles that have 2665 occurred. 2667 DEFVAL intentionally omitted - counter object."; 2668 } 2669 } 2671 container tudaV1TrapV2Cycles-tudaV1TSACertCycles { 2672 description 2673 "TPD" 2674 leaf tudaV1TSACertCycles { 2675 type yang:counter32; 2676 description 2677 "Count of TSA Certificate chain update cycles that have 2678 occurred. 2680 DEFVAL intentionally omitted - counter object."; 2681 } 2682 } 2684 container tudaV1TrapV2Cycles-tudaV1SyncTokenCycles { 2685 description 2686 "TPD" 2687 leaf tudaV1SyncTokenCycles { 2688 type yang:counter32; 2689 description 2690 "Count of Sync Token update cycles that have 2691 occurred. 2693 DEFVAL intentionally omitted - counter object."; 2694 } 2695 } 2697 container tudaV1TrapV2Cycles-tudaV1SyncTokenInstances { 2698 description 2699 "TPD" 2700 leaf tudaV1SyncTokenInstances { 2701 type yang:counter32; 2702 description 2703 "Count of Sync Token instance entries that have 2704 been recorded (some entries MAY have been pruned). 2706 DEFVAL intentionally omitted - counter object."; 2707 } 2708 } 2710 container tudaV1TrapV2Cycles-tudaV1RestrictCycles { 2711 description 2712 "TPD" 2713 leaf tudaV1RestrictCycles { 2714 type yang:counter32; 2715 description 2716 "Count of Restriction Info update cycles that have 2717 occurred. 2719 DEFVAL intentionally omitted - counter object."; 2720 } 2721 } 2723 container tudaV1TrapV2Cycles-tudaV1MeasureCycles { 2724 description 2725 "TPD" 2726 leaf tudaV1MeasureCycles { 2727 type yang:counter32; 2728 description 2729 "Count of Measurement Log update cycles that have 2730 occurred. 2732 DEFVAL intentionally omitted - counter object."; 2733 } 2734 } 2736 container tudaV1TrapV2Cycles-tudaV1MeasureInstances { 2737 description 2738 "TPD" 2739 leaf tudaV1MeasureInstances { 2740 type yang:counter32; 2741 description 2742 "Count of Measurement Log instance entries that have 2743 been recorded (some entries MAY have been pruned). 2745 DEFVAL intentionally omitted - counter object."; 2746 } 2747 } 2749 container tudaV1TrapV2Cycles-tudaV1VerifyTokenCycles { 2750 description 2751 "TPD" 2752 leaf tudaV1VerifyTokenCycles { 2753 type yang:counter32; 2754 description 2755 "Count of Verify Token update cycles that have 2756 occurred. 2758 DEFVAL intentionally omitted - counter object."; 2759 } 2760 } 2762 container tudaV1TrapV2Cycles-tudaV1SWIDTagCycles { 2763 description 2764 "TPD" 2765 leaf tudaV1SWIDTagCycles { 2766 type yang:counter32; 2767 description 2768 "Count of SWID Tag update cycles that have occurred. 2770 DEFVAL intentionally omitted - counter object."; 2771 } 2772 } 2774 } 2775 } 2776 2778 Appendix D. Realization with TPM functions 2780 D.1. TPM Functions 2782 The following TPM structures, resources and functions are used within 2783 this approach. They are based upon the TPM specifications [TPM12] 2784 and [TPM2]. 2786 D.1.1. Tick-Session and Tick-Stamp 2788 On every boot, the TPM initializes a new Tick-Session. Such a tick- 2789 session consists of a nonce that is randomly created upon each boot 2790 to identify the current boot-cycle -- the phase between boot-time of 2791 the device and shutdown or power-off -- and prevent replaying of old 2792 tick-session values. The TPM uses its internal entropy source that 2793 guarantees virtually no collisions of the nonce values between two of 2794 such boot cycles. 2796 It further includes an internal timer that is being initialize to 2797 Zero on each reboot. From this point on, the TPM increments this 2798 timer continuously based upon its internal secure clocking 2799 information until the device is powered down or set to sleep. By its 2800 hardware design, the TPM will detect attacks on any of those 2801 properties. 2803 The TPM offers the function TPM_TickStampBlob, which allows the TPM 2804 to create a signature over the current tick-session and two 2805 externally provided input values. These input values are designed to 2806 serve as a nonce and as payload data to be included in a 2807 TickStampBlob: TickstampBlob := sig(TPM-key, currentTicks || nonce || 2808 externalData). 2810 As a result, one is able to proof that at a certain point in time 2811 (relative to the tick-session) after the provisioning of a certain 2812 nonce, some certain externalData was known and provided to the TPM. 2813 If an approach however requires no input values or only one input 2814 value (such as the use in this document) the input values can be set 2815 to well-known value. The convention used within TCG specifications 2816 and within this document is to use twenty bytes of zero 2817 h'0000000000000000000000000000000000000000' as well-known value. 2819 D.1.2. Platform Configuration Registers (PCRs) 2821 The TPM is a secure cryptoprocessor that provides the ability to 2822 store measurements and metrics about an endpoint's configuration and 2823 state in a secure, tamper-proof environment. Each of these security 2824 relevant metrics can be stored in a volatile Platform Configuration 2825 Register (PCR) inside the TPM. These measurements can be conducted 2826 at any point in time, ranging from an initial BIOS boot-up sequence 2827 to measurements taken after hundreds of hours of uptime. 2829 The initial measurement is triggered by the Platforms so-called pre- 2830 BIOS or ROM-code. It will conduct a measurement of the first 2831 loadable pieces of code; i.e.\ the BIOS. The BIOS will in turn 2832 measure its Option ROMs and the BootLoader, which measures the OS- 2833 Kernel, which in turn measures its applications. This describes a 2834 so-called measurement chain. This typically gets recorded in a so- 2835 called measurement log, such that the values of the PCRs can be 2836 reconstructed from the individual measurements for validation. 2838 Via its PCRs, a TPM provides a Root of Trust that can, for example, 2839 support secure boot or remote attestation. The attestation of an 2840 endpoint's identity or security posture is based on the content of an 2841 TPM's PCRs (platform integrity measurements). 2843 D.1.3. PCR restricted Keys 2845 Every key inside the TPM can be restricted in such a way that it can 2846 only be used if a certain set of PCRs are in a predetermined state. 2847 For key creation the desired state for PCRs are defined via the 2848 PCRInfo field inside the keyInfo parameter. Whenever an operation 2849 using this key is performed, the TPM first checks whether the PCRs 2850 are in the correct state. Otherwise the operation is denied by the 2851 TPM. 2853 D.1.4. CertifyInfo 2855 The TPM offers a command to certify the properties of a key by means 2856 of a signature using another key. This includes especially the 2857 keyInfo which in turn includes the PCRInfo information used during 2858 key creation. This way, a third party can be assured about the fact 2859 that a key is only usable if the PCRs are in a certain state. 2861 D.2. IE Generation Procedures for TPM 1.2 2862 D.2.1. AIK and AIK Certificate 2864 Attestations are based upon a cryptographic signature performed by 2865 the TPM using a so-called Attestation Identity Key (AIK). An AIK has 2866 the properties that it cannot be exported from a TPM and is used for 2867 attestations. Trust in the AIK is established by an X.509 2868 Certificate emitted by a Certificate Authority. The AIK certificate 2869 is either provided directly or via a so-called PrivacyCA 2870 [AIK-Enrollment]. 2872 This element consists of the AIK certificate that includes the AIK's 2873 public key used during verification as well as the certificate chain 2874 up to the Root CA for validation of the AIK certificate itself. 2876 TUDA-Cert = [AIK-Cert, TSA-Cert]; maybe split into two for SNMP 2877 AIK-Cert = Cert 2878 TSA-Cert = Cert 2880 Figure 2: TUDA-Cert element in CDDL 2882 The TSA-Cert is a standard certificate of the TSA. 2884 The AIK-Cert may be provisioned in a secure environment using 2885 standard means or it may follow the PrivacyCA protocols. Figure 3 2886 gives a rough sketch of this protocol. See [AIK-Enrollment] for more 2887 information. 2889 The X.509 Certificate is built from the AIK public key and the 2890 corresponding PKCS #7 certificate chain, as shown in Figure 3. 2892 Required TPM functions: 2894 | create_AIK_Cert(...) = { 2895 | AIK = TPM_MakeIdentity() 2896 | IdReq = CollateIdentityRequest(AIK,EK) 2897 | IdRes = Call(AIK-CA, IdReq) 2898 | AIK-Cert = TPM_ActivateIdentity(AIK, IdRes) 2899 | } 2900 | 2901 | /* Alternative */ 2902 | 2903 | create_AIK_Cert(...) = { 2904 | AIK = TPM_CreateWrapKey(Identity) 2905 | AIK-Cert = Call(AIK-CA, AIK.pubkey) 2906 | } 2908 Figure 3: Creating the TUDA-Cert element 2910 D.2.2. Synchronization Token 2912 The reference for Attestations are the Tick-Sessions of the TPM. In 2913 order to put Attestations into relation with a Real Time Clock (RTC), 2914 it is necessary to provide a cryptographic synchronization between 2915 the tick session and the RTC. To do so, a synchronization protocol 2916 is run with a Time Stamp Authority (TSA) that consists of three 2917 steps: 2919 * The TPM creates a TickStampBlob using the AIK 2921 * This TickStampBlob is used as nonce to the Timestamp of the TSA 2923 * Another TickStampBlob with the AIK is created using the TSA's 2924 Timestamp a nonce 2926 The first TickStampBlob is called "left" and the second "right" in a 2927 reference to their position on a time-axis. 2929 These three elements, with the TSA's certificate factored out, form 2930 the synchronization token 2932 TUDA-Synctoken = [ 2933 left: TickStampBlob-Output, 2934 timestamp: TimeStampToken, 2935 right: TickStampBlob-Output, 2936 ] 2938 TimeStampToken = bytes ; RFC 3161 2940 TickStampBlob-Output = [ 2941 currentTicks: TPM-CURRENT-TICKS, 2942 sig: bytes, 2943 ] 2945 TPM-CURRENT-TICKS = [ 2946 currentTicks: uint 2947 ? ( 2948 tickRate: uint 2949 tickNonce: TPM-NONCE 2950 ) 2951 ] 2952 ; Note that TickStampBlob-Output "right" can omit the values for 2953 ; tickRate and tickNonce since they are the same as in "left" 2955 TPM-NONCE = bytes .size 20 2957 Figure 4: TUDA-Sync element in CDDL 2959 Required TPM functions: 2961 | dummyDigest = h'0000000000000000000000000000000000000000' 2962 | dummyNonce = dummyDigest 2963 | 2964 | create_sync_token(AIKHandle, TSA) = { 2965 | ts_left = TPM_TickStampBlob( 2966 | keyHandle = AIK_Handle, /*TPM_KEY_HANDLE*/ 2967 | antiReplay = dummyNonce, /*TPM_NONCE*/ 2968 | digestToStamp = dummyDigest /*TPM_DIGEST*/) 2969 | 2970 | ts = TSA_Timestamp(TSA, nonce = hash(ts_left)) 2971 | 2972 | ts_right = TPM_TickStampBlob( 2973 | keyHandle = AIK_Handle, /*TPM_KEY_HANDLE*/ 2974 | antiReplay = dummyNonce, /*TPM_NONCE*/ 2975 | digestToStamp = hash(ts)) /*TPM_DIGEST*/ 2976 | 2977 | TUDA-SyncToken = [[ts_left.ticks, ts_left.sig], ts, 2978 | [ts_right.ticks.currentTicks, ts_right.sig]] 2979 | /* Note: skip the nonce and tickRate field for ts_right.ticks */ 2980 | } 2982 Figure 5: Creating the Sync-Token element 2984 D.2.3. RestrictionInfo 2986 The attestation relies on the capability of the TPM to operate on 2987 restricted keys. Whenever the PCR values for the machine to be 2988 attested change, a new restricted key is created that can only be 2989 operated as long as the PCRs remain in their current state. 2991 In order to prove to the Verifier that this restricted temporary key 2992 actually has these properties and also to provide the PCR value that 2993 it is restricted, the TPM command TPM_CertifyInfo is used. It 2994 creates a signed certificate using the AIK about the newly created 2995 restricted key. 2997 This token is formed from the list of: 2999 * PCR list, 3001 * the newly created restricted public key, and 3003 * the certificate. 3005 TUDA-RestrictionInfo = [Composite, 3006 restrictedKey_Pub: Pubkey, 3007 CertifyInfo] 3009 PCRSelection = bytes .size (2..4) ; used as bit string 3011 Composite = [ 3012 bitmask: PCRSelection, 3013 values: [*PCR-Hash], 3014 ] 3016 Pubkey = bytes ; may be extended to COSE pubkeys 3018 CertifyInfo = [ 3019 TPM-CERTIFY-INFO, 3020 sig: bytes, 3021 ] 3023 TPM-CERTIFY-INFO = [ 3024 ; we don't encode TPM-STRUCT-VER: 3025 ; these are 4 bytes always equal to h'01010000' 3026 keyUsage: uint, ; 4byte? 2byte? 3027 keyFlags: bytes .size 4, ; 4byte 3028 authDataUsage: uint, ; 1byte (enum) 3029 algorithmParms: TPM-KEY-PARMS, 3030 pubkeyDigest: Hash, 3031 ; we don't encode TPM-NONCE data, which is 20 bytes, all zero 3032 parentPCRStatus: bool, 3033 ; no need to encode pcrinfosize 3034 pcrinfo: TPM-PCR-INFO, ; we have exactly one 3035 ] 3037 TPM-PCR-INFO = [ 3038 pcrSelection: PCRSelection; /* TPM_PCR_SELECTION */ 3039 digestAtRelease: PCR-Hash; /* TPM_COMPOSITE_HASH */ 3040 digestAtCreation: PCR-Hash; /* TPM_COMPOSITE_HASH */ 3041 ] 3043 TPM-KEY-PARMS = [ 3044 ; algorithmID: uint, ; <= 4 bytes -- not encoded, constant for TPM1.2 3045 encScheme: uint, ; <= 2 bytes 3046 sigScheme: uint, ; <= 2 bytes 3047 parms: TPM-RSA-KEY-PARMS, 3048 ] 3050 TPM-RSA-KEY-PARMS = [ 3051 ; "size of the RSA key in bits": 3052 keyLength: uint 3053 ; "number of prime factors used by this RSA key": 3054 numPrimes: uint 3055 ; "This SHALL be the size of the exponent": 3056 exponentSize: null / uint / biguint 3057 ; "If the key is using the default exponent then the exponentSize 3058 ; MUST be 0" -> we represent this case as null 3059 ] 3061 Figure 6: TUDA-Key element in CDDL 3063 Required TPM functions: 3065 | dummyDigest = h'0000000000000000000000000000000000000000' 3066 | dummyNonce = dummyDigest 3067 | 3068 | create_Composite 3069 | 3070 | create_restrictedKey_Pub(pcrsel) = { 3071 | PCRInfo = {pcrSelection = pcrsel, 3072 | digestAtRelease = hash(currentValues(pcrSelection)) 3073 | digestAtCreation = dummyDigest} 3074 | / * PCRInfo is a TPM_PCR_INFO and thus also a TPM_KEY */ 3075 | 3076 | wk = TPM_CreateWrapKey(keyInfo = PCRInfo) 3077 | wk.keyInfo.pubKey 3078 | } 3079 | 3080 | create_TPM-Certify-Info = { 3081 | CertifyInfo = TPM_CertifyKey( 3082 | certHandle = AIK, /* TPM_KEY_HANDLE */ 3083 | keyHandle = wk, /* TPM_KEY_HANDLE */ 3084 | antiReply = dummyNonce) /* TPM_NONCE */ 3085 | 3086 | CertifyInfo.strip() 3087 | /* Remove those values that are not needed */ 3088 | } 3090 Figure 7: Creating the pubkey 3092 D.2.4. Measurement Log 3094 Similarly to regular attestations, the Verifier needs a way to 3095 reconstruct the PCRs' values in order to estimate the trustworthiness 3096 of the device. As such, a list of those elements that were extended 3097 into the PCRs is reported. Note though that for certain 3098 environments, this step may be optional if a list of valid PCR 3099 configurations exists and no measurement log is required. 3101 TUDA-Measurement-Log = [*PCR-Event] 3102 PCR-Event = [ 3103 type: PCR-Event-Type, 3104 pcr: uint, 3105 template-hash: PCR-Hash, 3106 filedata-hash: tagged-hash, 3107 pathname: text; called filename-hint in ima (non-ng) 3108 ] 3110 PCR-Event-Type = &( 3111 bios: 0 3112 ima: 1 3113 ima-ng: 2 3114 ) 3116 ; might want to make use of COSE registry here 3117 ; however, that might never define a value for sha1 3118 tagged-hash /= [sha1: 0, bytes .size 20] 3119 tagged-hash /= [sha256: 1, bytes .size 32] 3121 D.2.5. Implicit Attestation 3123 The actual attestation is then based upon a TickStampBlob using the 3124 restricted temporary key that was certified in the steps above. The 3125 TPM-Tickstamp is executed and thereby provides evidence that at this 3126 point in time (with respect to the TPM internal tick-session) a 3127 certain configuration existed (namely the PCR values associated with 3128 the restricted key). Together with the synchronization token this 3129 tick-related timing can then be related to the real-time clock. 3131 This element consists only of the TPM_TickStampBlock with no nonce. 3133 TUDA-Verifytoken = TickStampBlob-Output 3135 Figure 8: TUDA-Verify element in CDDL 3137 Required TPM functions: 3139 | imp_att = TPM_TickStampBlob( 3140 | keyHandle = restrictedKey_Handle, /*TPM_KEY_HANDLE*/ 3141 | antiReplay = dummyNonce, /*TPM_NONCE*/ 3142 | digestToStamp = dummyDigest) /*TPM_DIGEST*/ 3143 | 3144 | VerifyToken = imp_att 3146 Figure 9: Creating the Verify Token 3148 D.2.6. Attestation Verification Approach 3150 The seven TUDA information elements transport the essential content 3151 that is required to enable verification of the attestation statement 3152 at the Verifier. The following listings illustrate the verification 3153 algorithm to be used at the Verifier in pseudocode. The pseudocode 3154 provided covers the entire verification task. If only a subset of 3155 TUDA elements changed (see Section 6.1), only the corresponding code 3156 listings need to be re-executed. 3158 | TSA_pub = verifyCert(TSA-CA, Cert.TSA-Cert) 3159 | AIK_pub = verifyCert(AIK-CA, Cert.AIK-Cert) 3161 Figure 10: Verification of Certificates 3163 | ts_left = Synctoken.left 3164 | ts_right = Synctoken.right 3165 | 3166 | /* Reconstruct ts_right's omitted values; Alternatively assert == */ 3167 | ts_right.currentTicks.tickRate = ts_left.currentTicks.tickRate 3168 | ts_right.currentTicks.tickNonce = ts_left.currentTicks.tickNonce 3169 | 3170 | ticks_left = ts_left.currentTicks 3171 | ticks_right = ts_right.currentTicks 3172 | 3173 | /* Verify Signatures */ 3174 | verifySig(AIK_pub, dummyNonce || dummyDigest || ticks_left) 3175 | verifySig(TSA_pub, hash(ts_left) || timestamp.time) 3176 | verifySig(AIK_pub, dummyNonce || hash(timestamp) || ticks_right) 3177 | 3178 | delta_left = timestamp.time - 3179 | ticks_left.currentTicks * ticks_left.tickRate / 1000 3180 | 3181 | delta_right = timestamp.time - 3182 | ticks_right.currentTicks * ticks_right.tickRate / 1000 3184 Figure 11: Verification of Synchronization Token 3186 | compositeHash = hash_init() 3187 | for value in Composite.values: 3188 | hash_update(compositeHash, value) 3189 | compositeHash = hash_finish(compositeHash) 3190 | 3191 | certInfo = reconstruct_static(TPM-CERTIFY-INFO) 3192 | 3193 | assert(Composite.bitmask == ExpectedPCRBitmask) 3194 | assert(certInfo.pcrinfo.PCRSelection == Composite.bitmask) 3195 | assert(certInfo.pcrinfo.digestAtRelease == compositeHash) 3196 | assert(certInfo.pubkeyDigest == hash(restrictedKey_Pub)) 3197 | 3198 | verifySig(AIK_pub, dummyNonce || certInfo) 3200 Figure 12: Verification of Restriction Info 3202 | for event in Measurement-Log: 3203 | if event.pcr not in ExpectedPCRBitmask: 3204 | continue 3205 | if event.type == BIOS: 3206 | assert_whitelist-bios(event.pcr, event.template-hash) 3207 | if event.type == ima: 3208 | assert(event.pcr == 10) 3209 | assert_whitelist(event.pathname, event.filedata-hash) 3210 | assert(event.template-hash == 3211 | hash(event.pathname || event.filedata-hash)) 3212 | if event.type == ima-ng: 3213 | assert(event.pcr == 10) 3214 | assert_whitelist-ng(event.pathname, event.filedata-hash) 3215 | assert(event.template-hash == 3216 | hash(event.pathname || event.filedata-hash)) 3217 | 3218 | virtPCR[event.pcr] = hash_extend(virtPCR[event.pcr], 3219 | event.template-hash) 3220 | 3221 | for pcr in ExpectedPCRBitmask: 3222 | assert(virtPCR[pcr] == Composite.values[i++] 3224 Figure 13: Verification of Measurement Log 3226 | ts = Verifytoken 3227 | 3228 | /* Reconstruct ts's omitted values; Alternatively assert == */ 3229 | ts.currentTicks.tickRate = ts_left.currentTicks.tickRate 3230 | ts.currentTicks.tickNonce = ts_left.currentTicks.tickNonce 3231 | 3232 | verifySig(restrictedKey_pub, dummyNonce || dummyDigest || ts) 3233 | 3234 | ticks = ts.currentTicks 3235 | 3236 | time_left = delta_right + ticks.currentTicks * ticks.tickRate / 1000 3237 | time_right = delta_left + ticks.currentTicks * ticks.tickRate / 1000 3238 | 3239 | [time_left, time_right] 3241 Figure 14: Verification of Attestation Token 3243 D.3. IE Generation Procedures for TPM 2.0 3245 The pseudocode below includes general operations that are conducted 3246 as specific TPM commands: 3248 * hash() : description TBD 3250 * sig() : description TBD 3252 * X.509-Certificate() : description TBD 3254 These represent the output structure of that command in the form of a 3255 byte string value. 3257 D.3.1. AIK and AIK Certificate 3259 Attestations are based upon a cryptographic signature performed by 3260 the TPM using a so-called Attestation Identity Key (AIK). An AIK has 3261 the properties that it cannot be exported from a TPM and is used for 3262 attestations. Trust in the AIK is established by an X.509 3263 Certificate emitted by a Certificate Authority. The AIK certificate 3264 is either provided directly or via a so-called PrivacyCA 3265 [AIK-Enrollment]. 3267 This element consists of the AIK certificate that includes the AIK's 3268 public key used during verification as well as the certificate chain 3269 up to the Root CA for validation of the AIK certificate itself. 3271 TUDA-Cert = [AIK-Cert, TSA-Cert]; maybe split into two for SNMP 3272 AIK-Certificate = X.509-Certificate(AIK-Key,Restricted-Flag) 3273 TSA-Certificate = X.509-Certificate(TSA-Key, TSA-Flag) 3274 Figure 15: TUDA-Cert element for TPM 2.0 3276 D.3.2. Synchronization Token 3278 The synchronization token uses a different TPM command, TPM2 3279 GetTime() instead of TPM TickStampBlob(). The TPM2 GetTime() command 3280 contains the clock and time information of the TPM. The clock 3281 information is the equivalent of TUDA v1's tickSession information. 3283 TUDA-SyncToken = [ 3284 left_GetTime = sig(AIK-Key, 3285 TimeInfo = [ 3286 time, 3287 resetCount, 3288 restartCount 3289 ] 3290 ), 3291 middle_TimeStamp = sig(TSA-Key, 3292 hash(left_TickStampBlob), 3293 UTC-localtime 3294 ), 3295 right_TickStampBlob = sig(AIK-Key, 3296 hash(middle_TimeStamp), 3297 TimeInfo = [ 3298 time, 3299 resetCount, 3300 restartCount 3301 ] 3302 ) 3303 ] 3305 Figure 16: TUDA-Sync element for TPM 2.0 3307 D.3.3. Measurement Log 3309 The creation procedure is identical to Appendix D.2.4. 3311 Measurement-Log = [ 3312 * [ EventName, 3313 PCR-Num, 3314 Event-Hash ] 3315 ] 3317 Figure 17: TUDA-Log element for TPM 2.0 3319 D.3.4. Explicit time-based Attestation 3321 The TUDA attestation token consists of the result of TPM2_Quote() or 3322 a set of TPM2_PCR_READ followed by a TPM2_GetSessionAuditDigest. It 3323 proves that --- at a certain point-in-time with respect to the TPM's 3324 internal clock --- a certain configuration of PCRs was present, as 3325 denoted in the keys restriction information. 3327 TUDA-AttestationToken = TUDA-AttestationToken_quote / TUDA-AttestationToken_audit 3329 TUDA-AttestationToken_quote = sig(AIK-Key, 3330 TimeInfo = [ 3331 time, 3332 resetCount, 3333 restartCount 3334 ], 3335 PCR-Selection = [ * PCR], 3336 PCR-Digest := PCRDigest 3337 ) 3339 TUDA-AttestationToken_audit = sig(AIK-key, 3340 TimeInfo = [ 3341 time, 3342 resetCount, 3343 restartCount 3344 ], 3345 Session-Digest := PCRDigest 3346 ) 3348 Figure 18: TUDA-Attest element for TPM 2.0 3350 D.3.5. Sync Proof 3352 In order to proof to the Verifier that the TPM's clock was not 'fast- 3353 forwarded' the result of a TPM2_GetTime() is sent after the TUDA- 3354 AttestationToken. 3356 TUDA-SyncProof = sig(AIK-Key, 3357 TimeInfo = [ 3358 time, 3359 resetCount, 3360 restartCount 3361 ] 3362 ), 3364 Figure 19: TUDA-Proof element for TPM 2.0 3366 Acknowledgements 3368 Authors' Addresses 3370 Andreas Fuchs 3371 Fraunhofer Institute for Secure Information Technology 3372 Rheinstrasse 75 3373 64295 Darmstadt 3374 Germany 3376 Email: andreas.fuchs@sit.fraunhofer.de 3378 Henk Birkholz 3379 Fraunhofer Institute for Secure Information Technology 3380 Rheinstrasse 75 3381 64295 Darmstadt 3382 Germany 3384 Email: henk.birkholz@sit.fraunhofer.de 3386 Ira E McDonald 3387 High North Inc 3388 PO Box 221 3389 Grand Marais, 49839 3390 United States of America 3392 Email: blueroofmusic@gmail.com 3394 Carsten Bormann 3395 Universität Bremen TZI 3396 Bibliothekstr. 1 3397 D-28359 Bremen 3398 Germany 3400 Phone: +49-421-218-63921 3401 Email: cabo@tzi.org