]> Sandelman Software Works

mcr+ietf@sandelman.ca

Red Hound Software

carl@redhoundsoftware.com

Huawei Technologies

william.panwei@huawei.com

Internet RATS Working Group Internet-Draft This document details mechanisms created for performing Remote Attestation that have been used in a number of industries. The document initially focuses on existing industry verticals, mapping terminology used in those specifications to the more abstract terminology used by the IETF RATS Working Group. The document aspires to describe possible future use cases that would be enabled by common formats.

The recently chartered IETF RATS WG intends to create a system of attestations that can be shared across a multitude of different users. This document exists as place to collect use cases for the common RATS technologies in support of the IETF RATS charter point 1. This document is not expected to be published as an RFC, but remain open as a working document. It could become an appendix to provide motivation for a protocol standards document. End-user use cases that would either directly leverage RATS technology, or would serve to inform technology choices are welcome, however.

Critical to dealing with and contrasting different technologies is to collect terms which are compatible, to distinguish those terms which are similar but used in different ways. This section will grow to include forward and external references to terms which have been seen. When terms need to be disambiguated they will be prefixed with their source, such as “TCG(claim)” or “FIDO(relying party)” Platform attestations generally come in two categories. This document will attempt to indicate for a particular attestation technology falls into this.

A static attestation says something about the platform on which the code is running.

A session attestation says something about how a session key used in a connection such as TLS connection was created. It is usually the result of evaluating attestations that are attached to the certificates used to create such a session.

The term “statement” is used as the generic term for the semantic content which is being attested to.

offers the following definition for root of trust.

SP800-155 uses the terms RoT for Reporting, Storage and Measurement, but not RoT for Verification – it uses “Verification Agent”. Though it is assumed the verifier is trustworthy. However, (page 9) includes a RoT for Verification (RTV) as well. The TCG Glossary also offers a general definition for Root of Trust “A component that performs one or more security-specific functions, such as measurement, storage, reporting, verification, and/or update. It is trusted always to behave in the expected manner, because its misbehavior cannot be detected (such as by measurement) under normal operation. “ defines RoT for Update (RoTU) and RoTU verification (RoTU-v). The TCG definition seems more concise than the NIST, but gets to the same point. For the purpose of this documenet, a hardware root of trust refers to security functionality that is trusted to behave in the expected manner, because its misbehavior cannot be detected under normal operation and resists soft exploits by encapsulating the functionality in hardware.

Each use case will consist of a table with a number of constant fields, as illustrated below. The claim names will be loosely synchronized with the EAT draft. The role workflow (formerly “attestation type”) will be described in the architecture draft. It will describe two classes of workflow: the passport type (Attestee sends evidence to Attester, receives signed statment, which is sent to relying party), or the background check type (Attestee sends measurements to Relying party, Relying Party checks with Attester). Twelve Monkeys Army of the Twelve Monkeys SDO James Cole Dr. Kathryn Reilly Passport OEM Identity, Age Claim, Location Claim, ptime Claim James Cole must convince Dr. Reilly he is from the future, and not insane.

This document is not a standards track document and does not make any normative protocol requirements using terminology described in .

The following specifications have been covered in this document: The Trusted Computing Group “Network Device Attestation Workflow” Android Keystore Fast Identity Online (FIDO) Alliance attestation, This document will be expanded to include summaries from: Trusted Computing Group (TCG) Trusted Platform Module (TPM)/Trusted Software Stack (TSS) ARM “Platform Security Architecture” Intel SGX attestation Windows Defender System Guard attestation Windows Device Health Attestation Azure Sphere Attestation : https://azure.microsoft.com/enus/resources/azure-sphere-device-authentication-andattestation-service/en-us/ IETF NEA WG Additional sources are welcome and requested.

This section lists a series of cases where an attestation is done.

This is a category of claims Device Identity Network Operators varies varies varies TBD Network operators want a trustworth report of identity and version of information of the hardware and software on the machines attached to their network. The process starts with some kind of Root of Trust that provides device identity and protected storage for measurements. The mechanism performs a series of measurements, and expresses this with an attestation as to the hardware and firmware/software which is running. This is a general description for which there are many specific use cases, including section 1.2, “Software Inventory”

