Hardware Attestation for Email Sender Verification

1.1. Requirements Language

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.¶

1.2. Terminology

TPM

Trusted Platform Module, as specified by the Trusted Computing Group (TCG) [TCG-TPM2]. This document assumes TPM 2.0.¶

EK

Endorsement Key. A unique RSA or ECC key pair generated inside the TPM at manufacturing time, as profiled in [TCG-EK-PROFILE]. The EK private key never leaves the TPM. The EK certificate is signed by the chip manufacturer's CA.¶

AK

Attestation Key. A signing key generated inside the TPM after deployment, certified by the EK (via TPM2_Certify) to prove it resides in the same TPM. Used for signing operations in this protocol.¶

Manufacturer CA

The Certificate Authority operated by the TPM chip manufacturer (e.g., Intel, AMD, Infineon) that signs EK certificates. Root CA certificates are publicly available.¶

Trust Registry

An entity that verifies TPM attestation evidence at enrollment time and subsequently issues trust assertions (e.g., SD-JWTs) about enrolled entities. A Trust Registry is OPTIONAL for Mode 1 (Direct TPM Attestation) and REQUIRED for Mode 2 (SD-JWT Trust Proof).¶

HSM

Hardware Security Module. A physical device that safeguards cryptographic keys and provides cryptographic processing. TPMs are one category of HSM; portable smart cards (such as PIV-capable YubiKeys) are another. This document focuses on TPM-based attestation; companion documents may address other HSM types.¶

Sybil Attack

An attack where a single adversary creates many pseudonymous identities to subvert a reputation or trust system.¶

4.1. Attestation Certificate Chain

The attestation chain consists of the following certificates, ordered from leaf to root:¶

1. AK Certificate: Created by TPM2_Certify, binding the AK public key to the EK-identified TPM. Contains the AK public key and the EK's certification signature.¶
2. EK Certificate: Issued by the TPM manufacturer at fabrication time. Contains the EK public key, TPM manufacturer identity, and TPM model information. Signed by the manufacturer's intermediate CA.¶
3. Manufacturer Intermediate CA Certificate(s): Zero or more intermediate CA certificates forming the chain between the EK certificate issuer and the manufacturer root.¶
4. Manufacturer Root CA Certificate: The trust anchor. This certificate SHOULD already be present in the verifier's trust store. Major TPM manufacturer root CAs are published at well-known URLs (e.g., Intel's Trusted Services API, AMD's Key Distribution Server).¶

4.2. Header Field Definition

This document defines the "TPM-Attestation" header field for use in email messages.¶

TPM-Attestation = "TPM-Attestation" ":" SP tpm-attest-value CRLF

tpm-attest-value = tpm-version ";" SP
                   tpm-algorithm ";" SP
                   tpm-body-hash ";" SP
                   tpm-timestamp ";" SP
                   tpm-chain

tpm-version    = "v" "=" "1"
tpm-algorithm  = "alg" "=" ("RS256" / "ES256" / "PS256")
tpm-body-hash  = "bh" "=" base64url
tpm-timestamp  = "ts" "=" 1*DIGIT
tpm-chain      = "chain" "=" base64

Where:¶

v

Protocol version. MUST be "1" for this specification.¶

alg

The signature algorithm used by the AK. MUST be one of RS256 (RSASSA-PKCS1-v1_5 with SHA-256), ES256 (ECDSA with P-256 and SHA-256), or PS256 (RSASSA-PSS with SHA-256). RS256 is RECOMMENDED for maximum compatibility with existing TPM deployments.¶

bh

The base64url-encoded SHA-256 hash of the canonicalised email body, computed using the same canonicalisation algorithm as DKIM simple body canonicalisation Section 3.4.3 of [RFC6376].¶

ts

Unix timestamp (seconds since 1970-01-01T00:00:00Z) at which the attestation signature was created.¶

chain

A base64-encoded CMS SignedData structure [RFC5652] containing:¶

• The AK signature over the concatenation of the body hash and timestamp: Sign(AK, SHA-256(bh || ts))¶
• The AK certificate¶
• The EK certificate¶
• Any intermediate CA certificates¶

