| RATS Working Group | A. Fuchs |
| Internet-Draft | H. Birkholz |
| Intended status: Standards Track | Fraunhofer SIT |
| Expires: September 10, 2020 | I. McDonald |
| High North Inc | |
| C. Bormann | |
| Universitaet Bremen TZI | |
| March 09, 2020 |
Time-Based Uni-Directional Attestation
draft-birkholz-rats-tuda-02
This documents defines the method and bindings used to conduct Time-based Uni-Directional Attestation (TUDA) between two RATS (Remote ATtestation procedureS) Principals over the Internet. TUDA does not require a challenge-response handshake and thereby does not rely on the conveyance of a nonce to prove freshness of remote attestation Evidence. Conversely, TUDA enables the creation of Secure Audit Logs that can constitute Evidence about current and past operational states of an Attester. As a prerequisite for TUDA, every RATS Principal requires access to a trusted and synchronized time-source. Per default, in TUDA this is a Time Stamp Authority (TSA) issuing signed Time Stamp Tokens (TST).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Remote ATtestation procedureS (RATS) describe the attempt to determine and appraise properties, such as integrity and trustworthiness, of a communication partner – the Attester – over the Internet to another communication parter – the Verifier – without direct access. TUDA uses the architectural constituents of the RATS Architecture [I-D.ietf-rats-architecture] that defines the Roles Attester and Verifier in detail. The RATS Architecture also defines Role Messages. TUDA creates and conveys a specific type of Role Message called Evidence, a composition of trustwrthiness Claims provided by an Attester and consumed by a Verifier (potentially relayed by another RATS Role that is a Relying Party). TUDA – in contrast to traditional bi-directional challenge-response protocols [I-D.birkholz-rats-reference-interaction-model] – enables a uni-directional conveyance of attestation Evidence that allows for providing attestation information without solicitation (e.g. as beacons or push data via YANG Push [RFC8641], [RFC8640], [RFC8639]).
As a result, this document introduces the term Forward Authenticity.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Remote attestation Evidence is basically a set of trustworthiness claims (assertions about the Attester and its system characteristics including security posture and protection characteristics) that are accompanied by a proof of their veracity – typically a signature based on shielded, private and potentially restricted key material. As key material alone is typically not self-descriptive with respect to its intended use (its semantics), the remote attestation Evidence created via TUDA is accompanied by two kinds of certificates that are cryptographically associated with a Trust Anchor (TA) [RFC4949] via a certification path:
If a Verifier decides to trust both the TA of an AK-Cert and an EK-Cert presented by an Attester – and the included assertions about the system characteristics describing the Attester, the attestation Evidence created via TUDA by the Attester is considered believable. Ultimately, believable Evidence is appraised by a Verifier in order to assess the trustworthiness of the corresponding Attester.
The TUDA protocol mechanism uses hash values of all started software components as a basis to provide and create Evidence about the integrity of the software components of an Attester. This section defines the processed data items, the required system components, and corresponding operations to enable the creation of Evidence about software component integrity for TUDA.
The hash value of a software component created before it is executed is referred to as a “measurement” in the remainder of this document. Measurements are chained using a rolling hash function. Each measurement added to the sequence of all measurements results in a new current hash value that is referred to as a “digest” in the remainder of this document.
The function to store these measurements via a rolling hash function is provided by a root of trust for storage – a system component that MUST be a component of the attester.
With respect to the boot sequence of an Attester, the very first measurements of software components (e.g. the BIOS, or a sometimes a bootloader) have to be conducted by a root of trust for measurement that is implemented in hardware and MUST be a system component of the Attester.
All measurements retained in the root of trust for measurements are handed over to the root of trust for storage when it becomes available during the boot procedure of the Attester. During that hand-over the sequence of measurements retained in the root of trust for measurement are processed by the rolling hash function of the root of trust for storage.
The function of retrieving the current output value of the rolling hash function, including a signature to provide a proof of veracity, is provided by a root of trust for reporting and MUST be a system component of the Attester.
Typically, a root of trust for storage and a root of trust for reporting are tightly coupled. Analogously, a root of trust for measurement is typically independent from the root of trust for storage, but has to be able to interact with root of trust for storage at some point of the boot sequence of the Attester to hand over the retained measurements.
The operation of processing a measurement and adding it to the sequence of measurements via the rolling hash function is called “extend” and is provided by the root of trust for storage.
The operation of retrieving the current available hash value that is the result of the rolling hash function including a signature based on an Attestation Key is called “quote” and is provided by the corresponding root of trust for reporting.
In essence, RATS are composed of three base activities. The following definitions are derived from the definitions presented in [PRIRA] and [TCGGLOSS], and are a simplified summary of the RATS Architecture relevant for TUDA. The complete RATS Architecture and every corresponding constituent, message and interaction is defined in [I-D.ietf-rats-architecture].
With TUDA, the claims that compose the evidence are signatures over trustworthy integrity measurements created by leveraging roots of trust. The evidence is appraised via corresponding signatures over reference integrity measurements (RIM, represented, for example via [I-D.ietf-sacm-coswid]).
Protocols that facilitate Trust-Anchor based signatures in order to provide RATS are usually bi-directional challenge/response protocols, such as the Platform Trust Service protocol [PTS] or CAVES [PRIRA], where one entity sends a challenge that is included inside the response to prove the recentness – the freshness (see fresh in [RFC4949]) – of the attestation information. The corresponding interaction model tightly couples the three activities of creating, transferring and appraising evidence.
The Time-Based Uni-directional Attestation family of protocols – TUDA – described in this document can decouple the three activities RATS are composed of. As a result, TUDA provides additional capabilities, such as:
TUDA is a family of protocols that bundles results from specific attestation activities. The attestation activities of TUDA are based on a hardware roots of trust that provides the following capabilities:
To appraise the evidence created by an Attester, the Verifier requires corresponding Reference Integrity Measurements (RIM). Typical set of RIMs are required to assess the integrity of an Attester. These sets are called RIM Bundles. The scope of a RIM Bundle encompasses, e.g., a platform, a device, a computing context, or a virtualised function. In order to be comparable, the hashing algorithms used by the Attester to create the integrity measurements have to match the hashing algorithms used to create the corresponding RIM that are used by the Verifier to appraise the attestation Evidence about software component integrity.
Depending on the platform (i.e. one or more computing contexts including a dedicated hardware RoT), a generic RA activity results in platform-specific actions that have to be conducted. In consequence, there are multiple specific operations and data models (defining the input and output of operations). Hence, specific actions are are not covered by this document. Instead, the requirements on operations and the information elements that are the input and output to these operations are illustrated using pseudo code in Appendix C and D.
Both the attestation and the verification activity of TUDA also require a trusted Time Stamp Authority (TSA) as an additional third party next to the Attester and the Verifier. The protocol uses a Time Stamp Authority based on [RFC3161]. The combination of the local source of time provided by the hardware RoT (located on the Attester) and the Time Stamp Tokens provided by the TSA (to both the Attester and the Verifier) enable the attestation and verification of an appropriate freshness of the evidence conveyed by the Attester — without requiring a challenge/response interaction model that uses a nonce to ensure the freshness.
Typically, the verification activity requires declarative guidance (representing desired or compliant endpoint characteristics in the form of RIM, see above) to appraise the individual integrity measurements the conveyed evidence is composed on. The acquisition or representation (data models) of declarative guidance as well as the corresponding evaluation methods are out of the scope of this document.
TUDA defines a set of information elements (IE) that are created and stored on the Attester and are intended to be transferred to the Verifier in order to enable appraisal. Each TUDA IE:
The Time-Based Uni-directional Attestation family of protocols is designed to:
The binding of the attestation scheme used by TUDA to generate the TUDA IE is specific to the methods provided by the hardware RoT used (see above). In this document,expositional text and pseudo-code that is provided as a reference to instantiate the TUDA IE is based on TPM 1.2 and TPM 2.0 operations. The corresponding TPM commands are specified in [TPM12] and [TPM2]. The references to TPM commands and corresponding pseudo-code only serve as guidance to enable a better understanding of the attestation scheme and is intended to encourage the use of any appropriate hardware RoT or equivalent set of functions available to a CPU or Trusted Execution Environment [TEE].
There are significant differences between conventional bi-directional attestation and TUDA regarding both the information elements conveyed between Attester and Verifier and the time-frame, in which an attestation can be considered to be fresh (and therefore trustworthy).
In general, remote attestation using a bi-directional communication scheme includes sending a nonce-challenge within a signed attestation token. Using the TPM 1.2 as an example, a corresponding nonce-challenge would be included within the signature created by the TPM_Quote command in order to prove the freshness of the attestation response, see e.g. [PTS].
In contrast, the TUDA protocol uses the combined output of TPM_CertifyInfo and TPM_TickStampBlob. The former provides a proof about the platform’s state by creating evidence that a certain key is bound to that state. The latter provides proof that the platform was in the specified state by using the bound key in a time operation. This combination enables a time-based attestation scheme. The approach is based on the concepts introduced in [SCALE] and [SFKE2008].
Each TUDA IE has an individual time-frame, in which it is considered to be fresh (and therefore trustworthy). In consequence, each TUDA IE that composes data in motion is based on different methods of creation.
The freshness properties of a challenge-response based protocol define the point-of-time of attestation between:
Given the time-based attestation scheme, the freshness property of TUDA is equivalent to that of bi-directional challenge response attestation, if the point-in-time of attestation lies between:
The accuracy of this time-frame is defined by two factors:
Since the conveyance of TUDA evidence does not rely upon a Verifier provided value (i.e. the nonce), the security guarantees of the protocol only incorporate the TSA and the hardware RoT. In consequence, TUDA evidence can even serve as proof of integrity in audit logs with precise point-in-time guarantees, in contrast to classical attestations.
Appendix A contains guidance on how to utilize a REST architecture.
Appendix B contains guidance on how to create an SNMP binding and a corresponding TUDA-MIB.
Appendix C contains a corresponding YANG module that supports both RESTCONF and CoMI.
Appendix D.2 contains a realization of TUDA using TPM 1.2 primitives.
Appendix D.3 contains a realization of TUDA using TPM 2.0 primitives.
This document introduces roles, information elements and types required to conduct TUDA and uses terminology (e.g. specific certificate names) typically seen in the context of attestation or hardware security modules.
A Time-Based Uni-Directional Attestation (TUDA) consists of the following seven information elements. They are used to gain assurance of the Attester’s platform configuration at a certain point in time:
These information elements could be sent en bloc, but it is recommended to retrieve them separately to save bandwidth, since these elements have different update cycles. In most cases, retransmitting all seven information elements would result in unnecessary redundancy.
Furthermore, in some scenarios it might be feasible not to store all elements on the Attester endpoint, but instead they could be retrieved from another location or be pre-deployed to the Verifier. It is also feasible to only store public keys on the Verifier and skip the whole certificate provisioning completely in order to save bandwidth and computation time for certificate verification.
An endpoint can be in various states and have various information associated with it during its life cycle. For TUDA, a subset of the states (which can include associated information) that an endpoint and its hardware root of trust can be in, is important to the attestation process. States can be:
Depending on this “lifetime of state”, data has to be transported over the wire, or not. E.g. information that does not change due to a reboot typically has to be transported only once between the Attester and the Verifier.
There are three kinds of events that require a renewed attestation:
The third event listed above is variable per application use case and also depends on the precision of the clock included in the hardware RoT. For usage scenarios, in which the device would periodically push information to be used in an audit-log, a time-frame of approximately one update per minute should be sufficient in most cases. For those usage scenarios, where Verifiers request (pull) a fresh attestation statement, an implementation could use the hardware RoT continuously to always present the most freshly created results. To save some utilization of the hardware RoT for other purposes, however, a time-frame of once per ten seconds is recommended, which would typically leave about 80% of utilization for other applications.
Attester Verifier | | Boot | | | Create Sync-Token | | | Create Restricted Key | Certify Restricted Key | | | | AIK-Cert ---------------------------------------------> | | Sync-Token -------------------------------------------> | | Certify-Info -----------------------------------------> | | Measurement Log --------------------------------------> | | Attestation ------------------------------------------> | | Verify Attestation | | | <Time Passed> | | | | Attestation ------------------------------------------> | | Verify Attestation | | | <Time Passed> | | | PCR-Change | | | Create Restricted Key | Certify Restricted Key | | | | Certify-Info -----------------------------------------> | | Measurement Log --------------------------------------> | | Attestation ------------------------------------------> | | Verify Attestation | | Boot | | | Create Sync-Token | | | Create Restricted Key | Certify Restricted Key | | | | Sync-Token -------------------------------------------> | | Certify-Info -----------------------------------------> | | Measurement Log --------------------------------------> | | Attestation ------------------------------------------> | | Verify Attestation | | | <Time Passed> | | | | Attestation ------------------------------------------> | | Verify Attestation | |
Figure 1: Example sequence of events
The uni-directional approach of TUDA requires evidence on how the TPM time represented in ticks (relative time since boot of the TPM) relates to the standard time provided by the TSA. The Sync Base Protocol (SBP) creates evidence that binds the TPM tick time to the TSA timestamp. The binding information is used by and conveyed via the Sync Token (TUDA IE). There are three actions required to create the content of a Sync Token:
The three time-related values — the relative timestamps provided by the hardware RoT (“left” and “right”) and the TSA timestamp — and their corresponding signatures are aggregated in order to create a corresponding Sync Token to be used as a TUDA Information Element that can be conveyed as evidence to a Verifier.
The drift of a clock incorporated in the hardware RoT that drives the increments of the tick counter constitutes one of the triggers that can initiate a TUDA Information Element Update Cycle in respect to the freshness of the available Sync Token.
content TBD
This memo includes requests to IANA, including registrations for media type definitions.
TBD
There are Security Considerations. TBD
Changes from version 04 to I2NSF related document version 00: * Refactored main document to be more technology agnostic * Added first draft of procedures for TPM 2.0 * Improved content consistency and structure of all sections
Changes from version 03 to version 04:
Changes from version 02 to version 03:
Changes from version 01 to version 02:
Changes from version 00 to version 01:
Major update to the SNMP MIB and added a table for the Concise SWID profile Reference Hashes that provides additional information to be compared with the measurement logs.
TBD
| [I-D.ietf-rats-architecture] | Birkholz, H., Thaler, D., Richardson, M., Smith, N. and W. Pan, "Remote Attestation Procedures Architecture", Internet-Draft draft-ietf-rats-architecture-02, March 2020. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [RFC8639] | Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E. and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019. |
| [RFC8640] | Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E. and A. Tripathy, "Dynamic Subscription to YANG Events and Datastores over NETCONF", RFC 8640, DOI 10.17487/RFC8640, September 2019. |
| [RFC8641] | Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019. |
Each of the seven data items is defined as a media type (Section 6). Representations of resources for each of these media types can be retrieved from URIs that are defined by the respective servers [RFC7320]. As can be derived from the URI, the actual retrieval is via one of the HTTPs ([RFC7230], [RFC7540]) or CoAP [RFC7252]. How a client obtains these URIs is dependent on the application; e.g., CoRE Web links [RFC6690] can be used to obtain the relevant URIs from the self-description of a server, or they could be prescribed by a RESTCONF data model [RFC8040].
SNMPv3 [STD62] [RFC3411] is widely available on computers and also constrained devices. To transport the TUDA information elements, an SNMP MIB is defined below which encodes each of the seven TUDA information elements into a table. Each row in a table contains a single read-only columnar SNMP object of datatype OCTET-STRING. The values of a set of rows in each table can be concatenated to reconstitute a CBOR-encoded TUDA information element. The Verifier can retrieve the values for each CBOR fragment by using SNMP GetNext requests to “walk” each table and can decode each of the CBOR-encoded data items based on the corresponding CDDL [RFC8610] definition.
Design Principles:
The following table summarizes the object groups, tables and their indexes, and conformance requirements for the TUDA MIB:
|-------------|-------|----------|----------|----------| | Group/Table | Cycle | Instance | Fragment | Required | |-------------|-------|----------|----------|----------| | General | | | | x | | AIKCert | x | x | x | | | TSACert | x | x | x | | | SyncToken | x | | x | x | | Restrict | x | | | x | | Measure | x | x | | | | VerifyToken | x | | | x | | SWIDTag | x | x | x | | |-------------|-------|----------|----------|----------|
A tudaV1<Group>CycleIndex is the:
A tudaV1<Group>InstanceIndex is the:
A tudaV1<Group>FragmentIndex is the:
The General group in the TUDA MIB is analogous to the System group in the Host Resources MIB [RFC2790] and provides context information for the TUDA attestation process.
The Verify Token group in the TUDA MIB is analogous to the Device group in the Host MIB and represents the verifiable state of a TPM device and its associated system.
The SWID Tag group (containing a Concise SWID reference hash profile [I-D.ietf-sacm-coswid]) in the TUDA MIB is analogous to the Software Installed and Software Running groups in the Host Resources MIB [RFC2790].
The General group in the TUDA MIB is analogous to the Entity General group in the Entity MIB v4 [RFC6933] and provides context information for the TUDA attestation process.
The SWID Tag group in the TUDA MIB is analogous to the Entity Logical group in the Entity MIB v4 [RFC6933].
The General group in the TUDA MIB is analogous to the System group in MIB-II [RFC1213] and the System group in the SNMPv2 MIB [RFC3418] and provides context information for the TUDA attestation process.
<CODE BEGINS>
TUDA-V1-ATTESTATION-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32,
enterprises, NOTIFICATION-TYPE
FROM SNMPv2-SMI -- RFC 2578
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF -- RFC 2580
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB; -- RFC 3411
tudaV1MIB MODULE-IDENTITY
LAST-UPDATED "202003090000Z" -- 09 March 2020
ORGANIZATION
"Fraunhofer SIT"
CONTACT-INFO
"Andreas Fuchs
Fraunhofer Institute for Secure Information Technology
Email: andreas.fuchs@sit.fraunhofer.de
Henk Birkholz
Fraunhofer Institute for Secure Information Technology
Email: henk.birkholz@sit.fraunhofer.de
Ira E McDonald
High North Inc
Email: blueroofmusic@gmail.com
Carsten Bormann
Universitaet Bremen TZI
Email: cabo@tzi.org"
DESCRIPTION
"The MIB module for monitoring of time-based unidirectional
attestation information from a network endpoint system,
based on the Trusted Computing Group TPM 1.2 definition.
Copyright (C) High North Inc (2020)."
REVISION "202003090000Z" -- 09 March 2020
DESCRIPTION
"Eighth version, published as draft-birkholz-rats-tuda-02."
REVISION "201909110000Z" -- 11 September 2019
DESCRIPTION
"Ninth version, published as draft-birkholz-rats-tuda-01."
REVISION "201903120000Z" -- 12 March 2019
DESCRIPTION
"Eighth version, published as draft-birkholz-rats-tuda-00."
REVISION "201805030000Z" -- 03 May 2018
DESCRIPTION
"Seventh version, published as draft-birkholz-i2nsf-tuda-03."
REVISION "201805020000Z" -- 02 May 2018
DESCRIPTION
"Sixth version, published as draft-birkholz-i2nsf-tuda-02."
REVISION "201710300000Z" -- 30 October 2017
DESCRIPTION
"Fifth version, published as draft-birkholz-i2nsf-tuda-01."
REVISION "201701090000Z" -- 09 January 2017
DESCRIPTION
"Fourth version, published as draft-birkholz-i2nsf-tuda-00."
REVISION "201607080000Z" -- 08 July 2016
DESCRIPTION
"Third version, published as draft-birkholz-tuda-02."
REVISION "201603210000Z" -- 21 March 2016
DESCRIPTION
"Second version, published as draft-birkholz-tuda-01."
REVISION "201510180000Z" -- 18 October 2015
DESCRIPTION
"Initial version, published as draft-birkholz-tuda-00."
::= { enterprises fraunhofersit(21616) mibs(1) tudaV1MIB(1) }
tudaV1MIBNotifications OBJECT IDENTIFIER ::= { tudaV1MIB 0 }
tudaV1MIBObjects OBJECT IDENTIFIER ::= { tudaV1MIB 1 }
tudaV1MIBConformance OBJECT IDENTIFIER ::= { tudaV1MIB 2 }
--
-- General
--
tudaV1General OBJECT IDENTIFIER ::= { tudaV1MIBObjects 1 }
tudaV1GeneralCycles OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of TUDA update cycles that have occurred, i.e.,
sum of all the individual group cycle counters.
DEFVAL intentionally omitted - counter object."
::= { tudaV1General 1 }
tudaV1GeneralVersionInfo OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Version information for TUDA MIB, e.g., specific release
version of TPM 1.2 base specification and release version
of TPM 1.2 errata specification and manufacturer and model
TPM module itself."
DEFVAL { "" }
::= { tudaV1General 2 }
--
-- AIK Cert
--
tudaV1AIKCert OBJECT IDENTIFIER ::= { tudaV1MIBObjects 2 }
tudaV1AIKCertCycles OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of AIK Certificate chain update cycles that have
occurred.
DEFVAL intentionally omitted - counter object."
::= { tudaV1AIKCert 1 }
tudaV1AIKCertTable OBJECT-TYPE
SYNTAX SEQUENCE OF TudaV1AIKCertEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of fragments of AIK Certificate data."
::= { tudaV1AIKCert 2 }
tudaV1AIKCertEntry OBJECT-TYPE
SYNTAX TudaV1AIKCertEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one fragment of AIK Certificate data."
INDEX { tudaV1AIKCertCycleIndex,
tudaV1AIKCertInstanceIndex,
tudaV1AIKCertFragmentIndex }
::= { tudaV1AIKCertTable 1 }
TudaV1AIKCertEntry ::=
SEQUENCE {
tudaV1AIKCertCycleIndex Integer32,
tudaV1AIKCertInstanceIndex Integer32,
tudaV1AIKCertFragmentIndex Integer32,
tudaV1AIKCertData OCTET STRING
}
tudaV1AIKCertCycleIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"High-order index of this AIK Certificate fragment.
Index of an AIK Certificate chain update cycle that has
occurred (bounded by the value of tudaV1AIKCertCycles).
DEFVAL intentionally omitted - index object."
::= { tudaV1AIKCertEntry 1 }
tudaV1AIKCertInstanceIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Middle index of this AIK Certificate fragment.
Ordinal of this AIK Certificate in this chain, where the AIK
Certificate itself has an ordinal of '1' and higher ordinals
go *up* the certificate chain to the Root CA.
DEFVAL intentionally omitted - index object."
::= { tudaV1AIKCertEntry 2 }
tudaV1AIKCertFragmentIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Low-order index of this AIK Certificate fragment.
DEFVAL intentionally omitted - index object."
::= { tudaV1AIKCertEntry 3 }
tudaV1AIKCertData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A fragment of CBOR encoded AIK Certificate data."
DEFVAL { "" }
::= { tudaV1AIKCertEntry 4 }
--
-- TSA Cert
--
tudaV1TSACert OBJECT IDENTIFIER ::= { tudaV1MIBObjects 3 }
tudaV1TSACertCycles OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of TSA Certificate chain update cycles that have
occurred.
DEFVAL intentionally omitted - counter object."
::= { tudaV1TSACert 1 }
tudaV1TSACertTable OBJECT-TYPE
SYNTAX SEQUENCE OF TudaV1TSACertEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of fragments of TSA Certificate data."
::= { tudaV1TSACert 2 }
tudaV1TSACertEntry OBJECT-TYPE
SYNTAX TudaV1TSACertEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one fragment of TSA Certificate data."
INDEX { tudaV1TSACertCycleIndex,
tudaV1TSACertInstanceIndex,
tudaV1TSACertFragmentIndex }
::= { tudaV1TSACertTable 1 }
TudaV1TSACertEntry ::=
SEQUENCE {
tudaV1TSACertCycleIndex Integer32,
tudaV1TSACertInstanceIndex Integer32,
tudaV1TSACertFragmentIndex Integer32,
tudaV1TSACertData OCTET STRING
}
tudaV1TSACertCycleIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"High-order index of this TSA Certificate fragment.
Index of a TSA Certificate chain update cycle that has
occurred (bounded by the value of tudaV1TSACertCycles).
DEFVAL intentionally omitted - index object."
::= { tudaV1TSACertEntry 1 }
tudaV1TSACertInstanceIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Middle index of this TSA Certificate fragment.
Ordinal of this TSA Certificate in this chain, where the TSA
Certificate itself has an ordinal of '1' and higher ordinals
go *up* the certificate chain to the Root CA.
DEFVAL intentionally omitted - index object."
::= { tudaV1TSACertEntry 2 }
tudaV1TSACertFragmentIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Low-order index of this TSA Certificate fragment.
DEFVAL intentionally omitted - index object."
::= { tudaV1TSACertEntry 3 }
tudaV1TSACertData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A fragment of CBOR encoded TSA Certificate data."
DEFVAL { "" }
::= { tudaV1TSACertEntry 4 }
--
-- Sync Token
--
tudaV1SyncToken OBJECT IDENTIFIER ::= { tudaV1MIBObjects 4 }
tudaV1SyncTokenCycles OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of Sync Token update cycles that have
occurred.
DEFVAL intentionally omitted - counter object."
::= { tudaV1SyncToken 1 }
tudaV1SyncTokenInstances OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of Sync Token instance entries that have
been recorded (some entries MAY have been pruned).
DEFVAL intentionally omitted - counter object."
::= { tudaV1SyncToken 2 }
tudaV1SyncTokenTable OBJECT-TYPE
SYNTAX SEQUENCE OF TudaV1SyncTokenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of fragments of Sync Token data."
::= { tudaV1SyncToken 3 }
tudaV1SyncTokenEntry OBJECT-TYPE
SYNTAX TudaV1SyncTokenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one fragment of Sync Token data."
INDEX { tudaV1SyncTokenCycleIndex,
tudaV1SyncTokenInstanceIndex,
tudaV1SyncTokenFragmentIndex }
::= { tudaV1SyncTokenTable 1 }
TudaV1SyncTokenEntry ::=
SEQUENCE {
tudaV1SyncTokenCycleIndex Integer32,
tudaV1SyncTokenInstanceIndex Integer32,
tudaV1SyncTokenFragmentIndex Integer32,
tudaV1SyncTokenData OCTET STRING
}
tudaV1SyncTokenCycleIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"High-order index of this Sync Token fragment.
Index of a Sync Token update cycle that has
occurred (bounded by the value of tudaV1SyncTokenCycles).
DEFVAL intentionally omitted - index object."
::= { tudaV1SyncTokenEntry 1 }
tudaV1SyncTokenInstanceIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Middle index of this Sync Token fragment.
Ordinal of this instance of Sync Token data
(NOT bounded by the value of tudaV1SyncTokenInstances).
DEFVAL intentionally omitted - index object."
::= { tudaV1SyncTokenEntry 2 }
tudaV1SyncTokenFragmentIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Low-order index of this Sync Token fragment.
DEFVAL intentionally omitted - index object."
::= { tudaV1SyncTokenEntry 3 }
tudaV1SyncTokenData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A fragment of CBOR encoded Sync Token data."
DEFVAL { "" }
::= { tudaV1SyncTokenEntry 4 }
--
-- Restriction Info
--
tudaV1Restrict OBJECT IDENTIFIER ::= { tudaV1MIBObjects 5 }
tudaV1RestrictCycles OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of Restriction Info update cycles that have
occurred.
DEFVAL intentionally omitted - counter object."
::= { tudaV1Restrict 1 }
tudaV1RestrictTable OBJECT-TYPE
SYNTAX SEQUENCE OF TudaV1RestrictEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of instances of Restriction Info data."
::= { tudaV1Restrict 2 }
tudaV1RestrictEntry OBJECT-TYPE
SYNTAX TudaV1RestrictEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one instance of Restriction Info data."
INDEX { tudaV1RestrictCycleIndex }
::= { tudaV1RestrictTable 1 }
TudaV1RestrictEntry ::=
SEQUENCE {
tudaV1RestrictCycleIndex Integer32,
tudaV1RestrictData OCTET STRING
}
tudaV1RestrictCycleIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index of this Restriction Info entry.
Index of a Restriction Info update cycle that has
occurred (bounded by the value of tudaV1RestrictCycles).
DEFVAL intentionally omitted - index object."
::= { tudaV1RestrictEntry 1 }
tudaV1RestrictData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An instance of CBOR encoded Restriction Info data."
DEFVAL { "" }
::= { tudaV1RestrictEntry 2 }
--
-- Measurement Log
--
tudaV1Measure OBJECT IDENTIFIER ::= { tudaV1MIBObjects 6 }
tudaV1MeasureCycles OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of Measurement Log update cycles that have
occurred.
DEFVAL intentionally omitted - counter object."
::= { tudaV1Measure 1 }
tudaV1MeasureInstances OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of Measurement Log instance entries that have
been recorded (some entries MAY have been pruned).
DEFVAL intentionally omitted - counter object."
::= { tudaV1Measure 2 }
tudaV1MeasureTable OBJECT-TYPE
SYNTAX SEQUENCE OF TudaV1MeasureEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of instances of Measurement Log data."
::= { tudaV1Measure 3 }
tudaV1MeasureEntry OBJECT-TYPE
SYNTAX TudaV1MeasureEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one instance of Measurement Log data."
INDEX { tudaV1MeasureCycleIndex,
tudaV1MeasureInstanceIndex }
::= { tudaV1MeasureTable 1 }
TudaV1MeasureEntry ::=
SEQUENCE {
tudaV1MeasureCycleIndex Integer32,
tudaV1MeasureInstanceIndex Integer32,
tudaV1MeasureData OCTET STRING
}
tudaV1MeasureCycleIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"High-order index of this Measurement Log entry.
Index of a Measurement Log update cycle that has
occurred (bounded by the value of tudaV1MeasureCycles).
DEFVAL intentionally omitted - index object."
::= { tudaV1MeasureEntry 1 }
tudaV1MeasureInstanceIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Low-order index of this Measurement Log entry.
Ordinal of this instance of Measurement Log data
(NOT bounded by the value of tudaV1MeasureInstances).
DEFVAL intentionally omitted - index object."
::= { tudaV1MeasureEntry 2 }
tudaV1MeasureData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A instance of CBOR encoded Measurement Log data."
DEFVAL { "" }
::= { tudaV1MeasureEntry 3 }
--
-- Verify Token
--
tudaV1VerifyToken OBJECT IDENTIFIER ::= { tudaV1MIBObjects 7 }
tudaV1VerifyTokenCycles OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of Verify Token update cycles that have
occurred.
DEFVAL intentionally omitted - counter object."
::= { tudaV1VerifyToken 1 }
tudaV1VerifyTokenTable OBJECT-TYPE
SYNTAX SEQUENCE OF TudaV1VerifyTokenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of instances of Verify Token data."
::= { tudaV1VerifyToken 2 }
tudaV1VerifyTokenEntry OBJECT-TYPE
SYNTAX TudaV1VerifyTokenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one instance of Verify Token data."
INDEX { tudaV1VerifyTokenCycleIndex }
::= { tudaV1VerifyTokenTable 1 }
TudaV1VerifyTokenEntry ::=
SEQUENCE {
tudaV1VerifyTokenCycleIndex Integer32,
tudaV1VerifyTokenData OCTET STRING
}
tudaV1VerifyTokenCycleIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index of this instance of Verify Token data.
Index of a Verify Token update cycle that has
occurred (bounded by the value of tudaV1VerifyTokenCycles).
DEFVAL intentionally omitted - index object."
::= { tudaV1VerifyTokenEntry 1 }
tudaV1VerifyTokenData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A instance of CBOR encoded Verify Token data."
DEFVAL { "" }
::= { tudaV1VerifyTokenEntry 2 }
--
-- SWID Tag
--
tudaV1SWIDTag OBJECT IDENTIFIER ::= { tudaV1MIBObjects 8 }
tudaV1SWIDTagCycles OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of SWID Tag update cycles that have occurred.
DEFVAL intentionally omitted - counter object."
::= { tudaV1SWIDTag 1 }
tudaV1SWIDTagTable OBJECT-TYPE
SYNTAX SEQUENCE OF TudaV1SWIDTagEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of fragments of SWID Tag data."
::= { tudaV1SWIDTag 2 }
tudaV1SWIDTagEntry OBJECT-TYPE
SYNTAX TudaV1SWIDTagEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one fragment of SWID Tag data."
INDEX { tudaV1SWIDTagCycleIndex,
tudaV1SWIDTagInstanceIndex,
tudaV1SWIDTagFragmentIndex }
::= { tudaV1SWIDTagTable 1 }
TudaV1SWIDTagEntry ::=
SEQUENCE {
tudaV1SWIDTagCycleIndex Integer32,
tudaV1SWIDTagInstanceIndex Integer32,
tudaV1SWIDTagFragmentIndex Integer32,
tudaV1SWIDTagData OCTET STRING
}
tudaV1SWIDTagCycleIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"High-order index of this SWID Tag fragment.
Index of an SWID Tag update cycle that has
occurred (bounded by the value of tudaV1SWIDTagCycles).
DEFVAL intentionally omitted - index object."
::= { tudaV1SWIDTagEntry 1 }
tudaV1SWIDTagInstanceIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Middle index of this SWID Tag fragment.
Ordinal of this SWID Tag instance in this update cycle.
DEFVAL intentionally omitted - index object."
::= { tudaV1SWIDTagEntry 2 }
tudaV1SWIDTagFragmentIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Low-order index of this SWID Tag fragment.
DEFVAL intentionally omitted - index object."
::= { tudaV1SWIDTagEntry 3 }
tudaV1SWIDTagData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A fragment of CBOR encoded SWID Tag data."
DEFVAL { "" }
::= { tudaV1SWIDTagEntry 4 }
--
-- Trap Cycles
--
tudaV1TrapV2Cycles NOTIFICATION-TYPE
OBJECTS {
tudaV1GeneralCycles,
tudaV1AIKCertCycles,
tudaV1TSACertCycles,
tudaV1SyncTokenCycles,
tudaV1SyncTokenInstances,
tudaV1RestrictCycles,
tudaV1MeasureCycles,
tudaV1MeasureInstances,
tudaV1VerifyTokenCycles,
tudaV1SWIDTagCycles
}
STATUS current
DESCRIPTION
"This trap is sent when the value of any cycle or instance
counter changes (i.e., one or more tables are updated).
Note: The value of sysUpTime in IETF MIB-II (RFC 1213) is
always included in SNMPv2 traps, per RFC 3416."
::= { tudaV1MIBNotifications 1 }
--
-- Conformance Information
--
tudaV1Compliances OBJECT IDENTIFIER
::= { tudaV1MIBConformance 1 }
tudaV1ObjectGroups OBJECT IDENTIFIER
::= { tudaV1MIBConformance 2 }
tudaV1NotificationGroups OBJECT IDENTIFIER
::= { tudaV1MIBConformance 3 }
--
-- Compliance Statements
--
tudaV1BasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"An implementation that complies with this module MUST
implement all of the objects defined in the mandatory
group tudaV1BasicGroup."
MODULE -- this module
MANDATORY-GROUPS { tudaV1BasicGroup }
GROUP tudaV1OptionalGroup
DESCRIPTION
"The optional TUDA MIB objects.
An implementation MAY implement this group."
GROUP tudaV1TrapGroup
DESCRIPTION
"The TUDA MIB traps.
An implementation SHOULD implement this group."
::= { tudaV1Compliances 1 }
--
-- Compliance Groups
--
tudaV1BasicGroup OBJECT-GROUP
OBJECTS {
tudaV1GeneralCycles,
tudaV1GeneralVersionInfo,
tudaV1SyncTokenCycles,
tudaV1SyncTokenInstances,
tudaV1SyncTokenData,
tudaV1RestrictCycles,
tudaV1RestrictData,
tudaV1VerifyTokenCycles,
tudaV1VerifyTokenData
}
STATUS current
DESCRIPTION
"The basic mandatory TUDA MIB objects."
::= { tudaV1ObjectGroups 1 }
tudaV1OptionalGroup OBJECT-GROUP
OBJECTS {
tudaV1AIKCertCycles,
tudaV1AIKCertData,
tudaV1TSACertCycles,
tudaV1TSACertData,
tudaV1MeasureCycles,
tudaV1MeasureInstances,
tudaV1MeasureData,
tudaV1SWIDTagCycles,
tudaV1SWIDTagData
}
STATUS current
DESCRIPTION
"The optional TUDA MIB objects."
::= { tudaV1ObjectGroups 2 }
tudaV1TrapGroup NOTIFICATION-GROUP
NOTIFICATIONS { tudaV1TrapV2Cycles }
STATUS current
DESCRIPTION
"The recommended TUDA MIB traps - notifications."
::= { tudaV1NotificationGroups 1 }
END
<CODE ENDS>
<CODE BEGINS>
module TUDA-V1-ATTESTATION-MIB {
namespace "urn:ietf:params:xml:ns:yang:smiv2:TUDA-V1-ATTESTATION-MIB";
prefix "tuda-v1";
import SNMP-FRAMEWORK-MIB { prefix "snmp-framework"; }
import yang-types { prefix "yang"; }
organization
"Fraunhofer SIT";
contact
"Andreas Fuchs
Fraunhofer Institute for Secure Information Technology
Email: andreas.fuchs@sit.fraunhofer.de
Henk Birkholz
Fraunhofer Institute for Secure Information Technology
Email: henk.birkholz@sit.fraunhofer.de
Ira E McDonald
High North Inc
Email: blueroofmusic@gmail.com
Carsten Bormann
Universitaet Bremen TZI
Email: cabo@tzi.org";
description
"The MIB module for monitoring of time-based unidirectional
attestation information from a network endpoint system,
based on the Trusted Computing Group TPM 1.2 definition.
Copyright (C) High North Inc (2017).";
revision "2017-10-30" {
description
"Fifth version, published as draft-birkholz-tuda-04.";
reference
"draft-birkholz-tuda-04";
}
revision "2017-01-09" {
description
"Fourth version, published as draft-birkholz-tuda-03.";
reference
"draft-birkholz-tuda-03";
}
revision "2016-07-08" {
description
"Third version, published as draft-birkholz-tuda-02.";
reference
"draft-birkholz-tuda-02";
}
revision "2016-03-21" {
description
"Second version, published as draft-birkholz-tuda-01.";
reference
"draft-birkholz-tuda-01";
}
revision "2015-10-18" {
description
"Initial version, published as draft-birkholz-tuda-00.";
reference
"draft-birkholz-tuda-00";
}
container tudaV1General {
description
"TBD";
leaf tudaV1GeneralCycles {
type yang:counter32;
config false;
description
"Count of TUDA update cycles that have occurred, i.e.,
sum of all the individual group cycle counters.
DEFVAL intentionally omitted - counter object.";
}
leaf tudaV1GeneralVersionInfo {
type snmp-framework:SnmpAdminString {
length "0..255";
}
config false;
description
"Version information for TUDA MIB, e.g., specific release
version of TPM 1.2 base specification and release version
of TPM 1.2 errata specification and manufacturer and model
TPM module itself.";
}
}
container tudaV1AIKCert {
description
"TBD";
leaf tudaV1AIKCertCycles {
type yang:counter32;
config false;
description
"Count of AIK Certificate chain update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
/* XXX table comments here XXX */
list tudaV1AIKCertEntry {
key "tudaV1AIKCertCycleIndex tudaV1AIKCertInstanceIndex
tudaV1AIKCertFragmentIndex";
config false;
description
"An entry for one fragment of AIK Certificate data.";
leaf tudaV1AIKCertCycleIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"High-order index of this AIK Certificate fragment.
Index of an AIK Certificate chain update cycle that has
occurred (bounded by the value of tudaV1AIKCertCycles).
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1AIKCertInstanceIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Middle index of this AIK Certificate fragment.
Ordinal of this AIK Certificate in this chain, where the AIK
Certificate itself has an ordinal of '1' and higher ordinals
go *up* the certificate chain to the Root CA.
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1AIKCertFragmentIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Low-order index of this AIK Certificate fragment.
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1AIKCertData {
type binary {
length "0..1024";
}
config false;
description
"A fragment of CBOR encoded AIK Certificate data.";
}
}
}
container tudaV1TSACert {
description
"TBD";
leaf tudaV1TSACertCycles {
type yang:counter32;
config false;
description
"Count of TSA Certificate chain update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
/* XXX table comments here XXX */
list tudaV1TSACertEntry {
key "tudaV1TSACertCycleIndex tudaV1TSACertInstanceIndex
tudaV1TSACertFragmentIndex";
config false;
description
"An entry for one fragment of TSA Certificate data.";
leaf tudaV1TSACertCycleIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"High-order index of this TSA Certificate fragment.
Index of a TSA Certificate chain update cycle that has
occurred (bounded by the value of tudaV1TSACertCycles).
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1TSACertInstanceIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Middle index of this TSA Certificate fragment.
Ordinal of this TSA Certificate in this chain, where the TSA
Certificate itself has an ordinal of '1' and higher ordinals
go *up* the certificate chain to the Root CA.
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1TSACertFragmentIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Low-order index of this TSA Certificate fragment.
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1TSACertData {
type binary {
length "0..1024";
}
config false;
description
"A fragment of CBOR encoded TSA Certificate data.";
}
}
}
container tudaV1SyncToken {
description
"TBD";
leaf tudaV1SyncTokenCycles {
type yang:counter32;
config false;
description
"Count of Sync Token update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
leaf tudaV1SyncTokenInstances {
type yang:counter32;
config false;
description
"Count of Sync Token instance entries that have
been recorded (some entries MAY have been pruned).
DEFVAL intentionally omitted - counter object.";
}
list tudaV1SyncTokenEntry {
key "tudaV1SyncTokenCycleIndex
tudaV1SyncTokenInstanceIndex
tudaV1SyncTokenFragmentIndex";
config false;
description
"An entry for one fragment of Sync Token data.";
leaf tudaV1SyncTokenCycleIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"High-order index of this Sync Token fragment.
Index of a Sync Token update cycle that has
occurred (bounded by the value of tudaV1SyncTokenCycles).
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1SyncTokenInstanceIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Middle index of this Sync Token fragment.
Ordinal of this instance of Sync Token data
(NOT bounded by the value of tudaV1SyncTokenInstances).
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1SyncTokenFragmentIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Low-order index of this Sync Token fragment.
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1SyncTokenData {
type binary {
length "0..1024";
}
config false;
description
"A fragment of CBOR encoded Sync Token data.";
}
}
}
container tudaV1Restrict {
description
"TBD";
leaf tudaV1RestrictCycles {
type yang:counter32;
config false;
description
"Count of Restriction Info update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
/* XXX table comments here XXX */
list tudaV1RestrictEntry {
key "tudaV1RestrictCycleIndex";
config false;
description
"An entry for one instance of Restriction Info data.";
leaf tudaV1RestrictCycleIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Index of this Restriction Info entry.
Index of a Restriction Info update cycle that has
occurred (bounded by the value of tudaV1RestrictCycles).
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1RestrictData {
type binary {
length "0..1024";
}
config false;
description
"An instance of CBOR encoded Restriction Info data.";
}
}
}
container tudaV1Measure {
description
"TBD";
leaf tudaV1MeasureCycles {
type yang:counter32;
config false;
description
"Count of Measurement Log update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
leaf tudaV1MeasureInstances {
type yang:counter32;
config false;
description
"Count of Measurement Log instance entries that have
been recorded (some entries MAY have been pruned).
DEFVAL intentionally omitted - counter object.";
}
list tudaV1MeasureEntry {
key "tudaV1MeasureCycleIndex tudaV1MeasureInstanceIndex";
config false;
description
"An entry for one instance of Measurement Log data.";
leaf tudaV1MeasureCycleIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"High-order index of this Measurement Log entry.
Index of a Measurement Log update cycle that has
occurred (bounded by the value of tudaV1MeasureCycles).
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1MeasureInstanceIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Low-order index of this Measurement Log entry.
Ordinal of this instance of Measurement Log data
(NOT bounded by the value of tudaV1MeasureInstances).
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1MeasureData {
type binary {
length "0..1024";
}
config false;
description
"A instance of CBOR encoded Measurement Log data.";
}
}
}
container tudaV1VerifyToken {
description
"TBD";
leaf tudaV1VerifyTokenCycles {
type yang:counter32;
config false;
description
"Count of Verify Token update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
/* XXX table comments here XXX */
list tudaV1VerifyTokenEntry {
key "tudaV1VerifyTokenCycleIndex";
config false;
description
"An entry for one instance of Verify Token data.";
leaf tudaV1VerifyTokenCycleIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Index of this instance of Verify Token data.
Index of a Verify Token update cycle that has
occurred (bounded by the value of tudaV1VerifyTokenCycles).
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1VerifyTokenData {
type binary {
length "0..1024";
}
config false;
description
"A instanc-V1-ATTESTATION-MIB.yang
}
}
}
container tudaV1SWIDTag {
description
"see CoSWID and YANG SIWD module for now"
leaf tudaV1SWIDTagCycles {
type yang:counter32;
config false;
description
"Count of SWID Tag update cycles that have occurred.
DEFVAL intentionally omitted - counter object.";
}
list tudaV1SWIDTagEntry {
key "tudaV1SWIDTagCycleIndex tudaV1SWIDTagInstanceIndex
tudaV1SWIDTagFragmentIndex";
config false;
description
"An entry for one fragment of SWID Tag data.";
leaf tudaV1SWIDTagCycleIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"High-order index of this SWID Tag fragment.
Index of an SWID Tag update cycle that has
occurred (bounded by the value of tudaV1SWIDTagCycles).
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1SWIDTagInstanceIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Middle index of this SWID Tag fragment.
Ordinal of this SWID Tag instance in this update cycle.
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1SWIDTagFragmentIndex {
type int32 {
range "1..2147483647";
}
config false;
description
"Low-order index of this SWID Tag fragment.
DEFVAL intentionally omitted - index object.";
}
leaf tudaV1SWIDTagData {
type binary {
length "0..1024";
}
config false;
description
"A fragment of CBOR encoded SWID Tag data.";
}
}
}
notification tudaV1TrapV2Cycles {
description
"This trap is sent when the value of any cycle or instance
counter changes (i.e., one or more tables are updated).
Note: The value of sysUpTime in IETF MIB-II (RFC 1213) is
always included in SNMPv2 traps, per RFC 3416.";
container tudaV1TrapV2Cycles-tudaV1GeneralCycles {
description
"TPD"
leaf tudaV1GeneralCycles {
type yang:counter32;
description
"Count of TUDA update cycles that have occurred, i.e.,
sum of all the individual group cycle counters.
DEFVAL intentionally omitted - counter object.";
}
}
container tudaV1TrapV2Cycles-tudaV1AIKCertCycles {
description
"TPD"
leaf tudaV1AIKCertCycles {
type yang:counter32;
description
"Count of AIK Certificate chain update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
}
container tudaV1TrapV2Cycles-tudaV1TSACertCycles {
description
"TPD"
leaf tudaV1TSACertCycles {
type yang:counter32;
description
"Count of TSA Certificate chain update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
}
container tudaV1TrapV2Cycles-tudaV1SyncTokenCycles {
description
"TPD"
leaf tudaV1SyncTokenCycles {
type yang:counter32;
description
"Count of Sync Token update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
}
container tudaV1TrapV2Cycles-tudaV1SyncTokenInstances {
description
"TPD"
leaf tudaV1SyncTokenInstances {
type yang:counter32;
description
"Count of Sync Token instance entries that have
been recorded (some entries MAY have been pruned).
DEFVAL intentionally omitted - counter object.";
}
}
container tudaV1TrapV2Cycles-tudaV1RestrictCycles {
description
"TPD"
leaf tudaV1RestrictCycles {
type yang:counter32;
description
"Count of Restriction Info update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
}
container tudaV1TrapV2Cycles-tudaV1MeasureCycles {
description
"TPD"
leaf tudaV1MeasureCycles {
type yang:counter32;
description
"Count of Measurement Log update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
}
container tudaV1TrapV2Cycles-tudaV1MeasureInstances {
description
"TPD"
leaf tudaV1MeasureInstances {
type yang:counter32;
description
"Count of Measurement Log instance entries that have
been recorded (some entries MAY have been pruned).
DEFVAL intentionally omitted - counter object.";
}
}
container tudaV1TrapV2Cycles-tudaV1VerifyTokenCycles {
description
"TPD"
leaf tudaV1VerifyTokenCycles {
type yang:counter32;
description
"Count of Verify Token update cycles that have
occurred.
DEFVAL intentionally omitted - counter object.";
}
}
container tudaV1TrapV2Cycles-tudaV1SWIDTagCycles {
description
"TPD"
leaf tudaV1SWIDTagCycles {
type yang:counter32;
description
"Count of SWID Tag update cycles that have occurred.
DEFVAL intentionally omitted - counter object.";
}
}
}
}
<CODE ENDS>
The following TPM structures, resources and functions are used within this approach. They are based upon the TPM specifications [TPM12] and [TPM2].
On every boot, the TPM initializes a new Tick-Session. Such a tick-session consists of a nonce that is randomly created upon each boot to identify the current boot-cycle – the phase between boot-time of the device and shutdown or power-off – and prevent replaying of old tick-session values. The TPM uses its internal entropy source that guarantees virtually no collisions of the nonce values between two of such boot cycles.
It further includes an internal timer that is being initialize to Zero on each reboot. From this point on, the TPM increments this timer continuously based upon its internal secure clocking information until the device is powered down or set to sleep. By its hardware design, the TPM will detect attacks on any of those properties.
The TPM offers the function TPM_TickStampBlob, which allows the TPM to create a signature over the current tick-session and two externally provided input values. These input values are designed to serve as a nonce and as payload data to be included in a TickStampBlob: TickstampBlob := sig(TPM-key, currentTicks || nonce || externalData).
As a result, one is able to proof that at a certain point in time (relative to the tick-session) after the provisioning of a certain nonce, some certain externalData was known and provided to the TPM. If an approach however requires no input values or only one input value (such as the use in this document) the input values can be set to well-known value. The convention used within TCG specifications and within this document is to use twenty bytes of zero h’0000000000000000000000000000000000000000’ as well-known value.
The TPM is a secure cryptoprocessor that provides the ability to store measurements and metrics about an endpoint’s configuration and state in a secure, tamper-proof environment. Each of these security relevant metrics can be stored in a volatile Platform Configuration Register (PCR) inside the TPM. These measurements can be conducted at any point in time, ranging from an initial BIOS boot-up sequence to measurements taken after hundreds of hours of uptime.
The initial measurement is triggered by the Platforms so-called pre-BIOS or ROM-code. It will conduct a measurement of the first loadable pieces of code; i.e.\ the BIOS. The BIOS will in turn measure its Option ROMs and the BootLoader, which measures the OS-Kernel, which in turn measures its applications. This describes a so-called measurement chain. This typically gets recorded in a so-called measurement log, such that the values of the PCRs can be reconstructed from the individual measurements for validation.
Via its PCRs, a TPM provides a Root of Trust that can, for example, support secure boot or remote attestation. The attestation of an endpoint’s identity or security posture is based on the content of an TPM’s PCRs (platform integrity measurements).
Every key inside the TPM can be restricted in such a way that it can only be used if a certain set of PCRs are in a predetermined state. For key creation the desired state for PCRs are defined via the PCRInfo field inside the keyInfo parameter. Whenever an operation using this key is performed, the TPM first checks whether the PCRs are in the correct state. Otherwise the operation is denied by the TPM.
The TPM offers a command to certify the properties of a key by means of a signature using another key. This includes especially the keyInfo which in turn includes the PCRInfo information used during key creation. This way, a third party can be assured about the fact that a key is only usable if the PCRs are in a certain state.
Attestations are based upon a cryptographic signature performed by the TPM using a so-called Attestation Identity Key (AIK). An AIK has the properties that it cannot be exported from a TPM and is used for attestations. Trust in the AIK is established by an X.509 Certificate emitted by a Certificate Authority. The AIK certificate is either provided directly or via a so-called PrivacyCA [AIK-Enrollment].
This element consists of the AIK certificate that includes the AIK’s public key used during verification as well as the certificate chain up to the Root CA for validation of the AIK certificate itself.
TUDA-Cert = [AIK-Cert, TSA-Cert]; maybe split into two for SNMP AIK-Cert = Cert TSA-Cert = Cert
Figure 2: TUDA-Cert element in CDDL
The TSA-Cert is a standard certificate of the TSA.
The AIK-Cert may be provisioned in a secure environment using standard means or it may follow the PrivacyCA protocols. Figure 3 gives a rough sketch of this protocol. See [AIK-Enrollment] for more information.
The X.509 Certificate is built from the AIK public key and the corresponding PKCS #7 certificate chain, as shown in Figure 3.
Required TPM functions:
| create_AIK_Cert(...) = {
| AIK = TPM_MakeIdentity()
| IdReq = CollateIdentityRequest(AIK,EK)
| IdRes = Call(AIK-CA, IdReq)
| AIK-Cert = TPM_ActivateIdentity(AIK, IdRes)
| }
|
| /* Alternative */
|
| create_AIK_Cert(...) = {
| AIK = TPM_CreateWrapKey(Identity)
| AIK-Cert = Call(AIK-CA, AIK.pubkey)
| }
Figure 3: Creating the TUDA-Cert element
The reference for Attestations are the Tick-Sessions of the TPM. In order to put Attestations into relation with a Real Time Clock (RTC), it is necessary to provide a cryptographic synchronization between the tick session and the RTC. To do so, a synchronization protocol is run with a Time Stamp Authority (TSA) that consists of three steps:
The first TickStampBlob is called “left” and the second “right” in a reference to their position on a time-axis.
These three elements, with the TSA’s certificate factored out, form the synchronization token
TUDA-Synctoken = [
left: TickStampBlob-Output,
timestamp: TimeStampToken,
right: TickStampBlob-Output,
]
TimeStampToken = bytes ; RFC 3161
TickStampBlob-Output = [
currentTicks: TPM-CURRENT-TICKS,
sig: bytes,
]
TPM-CURRENT-TICKS = [
currentTicks: uint
? (
tickRate: uint
tickNonce: TPM-NONCE
)
]
; Note that TickStampBlob-Output "right" can omit the values for
; tickRate and tickNonce since they are the same as in "left"
TPM-NONCE = bytes .size 20
Figure 4: TUDA-Sync element in CDDL
Required TPM functions:
| dummyDigest = h'0000000000000000000000000000000000000000'
| dummyNonce = dummyDigest
|
| create_sync_token(AIKHandle, TSA) = {
| ts_left = TPM_TickStampBlob(
| keyHandle = AIK_Handle, /*TPM_KEY_HANDLE*/
| antiReplay = dummyNonce, /*TPM_NONCE*/
| digestToStamp = dummyDigest /*TPM_DIGEST*/)
|
| ts = TSA_Timestamp(TSA, nonce = hash(ts_left))
|
| ts_right = TPM_TickStampBlob(
| keyHandle = AIK_Handle, /*TPM_KEY_HANDLE*/
| antiReplay = dummyNonce, /*TPM_NONCE*/
| digestToStamp = hash(ts)) /*TPM_DIGEST*/
|
| TUDA-SyncToken = [[ts_left.ticks, ts_left.sig], ts,
| [ts_right.ticks.currentTicks, ts_right.sig]]
| /* Note: skip the nonce and tickRate field for ts_right.ticks */
| }
Figure 5: Creating the Sync-Token element
The attestation relies on the capability of the TPM to operate on restricted keys. Whenever the PCR values for the machine to be attested change, a new restricted key is created that can only be operated as long as the PCRs remain in their current state.
In order to prove to the Verifier that this restricted temporary key actually has these properties and also to provide the PCR value that it is restricted, the TPM command TPM_CertifyInfo is used. It creates a signed certificate using the AIK about the newly created restricted key.
This token is formed from the list of:
TUDA-RestrictionInfo = [Composite,
restrictedKey_Pub: Pubkey,
CertifyInfo]
PCRSelection = bytes .size (2..4) ; used as bit string
Composite = [
bitmask: PCRSelection,
values: [*PCR-Hash],
]
Pubkey = bytes ; may be extended to COSE pubkeys
CertifyInfo = [
TPM-CERTIFY-INFO,
sig: bytes,
]
TPM-CERTIFY-INFO = [
; we don't encode TPM-STRUCT-VER:
; these are 4 bytes always equal to h'01010000'
keyUsage: uint, ; 4byte? 2byte?
keyFlags: bytes .size 4, ; 4byte
authDataUsage: uint, ; 1byte (enum)
algorithmParms: TPM-KEY-PARMS,
pubkeyDigest: Hash,
; we don't encode TPM-NONCE data, which is 20 bytes, all zero
parentPCRStatus: bool,
; no need to encode pcrinfosize
pcrinfo: TPM-PCR-INFO, ; we have exactly one
]
TPM-PCR-INFO = [
pcrSelection: PCRSelection; /* TPM_PCR_SELECTION */
digestAtRelease: PCR-Hash; /* TPM_COMPOSITE_HASH */
digestAtCreation: PCR-Hash; /* TPM_COMPOSITE_HASH */
]
TPM-KEY-PARMS = [
; algorithmID: uint, ; <= 4 bytes -- not encoded, constant for TPM1.2
encScheme: uint, ; <= 2 bytes
sigScheme: uint, ; <= 2 bytes
parms: TPM-RSA-KEY-PARMS,
]
TPM-RSA-KEY-PARMS = [
; "size of the RSA key in bits":
keyLength: uint
; "number of prime factors used by this RSA key":
numPrimes: uint
; "This SHALL be the size of the exponent":
exponentSize: null / uint / biguint
; "If the key is using the default exponent then the exponentSize
; MUST be 0" -> we represent this case as null
]
Figure 6: TUDA-Key element in CDDL
Required TPM functions:
| dummyDigest = h'0000000000000000000000000000000000000000'
| dummyNonce = dummyDigest
|
| create_Composite
|
| create_restrictedKey_Pub(pcrsel) = {
| PCRInfo = {pcrSelection = pcrsel,
| digestAtRelease = hash(currentValues(pcrSelection))
| digestAtCreation = dummyDigest}
| / * PCRInfo is a TPM_PCR_INFO and thus also a TPM_KEY */
|
| wk = TPM_CreateWrapKey(keyInfo = PCRInfo)
| wk.keyInfo.pubKey
| }
|
| create_TPM-Certify-Info = {
| CertifyInfo = TPM_CertifyKey(
| certHandle = AIK, /* TPM_KEY_HANDLE */
| keyHandle = wk, /* TPM_KEY_HANDLE */
| antiReply = dummyNonce) /* TPM_NONCE */
|
| CertifyInfo.strip()
| /* Remove those values that are not needed */
| }
Figure 7: Creating the pubkey
Similarly to regular attestations, the Verifier needs a way to reconstruct the PCRs’ values in order to estimate the trustworthiness of the device. As such, a list of those elements that were extended into the PCRs is reported. Note though that for certain environments, this step may be optional if a list of valid PCR configurations exists and no measurement log is required.
TUDA-Measurement-Log = [*PCR-Event] PCR-Event = [ type: PCR-Event-Type, pcr: uint, template-hash: PCR-Hash, filedata-hash: tagged-hash, pathname: text; called filename-hint in ima (non-ng) ] PCR-Event-Type = &( bios: 0 ima: 1 ima-ng: 2 ) ; might want to make use of COSE registry here ; however, that might never define a value for sha1 tagged-hash /= [sha1: 0, bytes .size 20] tagged-hash /= [sha256: 1, bytes .size 32]
The actual attestation is then based upon a TickStampBlob using the restricted temporary key that was certified in the steps above. The TPM-Tickstamp is executed and thereby provides evidence that at this point in time (with respect to the TPM internal tick-session) a certain configuration existed (namely the PCR values associated with the restricted key). Together with the synchronization token this tick-related timing can then be related to the real-time clock.
This element consists only of the TPM_TickStampBlock with no nonce.
TUDA-Verifytoken = TickStampBlob-Output
Figure 8: TUDA-Verify element in CDDL
Required TPM functions:
| imp_att = TPM_TickStampBlob( | keyHandle = restrictedKey_Handle, /*TPM_KEY_HANDLE*/ | antiReplay = dummyNonce, /*TPM_NONCE*/ | digestToStamp = dummyDigest) /*TPM_DIGEST*/ | | VerifyToken = imp_att
Figure 9: Creating the Verify Token
The seven TUDA information elements transport the essential content that is required to enable verification of the attestation statement at the Verifier. The following listings illustrate the verification algorithm to be used at the Verifier in pseudocode. The pseudocode provided covers the entire verification task. If only a subset of TUDA elements changed (see Section 4.1), only the corresponding code listings need to be re-executed.
| TSA_pub = verifyCert(TSA-CA, Cert.TSA-Cert) | AIK_pub = verifyCert(AIK-CA, Cert.AIK-Cert)
Figure 10: Verification of Certificates
| ts_left = Synctoken.left | ts_right = Synctoken.right | | /* Reconstruct ts_right's omitted values; Alternatively assert == */ | ts_right.currentTicks.tickRate = ts_left.currentTicks.tickRate | ts_right.currentTicks.tickNonce = ts_left.currentTicks.tickNonce | | ticks_left = ts_left.currentTicks | ticks_right = ts_right.currentTicks | | /* Verify Signatures */ | verifySig(AIK_pub, dummyNonce || dummyDigest || ticks_left) | verifySig(TSA_pub, hash(ts_left) || timestamp.time) | verifySig(AIK_pub, dummyNonce || hash(timestamp) || ticks_right) | | delta_left = timestamp.time - | ticks_left.currentTicks * ticks_left.tickRate / 1000 | | delta_right = timestamp.time - | ticks_right.currentTicks * ticks_right.tickRate / 1000
Figure 11: Verification of Synchronization Token
| compositeHash = hash_init() | for value in Composite.values: | hash_update(compositeHash, value) | compositeHash = hash_finish(compositeHash) | | certInfo = reconstruct_static(TPM-CERTIFY-INFO) | | assert(Composite.bitmask == ExpectedPCRBitmask) | assert(certInfo.pcrinfo.PCRSelection == Composite.bitmask) | assert(certInfo.pcrinfo.digestAtRelease == compositeHash) | assert(certInfo.pubkeyDigest == hash(restrictedKey_Pub)) | | verifySig(AIK_pub, dummyNonce || certInfo)
Figure 12: Verification of Restriction Info
| for event in Measurement-Log: | if event.pcr not in ExpectedPCRBitmask: | continue | if event.type == BIOS: | assert_whitelist-bios(event.pcr, event.template-hash) | if event.type == ima: | assert(event.pcr == 10) | assert_whitelist(event.pathname, event.filedata-hash) | assert(event.template-hash == | hash(event.pathname || event.filedata-hash)) | if event.type == ima-ng: | assert(event.pcr == 10) | assert_whitelist-ng(event.pathname, event.filedata-hash) | assert(event.template-hash == | hash(event.pathname || event.filedata-hash)) | | virtPCR[event.pcr] = hash_extend(virtPCR[event.pcr], | event.template-hash) | | for pcr in ExpectedPCRBitmask: | assert(virtPCR[pcr] == Composite.values[i++]
Figure 13: Verification of Measurement Log
| ts = Verifytoken | | /* Reconstruct ts's omitted values; Alternatively assert == */ | ts.currentTicks.tickRate = ts_left.currentTicks.tickRate | ts.currentTicks.tickNonce = ts_left.currentTicks.tickNonce | | verifySig(restrictedKey_pub, dummyNonce || dummyDigest || ts) | | ticks = ts.currentTicks | | time_left = delta_right + ticks.currentTicks * ticks.tickRate / 1000 | time_right = delta_left + ticks.currentTicks * ticks.tickRate / 1000 | | [time_left, time_right]
Figure 14: Verification of Attestation Token
The pseudo code below includes general operations that are conducted as specific TPM commands:
These represent the output structure of that command in the form of a byte string value.
Attestations are based upon a cryptographic signature performed by the TPM using a so-called Attestation Identity Key (AIK). An AIK has the properties that it cannot be exported from a TPM and is used for attestations. Trust in the AIK is established by an X.509 Certificate emitted by a Certificate Authority. The AIK certificate is either provided directly or via a so-called PrivacyCA [AIK-Enrollment].
This element consists of the AIK certificate that includes the AIK’s public key used during verification as well as the certificate chain up to the Root CA for validation of the AIK certificate itself.
TUDA-Cert = [AIK-Cert, TSA-Cert]; maybe split into two for SNMP AIK-Certificate = X.509-Certificate(AIK-Key,Restricted-Flag) TSA-Certificate = X.509-Certificate(TSA-Key, TSA-Flag)
Figure 15: TUDA-Cert element for TPM 2.0
The synchronization token uses a different TPM command, TPM2 GetTime() instead of TPM TickStampBlob(). The TPM2 GetTime() command contains the clock and time information of the TPM. The clock information is the equivalent of TUDA v1’s tickSession information.
TUDA-SyncToken = [
left_GetTime = sig(AIK-Key,
TimeInfo = [
time,
resetCount,
restartCount
]
),
middle_TimeStamp = sig(TSA-Key,
hash(left_TickStampBlob),
UTC-localtime
),
right_TickStampBlob = sig(AIK-Key,
hash(middle_TimeStamp),
TimeInfo = [
time,
resetCount,
restartCount
]
)
]
Figure 16: TUDA-Sync element for TPM 2.0
The creation procedure is identical to Appendix D.2.4.
Measurement-Log = [
* [ EventName,
PCR-Num,
Event-Hash ]
]
Figure 17: TUDA-Log element for TPM 2.0
The TUDA attestation token consists of the result of TPM2_Quote() or a set of TPM2_PCR_READ followed by a TPM2_GetSessionAuditDigest. It proves that — at a certain point-in-time with respect to the TPM’s internal clock — a certain configuration of PCRs was present, as denoted in the keys restriction information.
TUDA-AttestationToken = TUDA-AttestationToken_quote / TUDA-AttestationToken_audit
TUDA-AttestationToken_quote = sig(AIK-Key,
TimeInfo = [
time,
resetCount,
restartCount
],
PCR-Selection = [ * PCR],
PCR-Digest := PCRDigest
)
TUDA-AttestationToken_audit = sig(AIK-key,
TimeInfo = [
time,
resetCount,
restartCount
],
Session-Digest := PCRDigest
)
Figure 18: TUDA-Attest element for TPM 2.0
In order to proof to the Verifier that the TPM’s clock was not ‘fast-forwarded’ the result of a TPM2_GetTime() is sent after the TUDA-AttestationToken.
TUDA-SyncProof = sig(AIK-Key,
TimeInfo = [
time,
resetCount,
restartCount
]
),
Figure 19: TUDA-Proof element for TPM 2.0