]>
Time-Based Uni-Directional AttestationFraunhofer Institute for Secure Information TechnologyRheinstrasse 75Darmstadt64295Germanyandreas.fuchs@sit.fraunhofer.deFraunhofer Institute for Secure Information TechnologyRheinstrasse 75Darmstadt64295Germanyhenk.birkholz@sit.fraunhofer.deHigh North IncPO Box 221Grand Marais49839USblueroofmusic@gmail.comUniversitaet Bremen TZIBibliothekstr. 1BremenD-28359Germany+49-421-218-63921cabo@tzi.orgInternet-DraftThis memo documents the method and bindings used to conduct time-based uni-directional attestation between distinguishable endpoints over the network.Remote attestation describes the attempt to determine and appraise properties, such as integrity and trustworthiness, of an endpoint — the attestee — over a network to another endpoint — the verifier — without direct access. Typically, this kind of appraisal is based on integrity measurements of software components right before they are loaded as software instances on the attestee. In general, attestation procedures are utilizing a hardware root of trust (RoT). The TUDA protocol family uses hash values of all started software components that are stored (extended into) a Trust-Anchor (the Rot) implemented as a Hardware Security Module (e.g. a Trusted Platform Module or similar) and are reported via a signature over those measurements.This draft introduces the concept of including the exchange of evidence (created via a hardware root of trust containing an shielded secret that is unknown to the user in order to increase the confidence that a communication peer is a Trusted System . In consequnce, this document introduces the term forward authenticity.
A property of secure communication protocols, in which later compromise of the long-term keys of a data origin does not compromise past authentication of data from that origin. FA is achieved by timely recording of assessments of the authenticity from entities (via “audit logs” during “audit sessions”) that are authorized for this purpose, in a time frame much shorter than that expected for the compromise of the long-term keys.Forward Authenticity enables new level of guarantee and can be included in the basically every protocol, such as ssh, router advertisements , link layer neighbor discover, or even ICMP echo.In essence, remote attestation is composed of three activities. The following definitions are derived from the definitions presented in and .
The creation of one ore more claims about the properties of an attestee, such that the claims can be used as evidence.
The transfer of evidence from the attestee to the verifier via an interconnect.
The appraisal of evidence by evaluating it against declarative guidance.With TUDA, the claims that compose the evidence are signatures over trustworthy integrity measurements created by leveraging a hardware RoT. The evidence is appraised via corresponding signatures over reference integrity measurements (RIM, represented, for example via ).Protocols that facilitate Trust-Anchor based signatures in order to provide
remote attestation are usually bi-directional challenge/response protocols, such as the Platform Trust Service protocol or CAVES , where one entity sends a challenge that is included inside the response to ensure the recentness — the freshness (see fresh in ) — 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 remote attestation is composed of. As a result, TUDA provides additional capabilities, such as:remote attestation for attestees that might not always be able to reach the Internet by enabling the verification of past states,secure audit logs by combining the evidence created via TUDA with integrity measurement logs that represent a detailed record of corresponding past states,an uni-directional interaction model that can traverse “diode-like” network security functions (NSF) or can be leveraged in RESTful architectures (e.g. CoAP ), analogously.TUDA is a family of protocols that packages results from specific attestation and verification activities. The attestation activities of TUDA are based on a hardware root of trust that provides the following capabilities:platform Configuration Registers (PCR) that store measurements consecutively and represent the chain of measurements as a single measurement value,restricted signing keys that are can only be accessed if a specific signature about measurements can be provided as authentication, anda source of relative time (for example, a tick counter).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 attestee and the verifier.
The protocol uses a Time Stamp Authority based on . The combination of the local source of time provided by the hardware RoT (located on the attestee) and the Time Stamp Tokens provided by the TSA (to both the attestee and the verifier) enable the attestation and verification of an appropriate freshness of the evidence conveyed by the attestee — without requiring a challenge/response interaction model that uses a nonce to ensure the freshness.The verification activity can also use declarative guidance (representing desired or compliant endpoint characteristics in the form of RIM) to appraise the individual integrity measurements the conveyed evidence is based on. The acquisition or representation 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 attestee and are intended to be transferred to the verifier in order to enable appraisal. Each TUDA IE:is encoded in the Concise Binary Object Representation (CBOR ) to minimize the volume of data in motion. In this document, the composition of the CBOR data items that represent IE is described using the Concise Data Definition Language, CDDL that requires a certain freshness is only created/updated when out-dated, which reduces the overall resources required from the attestee, including the utilization of the hardware root of trust. The IE that have to be created are determined by their age or by specific state changes on the attestee (e.g. state changes due to a reboot-cycle)is only transferred when required, which reduces the amount of data in motion necessary to conduct remote attestation significantly. Only IE that have changed since their last conveyance have to be transferredthat requires a certain freshness can be reused for multiple remote attestation procedures in the limits of its corresponding freshness-window, further reducing the load imposed on the attestee and its corresponding hardware RoT.The Time-Based Uni-directional Attestation family of protocols is designed to:increase the confidence in authentication and authorization procedures,address the requirements of constrained-node networks,support interaction models that do not maintain connection-state over time, such as REST architectures ,be able to leverage existing management interfaces, such as SNMP . RESTCONF or CoMI — and corresponding bindings,support broadcast and multicast schemes (e.g. ),be able to cope with temporary loss of connectivity, and toprovide trustworthy audit logs of past endpoint states.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. As a reference, this document includes pseudo-code that illustrates the production of TUDA IE using a TPM 1.2 and TPM 2.0 as well as the corresponding TPM commands specified in and as an example. 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 encourages the use of any appropriate hardware RoT or equivalent set of functions stored in a Trusted Execution Environment .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 RFC
2119, BCP 14 .There are significant differences between conventional bi-directional attestation and TUDA regarding both the information elements conveyed between attestee 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. .In contrast, the TUDA protocol would use a combination output of TPM_CertifyInfo and
TPM_TickStampBlob. The former provides a proof about the platform’s state by attesting that a certain key is bound to said 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. This approach is based on the concepts introduced in and .The payload of information elements transmitted is based on different methods, because the time-frame, in which an attestation is considered to be fresh (and therefore trustworthy), is defined differently.The freshness properties of a challenge-response based protocol define the point-of-time of attestation between:the time of transmission of the nonce, andthe reception of the responseGiven 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 transmission of a TUDA time-synchronization token, andthe typical round-trip time between the verifier and the attestee,The accuracy of this time-frame is defined by two factors:the time-synchronization between the attestee and the TSA. The time between the two tickstamps acquired via the hardware RoT define the scope of the maximum drift (“left” and “right” in respect to the timeline) to the TSA timestamp, andthe drift of clocks included in the hardware RoT.Since TUDA attestations do 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 attestations can even serve as proof of integrity in audit logs with precise point-in-time guarantees, in contrast to classical attestations. contains guidance on how to utilize a REST architecture. contains guidance on how to create an SNMP binding and a corresponding TUDA-MIB. contains a corresponding YANG module that supports both RESTCONF and CoMI. contains a realization of TUDA using TPM 1.2 primitives. 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 special purpose signature (therefore asymmetric) key that supports identity related operations. The private portion of the key pair is maintained confidential to the entity via appropriate measures (that have an impact on the scope of confidence). The public portion of the key pair may be included in AIK credentials that provide a claim about the entity.
A piece of information asserted about a subject . A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value In the context of SACM, a claim is also specialized as an attribute/value pair that is intended to be related to a statement .
the creation of evidence on the attestee that provides proof of a set of the endpoints’s integrity measurements. This is done by digitally signing a set of PCRs using an AIK shielded by the hardware RoT.
the context, composition, configuration, state, and behavior of an endpoint.
a trustworthy set of claims about an endpoint’s characteristics.
a set of claims that is intended to be related to an entity.
Metrics of endpoint characteristics (i.e. composition, configuration and state) that
affect the confidence in the trustworthiness of an endpoint. Digests of integrity measurements
can be stored in shielded locations (i.e. PCR of a TPM).
Signed measurements about the characteristics of an endpoint’s characteristics that are provided by a vendor and are intended to be used as declarative guidance (e.g. a signed CoSWID).
the qualities of an endpoint that guarantee a specific behavior and/or endpoint characteristics defined by declarative guidance.
Analogously, trustworthiness is the quality of being trustworthy with respect to declarative guidance.
Trustworthiness is not an absolute property but defined with respect to an entity, corresponding declarative guidance, and has a scope of confidence.Trustworthy Endpoint: an endpoint that guarantees trustworthy behavior and/or composition (with respect to certain declarative guidance and a scope of confidence).Trustworthy Statement: evidence that is trustworthy conveyed by an endpoint that is not necessarily trustworthy.
the endpoint that is the subject of the attestation to another endpoint.
the endpoint that consumes the attestation of another endpoint to conduct a verification.
a Time Stamp Authority
the now customary synonym for octet
an X.509 certificate represented as a byte-string
a Platform Configuration Register that is part of a hardware root of trust and is used to securely store and report measurements about security posture
a hash value of the security posture measurements stored in a TPM PCR (e.g. regarding running software instances) represented as a byte-string
the Certificate Authority that provides the certificate for the TSA represented as a Cert
the Certificate Authority that provides the certificate for the attestation identity key of the TPM. This is the client platform credential for this protocol. It is a placeholder for a specific CA and AIK-Cert is a placeholder for the corresponding certificate, depending on what protocol was used. The specific protocols are out of scope for this document, see also and .A Time-Based Uni-Directional Attestation (TUDA) consists of the
following seven information elements. They are used to gain assurance of the Attestee’s
platform configuration at a certain point in time:
The certificate of the Time Stamp Authority that is used in a subsequent synchronization
protocol token. This certificate is signed by the TSA-CA.
A certificate about the Attestation Identity Key (AIK) used. This may or may not
also be an IDevID or LDevID, depending on their setting of the corresponding identity property.
(, ; see .)
The reference for attestations are the relative timestanps provided by the hardware RoT. In
order to put attestations into relation with a Real Time Clock
(RTC), it is necessary to provide a cryptographic synchronization
between these trusted relative timestamps and the regular RTC that is a hardware component of the attestee. To do so, a synchronization
protocol is run with a Time Stamp Authority (TSA).
The attestation relies on the capability of the hardware RoT 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 corresponding
signing capabilities of the hardware RoT are used. It creates a signed certificate using the AIK about
the newly created restricted key.
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
(in the form of RIM available to the verifier) exists and no measurement log is required.
The actual attestation is then based upon a signed timestamp provided by the hardware RoT using the restricted
temporary key that was certified in the steps above. The signed timestamp provides evidence that at this point in time (with respect to the relative time of the hardware RoT)
a certain configuration existed (namely the PCR values associated
with the restricted key). Together with the synchronization token this timestamp represented in relative time
can then be related to the real-time clock.
As an option to better assess the trustworthiness of an Attestee, a Verifier can request the
reference hashes (RIM, which are often referred to as golden measurements) of all started software components
to compare them with the entries in the measurement log. References hashes regarding installed
(and therefore running) software can be provided by the manufacturer via SWID tags. SWID tags are
provided by the attestee using the Concise SWID representation and bundled into a CBOR array (a RIM Manifest).
Ideally, the reference hashes include a signature created by the manufacturer of the software to prove their integrity.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 Attestee 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:persistent, even after a hard reboot. This includes certificates
that are associated with the endpoint itself or with services it relies on.volatile to a degree, because they change at the beginning of each boot cycle.
This includes the capability of a hardware RoT to provide relative time which provides the basis for the
synchronization token and implicit attestation—and which can reset after an endpoint is powered off.very volatile, because they change during an uptime cycle
(the period of time an endpoint is powered on, starting with its boot).
This includes the content of PCRs of a hardware RoT and thereby also the PCR-restricted signing
keys used for attestation.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 Attestee and the Verifier.There are three kinds of events that require a renewed attestation:The Attestee completes a boot-cycleA relevant PCR changesToo much time has passed since the last attestation statementThe 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. |
| Sync-Token -------------------------------------------> |
| Certify-Info -----------------------------------------> |
| Measurement Log --------------------------------------> |
| Attestation ------------------------------------------> |
| Verify Attestation
| |
| |
| |
| Attestation ------------------------------------------> |
| Verify Attestation
| |
| |
| |
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
| |
| |
| |
| Attestation ------------------------------------------> |
| Verify Attestation
| |
]]>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:At a given point in time (called “left”), a signed tickstamp counter value is acquired from the hardware RoT. The hash of counter and signature is used as a nonce in the request directed at the TSA.The corresponding response includes a data-structure incorporating the trusted timestamp token and its signature created by the TSA.At the point-in-time the response arrives (called “right”), a signed tickstamp counter value is acquired from the hardware RoT again, using a hash of the signed TSA timestamp as a nonce.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 TBDThis memo includes requests to IANA, including registrations for media
type definitions.TBDThere are Security Considerations. TBDChanges 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 sectionsChanges from version 03 to version 04:Refactoring of Introduction, intend, scope and audienceAdded first draft of Sync Base Prootoll section illustrated background for interaction with TSAAdded YANG moduleAdded missing changelog entryChanges from version 02 to version 03:Moved base concept out of IntroductionFirst refactoring of Introduction and ConceptFirst restructuring of Appendices and improved referencesChanges from version 01 to version 02:Restructuring of Introduction, highlighting conceptual prerequisitesRestructuring of Concept to better illustrate differences to hand-shake based attestation and deciding factors regarding freshness propertiesSubsection structure added to TerminologyClarification of descriptions of approach (these were the FIXMEs)Correction of RestrictionInfo structure: Added missing signature memberChanges 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.TBDKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Internet Security Glossary, Version 2This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.Host Resources MIBThis memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. [STANDARDS-TRACK]Entity MIB (Version 4)This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.Management Information Base for Network Management of TCP/IP-based internets: MIB-IIThis memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]Concise Binary Object Representation (CBOR)The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.Internet Standard 62Concise data definition language (CDDL): a notational convention to express CBOR data structuresThis document proposes a notational convention to express CBOR data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR.Security Automation and Continuous Monitoring (SACM) TerminologyThis memo documents terminology used in the documents produced by SACM (Security Automation and Continuous Monitoring).CoAP Management InterfaceThis document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CoMI). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CoMI uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CoMI extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks.Concise Software IdentifiersThis document defines a concise representation of ISO 19770-2:2015 Software Identifiers (SWID tags) that is interoperable with the XML schema definition of ISO 19770-2:2015 and augmented for application in Constrained-Node Networks. Next to the inherent capability of SWID tags to express arbitrary context information, CoSWID support the definition of additional semantics via well-defined data definitions incorporated by extension points.Improving Scalability for Remote AttestationPrinciples of Remote AttestationImproving the scalability of platform attestationInformation technology -- Trusted Platform Module -- Part 1: OverviewTrusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.16 ed.,
Trusted Computing GroupTEE System Architecture v1.1, GPD_SPE_009Global PlatformTCG Attestation PTS Protocol Binding to TNC IF-MTCG TNC Working GroupTCG GlossaryTCGA CMC Profile for AIK Certificate EnrollmentTCG Infrastructure Working GroupTCG Credential ProfileTCG Infrastructure Working GroupArchitectural Styles and the Design of Network-based Software ArchitecturesUniversity of California, IrvineInternet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK]An Architecture for Describing Simple Network Management Protocol (SNMP) Management FrameworksThis document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]URI Design and OwnershipSection 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards.JSON Web Token (JWT)JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.Hypertext Transfer Protocol Version 2 (HTTP/2)This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.Constrained RESTful Environments (CoRE) Link FormatThis specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).802.1AR-2009 - IEEE Standard for Local and metropolitan area networks - Secure Device IdentityIEEE Computer Society1609.4-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Multi-Channel OperationIEEE Computer SocietyEach of the seven data items is defined as a media type ().
Representations of resources for each of these media types can be
retrieved from URIs that are defined by the respective servers .
As can be derived from the URI, the actual retrieval is via one of the HTTPs
(, ) or CoAP . How a client obtains
these URIs is dependent on the application; e.g., CoRE Web links
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 .SNMPv3 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
definition.Design Principles:Over time, TUDA attestation values age and should no longer be used. Every
table in the TUDA MIB has a primary index with the value of a separate
scalar cycle counter object that disambiguates the transition from one
attestation cycle to the next.Over time, the measurement log information (for example) may grow
large. Therefore, read-only cycle counter scalar objects in all TUDA MIB object
groups facilitate more efficient access with SNMP GetNext requests.Notifications are supported by an SNMP trap definition with all of the cycle
counters as bindings, to alert a Verifier that a new attestation cycle has
occurred (e.g., synchronization data, measurement log, etc. have been updated
by adding new rows and possibly deleting old rows).The following table summarizes the object groups, tables and their indexes, and conformance requirements for the TUDA MIB:A tudaV1<Group>CycleIndex is the:first index of a row (element instance or element fragment) in the
tudaV1<Group>Table;identifier of an update cycle on the table, when rows were added and/or
deleted from the table (bounded by tudaV1<Group>Cycles); andbinding in the tudaV1TrapV2Cycles notification for directed polling.A tudaV1<Group>InstanceIndex is the:second index of a row (element instance or element fragment) in the
tudaV1<Group>Table; except fora row in the tudaV1SyncTokenTable (that has only one instance per cycle).A tudaV1<Group>FragmentIndex is the:last index of a row (always an element fragment) in the
tudaV1<Group>Table; andaccomodation for SNMP transport mapping restrictions for large string
elements that require fragmentation.The General group in the TUDA MIB is analogous to the System group in the
Host Resources MIB 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 ) in the TUDA MIB is analogous to the Software Installed and
Software Running groups in the Host Resources MIB .The General group in the TUDA MIB is analogous to the Entity General group in
the Entity MIB v4 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 .The General group in the TUDA MIB is analogous to the System group in MIB-II
and the System group in the SNMPv2 MIB and provides
context information for the TUDA attestation process.
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 "201710300000Z" -- 30 October 2017
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 (2017)."
REVISION "201710300000Z" -- 30 October 2017
DESCRIPTION
"Fifth version, published as draft-birkholz-tuda-05."
REVISION "201701090000Z" -- 09 January 2017
DESCRIPTION
"Fourth version, published as draft-birkholz-tuda-04."
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
]]>
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 instance of CBOR encoded Verify Token data.";
}
}
}
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.";
}
}
}
}
]]>The following TPM structures, resources and functions are used within this approach.
They are based upon the TPM specifications and .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 .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.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. gives a rough sketch
of this protocol. See for more information.The X.509 Certificate is built from the AIK public key and the
corresponding PKCS #7 certificate chain, as shown in
.Required TPM functions: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 TPM creates a TickStampBlob using the AIKThis TickstampBlob is used as nonce to the Timestamp of the TSAAnother TickStampBlob with the AIK is created using the TSA’s Timestamp a nonceThe 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 tokenRequired TPM functions: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:PCR list,the newly created restricted public key, andthe certificate. we represent this case as null
]
]]>Required TPM functions: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.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.Required TPM functions: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 ), only
the corresponding code listings need to be re-executed.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.The restriction
to certain PCR values is defined as a policy state-
ment containing a TPM2 PolicyPCR element referencing the
according PCR selection and values. The digest of this policy
statement is registered in the public area of the key during key
creation. In order to provide proof of this PCR restriction, the
command TPM2 Certify() is used. The restriction information
accordingly consists of the PolicyPCR-information, KeyPublic-
information and the certificate of this key.The creation procedure is identical to {mlog}.The attestation token consists of
the result of TPM2 GetTime(). It proofs 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.