YubiKey PIV 证明验证工具

What an attestation proves

A certificate authority that issues certificates for keys on hardware tokens — code signing under the CA/Browser Forum rules, a company's VPN or SSH CA — needs to know that the private key was generated inside the token and cannot leave it. A CSR alone cannot show that: anyone can sign a CSR with a key kept on disk. A YubiKey answers with attestation (Yubico, PIV attestation). On request it issues an X.509 certificate for the public key in a PIV slot, signed by a device attestation key in slot f9. That key's certificate was issued by Yubico at manufacture. The attestation only exists for keys generated on the device; an imported key cannot be attested.

The chain that is checked

1. Slot certificate ← f9. The attestation certificate (subject YubiKey PIV Attestation 9a for slot 9a) must be signed by the key of the device certificate. The f9 certificate is not a CA certificate, so this link is checked on its own, without CA path rules.
2. f9 ← Yubico. The device certificate must chain to a Yubico root. Two hierarchies are in use, and both are bundled with the page: the Yubico PIV Root CA that has signed device certificates since 2016, and the Yubico Attestation Root 1 with its PIV attestation intermediates, introduced in 2024. Yubico's published bundle also contains FIDO, OpenPGP and Secure Domain CAs; a PIV attestation must not chain through those, so they are excluded. For a test device or a private hierarchy, paste your own roots under Custom trust anchors.
3. Consistency. The serial number stated in the slot certificate must equal the one in the device certificate, and the attestation should be within its validity period.

A chain that ends anywhere but at a trusted root means the key may not come from a genuine YubiKey, and the verdict says so.

What the attestation states

Yubico writes the device's properties into extensions under the OID arc 1.3.6.1.4.1.41482.3:

• Firmware version (.3) — which also decides the advisories below.
• Serial number (.7) — printed on the key and shown by ykman info; match it against your inventory.
• PIN and touch policy (.8) — whether the key can be used without the PIN, with it once per session or for every use (and, on the Bio series, with a fingerprint), and whether every use needs a touch, a touch cached for 15 seconds, or none. Set Require a PIN policy and Require a touch policy to turn your own rules into checks: "at least once per session" accepts every use, "at least cached" accepts every use.
• Form factor (.9) — USB-A or USB-C, keychain or nano, Lightning, Bio; the high bit marks FIPS models.
• FIPS and CSPN (.10, .11) — certified models.

The slot names follow NIST SP 800-73: 9a PIV authentication, 9c digital signature, 9d key management, 9e card authentication, 82–95 retired key management. If you compare against a CSR you are about to sign, paste its public key or certificate under Expected public key: the attested key must be exactly that key.

Firmware advisories

• ROCA (CVE-2017-15361, Yubico YSA-2017-01): RSA keys generated by firmware 4.2.6 to 4.3.4 are weak enough that the private key can be computed from the public key. Such an attestation is reported as not valid; the key must be replaced.
• EUCLEAK (CVE-2024-45678, Yubico YSA-2024-03): ECDSA on firmware before 5.7.0 leaks through a side channel. Exploiting it needs physical access and laboratory equipment, so it is a warning, not a failure.

What stays in your browser

The certificates are parsed and every signature is verified on this page; the Yubico CA certificates come with it, so nothing is fetched and nothing is uploaded. Attestations are public by design — they exist to be shown to whoever must trust the key — so the page can put them into a share link, in the URL fragment that browsers never send to a server. Private keys are refused in every field.

To produce the two files, run ykman piv keys attest 9a attestation.pem and ykman piv certificates export f9 f9.pem, or with yubico-piv-tool, -a attest -s 9a and -a read-certificate -s f9. A CSR made from the same slot can be read in the CSR decoder, and FIDO2 attestations of security keys are a different format, checked by the WebAuthn inspector.