The CMS structure uses the SignedData content type (OID 1.2.840.113549.1.7.2). The encapContentInfo MUST be absent (detached signature); the signed content is the body hash concatenated with the timestamp, provided in the bh and ts fields.¶

4.3. Verification Algorithm

A receiving mail server that supports this specification MUST perform the following steps when a TPM-Attestation header is present:¶

1. Parse the TPM-Attestation header field and extract v, alg, bh, ts, and chain. If parsing fails, the result is "none" (header malformed).¶
2. Verify that v equals "1". If not, the result is "none" (unsupported version).¶
3. Compute the SHA-256 hash of the canonicalised email body using DKIM simple body canonicalisation. Compare with bh. If they differ, the result is "fail" (body modified).¶
4. Verify that ts is within an acceptable window of the current time. A window of 300 seconds (5 minutes) is RECOMMENDED for direct SMTP delivery. Verifiers SHOULD allow a wider window (up to 3600 seconds / 1 hour) for messages that have passed through intermediate MTAs, as indicated by Received headers or queue delays. The ts value reflects when the sender created the attestation, not when the MTA transmitted the message; multi-hop delivery and temporary queue backlogs are common operational realities. If ts is outside the acceptable window, the result is "fail" (timestamp expired).¶
5. Decode the base64 chain value and parse as a CMS SignedData structure. Extract the signer certificate (AK certificate) and the certificate chain.¶

6. Validate the certificate chain:¶

   1. The AK certificate MUST contain a TPM2_Certify structure in an extension or as the subject, binding the AK public key to the EK.¶
   2. The EK certificate MUST chain to a manufacturer intermediate CA certificate.¶
   3. The manufacturer intermediate CA MUST chain to a manufacturer root CA present in the verifier's TPM manufacturer CA trust store.¶

   If chain validation fails, the result is "fail" (chain invalid).¶

7. Verify the CMS signature using the AK public key and the specified algorithm. The signed content is SHA-256(bh || ts). If signature verification fails, the result is "fail" (bad signature).¶

8. If all checks pass, the result is "pass". The verifier MAY extract the following information from the certificate chain:¶

   • TPM manufacturer (from EK certificate issuer)¶
   • TPM model or family (from EK certificate extensions)¶
   • Hardware fingerprint: SHA-256 hash of the EK public key¶

4.4. Authentication-Results Integration

When recording the result of TPM-Attestation verification in an Authentication-Results header field [RFC8601], the following method identifier and property types are used:¶

Authentication-Results: mx.example.com;
  tpm-attest=pass
    header.alg=RS256
    header.mfr=INTC
    header.hw=tpm2.0
    header.chip=sha256:a1b2c3d4...

Where:¶

tpm-attest

The method identifier. Result is one of: "pass", "fail", "none" (header absent or unparseable), "temperror" (transient verification error), or "permerror" (permanent verification error).¶

header.alg

The signature algorithm from the TPM-Attestation header.¶

header.mfr

The TPM manufacturer code extracted from the EK certificate. Common values: "INTC" (Intel), "AMD" (AMD), "IFX" (Infineon), "STM" (STMicroelectronics), "NTC" (Nuvoton), "VMW" (VMware, virtual TPM).¶

header.hw

The hardware type. "tpm2.0" for a hardware or firmware TPM. "vtpm2.0" for a hypervisor-provided virtual TPM.¶

header.chip

The SHA-256 hash of the EK public key, truncated to the first 16 hex characters. This serves as a compact hardware fingerprint for reputation tracking. Full fingerprint SHOULD be available via an extended property.¶

4.5. Privacy Considerations for Direct Attestation

Direct TPM Attestation reveals the sender's hardware fingerprint (EK public key hash). This fingerprint is stable across all emails sent by the same machine, enabling linkability. This is a deliberate design choice: linkability is desirable for reputation systems (a hardware identity that sends spam can be permanently flagged) and is the mechanism by which Sybil resistance is achieved.¶

Senders who require unlinkability between messages SHOULD use Mode 2 (SD-JWT Trust Proof, Section 5) instead of or in addition to Direct TPM Attestation.¶