Third Party Attestation Server Network Operators background check manufacturer of OS or hardware system network access control systems TBD The measurements from a heterogenous network of devices are provided to device-specific attestation servers. The attestation servers know what the “golden” measurements are, and perform the appropriate evaluations, resulting in attestations that the relying parties can depend upon.

Autonomous network operators passport manufacturer of OS or hardware system peer systems TBD The signed measurements are sent to a relying party which must validate them directly. They are not sent to a third party. (It may do so with the help of a signed list of golden values, or some other process). The relying party needs to validate the signed statements directly. This may occur because the network is not connected, or even because it can not be connected until the equipment is validated.

Proxy Root of Trust network operators passport manufacturer of OS or hardware system peer systems TBD A variety of devices provide measurements via their Root of Trust. A proxy server collects these measurements, and (having applied a local policy) then creates a device agnostic attestation. The relying party can validate the claims in a standard format.

Network scaled – small enterprises background check manufacturer of OS or hardware system network equipment TBD An entire network of systems needs to be validated (such as all the desktops in an enterprise’s building). The infrastructure is in the control of a single operator and is already trusted. The network can be partitioned so that machines that do not pass attestation can be quarantined. A 1:1 relationship between the device and the relying party can be used to maintain freshness of the attestation.

Network scaled – medium larger enterprises, including network operators passport manufacturer of OS or hardware system network equipment TBD An entire network of systems needs to be validated: such as all the desktops in an enterprise’s building, or all the routers at an ISP. The infrastructure is not necessarily trusted: it could be subverted, and it must also attest. The devices may be under a variety of operators, and may be mutually suspicious: each device may therefore need to process attestations from every other device. An NxM mesh of attestations may be untenable, but a system of N:1:M relationships can be setup via proxy attestations.

Network scaled – large telco/LTE operators passport manufacturer of OS or hardware system malware auditing systems TBD An entire network of systems need to be continuously attested. This could be all of the smartphones on an LTE network, or every desktop system in a worldwide enterprise. The network operator wishes to do this in order to maintain identities of connected devices more than to validate correct firmware, but both situations are reasonable.

Hardware watchdog individual system designers passport manufacturer of OS or hardware system bootloader or service processor TBD One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates to be applied. This is a significant problem, because it allows a fleet of devices to be held hostage for ransom. Within CyRes the TCG is defining hardware Attention Triggers that force a periodical reboot in hardware. This can be implemented by forcing a reboot unless attestation to an Attestation Server succeeds within the period interval, and having a reboot do remediation by bringing a device into compliance, including installation of patches as needed. This is unlike the previous section on Device Attestation in that the attestation comes from a network operator, as to the device’s need to continue operating, and is evaluated by trusted firmware (the relying party), which resets a watchdog timer.

TAM validation The TAM server background check Trusted Execution Environment (TEE) end-application TBD The “Trusted Application Manager (TAM)” server wants to verify the state of a TEE, or applications in the TEE, of a device. The TEE attests to the TAM, which can then decide whether to install sensitive data in the TEE, or whether the TEE is out of compliance and the TAM needs to install updated code in the TEE to bring it back into compliance with the TAM’s policy.

Machine Learning protection Machine Learning systems TBD hardware TEE machine learning model owner TBD An example use case is where a device manufacturer wants to protect its intellectual property in terms of the ML model it developed and that runs in the devices that its customers purchased, and it wants to prevent attackers, potentially including the customer themselves, from seeing the details of the model. This works by having some protected environment (e.g., a hardware TEE) in the device attest to some manufacturer’s service, which if attestation succeeds, then the manufacturer service releases the model, or a key to decrypt the model, to the requester. If a hardware TEE is involved, then this use case overlaps with the TEEP use case.

Critical Infrastructure devices TBD plant controller actuator TBD When a protocol operation can affect some critical system, the device attached to the critical equipment wants some assurance that the requester has not been compromised. As such, attestation can be used to only accept commands from requesters that are within policy. Hardware attestation in particular, especially in conjunction with a TEE on the requester side, can provide protection against many types of malware.

