| Internet-Draft | Network Device RIV | November 2021 |
| Fedorkow, et al. | Expires 22 May 2022 | [Page] |
This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by the Trusted Computing Group (TCG).¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 May 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
There are many aspects to consider in fielding a trusted computing device, from operating systems to applications. Mechanisms to prove that a device installed at a customer's site is authentic (i.e., not counterfeit) and has been configured with authorized software, all as part of a trusted supply chain, are just a few of the many aspects which need to be considered concurrently to have confidence that a device is truly trustworthy.¶
A generic architecture for remote attestation has been defined in [I-D.ietf-rats-architecture]. Additionally, the use cases for remotely attesting networking devices are discussed within Section 6 of [I-D.richardson-rats-usecases]. However, these documents do not provide sufficient guidance for network equipment vendors and operators to design, build, and deploy interoperable devices.¶
The intent of this document is to provide such guidance. It does this by outlining the Remote Integrity Verification (RIV) problem, and then identifies elements that are necessary to get the complete, scalable attestation procedure working with commercial networking products such as routers, switches and firewalls. An underlying assumption will be the availability within the device of a Trusted Platform Module [TPM1.2], [TPM2.0] compliant cryptoprocessor to enable the trustworthy remote assessment of the device's software and hardware.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
A number of terms are reused from [I-D.ietf-rats-architecture]. These include: Appraisal Policy for Evidence, Attestation Result, Attester, Evidence, Reference Value, Relying Party, Verifier, and Verifier Owner.¶
Additionally, this document defines the following term:¶
Attestation: the process of generating, conveying and appraising claims, backed by evidence, about device trustworthiness characteristics, including supply chain trust, identity, device provenance, software configuration, device composition, compliance to test suites, functional and assurance evaluations, etc.¶
The goal of attestation is simply to assure an administrator or auditor that the device configuration and software that was launched when the device was last started is authentic and untampered-with. The determination of software authenticity is not prescribed in this document, but it's typically taken to mean a software image generated by an authority trusted by the administrator, such as the device manufacturer.¶
Within the Trusted Computing Group (TCG) context, the scope of attestation is typically narrowed to describe the process by which an independent Verifier can obtain cryptographic proof as to the identity of the device in question, and evidence of the integrity of software loaded on that device when it started up, and then verify that what's there matches the intended configuration. For network equipment, a Verifier capability can be embedded in a Network Management Station (NMS), a posture collection server, or other network analytics tool (such as a software asset management solution, or a threat detection and mitigation tool, etc.). While informally referred to as attestation, this document focuses on a specific subset of attestation tasks, defined here as Remote Integrity Verification (RIV). RIV takes a network equipment centric perspective that includes a set of protocols and procedures for determining whether a particular device was launched with authentic software, starting from Roots of Trust. While there are many ways to accomplish attestation, RIV sets out a specific set of protocols and tools that work in environments commonly found in network equipment. RIV does not cover other device characteristics that could be attested (e.g., geographic location, connectivity; see [I-D.richardson-rats-usecases]), although it does provide evidence of a secure infrastructure to increase the level of trust in other device characteristics attested by other means (e.g., by Entity Attestation Tokens [I-D.ietf-rats-eat]).¶
In line with [I-D.ietf-rats-architecture] definitions, this document uses the term Endorser to refer to the role that signs identity and attestation certificates used by the Attester, while Reference Values are signed by a Reference Value Provider. Typically, the manufacturer of an network device would be accepted as both the Endorser and Reference Value Provider, although the choice is ultimately up to the Verifier Owner.¶
The remainder of this document is organized into several sections:¶
Network operators benefit from a trustworthy attestation mechanism that provides assurance that their network comprises authentic equipment, and has loaded software free of known vulnerabilities and unauthorized tampering. In line with the overall goal of assuring integrity, attestation can be used to assist in asset management, vulnerability and compliance assessment, plus configuration management.¶
The RIV attestation workflow outlined in this document is intended to meet the following high-level goals:¶
In addition, RIV is designed to operate either in a centralized environment, such as with a central authority that manages and configures a number of network devices, or 'peer-to-peer', where network devices independently verify one another to establish a trust relationship. (See Section 3.3 below)¶
Attestation requires two interlocking mechanisms between the Attester network device and the Verifier:¶
Using these two interlocking mechanisms, RIV is a component in a chain of procedures that can assure a network operator that the equipment in their network can be reliably identified, and that authentic software of a known version is installed on each device. Equipment in the network includes devices that make up the network itself, such as routers, switches and firewalls.¶
Software used to boot a device can be described as a chain of measurements, anchored at the start by a Root of Trust for Measurement (see Section 9.2), each measuring the next stage and recording the result in tamper-resistant storage, normally ending when the system software is fully loaded. A measurement signifies the identity, integrity and version of each software component registered with an Attester's TPM [TPM1.2], [TPM2.0], so that a subsequent verification stage can determine if the software installed is authentic, up-to-date, and free of tampering.¶
RIV includes several major processes, split between the Attester and Verifier:¶
All implementations supporting this RIV specification require the support of the following three technologies:¶
Remote Integrity Verification must address the "Lying Endpoint" problem, in which malicious software on an endpoint may subvert the intended function, and also prevent the endpoint from reporting its compromised status. (See Section 5 for further Security Considerations.)¶
RIV attestation is designed to be simple to deploy at scale. RIV should work "out of the box" as far as possible, that is, with the fewest possible provisioning steps or configuration databases needed at the end-user's site. Network equipment is often required to "self-configure", to reliably reach out without manual intervention to prove its identity and operating posture, then download its own configuration, a process which precludes pre-installation configuration. See [RFC8572] for an example of Secure Zero Touch Provisioning.¶
The need for assurance of software integrity, addressed by Remote Attestation, is a very general problem that could apply to most network-connected computing devices. However, this document includes several assumptions that limit the scope to network equipment (e.g., routers, switches and firewalls):¶
RIV Attestation is a process which can be used to determine the identity of software running on a specifically-identified device. The Remote Attestation steps of Section 1.5 are broken into two phases, shown in Figure 1:¶
The result is that the Verifier can verify the device's identity by checking the subjectName and signature of the certificate containing the TPM's attestation public key, and can validate the software that was launched by verifying the correctness of the logs by comparing with the signed digests from the TPM, and comparing digests in the log with Reference Values.¶
It should be noted that attestation and identity are inextricably linked; signed Evidence that a particular version of software was loaded is of little value without cryptographic proof of the identity of the Attester producing the Evidence.¶
+-------------------------------------------------------+
| +--------+ +--------+ +--------+ +---------+ |
| | BIOS |--->| Loader |-->| Kernel |--->|Userland | |
| +--------+ +--------+ +--------+ +---------+ |
| | | | |
| | | | |
| +------------+-----------+-+ |
| Boot Phase | |
| V |
| +--------+ |
| | TPM | |
| +--------+ |
| Router | |
+--------------------------------|----------------------+
|
| Verification Phase
| +-----------+
+--->| Verifier |
+-----------+
Reset---------------flow-of-time-during-boot--...------->
In the Boot phase, measurements are "extended", or hashed, into the TPM as processes start, with the result that the TPM ends up containing hashes of all the measured hashes. Later, once the system is operational, during the Verification phase, signed digests are retrieved from the TPM for off-box analysis.¶
TPM attestation is focused on Platform Configuration Registers (PCRs), but those registers are only vehicles for certifying accompanying Evidence, conveyed in log entries. It is the hashes in log entries that are extended into PCRs, where the final PCR values can be retrieved in the form of a structure called a Quote, signed by an Attestation key known only to the TPM. The use of multiple PCRs serves only to provide some independence between different classes of object, so that one class of objects can be updated without changing the extended hash for other classes. Although PCRs can be used for any purpose, this section outlines the objects within the scope of this document which may be extended into the TPM.¶
In general, assignment of measurements to PCRs is a policy choice made by the device manufacturer, selected to independently attest three classes of object:¶
The TCG PC Client Platform Firmware Profile Specification [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be measured during the boot phase of platform startup using a UEFI BIOS (www.uefi.org), but the goal is simply to measure every bit of code executed in the process of starting the device, along with any configuration information related to security posture, leaving no gap for unmeasured code to remain undetected, potentially subverting the chain.¶
For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] and [PC-Client-EFI-TPM-1.2] give detailed normative requirements for PCR usage. For other platform architectures, where TCG normative requirements currently do not exist, the table in Figure 2 gives non-normative guidance for PCR assignment that generalizes the specific details of [PC-Client-BIOS-TPM-2.0].¶
By convention, most PCRs are assigned in pairs, which the even-numbered PCR used to measure executable code, and the odd-numbered PCR used to measure whatever data and configuration are associated with that code. It is important to note that each PCR may contain results from dozens (or even thousands) of individual measurements.¶
+------------------------------------------------------------------+ | | Assigned PCR # | | Function | Code | Configuration| -------------------------------------------------------------------- | Firmware Static Root of Trust, (i.e., | 0 | 1 | | initial boot firmware and drivers) | | | -------------------------------------------------------------------- | Drivers and initialization for optional | 2 | 3 | | or add-in devices | | | -------------------------------------------------------------------- | OS Loader code and configuration, (i.e., | 4 | 5 | | the code launched by firmware) to load an | | | | operating system kernel. These PCRs record | | | | each boot attempt, and an identifier for | | | | where the loader was found | | | -------------------------------------------------------------------- | Vendor Specific Measurements during boot | 6 | 6 | -------------------------------------------------------------------- | Secure Boot Policy. This PCR records keys | | 7 | | and configuration used to validate the OS | | | | loader | | | -------------------------------------------------------------------- | Measurements made by the OS Loader | 8 | 9 | | (e.g GRUB2 for Linux) | | | -------------------------------------------------------------------- | Measurements made by OS (e.g., Linux IMA) | 10 | 10 | +------------------------------------------------------------------+
It is important to recognize that PCR[0] is critical. The first measurement into PCR[0] is taken by the Root of Trust for Measurement, code which, by definition, cannot be verified by measurement. This measurement establishes the chain of trust for all subsequent measurements. If the PCR[0] measurement cannot be trusted, the validity of the entire chain is put into question.¶
Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized below:¶
Although the TCG PC Client document specifies the use of the first eight PCRs very carefully to ensure interoperability among multiple UEFI BIOS vendors, it should be noted that embedded software vendors may have considerably more flexibility. Verifiers typically need to know which log entries are consequential and which are not (possibly controlled by local policies) but the Verifier may not need to know what each log entry means or why it was assigned to a particular PCR. Designers must recognize that some PCRs may cover log entries that a particular Verifier considers critical and other log entries that are not considered important, so differing PCR values may not on their own constitute a check for authenticity. For example, in a UEFI system, some administrators may consider booting an image from a removable drive, something recorded in a PCR, to be a security violation, while others might consider that operation an authorized recovery procedure.¶
Designers may allocate particular events to specific PCRs in order to achieve a particular objective with local attestation, (e.g., allowing a procedure to execute, or releasing a particular decryption key, only if a given PCR is in a given state). It may also be important to designers to consider whether streaming notification of PCR updates is required (see [I-D.birkholz-rats-network-device-subscription]). Specific log entries can only be validated if the Verifier receives every log entry affecting the relevant PCR, so (for example) a designer might want to separate rare, high-value events such as configuration changes, from high-volume, routine measurements such as IMA [IMA] logs.¶
RIV attestation relies on two credentials:¶
In a TPM application, both the Attestation private key and the DevID private key MUST be protected by the TPM. Depending on other TPM configuration procedures, the two keys are likely be different; some of the considerations are outlined in TCG "TPM 2.0 Keys for Device Identity and Attestation" [Platform-DevID-TPM-2.0].¶
The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies further conventions for these keys:¶
RIV workflow for network equipment is organized around a simple use case where a network operator wishes to verify the integrity of software installed in specific, fielded devices. A normative taxonomy of terms is given in [I-D.ietf-rats-architecture], but as a reminder, this use case implies several roles and objects:¶
These components are illustrated in Figure 3.¶
+----------------+ +-------------+ +---------+--------+
|Reference Value | | Attester | Step 1 | Verifier| |
|Provider | | (Device |<-------| (Network| Relying|
|(Device | | under |------->| Mngmt | Party |
|Manufacturer | | attestation)| Step 2 | Station)| |
|or other | | | | | |
|authority) | | | | | |
+----------------+ +-------------+ +---------+--------+
| /\
| Step 0 |
-----------------------------------------------
Use of the following standards components allows for interoperability:¶
This document makes the following simplifying assumptions to reduce complexity:¶
[I-D.ietf-rats-yang-tpm-charra] focuses on collecting and transmitting evidence in the form of PCR measurements and attestation logs. But the critical part of the process is enabling the Verifier to decide whether the measurements are "the right ones" or not.¶
While it must be up to network administrators to decide what they want on their networks, the software supplier should supply the Reference Values, in signed Reference Integrity Manifests, that may be used by a Verifier to determine if evidence shows known good, known bad or unknown software configurations.¶
In general, there are two kinds of reference measurements:¶
In both cases, the expected values can be expressed as signed SWID or CoSWID tags, but the SWID structure in the second case is somewhat more complex, as reconstruction of the extended hash in a PCR may involve thousands of files and other objects.¶
TCG has published an information model defining elements of Reference Integrity Manifests under the title TCG Reference Integrity Manifest Information Model [RIM]. This information model outlines how SWID tags should be structured to allow attestation, and defines "bundles" of SWID tags that may be needed to describe a complete software release. The RIM contains metadata relating to the software release it belongs to, plus hashes for each individual file or other object that could be attested.¶
Many network equipment vendors use a UEFI BIOS to launch their network operating system. These vendors may want to also use the TCG PC Client Reference Integrity Measurement specification [PC-Client-RIM], which focuses specifically on a SWID-compatible format suitable for expressing measurement values expected from a UEFI BIOS.¶
Quotes from a TPM can provide evidence of the state of a device up to the time the evidence was recorded, but to make sense of the quote in most cases an event log that identifies which software modules contributed which values to the quote during startup MUST also be provided. The log MUST contain enough information to demonstrate its integrity by allowing exact reconstruction of the digest conveyed in the signed quote (that is, calculating the hash of all the hashes in the log should produce the same values as contained in the PCRs; if they don't match, the log may have been tampered with. See Section 9.1).¶
There are multiple event log formats which may be supported as viable formats of Evidence between the Attester and Verifier, but to simplify interoperability, RIV focuses on just three:¶
The Reference Interaction Model for Challenge-Response-based Remote Attestation ([I-D.birkholz-rats-reference-interaction-model]) is based on the standard roles defined in [I-D.ietf-rats-architecture]. However additional prerequisites have been established to allow for interoperable RIV use case implementations. These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurements collected by the Attester.¶
A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID certificate [IEEE-802-1AR] MUST be provisioned in the Attester's TPMs.¶
The Attestation Key (AK) and certificate MUST also be provisioned on the Attester according to [Platform-DevID-TPM-2.0], or [Platform-ID-TPM-1.2].¶
It MUST be possible for the Verifier to determine that the Attester's Attestation keys are resident in the same TPM as its DevID keys (see Section 2.2 and Section 5 Security Considerations).¶
As noted in Section 2.3, the Verifier may obtain Reference Values from several sources. In addition, administrators may make authorized, site-specific changes (e.g. keys in key databases) that could impact attestation results. As such, there could be conflicts, omissions or ambiguities between some Reference Values and collected Evidence.¶
The Verifier MUST have an Appraisal Policy for Evidence to evaluate the significance of any discrepancies between different reference sources, or between reference values and evidence from logs and quotes. While there must be an Appraisal Policy, this document does not specify the format or mechanism to convey the intended policy, nor does RIV specify mechanisms by which the results of applying the policy are communicated to the Relying Party.¶
Once the prerequisites for RIV are met, a Verifier is able to acquire Evidence from an Attester. The following diagram illustrates a RIV information flow between a Verifier and an Attester, derived from Section 7.1 of [I-D.birkholz-rats-reference-interaction-model]. In this diagram, each event with its input and output parameters is shown as "Event(input-params)=>(outputs)". Event times shown correspond to the time types described within Appendix A of [I-D.ietf-rats-architecture]:¶
.----------. .-----------------------. | Attester | | Relying Party/Verifier | '----------' '------------------------' time(VG) | generateClaims(attestingEnvironment) | | => claims, eventLogs | | | | time(NS) | <-- requestAttestation(handle, authSecIDs, claimSelection) | | | time(EG) | collectClaims(claims, claimSelection) | | => collectedClaims | | | generateEvidence(handle, authSecIDs, collectedClaims) | | => evidence | | time(RG,RA) | evidence, eventLogs -------------------------------------> | | | | appraiseEvidence(evidence, eventLogs, refValues) | attestationResult <= | | | ~ ~ | time(RX)
Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes action as needed. As the interaction between Relying Party and Verifier is out of scope for RIV, this can be described as one step.¶
Network Management systems MUST retrieve signed PCR based Evidence using [I-D.ietf-rats-yang-tpm-charra] with NETCONF or RESTCONF.¶
Implementations that use NETCONF MUST do so over a TLS or SSH secure tunnel. Implementations that use RESTCONF transport MUST do so over a TLS or SSH secure tunnel.¶
Log Evidence MUST be retrieved via log interfaces specified in [I-D.ietf-rats-yang-tpm-charra].¶
Figure 4 above assumes that the Verifier is trusted, while the Attester is not. In a Peer-to-Peer application such as two routers negotiating a trust relationship, the two peers can each ask the other to prove software integrity. In this application, the information flow is the same, but each side plays a role both as an Attester and a Verifier. Each device issues a challenge, and each device responds to the other's challenge, as shown in Figure 5. Peer-to-peer challenges, particularly if used to establish a trust relationship between routers, require devices to carry their own signed reference measurements (RIMs). Devices may also have to carry Appraisal Policy for Evidence for each possible peer device so that each device has everything needed for remote attestation, without having to resort to a central authority.¶
+---------------+ +---------------+
| RefVal | | RefVal |
| Provider A | | Provider B |
| Firmware | | Firmware |
| Configuration | | Configuration |
| Authority | | Authority |
| | | |
+---------------+ +---------------+
| |
| +------------+ +------------+ |
| | | Step 1 | | | \
| | Attester |<------>| Verifier | | |
| | |<------>| | | | Router B
+------>| | Step 2 | | | |- Challenges
Step 0A| | | | | | Router A
| |------->| | | |
|- Router A -| Step 3 |- Router B -| | /
| | | | |
| | | | |
| | Step 1 | | | \
| Verifier |<------>| Attester |<-+ | Router A
| |<------>| | |- Challenges
| | Step 2 | | | Router B
| | | | |
| |<-------| | |
+------------+ Step 3 +------------+ /
In this application, each device may need to be equipped with signed RIMs to act as an Attester, and also an Appraisal Policy for Evidence and a selection of trusted X.509 root certificates, to allow the device to act as a Verifier. An existing link layer protocol such as 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable methods for such an exchange.¶
Network equipment, such as routers, switches and firewalls, has a key role to play in guarding the privacy of individuals using the network. Network equipment generally adheres to several rules to protect privacy:¶
Packets passing through the device must not be sent to unauthorized destinations. For example:¶
Functions that protect privacy are implemented as part of each layer of hardware and software that makes up the networking device. In light of these requirements for protecting the privacy of users of the network, the network equipment must identify itself, and its boot configuration and measured device state (for example, PCR values), to the equipment's administrator, so there's no uncertainty as to what function each device and configuration is configured to carry out. Attestation is a component that allows the administrator to ensure that the network provides individual and peer privacy guarantees, even though the device itself may not have a right to keep its identity secret.¶
See [NetEq] for more context on privacy in networking devices.¶
While attestation information from network devices is not likely to contain privacy-sensitive content regarding network users, administrators may want to keep attestation records confidential to avoid disclosing versions of software loaded on the device, information which could facilitate attacks against known vulnerabilities.¶
Attestation Evidence from the RIV procedure are subject to a number of attacks:¶
Trustworthiness of RIV attestation depends strongly on the validity of keys used for identity and attestation reports. RIV takes full advantage of TPM capabilities to ensure that evidence can be trusted.¶
Two sets of key-pairs are relevant to RIV attestation:¶
TPM practices usually require that these keys be different, as a way of ensuring that a general-purpose signing key cannot be used to spoof an attestation quote.¶
In each case, the private half of the key is known only to the TPM, and cannot be retrieved externally, even by a trusted party. To ensure that's the case, specification-compliant private/public key-pairs are generated inside the TPM, where they are never exposed, and cannot be extracted (See [Platform-DevID-TPM-2.0]).¶
Keeping keys safe is a critical enabler of trustworthiness, but it's just part of attestation security; knowing which keys are bound to the device in question is just as important in an environment where private keys are never exposed.¶
While there are many ways to manage keys in a TPM (see [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch" provisioning (also known as zero-touch onboarding) of fielded devices (e.g., Secure ZTP, [RFC8572]), where keys which have predictable trust properties are provisioned by the device vendor.¶
Device identity in RIV is based on IEEE 802.1AR Device Identity (DevID). This specification provides several elements:¶
The X.509 certificate contains several components:¶
With these elements, the device's manufacturer and serial number can be identified by analyzing the DevID certificate plus the chain of intermediate certificates leading back to the manufacturer's root certificate. As is conventional in TLS or SSH connections, a random nonce must be signed by the device in response to a challenge, proving possession of its DevID private key.¶
RIV uses the DevID to validate a TLS or SSH connection to the device as the attestation session begins. Security of this process derives from TLS or SSH security, with the DevID providing proof that the session terminates on the intended device. See [RFC8446], [RFC4253].¶
Evidence of software integrity is delivered in the form of a quote signed by the TPM itself. Because the contents of the quote are signed inside the TPM, any external modification (including reformatting to a different data format) after measurements have been taken will be detected as tampering. An unbroken chain of trust is essential to ensuring that blocks of code that are taking measurements have been verified before execution (see Figure 1).¶
Requiring measurements of the operating software to be signed by a key known only to the TPM also removes the need to trust the device's operating software (beyond the first measurement in the RTM; see below); any changes to the quote, generated and signed by the TPM itself, made by malicious device software, or in the path back to the Verifier, will invalidate the signature on the quote.¶
A critical feature of the YANG model described in [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data structures in their native format, without requiring any changes to the structures as they were signed and delivered by the TPM. While alternate methods of conveying TPM quotes could compress out redundant information, or add an additional layer of signing using external keys, the implementation MUST preserve the TPM signing, so that tampering anywhere in the path between the TPM itself and the Verifier can be detected.¶
Prevention of spoofing attacks against attestation systems is also important. There are two cases to consider:¶
Protection against spoofed quotes from a device with valid identity is a bit more complex. An identity key must be available to sign any kind of nonce or hash offered by the Verifier, and consequently, could be used to sign a fabricated quote. To block a spoofed Attestation Result, the quote generated inside the TPM must be signed by a key that's different from the DevID, called an Attestation Key (AK).¶
Given separate Attestation and DevID keys, the binding between the AK and the same device must also be proven to prevent a person-in-the-middle attack (e.g., the 'Asokan Attack' [RFC6813]).¶
This is accomplished in RIV through use of an AK certificate with the same elements as the DevID (same manufacturer's serial number, signed by the same manufacturer's key), but containing the device's unique AK public key instead of the DevID public key.¶
The TCG document TPM 2.0 Keys for Device Identity and Attestation [Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates that allow the CA to mark a key as specifically known to be an Attestation key.¶
These two key-pairs and certificates are used together:¶
Replay attacks, where results of a previous attestation are submitted in response to subsequent requests, are usually prevented by inclusion of a random nonce in the request to the TPM for a quote. Each request from the Verifier includes a new random number (a nonce). The resulting quote signed by the TPM contains the same nonce, allowing the Verifier to determine freshness, (i.e., that the resulting quote was generated in response to the Verifier's specific request). Time-Based Uni-directional Attestation [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify freshness without requiring a request/response cycle.¶
Although device manufacturers MUST pre-provision devices with easily verified DevID and AK certificates if zero-touch provisioning such as described in [RFC8572] is to be supported, use of those credentials is not mandatory. IEEE 802.1AR incorporates the idea of an Initial Device ID (IDevID), provisioned by the manufacturer, and a Local Device ID (LDevID) provisioned by the owner of the device. RIV and [Platform-DevID-TPM-2.0] extends that concept by defining an Initial Attestation Key (IAK) and Local Attestation Key (LAK) with the same properties.¶
Device owners can use any method to provision the Local credentials.¶
Clearly, local keys can't be used for secure Zero Touch provisioning; installation of the local keys can only be done by some process that runs before the device is installed for network operation.¶
On the other end of the device life cycle, provision should be made to wipe local keys when a device is decommissioned, to indicate that the device is no longer owned by the enterprise. The manufacturer's Initial identity keys must be preserved, as they contain no information that's not already printed on the device's serial number plate.¶
In addition to trustworthy provisioning of keys, RIV depends on a number of other factors for trustworthy operation.¶
RIV also depends on reliable Reference Values, as expressed by the RIM [RIM]. The definition of trust procedures for RIMs is out of scope for RIV, and the device owner is free to use any policy to validate a set of reference measurements. RIMs may be conveyed out-of-band or in-band, as part of the attestation process (see Section 3.1.3). But for network devices, where software is usually shipped as a self-contained package, RIMs signed by the manufacturer and delivered in-band may be more convenient for the device owner.¶
The validity of RIV attestation results is also influenced by procedures used to create Reference Values:¶
TCG technologies can play an important part in the implementation of Remote Integrity Verification. Standards for many of the components needed for implementation of RIV already exist:¶
This memo includes no request to IANA.¶
The authors wish to thank numerous reviewers for generous assistance, including William Bellingrath, Mark Baushke, Ned Smith, Henk Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty, Nancy Cam-Winget and Shwetha Bhandari¶
The Trusted Platform Module and surrounding ecosystem provide three interlocking capabilities to enable secure collection of evidence from a remote device, Platform Configuration Registers (PCRs), a Quote mechanism, and a standardized Event Log.¶
Each TPM has at least eight and at most twenty-four PCRs (depending on the profile and vendor choices), each one large enough to hold one hash value (SHA-1, SHA-256, and other hash algorithms can be used, depending on TPM version). PCRs can't be accessed directly from outside the chip, but the TPM interface provides a way to "extend" a new security measurement hash into any PCR, a process by which the existing value in the PCR is hashed with the new security measurement hash, and the result placed back into the same PCR. The result is a composite fingerprint comprising the hash of all the security measurements extended into each PCR since the system was reset.¶
Every time a PCR is extended, an entry should be added to the corresponding Event Log. Logs contain the security measurement hash plus informative fields offering hints as to which event generated the security measurement. The Event Log itself is protected against accidental manipulation, but it is implicitly tamper-evident - any verification process can read the security measurement hash from the log events, compute the composite value and compare that to what ended up in the PCR. If there's no discrepancy, the logs do provide an accurate view of what was placed into the PCR.¶
Note that the composite hash-of-hashes recorded in PCRs is order-dependent, resulting in different PCR values for different ordering of the same set of events (e.g. Event A followed by Event B yields a different PCR value than B followed by A). For single-threaded code, where both the events and their order are fixed, a Verifier may validate a single PCR value, and use the log only to diagnose a mismatch from Reference Values. However, operating system code is usually non-deterministic, meaning that there may never be a single "known good" PCR value. In this case, the Verifier may have to verify that the log is correct, and then analyze each item in the log to determine if it represents an authorized event.¶
In a conventional TPM Attestation environment, the first measurement must be made and extended into the TPM by trusted device code (called the Root of Trust for Measurement, RTM). That first measurement should cover the segment of code that is run immediately after the RTM, which then measures the next code segment before running it, and so on, forming an unbroken chain of trust. See [TCGRoT] for more on Mutable vs Immutable roots of trust.¶
The TPM provides another mechanism called a Quote that can read the current value of the PCRs and package them, along with the Verifier's nonce, into a TPM-specific data structure signed by an Attestation private key, known only to the TPM.¶
As noted above in Section 5 Security Considerations, it's important to note that the Quote data structure is signed inside the TPM. The trust model is preserved by retrieving the Quote in a way that does not invalidate the signature, as specified in [I-D.ietf-rats-yang-tpm-charra]. The structure of the command and response for a quote, including its signature, as generated by the TPM, can be seen in [TPM1.2] Part 3, Section 16.5, and [TPM2.0] Section 18.4.2.¶
The Verifier uses the Quote and Log together. The Quote contains the composite hash of the complete sequence of security measurement hashes, signed by the TPM's private Attestation Key. The Log contains a record of each measurement extended into the TPM's PCRs. By computing the composite hash of all the measurements, the Verifier can verify the integrity of the Event Log, even though the Event Log itself is not signed. Each hash in the validated Event Log can then be compared to corresponding expected values in the set of Reference Values to validate overall system integrity.¶
A summary of information exchanged in obtaining quotes from TPM1.2 and TPM2.0 can be found in [TAP], Section 4. Detailed information about PCRs and Quote data structures can be found in [TPM1.2], [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0], and [Canonical-Event-Log].¶
The measurements needed for attestation require that the device being attested is equipped with a Root of Trust for Measurement, that is, some trustworthy mechanism that can compute the first measurement in the chain of trust required to attest that each stage of system startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to record the results, and a Root of Trust for Reporting to report the results [TCGRoT], [SP800-155], [SP800-193].¶
While there are many complex aspects of a Root of Trust, two aspects that are important in the case of attestation are:¶
The first measurement must be computed by code that is implicitly trusted; if that first measurement can be subverted, none of the remaining measurements can be trusted. (See [SP800-155])¶
It's important to note that the trustworthiness of the RTM code cannot be assured by the TPM or TPM supplier - code or procedures external to the TPM must guarantee the security of the RTM.¶
Retrieval of identity and attestation state uses one protocol stack, while retrieval of Reference Values uses a different set of protocols. Figure 5 shows the components involved.¶
+-----------------------+ +-------------------------+
| | | |
| Attester |<-------------| Verifier |
| (Device) |------------->| (Management Station) |
| | | | |
+-----------------------+ | +-------------------------+
|
-------------------- --------------------
| |
------------------------------- ---------------------------------
|Reference Values | | Attestation |
------------------------------- ---------------------------------
********************************************************************
* IETF Attestation Reference Interaction Diagram *
********************************************************************
....................... .......................
. Reference Integrity . . TAP (PTS2.0) Info .
. Manifest . . Model and Canonical .
. . . Log Format .
....................... .......................
************************* **********************
* YANG SWID Module * * YANG Attestation *
* I-D.ietf-sacm-coswid * * Module *
* * * I-D.ietf-rats- *
* * * yang-tpm-charra *
************************* **********************
************************* ************ ************************
* XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)*
************************* ************ ************************
************************* ************************
* RESTCONF/NETCONF * * RESTCONF/NETCONF *
************************* ************************
************************* ************************
* TLS, SSH * * TLS, SSH *
************************* ************************
IETF documents are captured in boxes surrounded by asterisks. TCG documents are shown in boxes surrounded by dots.¶
Figure 7 summarizes many of the actions needed to complete an Attestation system, with links to relevant documents. While documents are controlled by several standards organizations, the implied actions required for implementation are all the responsibility of the manufacturer of the device, unless otherwise noted.¶
As noted, SWID tags can be generated many ways, but one possible tool is [SWID-Gen]¶
+------------------------------------------------------------------+ | Component | Controlling | | | Specification | -------------------------------------------------------------------- | Make a Secure execution environment | TCG RoT | | o Attestation depends on a secure root of | UEFI.org | | trust for measurement outside the TPM, as | | | well as roots for storage and reporting | | | inside the TPM. | | | o Refer to TCG Root of Trust for Measurement.| | | o NIST SP 800-193 also provides guidelines | | | on Roots of Trust | | -------------------------------------------------------------------- | Provision the TPM as described in |[Platform-DevID-TPM-2.0]| | TCG documents. | TCG Platform | | | Certificate | -------------------------------------------------------------------- | Put a DevID or Platform Cert in the TPM | TCG TPM DevID | | o Install an Initial Attestation Key at the | TCG Platform | | same time so that Attestation can work out | Certificate | | of the box |----------------- | o Equipment suppliers and owners may want to | IEEE 802.1AR | | implement Local Device ID as well as | | | Initial Device ID | | -------------------------------------------------------------------- | Connect the TPM to the TLS stack | Vendor TLS | | o Use the DevID in the TPM to authenticate | stack (This | | TAP connections, identifying the device | action is | | | simply | | | configuring TLS| | | to use the DevID | | | as its client | | | certificate) | -------------------------------------------------------------------- | Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID | | o Add reference measurements into SWID tags | ISO/IEC 19770-2| | o Manufacturer should sign the SWID tags | NIST IR 8060 | | o The TCG RIM-IM identifies further | | | procedures to create signed RIM | | | documents that provide the necessary | | | reference information | | -------------------------------------------------------------------- | Package the SWID tags with a vendor software | Retrieve tags | | release | with | | o A tag-generator plugin such | I-D.ietf-sacm-coswid| | as [SWID-Gen] can be used |----------------| | | TCG PC Client | | | RIM | -------------------------------------------------------------------- | Use PC Client measurement definitions | TCG PC Client | | to define the use of PCRs | BIOS | | (although Windows OS is rare on Networking | | | Equipment, UEFI BIOS is not) | | -------------------------------------------------------------------- | Use TAP to retrieve measurements | | | o Map to YANG | YANG Module for| | Use Canonical Log Format | Basic | | | Attestation | | | TCG Canonical | | | Log Format | -------------------------------------------------------------------- | Posture Collection Server (as described in IETF | | | SACMs ECP) should request the | | | attestation and analyze the result | | | The Management application might be broken down | | | to several more components: | | | o A Posture Manager Server | | | which collects reports and stores them in | | | a database | | | o One or more Analyzers that can look at the| | | results and figure out what it means. | | --------------------------------------------------------------------