Network Working Group A. Fuchs
Internet-Draft H. Birkholz
Intended status: Informational Fraunhofer SIT
Expires: July 13, 2017 I. McDonald
High North Inc
C. Bormann
Universitaet Bremen TZI
January 09, 2017
Time-Based Uni-Directional Attestation
draft-birkholz-tuda-03
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 July 13, 2017.
Copyright Notice
Copyright (c) 2017 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 July 13, 2017 [Page 1]
Internet-Draft tuda January 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Remote Attestation . . . . . . . . . . . . . . . . . . . 3
1.2. Attestation and Verification . . . . . . . . . . . . . . 4
1.3. Information Elements and Conveyance . . . . . . . . . . . 4
1.4. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 5
1.5. Hardware Dependencies . . . . . . . . . . . . . . . . . . 5
1.6. Requirements Notation . . . . . . . . . . . . . . . . . . 6
2. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. General Types . . . . . . . . . . . . . . . . . . . . 8
2.1.3. TPM-Specific Terms . . . . . . . . . . . . . . . . . 8
2.1.4. Certificates . . . . . . . . . . . . . . . . . . . . 8
3. Time-Based Uni-Directional Attestation . . . . . . . . . . . 8
3.1. TUDA Information Elements Update Cycles . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 16
Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 16
B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 17
B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 17
B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 18
B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 18
B.2. Relationship to Host Resources MIB . . . . . . . . . . . 18
B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 18
B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 19
B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 19
Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 34
Appendix D. Realization with TPM 1.2 functions . . . . . . . . . 35
D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 35
D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 35
D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 35
D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 36
D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 36
D.2. Protocol and Procedure . . . . . . . . . . . . . . . . . 36
D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 36
D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 37
D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 39
Fuchs, et al. Expires July 13, 2017 [Page 2]
Internet-Draft tuda January 2017
D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 41
D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 42
D.2.6. Attestation Verification Approach . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction
Remote attestation describes the attempt to determine and appraise
the 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 assessment 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 the measurements.
1.1. Remote Attestation
In essence, remote attestation is composed of three activities. The
following definitions are derived from the definitions presented in
[PRINCIPLES] and [GLOSSARY].
Attestation: The creation of a claim about the properties of an
attestee, such that the claim can be used as evidence.
Conveyance: The transfer of evidence from the attestee to the
verifier.
Verification: The appraisal of evidence by evaluating it against
declarative guidance.
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
[PTS], where one entity sends a challenge that is included inside the
response to ensure the recentness -- the freshness -- 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 protocol -- TUDA --
described in this document can decouple the three activities remote
attestation is composed of. As a result, TUDA provides additional
capabilities, such as:
Fuchs, et al. Expires July 13, 2017 [Page 3]
Internet-Draft tuda January 2017
o remote attestation for attestees that might not always be able to
reach the Internet by enabling the authentication of past states,
o secure audit logs by combining the evidence created via TUDA with
measurement logs that represent a detailed record of corresponding
past states,
o an uni-directional interaction model that can traverse "diode-
like" network security functions or can be leveraged in RESTfull
architectures (e.g. CoAP [RFC7252]), analogously.
1.2. Attestation and Verification
The attestation activity of TUDA requires a Trusted Platform Module
(TPM [TPM12]), a specific Hardware Security Module (HSM) providing,
e.g., Platform Configuration Registers (PCR), restricted signing
keys, and a source of (relative) time (i.e. a tick-counter).
Both the attestation and the verification activity of TUDA require a
trusted Time Stamp Authority (TSA) [RFC3161] as an additional third
party next to the attestee and the verifier. The combination of the
local source of time provided by the TPM (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 also requires declarative guidance
(representing desired or compliant endpoint configuration and state)
evidence conveyed by the attestee can be evaluated against. The
acquisition or representation of declarative guidance as well as the
corresponding evaluation methods are out of the scope of this
document.
1.3. Information Elements and Conveyance
TUDA defines a set of information elements (IE) that are created or
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 [RFC7049]) 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 CBOR Data Definition Language, CDDL
[I-D.greevenbosch-appsawg-cbor-cddl].
Fuchs, et al. Expires July 13, 2017 [Page 4]
Internet-Draft tuda January 2017
Each TUDA IE 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 TPM. 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).
Each TUDA IE 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 transferred.
Each TUDA IE that 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 TPM.
1.4. TUDA Objectives
The Time-Based Uni-directional Attestation is designed to:
o increase the confidence in authentication and authorization
procedures,
o address the requirements of constrained-node networks,
o support interaction models that do not maintain connection-state
over time, such as REST architectures [REST],
o be able to leverage existing management interfaces, such as SNMP
[RFC3411]. RESTCONF [I-D.ietf-netconf-restconf] or CoMI
[I-D.vanderstok-core-comi] -- and corresponding bindings.
o support broadcast and multicast schemes (e.g. IEEE802.11p)
o be able to cope with temporary loss of connectivity, and to
o provide trustworthy audit logs of past endpoint states.
1.5. Hardware Dependencies
The binding of the attestation scheme used by TUDA to generate the
TUDA IE is specific to the methods provided by the HSM used. As a
reference, this document includes pseudo-code that illustrates the
production of TUDA IE 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 serve as guidance to
enable a better understanding of the attestation scheme and is
Fuchs, et al. Expires July 13, 2017 [Page 5]
Internet-Draft tuda January 2017
intended to encourages the use of any appropriate HSM or equivalent
set of Trust-Zone functions.
1.6. 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].
2. TUDA Core Concept
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. [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.
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:
Fuchs, et al. Expires July 13, 2017 [Page 6]
Internet-Draft tuda January 2017
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 guidance on how to utilize a REST architecture.
Appendix B contains guidance on how to create an SNMP binding and a
corresponding TUDA-MIB.
Appendix C contains a corrresponding YANG module that supports both
RESTCONF and CoMI.
Appendix D 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.
2.1. 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.
2.1.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.
TSA: a Time Stamp Authority [RFC3161]
Fuchs, et al. Expires July 13, 2017 [Page 7]
Internet-Draft tuda January 2017
2.1.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
2.1.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
2.1.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].
3. 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 July 13, 2017 [Page 8]
Internet-Draft tuda January 2017
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 July 13, 2017 [Page 9]
Internet-Draft tuda January 2017
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.
3.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 July 13, 2017 [Page 10]
Internet-Draft tuda January 2017
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
| |
|