Shared Block Chain Computational claims Consortia of Computation systems TBD computer system (physical or virtual) other computer systems TBD A group of enterprises organized as a consortium seeks to deploy computing nodes as the basis of their shared blockchain system. Each member of the consortium must forward an equal number of computing nodes to participate in the P2P network of nodes that form the basis of the blockchain system. In order to prevent the various issues (e.g. concentration of hash power, anonymous mining nodes) found in other blockchain systems, each computing node must comply to a predefined allowable manifest of system hardware, software and firmware, as agreed to by the membership of the consortium. Thus, a given computing node must be able to report the (pre-boot) configuration of its system and be able to report at an y time the operational status of the various components that make-up its system. The consortium seeks to have the following things attested: system configuration, group membership, and virtualization status. This is a peer-to-peer protocol so each device in the consortium is a relying party. The attestation may be requested online by another entity within the consortium, but not by other parties. The attestation needs to be compact and interoperable and may be included in the blockchain itself at the completion of the consensus algorithm. The attestation will need to start in a hardware RoT in order to validate if the system is running real hardware rather than running a virtual machine.

Multi-tenant hosts Virtual machine systems TBD virtual machine hypervisor network operators TBD The host system will do verification as per 5.1. The tenant virtual machines will do verification as per 5.1 The network operator wants to know if the system as a whole is free of malware, but the network operator is not allowed to know who the tenants are. This is contrasted to the Chassis + Line Cards case (To Be Defined: TBD). Multiple Line Cards, but a small attestation system on the main card can combine things together. This is a kind of proxy.

Key Attestation network authentication systems TBD device platform internet peers TBD The relying party wants to know how secure a private key that identifies an entity is. Unlike the network attestation, the relying party is not part of the network infrastructure, nor do they necessarily have a business relationship (such as ownership) over the end device.

Device Type Attestation mobile platforms TBD device platform internet peers TBD This use case convinces the relying party of the characteristics of a device. For privacy reasons, it might not identify the actual device itself, but rather the class of device. The relying party can understand from either in-band (claims) or out-of-band (model numbers, which may be expressed as a claim) whether the device has trustworthy features such as a hardware TPM, software TPM via TEE, or software TPM without TEE. Other details such as the availability of finger-print readers or HDMI outputs may also be inferred.