The EK certificate also reveals the TPM manufacturer and model family. In most deployments, this information is not sensitive. If the sender considers hardware provenance information sensitive, they SHOULD use Mode 2 exclusively.¶

5.1. Overview

SD-JWT Trust Proof provides an alternative attestation mechanism where a Trust Registry (an entity that has previously verified the sender's hardware attestation) issues a Selective Disclosure JWT [RFC9901] containing claims about the sender's trust classification. The claim structure is informed by the Entity Attestation Token (EAT) model [RFC9711].¶

The sender can then present this SD-JWT to email recipients with only the claims it chooses to disclose. For example, a sender might prove "my hardware trust level is sovereign" (indicating a genuine, non-virtual TPM was verified) without revealing its identity, hardware fingerprint, or registration date. The Trust Registry issuer (iss) is always visible in the SD-JWT (required for signature verification), but all other claims are selectively disclosable.¶

This mode requires the recipient to trust the Trust Registry's signing key (obtainable via the registry's JWKS endpoint). It does NOT require trust in any TPM manufacturer CA, as the Trust Registry has already performed that verification.¶

5.2. Header Field Definition

TPM-Trust-Proof = "TPM-Trust-Proof" ":" SP sd-jwt-compact CRLF

sd-jwt-compact = sd-jwt "~" *( disclosure "~" ) kb-jwt

; sd-jwt, disclosure, and kb-jwt are defined in RFC 9901

The header value is a complete SD-JWT presentation as defined in [RFC9901], including optional disclosures and a Key Binding JWT (KB-JWT).¶

The SD-JWT payload MUST include the following claims:¶

iss

The Trust Registry's identifier (a URI). Used to locate the Trust Registry's JWKS for signature verification.¶

iat

Issuance time as a NumericDate.¶

exp

Expiration time as a NumericDate. MUST NOT exceed 7 days after iat.¶

_sd

Array of digests for selectively disclosable claims, as defined in [RFC9901].¶

cnf

Confirmation claim containing the sender's public key (JWK format). When the sender's key is TPM-bound, this enables holder binding: the recipient can verify that the presenter possesses the TPM-resident private key corresponding to this public key.¶

The following claims SHOULD be available for selective disclosure (present as hashed entries in _sd):¶

trust_tier

The sender's hardware trust classification. Values defined by the Trust Registry (e.g., "sovereign" for genuine non-virtual TPM, "virtual" for hypervisor-provided TPM, "declared" for software-only).¶

sub

The sender's identifier within the Trust Registry.¶

handle

A human-readable name for the sender, if assigned.¶

hsm_manufacturer

The TPM manufacturer code (e.g., "INTC", "AMD").¶

enrolled_at

The timestamp at which the sender enrolled with the Trust Registry.¶

5.3. Verification Algorithm

1. Parse the TPM-Trust-Proof header as an SD-JWT presentation per [RFC9901].¶
2. Extract the issuer (iss) claim from the SD-JWT payload.¶
3. Fetch the issuer's JWKS from the well-known endpoint (e.g., {iss}/.well-known/jwks.json) or from a locally cached copy. The JWKS SHOULD be cached with a TTL of at least 1 hour and at most 24 hours.¶
4. Verify the SD-JWT signature against the issuer's public key per [RFC9901].¶
5. Verify that exp has not passed and iat is within an acceptable window.¶
6. For each disclosure present, verify that its hash matches an entry in the _sd array.¶
7. If a Key Binding JWT (KB-JWT) is present and the SD-JWT contains a cnf claim, verify the KB-JWT signature against the cnf key. This proves the presenter holds the private key (which, if TPM-bound, proves the email was composed on the enrolled hardware).¶
8. Extract the disclosed claims. The result is "pass" with the set of verified claims.¶

5.4. Authentication-Results Integration

Authentication-Results: mx.example.com;
  tpm-trust=pass
    header.trust_tier=sovereign
    header.registry=registry.example.com
    header.kb=tpm-bound

tpm-trust

The method identifier. Result values are the same as for tpm-attest.¶

header.trust_tier

The disclosed trust tier value, if the sender chose to reveal it.¶

header.registry

The Trust Registry identifier (from the iss claim).¶

header.kb

