Network Working Group A. Fuchs Internet-Draft H. Birkholz Intended status: Informational Fraunhofer SIT Expires: April 21, 2016 I. McDonald High North Inc C. Bormann Universitaet Bremen TZI October 19, 2015 Time-Based Uni-Directional Attestation draft-birkholz-tuda-00 Abstract This memo documents the method and bindings used to conduct time- based unidirectional 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 April 21, 2016. Copyright Notice Copyright (c) 2015 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 April 21, 2016 [Page 1] Internet-Draft tuda October 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Time-Based Uni-Directional Attestation . . . . . . . . . . . 4 2.1. Attestation Element Update Cycles . . . . . . . . . . . . 6 3. Realisation Approaches . . . . . . . . . . . . . . . . . . . 8 3.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. REST . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Informative References . . . . . . . . . . . . . . . . . . . 12 Appendix A. Realization with TPM 1.2 functions . . . . . . . . . 14 A.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 14 A.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 14 A.1.2. Platform Configuration Registers (PCRs) . . . . . . . 15 A.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 15 A.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 15 A.2. Protocol and Procedure . . . . . . . . . . . . . . . . . 16 A.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 16 A.2.2. Synchronization Token . . . . . . . . . . . . . . . . 17 A.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 19 A.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 21 A.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 22 A.2.6. Attestation Verification Approach . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction 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.1p as well as communication models that do not maintain connection state over time, such as REST [REST] and SNMP [RFC3411]. Fuchs, et al. Expires April 21, 2016 [Page 2] Internet-Draft tuda October 2015 The protocols usually employed - such as the Platform Trust Service (PTS) Protocol [PTS] - for Remote Attestations using the Trusted Platform Module (TPM) as specified by the Trusted Computing Group (TCG) are based upon the TPM_Quote() function. It consists of the sending of a nonce-challenge that is then used within TPM_Quote()'s signature to prove the freshness of the Attestation response. This scheme requires bi-directional communication. This specification describes a new scheme for Remote Attestations based upon a combination of TPM_CertifyInfo() and TPM_TickStampBlob() to implement a time-based attestation scheme. The approach is based upon the work described in [MTAF] and [SFKE2008]. The freshness properties of a challenge-response based protocol define the time- frame between the transmission of the nonce and the reception of the response as the point in time of attestation. Given the time-based attestation scheme, the point in time of attestation lies within the time-frame given by the accuracy of the time-synchronization and the drift of clocks. If the point in time is within the range of the typical round-trip of a challenge response attestation, the freshness property of TUDA is equivalent to that of classic challenge response attestation. Even if the typical round-trip time is exceeded slightly, the TUDA attestation statements provide sufficiently fresh proofs for most scenarios. In contrast to classical attestations, TUDA attestations can serve as proof of integrity in audit logs with point in time guarantees. Also, it can be used via uni-directional and connection-less communication channels. Appendix A contains a realization of TUDA using TPM 1.2 primitives. TODO: TPM 2.0 follows next year. 1.1. Terminology This specification makes use of the terminology defined in [RFC4949]. This specification uses CDDL as defined in [I-D.greevenbosch-appsawg-cbor-cddl]. The specific data structures defined by this specification for use by other specifications are: tuda = [TUDA-Synctoken, TUDA-Verifytoken, TUDA-RestrictionInfo, TUDA-Cert, TUDA-Measurement-Log] Common types used in these are: Cert = bytes ; an X.509 certificate PCR-Hash = Hash Hash = bytes Fuchs, et al. Expires April 21, 2016 [Page 3] Internet-Draft tuda October 2015 The roles used in this document are: Attestee: the endpoint that is the subject of the attestation to another endpoint. Verifier: the endpoint that consumes the attestation of another endpoint. TSA: Time Stamp Authority [RFC3161]. TSA-CA: a Certificate Authority, that provides the certificate for the TSA. AIK-CA: The Attestation Identity Key (AIK) is a special key type used within TPMs for identity-related operations (such as TPM_Certify or TPM_Quote). Such an AIK can be established in many ways, using either a combination of TPM_MakeIdentity and TPM_ActivateIdentity with a so-called PrivacyCA [AIK-Enrollment] or by means of TPM_CreateWrapKey, readout in a secure environment and regular certification by a custom CA similar to IDevIDs or LDevIDs in [IEEE802.1AR]. AIK-CA is a placeholder for any 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. 2. Time-Based Uni-Directional Attestation A Time-Based Uni-Directional Attestation (TUDA) consists of the following four elements in order to gain assurance of the Attestee's platform configuration at a certain point in time. o 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. o 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). o Restriction Info Fuchs, et al. Expires April 21, 2016 [Page 4] Internet-Draft tuda October 2015 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. o 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. o 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. These elements could be sent en bloc, but it is recommended to retrieve them separately to save bandwidth, since each of these elements has different update cycles. Furthermore, in some scenarios it might be feasible not to store all elements on the Attestee end device, but instead they will be retrieved from another location or pre-deployed to the Verifier. It may even be feasible to only store public keys at the Verifier and skip all certificate provisioning completely in order to save bandwidth and computation time for certificate verification. When mapped to TPM1.2 (see Appendix A), one additional item is added to these five: o AIK Certificate ([AIK-Credential], [AIK-Enrollment]; see Appendix A.2.1). Fuchs, et al. Expires April 21, 2016 [Page 5] Internet-Draft tuda October 2015 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 identity property. 2.1. Attestation Element 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 includes 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 PCR registers 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 kind of events that require a renewed attestation: o The Attestee completes a boot-cycle o A relevant PCR changes o Too much time has passed since the last attestation statement Attestee Verifier | | Boot | | | Create Sync-Token | | | Create Restricted Key | Certify Restricted Key | | | | AIK-Cert ---------------------------------------------> | Fuchs, et al. Expires April 21, 2016 [Page 6] Internet-Draft tuda October 2015 | Sync-Token -------------------------------------------> | | Certify-Info -----------------------------------------> | | Measurement Log --------------------------------------> | | Attestation ------------------------------------------> | | Verify Attestation | | |