A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)
Extracted elements (29)
The ietf-tcg-algs module encodes the full TCG Algorithm Registry Table 3 (rather than just the subset needed for attestation) to allow other YANG modules to leverage the complete algorithm identity hierarchy without depending on a separate specification.
The netequip_boot log format is identical to the IMA format but its scope combines BIOS events and IMA events, covering every measurable event from boot (BIOS, Bootloader, etc.) through OS runtime. This unified format simplifies log retrieval for network equipment that needs a single comprehensive integrity log.
The tpm20-attestation grouping includes optional unsigned-pcr-values alongside the mandatory TPMS_QUOTE_INFO digest. This is because the TPM2B_DIGEST is calculated across multiple PCRs, making it expensive for a Verifier to detect which single PCR changed. Providing individual PCR values allows the Verifier to confirm the signature while eliminating significant processing when only one PCR has changed.
The YANG module imports ietf-hardware (RFC 8348) and uses entPhysicalIndex via the hw:entity-mib feature to associate TPMs and compute nodes with physical hardware inventory entries, enabling correlation with existing hardware management data models.
TPM 1.2 and TPM 2.0 support are modeled as separate YANG features ('tpm12' and 'tpm20') with distinct RPCs and data nodes. Most commonly only one type will be available on an Attester; composite devices with multiple TPMs of different versions may expose both feature sets simultaneously.
TPM 1.2 defaults to TPM_ALG_SHA1 for PCR hashing, while TPM 2.0 defaults to TPM_ALG_SHA256. SHA1 is marked as deprecated due to insufficient cryptographic protection in the ietf-tcg-algs module, though it is retained for legacy TPM 1.2 compatibility.
A fresh nonce with an appropriate amount of entropy MUST be supplied by the YANG client to enable proof-of-freshness with respect to attestation Evidence. This nonce is also used to prevent replay attacks.
Any selection of PCRs MUST verify that the set of PCRs requested are a subset of the set of PCRs exposed in the device's rats-support-structures. This applies to both TPM 1.2 and TPM 2.0 PCR selection groupings.
One or more TPMs MUST be embedded in a composite device that provides attestation Evidence via the YANG module defined in this document. The device must include either TPM 1.2 or TPM 2.0 hardware, along with a corresponding TPM Software Stack (TSS).
RPCs should be protected by NACM with a default setting of deny-all to limit the extraction of attestation data by only authorized Verifiers. Information collected through RPCs could reveal software versions and configurations that identify vulnerabilities.
The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is SSH. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS.
The random nonce MUST be derived from an entropy source external to the Attester. A nonce sent into a TPM will typically be 160 or 256 binary digits long; shorter values are padded with leading zeros and longer values are trimmed to the most significant bits.
The receiver of the tpm12-challenge-response-attestation RPC response must verify that the certificate is for an active AIK confirmed by a third party as supporting Attestation on the targeted TPM 1.2.
The receiver of the tpm20-challenge-response-attestation RPC response must verify that the certificate is for an active AK, confirmed by a third party to belong to an entity legitimately able to perform Attestation on the targeted TPM 2.0.
The attester-supported-algos container identifies which TCG hash and asymmetric-signing algorithms are available for use on the attesting platform, separately for TPM 1.2 and TPM 2.0. Operators use this to restrict the algorithm set available to RPCs.
The ietf-tcg-algs YANG module defines algorithm identities corresponding to TCG Algorithm Registry Table 3 (rev 1.32), organized into cryptographic function categories: asymmetric, symmetric, hash, signing, anonymous_signing, encryption_mode, method, and object_type. It also defines tpm12 and tpm20 API specification identities.
The log-retrieval RPC allows a Verifier to acquire measurement log Evidence that was extended into specific TPM PCRs. Log selection supports three index types: last-entry (binary content match), numeric index, or timestamp. Supported log types include bios, ima, and netequip_boot.
The mtpm feature indicates that multiple TPMs on the device can support remote attestation, enabling scenarios such as multiple line cards each with their own TPM. When mtpm is active and no certificate-name is provided in an RPC, all compliant TPMs respond.
The rats-support-structures container is the top-level datastore definition enabling Verifiers or Relying Parties to discover information necessary to use the remote attestation RPCs. It houses tpms, compute-nodes, and attester-supported-algos sub-containers.
The tpm12-challenge-response-attestation RPC allows a Verifier to request signed TPM PCRs (TPM Quote operation) from a TPM 1.2 cryptoprocessor. Input includes PCR index selection, nonce, and optional certificate name(s); output includes a TPM_QUOTE2 binary response per TPM.
The tpm20-challenge-response-attestation RPC allows a Verifier to request signed TPM PCRs from a TPM 2.0 cryptoprocessor. Input includes a nonce, PCR bank selection with hash algorithm, and optional certificate name(s); output includes TPMS_QUOTE_INFO, quote-signature, optional unsigned PCR values, and uptime.
The tpms container provides configuration and operational details for each supported TPM, including tpm-firmware-version, quotable PCRs, associated certificates (EK, IAK, LAK types), hardware-based indicator, manufacturer, path, and operational status (operational or non-operational).
This document registers two YANG modules in the IANA YANG Parameters registry: ietf-tpm-remote-attestation (prefix 'tpm', namespace urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation) and ietf-tcg-algs (prefix 'taa', namespace urn:ietf:params:xml:ns:yang:ietf-tcg-algs). Both namespaces are also registered in the IETF XML Registry.
Requesting a large volume of logs via the log-retrieval RPC could require significant system resources and create a denial of service. Event logs containing hash values (digests) of boot and OS software are sensitive, as passive attackers can use them to identify software versions and launch targeted attacks.
The attester-supported-algos container could be populated with algorithms not supported by the underlying physical TPM. Vendors should restrict the ability to configure unsupported algorithms. The ietf-tcg-algs module notes that some algorithms (e.g., SHA1) are considered legacy and should be evaluated carefully before use.
The 'certificates' sub-container within 'tpms' exposes certificates used for attestation, potentially allowing selection of a compromised certificate. The 'type' field could be misconfigured to represent a different key type, altering how a Verifier evaluates attestation results.
BIOS event log entries include event-number (uint32, monotonically increasing), event-type (uint32), pcr-index (0-31), a digest-list with hash-algo and digest pairs, event-size (uint32), and event-data (binary). IMA and netequip_boot log entries use a 64-bit event-number and include ima-template, filename-hint, filedata-hash, hash algorithm fields, template-hash, pcr-index, and optional digital signature.
The TPM 1.2 attestation response carries three binary fields from a TPM1.2 Quote2 operation: pcr-data (type TPM_PCR_INFO_SHORT, the signed PCR data), version-info (type TPM_CAP_VERSION_INFO), and sig (the signature over the signed data).
The TPM 2.0 attestation response carries quote-data (mandatory binary field, a hash of selected PCR values including the hash algorithm, as TPMS_ATTEST structure), quote-signature (TPMT_SIGNATURE over quote-data), and optionally unsigned-pcr-values listing individual PCR bank values per hash algorithm.