| Internet-Draft | Network Device Remote Integrity Verifica | February 2020 |
| Fedorkow & Fitzgerald-McKay | Expires 1 September 2020 | [Page] |
This document describes a workflow for remote attestation of integrity of network devices.¶
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 4 August 2020.¶
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified 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, is one of those aspects that's easily overlooked.¶
Attestation is defined here as the process of creating, conveying and appraising assertions about Platform trustworthiness characteristics, including supply chain trust, identity, platform provenance, software configuration, hardware configuration, platform composition, compliance to test suites, functional and assurance evaluations, etc.¶
The supply chain itself has many elements, from validating suppliers of electronic components, to ensuring that shipping procedures protect against tampering through many stages of distribution and warehousing. One element that helps maintain the integrity of the supply chain after manufacturing is Attestation, by assuring an administrator that the software that was launched when the device was started is the same as the software that the device vendor initially shipped.¶
Within the Trusted Computing Group context, attestation is the process by which an independent Verifier can obtain cryptographic proof as to the identity of the device in question, evidence of the integrity of software loaded on that device when it started up, and then verify that what's there is what's supposed to be there. For networking 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 subset 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 untampered 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 Networking Equipment. RIV does not cover other platform characteristics that could be attested, although it does provide evidence of a secure infrastructure to increase the level of trust in other platform characteristics attested by other means.¶
This profile outlines the RIV problem, and then identifies elements that are necessary to get the complete attestation procedure working in a scalable solution using commercial products.¶
This document focuses primarily on software integrity verification using the Trusted Platform Module (TPM) to ensure a trustworthy result.¶
The integrity of attestation information must be protected by means of cryptographic techniques, to assure its validity. It's important to note that TCG technologies are available to use either symmetric key encryption with shared keys, or public key cryptography using private/public key pairs. The two techniques can each produce secure results, but do require different provisioning mechanisms. The RIV document currently focuses on asymmetric keying approaches only; future work might include techniques for attestation using symmetric keys.¶
This document is non-normative; the document does not define protocols, but rather identifies existing protocols that can be used together to achieve the goals above, and in some cases, highlights gaps in existing protocols.¶
Attestation requires two interlocking services on the device:¶
As a part of a trusted supply chain, the RIV attestation workflow outlined in this document is intended to meet the following high-level goals:¶
RIV is a procedure that assures a network operator that the equipment on their network can be reliably identified, and that untampered software of a known version is installed on each endpoint. In this context, endpoint might include the conventional connected devices like servers and laptops, but also connected devices that make up the network equipment itself, such as routers, switches and firewalls.¶
RIV can be viewed as a link in a trusted supply chain that ensures that devices launch software without unauthorized modification, and includes three major processes:¶
Clearly the second part of the problem, attesting the state of mutable components of a given device, is of little value without reliable identification of the device in question. By the same token, unambiguous identity of a device is necessary, but is insufficient to assure the operator of the provenance of the device through the supply chain, or that the device is configured to behave properly.¶
An implementation of RIV requires three technologies¶
Service Providers 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.¶
The RIV attestation solution must meet a number of requirements to make it simple to deploy at scale.¶
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):¶
Remote Integrity Verification can go a long way to solving the "Lying Endpoint" problem, in which malicious software on an endpoint may both subvert the intended function, and also prevent the endpoint from reporting its compromised status. Man-in-the Middle attacks are also made more difficult through a strong focus on device identity¶
Attestation data can be used for asset management, vulnerability and compliance assessment, plus configuration management.¶
There have been demonstrations of attestation using TPMs for years, accompanied by compelling security reasons for adopting attestation. Despite this, the technology has not been widely adopted, in part, due to the difficulties in deploying TPM-based attestation. Some of those difficulties are:¶
None of these issues are insurmountable, but together, they've made deployment of attestation a major challenge. The intent of this document is to outline an attestation profile that's simple enough to deploy, while yielding enough security to be useful.¶
Even in embedded systems, adding Attestation at the OS level (e.g. Linux IMA, Integrity Measurement Architecture [IMA]) increases the number of objects to be attested by one or two orders of magnitude, involves software that's updated and changed frequently, and introduces processes that begin in unpredictable order.¶
TCG and others (including the Linux community) are working on methods and procedures for attesting the operating system and application software, but standardization is still in process.¶
RIV Attestation is a process for determining the identity of software running on a specifically-identified device. Remote Attestation is broken into two phases, shown in Figure 1:¶
The result is that the Verifier can verify the device's identity by checking the certificate containing the TPM's attestation public key, and can validate the software that was launched by comparing digests in the log with known-good values, and verifying their correctness by comparing with the signed digests from the TPM.¶
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 device producing the evidence.¶
+-------------------------------------------------------+
| +--------+ +--------+ +--------+ +---------+ |
| | BIOS |--->| Loader |-->| Kernel |--->|Userland | |
| +--------+ +--------+ +--------+ +---------+ |
| | | | |
| | | | |
| +------------+-----------+-+ |
| Step 1 | |
| V |
| +--------+ |
| | TPM | |
| +--------+ |
| Router | |
+--------------------------------|----------------------+
|
| Step 2
| +-----------+
+--->| Verifier |
+-----------+
Reset---------------flow-of-time-during-boot--...------->
In Step 1, measurements are "extended" into the TPM as processes start. In Step 2, signed PCR digests are retrieved from the TPM for off-box analysis after the system is operational.¶
TPM attestation is strongly focused around Platform Configuration Registers (PCRs), but those registers are only vehicles for certifying attestation evidence. The evidence itself is conveyed in log files (xref) which give the name and hash of each object to be attested. These hashes are also extended into PCRs, where they can be retrieved in the form of a quote signed by a key known only to the TPM (xref). 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 that are conventionally attested with a TPM.¶
In general, PCRs are organized 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 a platform boot using a UEFI BOIS (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. Table XX summarizes the functions that are measured, and how they are allocated to PCRs. It's important to note that each PCR may contain results from dozens (or even thousands) of individual measurements.¶
+------------------------------------------------------------------+ | | Allocated PCR # | | Function | Code | Configuration| -------------------------------------------------------------------- | BIOS Static Root of Trust, plus embedded | 0 | 1 | | Option ROMs and drivers | | | -------------------------------------------------------------------- | Pluggable Option ROMs to initialize and | 2 | 3 | | configure add-in devices | | | -------------------------------------------------------------------- | Boot Manager code and configuration (UEFI | 4 | 5 | | uses a separate module to implement | | | | policies for selecting among a variety of | | | | potential boot devices). This PCR records | | | | boot attempts, and identifies what | | | | resources were used to boot the OS. | | | -------------------------------------------------------------------- | Vendor Specific Measurements | 6 | 6 | -------------------------------------------------------------------- | Secure Boot Policy. This PCR records keys | | 7 | | and configuration used to validate the OS | | | | loader | | | -------------------------------------------------------------------- | OS Loader (e.g GRUB2 for Linux) | 8 | 9 | -------------------------------------------------------------------- | Reserved for OS (e.g. Linux IMA) | 10 | 10 | +------------------------------------------------------------------+
TPM 1.2 and TPM 2.0 have a variety of rules separating the functions of identity and attestation, allowing for use-cases where software configuration must be attested, but privacy must be maintained.¶
To accommodate these rules, enforced inside the TPM, in an environment where device privacy is not normally a requirement, the TCG Guidance for Securing Network Equipment [NetEq] suggests using separate keys for Identity (i.e., DevID) and Attestation (i.e., signing a quote of the contents of the PCRs), but provisioning an Initial Attestation Key (IAK) and x.509 certificate that parallels the IDevID, with the same device ID information as the IDevID certificate (i.e., the same Subject Name and Subject Alt Name, even though the key pairs are different). This allows a quote from the device, signed by the IAK, to be linked directly to the device that provided it, by examining the corresponding IAK certificate.¶
Inclusion of an IAK by a vendor does not preclude a mechanism whereby an Administrator can define Local Attestation Keys (LAKs) if desired.¶
RIV workflow for networking equipment is organized around a simple use-case, where a network operator wishes to verify the integrity of software installed in specific, fielded devices. This use-case implies several components:¶
These components are illustrated in Figure 2.¶
A more-detailed taxonomy of terms is given in [I-D.birkholz-rats-architecture]¶
+---------------+ +-------------+ +---------+--------+
| | | Attester | Step 1 | Verifier| |
| Asserter | | (Device |<-------| (Network| Relying|
| (Device | | under |------->| Mngmt | Party |
| Manufacturer | | attestation)| Step 2 | Station)| |
| or other | | | | | |
| authority) | | | | | |
+---------------+ +-------------+ +---------+--------+
| /\
| Step 0 |
-----------------------------------------------
In Step 0, The Asserter (the device manufacturer) provides a Software Image accompanied by one or more Reference Integrity Manifests (RIMs) to the Attester (the device under attestation) signed by the asserter. In Step 1, the Verifier (Network Management Station), on behalf of a Relying Party, requests Identity, Measurement Values (and possibly RIMs) from the Attester. In Step 2, the Attester responds to the request by providing a DevID, quotes (measured values), and optionally RIMs, signed by the Attester.¶
See [I-D.birkholz-rats-reference-interaction-model] for more narrowly defined terms related to Attestation¶
This document makes the following simplifying assumptions to reduce complexity:¶
Some situations may have privacy-sensitive requirements that preclude shipping every device with an Initial Device ID installed. In these cases, the IDevID can be installed remotely using the TCG Platform Certificate [Platform-Certificates].¶
Some administrators may want to install their own identity credentials to certify device identity and attestation results. IEEE 802.1AR [IEEE-802-1AR] allows for both Initial Device Identity credentials, installed by the manufacturer, (analogous to a physical serial number plate), or Local Device Identity credentials installed by the administrator of the device (analogous to the physical Asset Tag used by many enterprises to identify their property). TCG TPM 2.0 Keys documents [Platform-DevID-TPM-2.0] and [PC-Client-BIOS-TPM-2.0] specifies parallel Initial and Local Attestation Keys (IAK and LAK), and contains figures showing the relationship between IDevID, LDevID, IAK and LAK keys.¶
Device administrators are free to use any number of criteria to judge authenticity of a device before installing local identity keys, as part of an on-boarding process. The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] also outlines procedures for creating Local Attestation Keys and Local Device IDs (LDevIDs) rooted in the manufacturer's IDevID as a check to reduce the chances that counterfeit devices are installed in the network.¶
Note that many networking devices are expected to self-configure (aka Zero Touch Provisioning). Current standardized zero-touch mechanisms such as [RFC8572] assume that identity keys are already in place before network on-boarding can start, and as such, are compatible with IDevID and IAK keys installed by the manufacturer, but not with LDevID and LAK keys, which would have to be installed by the administrator.¶
The Platform Attribute Credential [Platform-Certificates] can also be used to convey additional information about a platform from the manufacturer or other entities in the supply chain. While outside the scope of RIV, the Platform Attribute Credential can deliver information such as lists of serial numbers for components embedded in a device or security assertions related to the platform, signed by the manufacturer, system integrator or value-added-reseller.¶
The measurements needed for attestation require that the device being attested is equipped with a Root of Trust for Measurement, i.e., 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, and a Root of Trust for Reporting to report the results [TCGRoT], [GloPlaRoT].¶
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 [NIST-SP-800-155])¶
Much of attestation 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 Integrity Measurements, (aka Golden Measurements or "known good" digests) 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.¶
The 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 some metadata relating to the software release it belongs to, plus hashes for each individual file or other object that could be attested.¶
TCG has also published the PC Client Reference Integrity Measurement specification [PC-Client-RIM], which focuses on a SWID-compatible format suitable for expressing expected measurement values in the specific case of a UEFI-compatible BIOS, where the SWID focus on files and file systems is not a direct fit. While the PC Client RIM is not directly applicable to network equipment, many vendors do use a conventional UEFI BIOS to launch their network OS.¶
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 of what 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 (e.g., PCR values).¶
TCG has defined several event log formats:¶
It should be noted that a given device might use more than one event log format (e.g., a UEFI log during initial boot, switching to Canonical Log when the host OS launches).¶
The TCG SNMP Attestation MIB [SNMP-Attestation-MIB] will support any record-oriented log format, including the three TCG-defined formats, but it currently leaves figuring out which log(s) are in what format up to the Verifier.¶
Initial work at IETF defines remote attestation as follows:¶
The Reference Interaction Model for Challenge-Response-based Remote Attestation is based on the standard roles defined in [I-D.birkholz-rats-architecture]:¶
The following diagram illustrates a common information flow between a Verifier and an Attester, specified in [I-D.birkholz-rats-reference-interaction-model]:¶
Attester Verifier | | | <------- requestAttestation(nonce, authSecID, claimSelection) | | | collectAssertions(assertionsSelection) | | => assertions | | | signAttestationEvidence(authSecID, assertions, nonce) | | => signedAttestationEvidence | | | | signedAttestationEvidence ----------------------------------> | | | | verifyAttestationEvidence(signedAttestatEvidence, refassertions) | attestationResult <= | | |
The RIV approach outlined in this document aligns with the RATS reference model.¶
The overall flow for an attestation session is shown in Figure 4. In this diagram:¶
These steps yield enough information for the Verifier to verify measurements against reference values. Of course, in all cases, the signatures protecting quotes and RIMs must be checked before the contents are used.¶
+---------------+ +-------------+ +---------+
| | | | Step 1 | |
| | | Attester |<------>| Verifier|
| Asserter | | (Device |<------>| (Network|
|(Configuration |------->| under | Step 2 | Mngmt |
| Authority) | Step 0A| attestation)| | Station)|
| | | |------->| |
+---------------+ +-------------+ Step 3 +---------+
| /|\
| |
----------------------------------------------
Step 0B
Either CoSWID-encoded reference measurements are signed by a trusted authority and retrieved directly prior to attestation (as shown in Step 0A), or CoSWID-encoded reference measurements are signed by the device manufacturer, installed on the device by a proprietary installer, and delivered during attestation (as shown in Step 0B). In Step 1, the Verifier initiates a connection for attestation. The Attester's identity is validated using DevID with TLS. In Step 2, a nonce, quotes (measured values) and measurement log are conveyed via TAP with a protocol-specific binding (e.g. SNMP). Logs are sent in the Canonical Log Format In Step 3, CoSWID-encoded reference measurements are retrieved from the Attester using the YANG ([I-D.birkholz-yang-swid]. .¶
The following components are used:¶
Retrieval of identity and attestation state uses one protocol stack, while retrieval of Reference Measurements uses a different set of protocols. Figure 5 shows the components involved.¶
+-----------------------+ +-------------------------+
| | | |
| Attester |<-------------| Verifier |
| (Device) |------------->| (Management Station) |
| | | | |
+-----------------------+ | +-------------------------+
|
-------------------- --------------------
| |
---------------------------------- ---------------------------------
|Reference Integrity Measurements| | Attestation |
---------------------------------- ---------------------------------
********************************************************************
* IETF Attestation Reference Interaction Diagram *
********************************************************************
....................... .......................
. Reference Integrity . . TAP (PTS2.0) Info .
. Manifest . . Model and Canonical .
. . . Log Format .
....................... .......................
************************* .............. **********************
* YANG SWID Module * . TCG . * YANG Attestation *
* I-D.birkholz-yang-swid* . Attestation. * Module *
* * . MIB . * I-D.birkholz-yang- *
* * . . * basic-remote- *
* * . . * attestation *
************************* .............. **********************
************************* ************ ************************
* 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. The IETF Attestation Reference Interaction Diagram, Reference Integrity Manifest, TAP Information Model and Canonical Log Format, and both YANG modules are works in progress. Information Model layers describe abstract data objects that can be requested, and the corresponding response SNMP is still widely used, but the industry is transitioning to YANG, so in some cases, both will be required. TLS Authentication with TPM has been shown to work; SSH authentication using TPM-protected keys is not as easily done [as of 2019]¶
Networking Equipment such as routers, switches and firewalls has a key role to play in guarding the privacy of individuals using the network: * Packets passing through the device must not be sent to unauthorized destinations. For example * Routers often act as Policy Enforcement Points, where individual subscribers may be checked for authorization to access a network. Subscriber login information must not be released to unauthorized parties. * Networking Equipment is often called upon to block access to protected resources, or from unauthorized users. * Routing information, such as the identity of a router's peers, must not be leaked to unauthorized neighbors. * If configured, encryption and decryption of traffic must be carried out reliably, while protecting keys and credentials. 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 . This allows the administrator to ensure that the network provides individual and peer privacy guarantees.¶
RIV specifically addresses the collection information from enterprise network devices by an enterprise network. As such, privacy is a fundamental concern for those deploying this solution, given EU GDPR, California CCPA, and many other privacy regulations. The enterprise should implement and enforce their duty of care.¶
See [NetEq] for more context on privacy in networking devices¶
Attestation results 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 results can be trusted.¶
Two sets of keys are relevant to RIV attestation¶
TPM practices 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're never exposed, and cannot be extracted (See [Platform-DevID-TPM-2.0]).¶
Keeping keys safe is just part of attestation security; knowing which keys are bound to the device in question is just as important.¶
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 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 certs leading back to the manufacturer's root certificate. As is conventional in TLS connections, a 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 connection to the device as the attestation session begins. Security of this process derives from TLS security, with the DevID providing proof that the TLS session terminates on the intended device. [RFC8446].¶
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) will be detected as tampering.¶
A critical feature of the YANG model described in [I-D.birkholz-yang-basic-remote-attestation] 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 add an additional layer of signing using external keys, the important part is to 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: * The entire device could be spoofed, that is, when the Verifier goes to verify a specific device, it might be redirected to a different device. Use of the 802.1AR identity in the TPM ensures that the Verifier's TLS session is in fact terminating on the right device. * A compromised device could respond with a spoofed attestation result, that is, a compromised OS could return a fabricated quote.¶
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 spoofed attestation result, the quote generated inside the TPM must by 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 man-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 (i.e., 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. [this will require an OID that says the key is known by the CA to be an Attestation key]¶
These two keys 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 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.¶
Requiring results of attestation 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; 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.¶
Although RIV recommends that device manufacturers pre-provision devices with easily-verified DevID and AK certs, 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 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 configured 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 other trust anchors. (See [GloPlaRoT] for definitions of Roots of Trust.)¶
RIV also depends on reliable reference measurements, 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.2). But for embedded 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.¶
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:¶
Table 1 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.¶
+------------------------------------------------------------------+
| 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 amd 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 | TCG TPM DevID |
| 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 |
| | trust anchor.) |
--------------------------------------------------------------------
| 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.birkholz-yang-swid}}|
| as https://github.com/Labs64/swid-maven-plugin |
| 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 TAP to SNMP | TCG SNMP MIB |
| 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. | |
--------------------------------------------------------------------
Some components of an Attestation system have been implemented for end-user machines such as PCs and laptops. Figure 7 shows the corresponding protocol stacks.¶
+-----------------------+ +-------------------------+
| | | |
| Attester |<-------------| Verifier |
| (Device) |------------->| (Management Station) |
| | | | |
+-----------------------+ | +-------------------------+
|
-------------------- --------------------
| |
---------------------------------- ---------------------------------
|Reference Integrity Measurements| | Attestation |
---------------------------------- ---------------------------------
--------------------------------------------------------------------
| IETF Attestation Reference Interaction Diagram |
-------------------------------------------------------------------
....................... --------------------------------
. No Existing . | TAPS (PTS2.0) Info Model and|
. Reference Integrity . | Canonical Log Format |
. Manifest . | |
. Protocols Exist . --------------------------------
. .
. . ---------------------- ----------
. . | YANG Attestation | |IETF NEA|
. . | Module | | Msg and|
. . | I-D.birkholz-yang- | | Attrib.|
. . | basic-remote- | | for PA-|
. . | attestation | | TNC |
. . ---------------------- ----------
. . ---------------------- ----------
. . | XML, JSON, CBOR | | PT-TLS |
. . ---------------------- | (for |
. . ---------------------- |endpoint|
. . | NETCONF, RESTCONF, | |mcahines|
. . | COAP | | |
....................... ---------------------- ----------
----------------------------------------------------------------
| TLS, SSH |
----------------------------------------------------------------
This memo includes no request to IANA.¶