Request for enhancement: support for verifying generated attestation certificates

[DemiMarie]

• YubiKey Manager (ykman) version:

    YubiKey Manager (ykman) version: 3.1.1
    Libraries:
        libykpers 1.20.0
        libusb 1.0.23
  

• How was it installed?: Fedora 32 RPM package

• Operating system and version: Fedora 32

• YubiKey model and version: YubiKey 5 NFC

• Bug description summary:

This isn’t a bug per se, but rather an enhancement request. Would it be possible for the YubiKey Manager to support verifying attestation certificates? While they chain to a Yubico CA, the root certificate isn’t signed (directly or indirectly) by any trust anchor I know of and am in a position to verify.

It would be especially nice if ykman could verify that a signature was made by a specific YubiKey (specified by serial number).

[fdennis]

Hi,
You can find the root certificate (and more information about this in general) here. Have a look and let me know if it clarifies things for you or not.

Furthermore, could you elaborate in more detail regarding your use case?

[DemiMarie]

My threat model assumes that the infrastructure is compromised, and that a trusted CA might have issued a rogue certificate for developers.yubico.com. Therefore, the TLS connection to the server is not sufficient for me to trust that the root certificate on the website is authentic. Furthermore, the QubesOS AppVMs in which I usually run ykman have no network access whatsoever, so they cannot obtain the root certificate.

Not only would embedding the root certificate allow me trust that it is authentic, but it would also ease using ykman in air-gapped environments, where downloading the certificate from Yubico isn’t possible.

[dainnilsson]

The way I see it you have a boot-strapping problem no matter what: To verify attestation you have to get our root CA from "somewhere", and you need to be able to trust it. Even if we embedd it into ykman, this just moves the problem to there, doesn't it?

The threat model is one thing, but can you explain more about your specific use case for attestation? What is it you want to actually achieve? I'm struggling a bit with understanding what gets verified to whom here, because I think your use case might be different than the typical one we see, which goes something like this:

Attestation typically involves a client-server model, where the client provides a public key and attestation to a server, and the server verifies that the public key was generated on a (specific) YubiKey.

In this scenario, the client will:

• Get a YubiKey.
• Use ykman to generate a private key, attest the key, and export the attestation batch certificate.
• Send the attestation and batch certificates to the server.

The server will then:

• Once, at some point in time acquire and trust the Yubico PIV Attestation CA certificate.
• Verify the chain: CA -> batch certificate -> attestation certificate.
• Accept the clients public key (contained in the attestation certificate) as valid.

Since the server never actually sees a YubiKey, we typically don't see a use for having the verification functionality in the ykman tool (it wouldn't be installed on the server).

[DemiMarie]

The way I see it you have a boot-strapping problem no matter what: To verify attestation you have to get our root CA from "somewhere", and you need to be able to trust it. Even if we embedd it into ykman, this just moves the problem to there, doesn't it?

In my case, I trust ykman because it is included in a Fedora package, and that package is signed by a Fedora key.

The threat model is one thing, but can you explain more about your specific use case for attestation? What is it you want to actually achieve? I'm struggling a bit with understanding what gets verified to whom here, because I think your use case might be different than the typical one we see, which goes something like this:

I actually have two uses for attestation.

The first is as a way to check that a GPG public key is actually the one that corresponds to the card’s secret key. I use YubiKeys to sign and encrypt backups, so when it comes time to restore, I need to somehow verify that the public verification key matches that which I used to sign the backup. The backup storage is considered untrusted, so just putting the key there won’t work, and writing down a fingerprint on paper is inconvenient.

The second is to validate that a YubiKey is genuine. I use QubesOS, so the classic BadUSB attack doesn’t work. In particular, I can have one AppVM validate an attestation certificate generated by another.

[Sebi2020]

If you sign your backups with the gpg private key (and can be sure, that you really sign your backup with the stored private key), the verification would fail if the public key does not belong to the secret key on your card/yubikey.