[Bug 3516] New: ssh-keygen when creating sk fido keys does not create sufficient data for attestation verification.

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3516

            Bug ID: 3516
           Summary: ssh-keygen when creating sk fido keys does not create
                    sufficient data for attestation verification.
           Product: Portable OpenSSH
           Version: 9.1p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: william.brown at suse.com

An ssh key backed with a fido2 device can be created by ssh-keygen with
the command:

ssh-keygen-t ecdsa-sk -f ~/.ssh/id_ecdsa_sk

However in some environments it may be desired to associate an
attestation with these keys to perform verification of the supplier of
the fido2 device. ssh-keygen allows writing of this attestation with:

ssh-keygen -t ecdsa-sk -O write-attestation=~/.ssh/id_ecdsa_sk.attest
-f ~/.ssh/id_ecdsa_sk

This id_ecdsa_sk.attest file is a binary blob generated from
'fill_attestation_blob' per:
https://github.com/openssh/openssh-portable/blob/c46f6fed419167c1671e4227459e108036c760f8/ssh-sk.c#L437
 with the data populated from
https://github.com/openssh/openssh-portable/blob/ff9809fdfd1d9a91067bb14a77d176002edb153c/sk-usbhid.c#L1004 

However, this information is not sufficient for a valid attestation to
be performed as the webauthn packed type requires the concatenation of
auth_data_bytes and collected_client_data_hash. The verification
procedure for "packed" attestations (which are the type generated by
most fido2 devices) is documented here:
https://w3c.github.io/webauthn/#sctn-packed-attestation

Since the attestation blob does *not* contain
collected_client_data_hash it is not possible to validate the
attestation provided by ssh-keygen.

In addition, the current design of the blob also may have some issues
since the blob can only convey a singe x509 der for attestation cert,
when some devices may require a certificate chain in their x5c element.
The implementation of libfido2 only exposes the leaf certificate - not
the chain. Also worth noting that ed25519 keys do not use the x5c
element, but use a seperate field in the attestation statement for the
conveyance of their CA. 

In addition the attestation blob lacks the algorithm fields to assist
identification of the signature algorithm in use by the authenticator
in the attestation. The needed data are all found in the attestation
statement object.

As a result, it's likely that the current attestation blob format will
need to change:

* Inclusion of the collected_client_data_hash
* replace fido_cred_authdata_ptr with fido_cred_authdata_raw_ptr to
prevent a needless cbor array deserialise for attestation callers.
* replacement of attestation cert with the full attestation statement
object obtained from fido_cred_attstmt_ptr
* addition of the "format" for the attestation statement type, in this
case "packed" to account for future changes in attestation statements.

For libfido2 reference see:
https://developers.yubico.com/libfido2/Manuals/fido_cred_attstmt_ptr.html

Without these changes I believe it is currently not possible to
validate attestations for fido2 sk keys for ecdsa or ed25519.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.