"tpm-bound" if the KB-JWT was verified against a cnf key known to be TPM-resident. "software" if the key binding used a software key. "none" if no KB-JWT was present.¶

7.1. Direct TPM Attestation (Mode 1)

Each TPM contains exactly one EK, which produces exactly one EK certificate. The EK public key hash serves as a unique hardware fingerprint. A receiving mail server that tracks these fingerprints can enforce policies such as:¶

• Rate limiting per hardware fingerprint¶
• Reputation scoring per hardware fingerprint¶
• Blocking hardware fingerprints associated with abuse¶

An attacker attempting to evade these policies requires a new physical TPM chip (minimum cost: the chip itself at ~$20 plus a machine to host it at ~$200-2000), compared to zero cost for creating a new software identity.¶

7.2. SD-JWT Trust Proof (Mode 2)

Sybil resistance in Mode 2 depends on the Trust Registry's enrollment policy. A Trust Registry that issues trust_tier values indicating hardware verification (e.g., "sovereign") MUST verify hardware attestation at enrollment time and MUST maintain a uniqueness registry enforcing at most one identity per EK public key hash. Such a Trust Registry provides equivalent Sybil resistance to Mode 1, with the additional benefit that the hardware fingerprint is not revealed to email recipients.¶

Trust Registries SHOULD monitor for anomalous enrollment patterns (e.g., many enrollments from a single IP range or a sudden spike in enrollments from a specific manufacturer CA) and SHOULD be capable of suspending enrollments pending investigation.¶

A Trust Registry that does not perform hardware verification (e.g., one that enrolls software-only agents) provides no Sybil resistance and MUST NOT issue trust_tier values that imply hardware verification. The trust_tier claim distinguishes these cases, enabling recipients to weight trust appropriately.¶

7.3. Virtual TPMs

Virtual TPMs (vTPMs) provided by hypervisors (VMware, Hyper-V, QEMU) have valid EK certificates signed by the hypervisor vendor's CA, but the hypervisor operator can create arbitrarily many vTPMs. This weakens Sybil resistance.¶

Receiving mail servers SHOULD distinguish between physical TPMs and virtual TPMs. The EK certificate's issuer field identifies the manufacturer: VMware-issued EK certificates indicate a virtual TPM. The header.hw property in Authentication-Results ("tpm2.0" vs "vtpm2.0") communicates this distinction.¶

Mail servers MAY apply different policies to virtual TPM attestations (e.g., lower trust weighting, stricter rate limits) while still recognising them as superior to no attestation at all.¶

8.1. Multiple Headers and Forwarding

If multiple TPM-Attestation headers are present in a message (e.g., if a forwarding gateway adds its own attestation), the verifier SHOULD evaluate all of them independently and record each result separately in Authentication-Results, using the same precedence conventions as for multiple DKIM-Signature headers [RFC6376].¶

Mailing lists and content-modifying forwarders that alter the message body will invalidate the body hash (bh) in any existing TPM-Attestation header. This is expected and analogous to DKIM signature breakage through body modification. Such intermediaries SHOULD preserve the original TPM-Attestation header (the verifier will record "fail" due to body hash mismatch) and MAY add their own TPM-Attestation header covering the modified body, if the intermediary itself has TPM capability. ARC [RFC8617] SHOULD be used to preserve the original authentication results from before the modification.¶

11.1. Manufacturer CA Compromise

If a TPM manufacturer's root CA private key is compromised, an attacker could forge EK certificates and create unlimited fake hardware identities. This risk is inherent to any PKI-based system and is mitigated by the same measures that protect manufacturer CAs today: hardware security modules, air-gapped signing ceremonies, and Certificate Transparency [RFC9162].¶

The SD-JWT Trust Proof (Mode 2) provides partial mitigation: if the Trust Registry detects anomalous enrollment patterns (e.g., thousands of enrollments from a single manufacturer CA in a short period), it can suspend enrollments while the compromise is investigated. This is analogous to how Certificate Transparency monitors detect mis-issued TLS certificates.¶

11.2. Replay Attacks

