Network Working Group A. Fuchs Internet-Draft H. Birkholz Intended status: Informational Fraunhofer SIT Expires: January 9, 2017 I. McDonald High North Inc C. Bormann Universitaet Bremen TZI July 08, 2016 Time-Based Uni-Directional Attestation draft-birkholz-tuda-02 Abstract This memo documents the method and bindings used to conduct time- based uni-directional attestation between distinguishable endpoints over the network. Status of This Memo 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 http://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 January 9, 2017. Copyright Notice Copyright (c) 2016 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 (http://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 Fuchs, et al. Expires January 9, 2017 [Page 1] Internet-Draft tuda July 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.2. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.2. General Types . . . . . . . . . . . . . . . . . . . . 6 1.3.3. TPM-Specific Terms . . . . . . . . . . . . . . . . . 6 1.3.4. Certificates . . . . . . . . . . . . . . . . . . . . 6 2. Time-Based Uni-Directional Attestation . . . . . . . . . . . 6 2.1. TUDA Information Elements Update Cycles . . . . . . . . . 8 3. REST Realization . . . . . . . . . . . . . . . . . . . . . . 10 4. SNMP Realization . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 11 4.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 12 4.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 12 4.2. Relationship to Host Resources MIB . . . . . . . . . . . 12 4.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 12 4.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 13 4.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Realization with TPM 1.2 functions . . . . . . . . . 32 A.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 32 A.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 32 A.1.2. Platform Configuration Registers (PCRs) . . . . . . . 32 A.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 33 A.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 33 A.2. Protocol and Procedure . . . . . . . . . . . . . . . . . 33 A.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 33 A.2.2. Synchronization Token . . . . . . . . . . . . . . . . 34 A.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 36 A.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 38 A.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 39 A.2.6. Attestation Verification Approach . . . . . . . . . . 40 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Fuchs, et al. Expires January 9, 2017 [Page 2] Internet-Draft tuda July 2016 1. Introduction Remote attestation describes the attempt to determine the integrity and trustworthiness of an endpoint -- the attestee -- over a network to another endpoint -- the verifier -- without direct access. One way to do so is based on measurements of software components running on the attestee, where the hash values of all started software components are stored (extended into) a Trust Anchor implemented as a Hardware Security Module (e.g. a Trusted Platform Module or similar) and reported via a signature over these measurements. Protocols that facilitate these Trust Anchor based signatures in order to provide remote attestations are usually bi-directional protocols [PTS], where one entity sends a challenge that is included inside the response to ensure the recentness -- the freshness -- of the attestation information. In many contexts and scenarios it is not feasible to deploy bi- directional protocols, due to constraints in the underlying communication schemes. Furthermore, many communication schemes do not have a notion of connection, which disallows the usage of connection context related state information. These constraints may make it impossible to deploy challenge-response based schemes to achieve freshness of messages in security protocols. Examples of these constrained environments include broadcast and multicast schemes such as automotive IEEE802.11p as well as communication models that do not maintain connection state over time, such as REST [REST] and SNMP [RFC3411]. This document describes the time-based uni-directional attestation protocol -- TUDA -- that requires only uni-directional communication channels between verifier and attestee. whilst still providing up- to-date information about the integrity and thereby trustworthiness of the attested device. There are two important prerequisites next to the Hardware Security Module (HSM) itself: o a source of (relative) time (i.e. a tick counter) integrated in the HSM, and o network access to a trusted time stamp authority (TSA) [RFC3161]. Both prerequisites are mandatory to attest the appropriate freshness of the remotes attestation without bi-directional communication. The attestation scheme of TUDA is based on a set of TUDA information elements that are generated on the attestee and transported to the verifier. TUDA information elements are encoded in the Concise Binary Object Representation, CBOR [RFC7049]. In this document, the composition of the CBOR data items that represent the information Fuchs, et al. Expires January 9, 2017 [Page 3] Internet-Draft tuda July 2016 elements is described using the CBOR Data Definition Language, CDDL [I-D.greevenbosch-appsawg-cbor-cddl]. The binding of the attestation scheme used by TUDA to generate the TUDA information elements is specific to the methods provided by the HSM used. As a reference, this document includes pseudo-code that illustrates the production of TUDA information elements using a TPM 1.2 and the corresponding TPM commands specified in [TPM12] as an example. The references to TPM 1.2 commands and corresponding pseudo-code only serves as guidance to enable a better understanding of the attestation scheme and does not imply the use of a specific HSM (excluding, of course, the requirements highlighted above). 1.1. Requirements Notation 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 [RFC2119]. 1.2. Concept There are significant differences between conventional bi-directional attestation and TUDA regarding both the information elements transmitted 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. [PTS]. 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 [SCALE] and [SFKE2008]. 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. Fuchs, et al. Expires January 9, 2017 [Page 4] Internet-Draft tuda July 2016 The freshness properties of a challenge-response based protocol define the point-of-time of attestation between: o the time of transmission of the nonce, and o the reception of the response 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: o the transmission of a TUDA time-synchronization token, and o the typical round-trip time between the verifier and the attestee, The accuracy of this time-frame is defined by two factors: o the time-synchronization between the attestee and the TSA. The time between the two TPM tickstamps give the maximum drift (left and right) to the TSA timestamp, and o the drift of local TPM clocks 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 TPM. As a consequence TUDA attestations can even serve as proof of integrity in audit logs with point in time guarantees, in contrast to classical attestations. Appendix A contains a realization of TUDA using TPM 1.2 primitives. A realization of TUDA using TPM 2.0 primitives will be added with the next iteration of this document. 1.3. Terminology 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. 1.3.1. Roles Attestee: the endpoint that is the subject of the attestation to another endpoint. Verifier: the endpoint that consumes the attestation of another endpoint. Fuchs, et al. Expires January 9, 2017 [Page 5] Internet-Draft tuda July 2016 TSA: a Time Stamp Authority [RFC3161] 1.3.2. General Types Byte: the now customary synonym for octet Cert: an X.509 certificate represented as a byte-string PCR-Hash: a hash value of the security posture measurements stored in a TPM Platform Configuration Register (e.g. regarding running software instances) represented as a byte-string 1.3.3. TPM-Specific Terms AIK: an Attestation Identity Key, a special key type used within a TPM for identity-related operations (such as TPM_Certify or TPM_Quote) PCR: a Platform Configuration Register that is part of a TPM and is used to securely store and report measurements about security posture 1.3.4. Certificates TSA-CA: the Certificate Authority that provides the certificate for the TSA represented as a Cert AIK-CA: 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 [AIK-Enrollment] and [IEEE802.1AR]. 2. Time-Based Uni-Directional Attestation 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: TSA Certificate: The certificate of the Time Stamp Authority that is used in a subsequent synchronization protocol token. This certificate is signed by the TSA-CA. AIK Certificate (, ; see ): Fuchs, et al. Expires January 9, 2017 [Page 6] Internet-Draft tuda July 2016 A certificate about the Attestation Identity Key (AIK) used. This may or may not also be an [IEEE802.1AR] IDevID or LDevID, depending on their setting of the corresponding identity property. Synchronization Token: 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). Restriction Info: 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. Measurement Log: 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. Implicit Attestation: The actual attestation is then based upon a TPM_TickStampBlob operation using the restricted temporary key that was certified in the steps above. The TPM_TickStampBlob 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. Concise SWID tags: As an option to better assess the trustworthiness of an Attestee, a Verifier can request the reference hashes (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 [I-D-birkholz-sacm-coswid] and bundled into a Fuchs, et al. Expires January 9, 2017 [Page 7] Internet-Draft tuda July 2016 CBOR array. Ideally, the reference hashes include a signature created by the manufacturer of the software. 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 pre-deployed to the Verifier. It is also feasible to only store public keys at the Verifier and skip the whole certificate provisioning completely in order to save bandwidth and computation time for certificate verification. 2.1. TUDA Information Elements Update Cycles 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 TPM can be in, is important to the attestation process. o Some states are persistent, even after reboot. This includes certificates that are associated with the endpoint itself or with services it relies on. o Some states are more volatile and change at the beginning of each boot cycle. This includes the TPM-internal Tick-Session which provides the basis for the synchronization token and implicit attestation. o Some states are even more volatile and 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 TPM and thereby also the PCR-restricted keys used during 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: o The Attestee completes a boot-cycle o A relevant PCR changes Fuchs, et al. Expires January 9, 2017 [Page 8] Internet-Draft tuda July 2016 o Too much time has passed since the last attestation statement The third event listed above is variable per application use case and can therefore be set appropriately. 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 TPM continuously to always present the most freshly created results. To save some utilization of the TPM for other purposes, however, a time-frame of once per ten seconds is recommended, which would leave 80% of utilization for applications. Attestee Verifier | | Boot | | | Create Sync-Token | | | Create Restricted Key | Certify Restricted Key | | | | AIK-Cert ---------------------------------------------> | | Sync-Token -------------------------------------------> | | Certify-Info -----------------------------------------> | | Measurement Log --------------------------------------> | | Attestation ------------------------------------------> | | Verify Attestation | | |