Key storage Attestation secure key storage subsystems TBD device platform internet peers TBD This use case convinces the relying party only about the provenance of a private key by providing claims of the storage security of the private key. This can be conceived as a subset of the previous case, but may be apply very specifically to just a keystore. Additional details associated with the private key may be provided as well, including limitations on usage of the key. Key storage attestations may be consumed by systems provisioning public key certificates for devices or human users. In these cases, attestations may be incorporated into certificate request protocols (e.g., EST {#rfc7030}, CMP {#rfc4210}, ACME {#rfc8555}, SCEP , etc.) and processed by registration authorities or certification authorities prior to determining contents for any issued certificate.

End User authorization authorization systems TBD device platform internet peers TBD This use case convinces the relying party that the digital signatures made by the indicated key pair were done with the approval of the end-user/device-operator. This may also be considered possible subset of the device attestation above, but the attestation may be on a case-by-case basis. The nature of the approval by the end-user would be indicated. Examples include: the user unlocked the device, the user viewed some message and acknowledge it inside an app, the message was displayed to the user via out-of-app control mechanism. The acknowledgements could include selecting options on the screen, pushing physical buttons, scanning fingerprints, proximity to other devices (via bluetooth beacons, chargers, etc)

Location attestation geo-fenced systems passport (probably) secure GPS system(s) internet peers TBD The relying party wants to know the physical location (on the planet earth) of the device. This may be provided directly by a GPS/GLONASS/Galileo module that is incorporated into a TPM. This may also be provided by collecting other proximity messages from other device that the relying party can form a trust relationship with.

The simplest use case is the claim of some specific coordinates.

The second use case is the claim that some other devices are nearby. This may be absolute (“I am near device X, which claims to be at location A”), or just relative, (“I am near device X”). This use could use “I am here” or “I am near” claims from a 1:1 basis with device X, or use some other protocol. The nature of how the proximity was established would be part of this claim. In order to defeat a variety of mechanisms that might attempt to proxy (“wormhole”) radio communications, highly precise clocks may be required, and there may also have to be attestations as to the precision of those clocks. An additional example of being near would be for the case where two smartphones can establish that they are together by recording a common random movement, such as both devices being shaken together. Each device may validate the claim from the other (in a disconnected fashion), or a third party may validate the claim as the relying party. This could be used to establish that a medical professional was in proximity of a patient with implanted devices who needs help.

A third way to establish location is for a third party to communicate directly with the relying party. The nature of how this trust is established (and whether it is done recursively) is outside of the scope here. What is critical is that the identity of “You” can be communicated through the third party in a way that the relying party can use, but other intermediaries can not view.

Connectivity attestation entertainment systems TBD hardware-manufacturer/TEE connected peer TBD The relying party wants to know what devices are connected. A typical situation would be a media owner needing to know what TV device is connected via HDMI and if High-bandwidth Digital Content Protection (HDCP) is intact.

Component connectivity chassis systems with pluggable components background check line card management/control plane software TBD A management controller or similar hardware component wants to know what peripherals, rack scale device or other dynamically configurable components are currently attached to the platform that is under management controller control. The management controller may serve as attestation verifier over a local bus or backplane but may also aggregate local attestation results and act as a platform attester to a remote verifier.

RIV - Device Provenance Industrial IoT devices passport network management station a network entity TBD A newly manufactured device needs to be onboarded into a network where many if not all device management duties are performed by the network owner. The device owner wants to verify the device originated from a legitimate vendor. A cryptographic device identity such as an IEEE802.1AR is embedded during manufacturing and a certificate identifying the device is delivered to the owner onboarding agent. The device authenticates using its 802.1AR IDevID to prove it originated from the expected vendor. The device chain of custody from the original device manufacturer to the new owner may also be verified as part of device provenance attestation. The chain of custody history may be collected by a cloud service or similar capability that the supply chain and owner agree to use. section 1.2 refers to this as “Provable Device Identity”, and section 2.3 details the parties.

DNS-over-TLS or DNS-over-HTTPS server privacy policy enterprises and browsers and BYOD operating systems passport review agency browsers and operating systems DNS server identity, privinfo (see draft-reddy-dprive-dprive-privacy-policy ) Users want to control how their DNS queries are handled by DNS servers so they can configure their system to use DNS servers that comply with their privacy expectations. This use case communicates an attestion from a DoH server to a web browser or equivalent in a desktop or mobile operating system. The attester is a third party which has performed some kind of review of the DNS server. This may include significant levels of Device Capability attestation as to what is running and how it is configured (see ), in which case this is a form of Proxy Root of Trust ().

Safety Critical Systems Power plants and other systems that need to assert their current state, but which can not accept any inputs from the outside. The corollory system is a black-box (such as in an aircraft), which needs to log the state of a system, but which can never initiate a handshake. background check web services and other sources of status/sensor information open the beginning and ending time as endorsed by a Time Stamp Authority, represented by a time stamp token. The real time clock of the system itself. A Root of Trust for time; the TPM has a relative time from startup. These requirements motivate the creation of the Time Base Unidirectional Attestation (TUDA) , the output of TUDA are typically a secure audit log, where freshness is determined by synchronization to an source of external time. The freshness is preserved in the evidence by the use of a Time Stamp Authority (TSA) which provides Time Stamp Tokens (TST).

Trusted Path Routing Service Providers want to offer a trustworthy transport service to Government, Military, Financial, and Medical end-users. background check model for a centralized controller based alternative, and passport model for a router/switch distributed alternative. Routers/switches Network Controllers and Peer Routers/Switches TPM Quotes, log entries passed into TPM PCRs, trustworthiness levels appraised by Verifiers, and included in passports. There are end-users who believe encryption technologies like IPsec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These end-users want their sensitive flows to be forwarded across just those network devices currently appraised as trustworthy by the TCG-RIV use case. discusses two alternatives for exchanging traffic with end-user customer identified “sensitive subnets”. Traffic going to and from these subnets will transit a path where the IP layer and above are only interpretable by those network devices recently evaluated as trustworthy. These two alternatives are: For sensitive subnets, trusted end-to-end paths are pre-assigned through a network provider domain. Along these paths, attestation evidence of potentially transited components has been assessed. Each path is guaranteed to only include devices meeting the needs of a formally defined trustworthiness level. Through the exchange of attestation evidence between peering network devices, a trusted topology is established and maintained. Only devices meeting the needs of a formally defined trustworthiness level are included as members of this topology. Traffic exchanged with sensitive subnets is forwarded into this topology.

The TCG RIV Reference Document addresses the problem of knowing if a networking device should be part of a network, if it belongs to the operator, and if it is running appropriate software. The work covers most of the use cases in . This proposal is available as . The goal is to be multi-vendor, scalable and extensible. The proposal intentionally limits itself to: “non-privacy-preserving applications (i.e., networking, Industrial IoT )”, the firmware is provided by the device manufacturer there is a manufacturer installed hardware root of trust (such as a TPM and boot ROM) Service providers and enterprises deploy hundreds of routers, many of them in remote locations where they’re difficult to access or secure. The point of remote attestation is to: identify a remote box in a way that’s hard to spoof report the inventory of software was launched on the box in a way that cannot be spoofed, that is undetectably altered by a “Lying Endpoint” The use case described is to be able to monitor the authenticity of software versions and configurations running on each device. This allows owners and auditors to detect deviation from approved software and firmware versions and configurations, potentially identifying infected devices. Attestation may be performed by network management systems. Networking Equipment is often highly interconnected, so it’s also possible that attestation could be performed by neighboring devices. Specifically listed to be out of scope for the first generation includes: Linux processes, composite assemblies of hardware/software created by end-customers, and equipment that uses Sleep or Hibernate modes. There is an intention to cover some of these are topics in future versions of the documents. The TCG-RIV Attestation leverages the TPM to make a series of measurements during the boot process, and to have the TPM sign those measurements. The resulting “PCR” hashes are then available to an external verifier. A critical component of the RIV is compatibility with existing TPM practice for attestation proceedures, as spelled out in the TCG TAP Informational Model and TPM architecture specifications . The TCG uses the following terminology: Device Manufacturer Attester (“device under attestation”) Verifier (Network Management Station) “Explicit Attestation” is the TCG term for a static (platform) attestation “Implicit Attestation” is the TCG term for a session attestation Reference Integrity Measurements (RIM), which are signed my device manufacturer and integrated into firmware. Quotes: measured values (having been signed), and RIMs Reference Integrity Values (RIV) devices have a Initial Attestation Key (IAK), which is provisioned at the same time as the IDevID PCR - Platform Configuration Registry (deals with hash chains) The TCG document builds upon a number of IETF technologies: SNMP (Attestation MIB), YANG, XML, JSON, CBOR, NETCONF, RESTCONF, CoAP, TLS and SSH. The TCG document leverages the 802.1AR IDevID and LDevID processes.

describes a system used in smart phones that run the Android operation system. The system is primarily a software container to contain and control access to cryptographic keys, and therefore provides many of the same functions that a hardware Trusted Platform Module might provide. The uses described in section are the primary focus. On hardware which is supported, the Android Keystore will make use of whatever trusted hardware is available, including use of a Trusted Execution Environment (TEE) or Secure Element (SE). The Keystore therefore abstracts the hardware, and guarantees to applications that the same APIs can be used on both more and less capable devices. A great deal of focus from the Android Keystore seems to be on providing fine-grained authorization of what keys can be used by which applications. XXX - clearly there must be additional (intended?) use cases that provide some kind of attestation. Android 9 on Pixel 2 and 3 can provided protected confirmation messages. This uses hardware access from the TPM/TEE to display a message directly to the user, and receives confirmation directly from the user. A hash of the contents of the message can provided in an attestation that the device provides. In addition, the Android Keystore provides attestation information about itself for use by FIDO. QUOTE: Finally, the Verified Boot state is included in key attestation certificates (provided by Keymaster/Strongbox) in the deviceLocked and verifiedBootState fields, which can be verified by apps as well as passed onto backend services to remotely verify boot integrity

The FIDO Alliance has a number of specifications aimed primarily at eliminating the need for passwords for authentication to online services. The goal is to leverage asymmetric cryptographic operations in common browser and smart-phone platforms so that users can easily authentication. The use cases of are primary. FIDO specifications extend to various hardware second factor authentication devices. Terminology includes: “relying party” validates a claim “relying party application” makes FIDO Authn calls “browser” provides the Web Authentication JS API “platform” is the base system “internal authenticator” is some credential built-in to the device “external authenticator” may be connected by USB, bluetooth, wifi, and may be an stand-alone device, USB connected key, phone or watch. FIDO2 had a Key Attestation Format , and a Signature Format , but these have been combined into the W3C document specification. A FIDO use case involves the relying party receiving a device attestation about the biometric system that performs the identication of the human. It is the state of the biometric system that is being attested to, not the identity of the human! FIDO does provides a transport in the form of the WebAuthn and FIDO CTAP protocols. According to FIDO uses attestation to make claims about the kind of device which is be used to enroll. Keypairs are generated on a per-device model basis, with a certificate having a trust chain that leads back to a well-known root certificate. It is expected that as many as 100,000 devices in a production run would have the same public and private key pair. One assumes that this is stored in a tamper-proof TPM so it is relatively difficult to get this key out. The use of this key attests to the the device type, and the kind of protections for keys that the relying party may assume, not to the identity of the end user.

This section provides examples of some existing attestation formats.

Android Keystore attestations take the form of X.509 certificates. The examples below package the attestation certificate along with intermediate CA certificates required to validate the attestation as a certificates-only SignedData message . The trust anchor is available here: . The attestations below were generated using the generateKeyPair method from the DevicePolicyManager class using code similar to the following.

Annotations included below are delimited by ASN.1 comments, i.e., –. Annotations should be consistent with structures described here: .

The structures below are not annotated except where the difference is specific to the difference between the TEE structure shown above and artifacts emitted by StrongBox.

The next two sections provide two views of a CSR generated via invocation of the Certificate Enrollment Manager API similar to the below:

Attestation details are described here: https://msdn.microsoft.com/en-us/library/dn366894.aspx. The structure is essentially a Full PKI Request as described in RFC 5272.

This section provides an annotation attestation statement as extracted from an encrypted attestation extension. The structure of the attestation statement is defined here: https://msdn.microsoft.com/en-us/library/dn408990.aspx.

The format is structured as follows:

The remainder is the keyAttestation, which is structured as follows:

keyAttest (161 bytes) ~~~~~~~~~~~ FF 54 43 47 80 17 00 22 00 0B 9A FD AB 8A 0B E9 0B BB 3F 7F E6 B6 77 91 EF A9 15 8A 03 B2 2B 8C BE 3F EC 56 B6 30 BF 82 73 9C 00 14 13 6E 2F 14 DD AF 30 72 A6 E3 89 4D BF 7A 54 26 36 2F 10 D6 00 00 00 00 51 4F CB E5 AD 8C 8C 60 E6 C2 70 80 00 D4 2C 65 4C 6B 95 ED 95 00 22 00 0B 2B E6 2C AD 8D E8 9A 85 04 D7 F3 7B B7 4C F8 32 CD B4 F1 80 CA A6 35 B9 2C 39 87 B7 96 03 C3 A3 00 22 00 0B 6C 88 60 B2 80 E3 BE 7D 34 F2 85 DC 26 9D 1B 72 A8 0A 17 CF 31 08 F1 55 F2 9B 4E 82 C8 5B 49 7B ~~~~~~~~~~~ The keyAttest field is of type TPMS_ATTEST. The TPMS_ATTEST structure is defined in section 10.11.8 of https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-Structures-00.99.pdf. ~~~~~~~~~~~ FF 54 43 47 - magic 80 17 – type (TPM_ST_ATTEST_CERTIFY) 00 22 – name - TPM2B_NAME.size (34 bytes) 00 0B 9A FD AB 8A 0B E9 0B BB - TPM2B_NAME.name 3F 7F E6 B6 77 91 EF A9 15 8A 03 B2 2B 8C BE 3F EC 56 B6 30 BF 82 73 9C 00 14 – extraData – TPM2B_DATA.size (20 bytes) 13 6E 2F 14 DD AF 30 72 A6 E3 – TPM2B_DATA.buffer 89 4D BF 7A 54 26 36 2F 10 D6 00 00 00 00 51 4F CB E5 – clockInfo – TPMS_CLOCK_INFO.clock AD 8C 8C 60 – TPMS_CLOCK_INFO.resetCount E6 C2 70 80 – TPMS_CLOCK_INFO.restartCount 00 - – TPMS_CLOCK_INFO.safe D4 2C 65 4C 6B 95 ED 95 - firmwareVersion 00 22 – attested – TPMS_CERTIFY_INFO.name.size 00 0B 2B E6 2C AD 8D E8 9A 85 - TPM2B_NAME.name 04 D7 F3 7B B7 4C F8 32 CD B4 F1 80 CA A6 35 B9 2C 39 87 B7 96 03 C3 A3 00 22 – TPMS_CERTIFY_INFO.qualifiedName.size 00 0B 6C 88 60 B2 80 E3 BE 7D - TPM2B_NAME.name 34 F2 85 DC 26 9D 1B 72 A8 0A 17 CF 31 08 F1 55 F2 9B 4E 82 C8 5B 49 7B ~~~~~~~~~~~ Signature (256 bytes) – generated using the AIK private key ~~~~~~~~~~~ 1A F1 4B 12 A1 C5 D1 A4 C5 A4 59 C4 0A 97 E0 88 ED 1C D3 B6 38 4A 5D 6C 27 F5 69 7D 17 AD F6 C0 03 27 09 5D 93 B5 13 EA 50 B5 05 27 7B A0 51 4D 1B 17 52 87 7D B8 A6 05 4A 4F 39 CA 36 5C A1 19 19 0B 73 B4 0E 7F D3 91 DA 91 EE 37 C6 CE 78 AF 15 21 5D EB 5E 5F 23 A7 08 E9 85 D4 6B A0 95 6D D7 E0 3A D1 92 72 B7 D4 E5 35 6A 01 B0 7D 35 D0 99 BA A1 77 35 76 75 E3 90 A8 8B 86 27 B8 3D 47 75 2D 98 D0 23 4E 09 D8 26 6B 32 3C AB AC 50 A2 E8 FF 70 21 85 C5 5E B1 F5 9C B9 6E 21 27 C7 2A CD 84 61 02 47 6A A0 E1 9A 9F AF 02 43 08 D8 BF 9F 69 14 C4 8C 80 32 2D 5C A3 60 48 F5 5E 8E 65 6B 5E B5 0E A4 ED B9 8B F9 C3 D9 A8 CE C0 64 71 F6 E3 81 F7 9D 79 E5 73 7B F3 A4 6E 65 8D 72 B4 0A 3E 5E 70 5F AB 2B 89 B9 5E 65 44 BF 44 7B FB 2E 29 39 64 36 85 63 46 62 AF 25 A5 8B 19 30 AF ~~~~~~~~~~~ The remainder is the keyBlob, which is defined here: https://github.com/Microsoft/TSS.MSR/blob/master/PCPTool.v11/inc/TpmAtt.h.

As with the Android Keystore attestations, Yubikey attestations take the form of an X.509 certificate. As above, the certificate is presented here packaged along with an intermediate CA certificate as a certificates-only SignedData message. The attestations below were generated using code similar to that found in the yubico-piv-tool (https://github.com/Yubico/yubico-piv-tool). Details regarding attestations are here: https://developers.yubico.com/PIV/Introduction/PIV_attestation.html

TBD

TBD.

TBD.

Thomas Hardjono provided the text on blockchain system. Dave Thaler suggested many small variations. Frank Xialiang suggested the scalling scenarios that might preclude a 1:1 protocol between attesters and relying parties. Henk Birkholz provided many reviews. Kathleen Moriarty provided many useful edits. Ned Smith, Anders Rundgren and Steve Hanna provided many useful pointers to TCG terms and concepts. Thomas Fossati and Shawn Willden elucidated the Android Keystore goals and limitations.

&RFC2119; &RFC5652; &RFC5209; &RFC7030; &RFC4210; &RFC8555; &I-D.birkholz-rats-tuda; &I-D.fedorkow-rats-network-device-attestation; &I-D.tschofenig-rats-psa-token; &I-D.gutmann-scep; &I-D.voit-rats-trusted-path-routing;

created new section for target use cases added comments from Guy, Jessica, Henk and Ned on TCG description.