The timestamp (ts) in the TPM-Attestation header limits the replay window. Receiving mail servers SHOULD reject attestations with timestamps more than 300 seconds from the current time. Additionally, the body hash (bh) binds the attestation to a specific email body, preventing a valid attestation from being attached to a different message.¶

For SD-JWT Trust Proofs, the Key Binding JWT includes an iat claim and MAY include an aud claim binding the presentation to a specific recipient.¶

11.3. Compromised Endpoints and Privilege Requirements

This specification does not prevent a compromised machine from sending attested email - if an attacker has full control of a machine with a TPM, they can use that TPM to attest. However, this is by design: each compromised machine contributes exactly one hardware identity, and that identity accrues reputation (good or bad) permanently. A botnet of 10,000 compromised machines yields 10,000 attestable identities, not the millions possible with software-only identity systems.¶

Additionally, TPM operations provide a practical barrier against casual malware. Initial provisioning of an Attestation Key - the one-time setup step that creates the AK and certifies it against the EK - typically requires elevated operating system privileges (administrator on Windows via the TPM Base Services API, or root on Linux via /dev/tpmrm0). This means that unprivileged userspace malware (the most common class, distributed via phishing, drive-by downloads, and browser exploits) cannot provision new attestation keys, even if it runs on a machine with a TPM.¶

Once an AK has been provisioned, subsequent signing operations (TPM2_Sign) MAY be available to unprivileged processes depending on the TPM's authorization policy and operating system configuration. Implementations that wish to restrict signing to authorised software SHOULD configure appropriate TPM authorization policies (e.g., password or policy session requirements on the AK).¶

The net effect is that hardware attestation raises the bar for email abuse from "any script" to "kernel-level compromise of a specific physical machine," which is a substantial improvement over the status quo even if it is not a complete solution.¶

11.4. Physical Attacks on TPMs

Extracting private keys from a TPM requires physical attacks such as electron microscopy, laser fault injection, or side-channel analysis. Modern TPMs include countermeasures against these attacks. The cost and expertise required for successful key extraction is estimated at $50,000-$200,000 per chip, making it economically unviable for spam operations.¶

Even if key extraction were feasible, the extracted key could only impersonate one hardware identity. The attacker would still need to extract keys from additional TPMs to create additional identities.¶

11.5. Virtual TPM Risk

As noted in Section 7.3, virtual TPMs do not provide the same Sybil resistance as physical TPMs because the hypervisor operator can create arbitrary numbers of vTPMs. Receiving mail servers MUST be able to distinguish virtual from physical TPMs (via the manufacturer code in the EK certificate) and SHOULD apply appropriate policy differences.¶

11.6. Policy Abuse and Deanonymisation Risk

Mode 1 (Direct TPM Attestation) creates a persistent, globally unique hardware fingerprint that is visible to every recipient. While this is the intended mechanism for Sybil resistance and reputation building, it also creates risks if misused as a surveillance tool:¶

• Authoritarian regimes could correlate hardware fingerprints across messages to track individuals or organisations.¶
• Employers or platforms could mandate attestation to deanonymise senders who have legitimate reasons for pseudonymity.¶
• Receiving mail servers that log hardware fingerprints create long-lived tracking databases.¶

These risks are mitigated by the availability of Mode 2 (SD-JWT Trust Proof), which provides Sybil resistance without revealing the hardware fingerprint. Senders operating in contexts where hardware fingerprint disclosure is unacceptable SHOULD use Mode 2 exclusively.¶

Receiving mail servers SHOULD NOT require Mode 1 attestation when Mode 2 provides sufficient trust signal for the receiver's policy needs. The Applicability section (Section 3) notes that this specification is designed for automated senders, not human users, further limiting the deanonymisation risk in practice.¶

11.7. Header Stripping and Modification

An intermediary mail server could strip or modify the TPM-Attestation or TPM-Trust-Proof headers. This risk is identical to the risk of DKIM signature stripping and is mitigated by the same mechanisms: ARC [RFC8617] preserves authentication results through forwarding chains, and DMARC policy can specify handling for messages that lose authentication in transit.¶

Stripping these headers cannot cause a legitimate message to appear illegitimate (it simply loses the attestation). Adding forged headers is prevented by the cryptographic signatures.¶