OpenSSH ssh-keygen write-attestation enrollment signature length

[hochhaus]

I'm using the OpenSSH ssh-keygen write-attestation option while generating a ed25519-sk style key. Specifically I'm using the following command line:

$ ssh-keygen -t ed25519-sk -O resident -O verify-required -O write-attestation=/somepath/id_ed25519_sk.attest

The key is created successfully on my YubiKey as I would expect. I am now attempting to write some code to process the ssh-sk-attest-v01 format attestation file. All of the fields are reasonably easy to parse with the exception of enrollment signature which I would expect to be 64 bytes but is coming out at 70 bytes instead. Per the OpenSSH documentation:

OpenSSH treats the attestation certificate and enrollment signatures as opaque objects and does no interpretation of them itself.

Looking at the implementation I see that the OpenSSH codebase is just copying (1, 2) the signature return value from fido_cred_sig_ptr().

  if ((ptr = fido_cred_sig_ptr(cred)) != NULL) {
    len = fido_cred_sig_len(cred);
    if ((response->signature = calloc(1, len)) == NULL) {
      skdebug(__func__, "calloc signature failed");
      goto out;
    }
    memcpy(response->signature, ptr, len);
    response->signature_len = len;
  }

Therefore, I feel that this is a better question for libfido2 than OpenSSH. Could someone help me understand the layout of the memory returned by fido_cred_sig_ptr? How can I extract the 64 byte signature to use it for verification?

[LDVG]

The attestation signature is created using the key of the attesting authority (except for the case of self attestation, when it is created using the credential private key). For YubiKeys, the algorithm is ES256 and the signature is encoded as an ASN.1 DER Ecdsa-Sig-Value object. You can find the attestation public key in the attestation certificate.

[hochhaus]

Thanks @LDVG! This worked perfectly.

[hochhaus]

@LDVG Thanks for your help on correctly parsing the ASN.1 DER Ecdsa-Sig-Value object.

Unfortunately, I still am running into issues getting the signature to verify. Can you offer any additional pointers here?

The spec says:

Typically, this attestation statement contains a signature by an attestation private key over the attested credential public key and a challenge, as well as a certificate or similar data providing provenance information for the attestation public key, enabling the Relying Party to make a trust decision.

However, I'm uncertain of what should be included in the verified message (and the format it should be in). Should I include the ATTESTED CRED DATA as a byte slice? If so, where does the challenge fit in? Instead, should I formatting the message as JSON using the serialization algorithm. If so, in the context of SSH, how do I know the correct values for origin, crossOrigin, etc?

[hochhaus]

In case a bit more context of what I'm attempting is helpful I am currently using a subset of the steps from 7.2. Verifying an Authentication Assertion:

7. Let cData, authData and sig denote the value of response’s clientDataJSON, authenticatorData, and signature respectively.

• For clientDataJSON I think I should use the JSON-compatible serialization however, in the context of SSH, I'm not sure how to complete all of the fields

19. Let hash be the result of computing a hash over the cData using SHA-256.

20. Using credentialPublicKey, verify that sig is a valid signature over the binary concatenation of authData and hash.

Can you point me in the right direction here?

[LDVG]

The YubiKey uses the packed attestation format and per the specification's description of the format's verification procedure:

Verify that sig is a valid signature over the concatenation of authenticatorData and clientDataHash using the attestation public key in attestnCert with the algorithm specified in alg.

As seen from the previously liked OpenSSH attestation documentation, we've already got the attestation public key from the certificate and CBOR encoded authenticatorData. What remains is the clientDataHash.

In OpenSSH, the clientData is by default a set of random bytes (passed directly without any other structure). If you want to verify the attestation signature, you must also specify what challenge to use:

1. Generate a challenge (clientData) to pass to ssh-keygen.
2. Use ssh-keygen to generate the credential, also specifying the challenge using -O challenge=/path/to/challenge.
3. Parse the fields from the OpenSSH attestation information.
4. Extract the attestation public key from the certificate.
5. Decode the CBOR-encoded authenticatorData (the output from OpenSSH should be a CBOR bytestring and you need its contents).
6. Calculate the clientDataHash, i.e. SHA256(challenge).
7. Verify that the attestation signature is a valid signature over the binary concatenation of authenticatorData and clientDataHash.

[hochhaus]

Thanks for your help @LDVG. Unfortunately, I'm still have issues verifying the signature. I generated a specific example using a local testing only YubiKey which has never and will never be used outside the testing environment:

$ echo -n "0000000000000000" > /tmp/challenge
$ ssh-keygen -t ed25519-sk -O resident -O verify-required -O write-attestation=/tmp/id_ed25519_sk.attest -O challenge=/tmp/challenge 
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter file in which to save the key (/home/user/.ssh/id_ed25519_sk): 
Enter passphrase (empty for no passphrase): [empty]
Enter same passphrase again: [empty]
Your identification has been saved in /home/user/.ssh/id_ed25519_sk
Your public key has been saved in /home/user/.ssh/id_ed25519_sk.pub
The key fingerprint is:
SHA256:+mnkhnryN7JYxssl7xWZuMnRULkdtExB2BGnqsKytYI user@user-pc
The key's randomart image is:
+[ED25519-SK 256]-+
|          .*B+.  |
|         .ooo+   |
|        .  o+.   |
|         +.+.    |
|        S *      |
|     o o.= .     |
|   .. X+* .      |
|  E oO+O*o       |
|    +**B=.       |
+----[SHA256]-----+
Your FIDO attestation certificate has been saved in /tmp/id_ed25519_sk.attest
$ hexdump /tmp/id_ed25519_sk.attest 
0000000 0000 1100 7373 2d68 6b73 612d 7474 7365
0000010 2d74 3076 0031 0200 30dd 0282 30d9 0182
0000020 a0c1 0203 0201 0902 c800 89e7 7745 9d89
0000030 30fc 060d 2a09 4886 f786 010d 0b01 0005
0000040 2e30 2c31 2a30 0306 0455 1303 5923 6275
0000050 6369 206f 3255 2046 6f52 746f 4320 2041
0000060 6553 6972 6c61 3420 3735 3032 3630 3133
0000070 2030 0d17 3431 3830 3130 3030 3030 3030
0000080 185a 320f 3530 3030 3039 3034 3030 3030
0000090 5a30 6f30 0b31 0930 0306 0455 1306 5302
00000a0 3145 3012 0610 5503 0a04 090c 7559 6962
00000b0 6f63 4120 3142 3022 0620 5503 0b04 190c
00000c0 7541 6874 6e65 6974 6163 6f74 2072 7441
00000d0 6574 7473 7461 6f69 316e 3028 0626 5503
00000e0 0304 1f0c 7559 6962 6f63 5520 4632 4520
00000f0 2045 6553 6972 6c61 3120 3631 3636 3536
0000100 3736 3032 3059 0613 2a07 4886 3dce 0102
0000110 0806 862a ce48 033d 0701 4203 0400 9672
0000120 1cbd 9337 3f01 9f96 ac26 33f1 d40d b02f
0000130 1cb3 e7ca 21ab 7f09 b963 a8d2 0cd4 a4b0
0000140 03f9 1352 f482 af3f 7c69 36ea 4198 9e53
0000150 1c08 c02f 0da4 3fc8 fa67 edf8 ddae 81a3
0000160 3081 307f 0613 2b0a 0106 0104 c482 0d0a
0000170 0401 0405 0503 0304 2230 0906 062b 0401
0000180 8201 0ac4 0402 3115 332e 362e 312e 342e
0000190 312e 342e 3431 3238 312e 372e 1330 0b06
00001a0 062b 0401 8201 1ce5 0102 0401 0304 0502
00001b0 3020 0621 2b0b 0106 0104 e582 011c 0401
00001c0 1204 1004 88ee 7928 1c72 1349 7597 fc3d
00001d0 97ce 2a07 0c30 0306 1d55 0113 ff01 0204
00001e0 0030 0d30 0906 862a 8648 0df7 0101 050b
00001f0 0300 0182 0001 8095 853a 7442 b658 e070
0000200 3884 4055 4ab9 efab a71d 67ff ae6d 095c
0000210 9276 ae7a 5d91 fcd0 7b74 0a8a f852 6301
0000220 1627 ce83 df1f 200a bb82 6a4c c92a 703a
0000230 3012 64a4 a851 9331 100a dda2 75ca 8f10
0000240 9ec9 8303 a9ac 62e7 d424 339c 6d27 6e65
0000250 d84b 9d9f 632d cd2c 6111 f936 cc30 7c3c
0000260 f2dc af5d bee5 b04d 968e 7f9d 4e1e e1b7
0000270 fcde 8331 6a62 3f8f f34a cc33 20c0 f44c
0000280 6e05 fbb8 703c 6dae ac91 568a 17c9 0acc
0000290 aeef e200 7009 7d42 d2c1 65da a1bb 7823
00002a0 ab7f 3235 2011 e1a7 8fb1 7e9d 2791 3120
00002b0 fa2b 2e4b 0315 182d fb2f 0384 2328 a373
00002c0 ec77 2a2c 2f1a 1c93 1582 acdc 9b28 892d
00002d0 8e72 b82c 66d6 7b38 641e 6ae5 6099 8e5d
00002e0 f5df 2781 b4f0 bb24 3b6d af8e 371a 86f3
00002f0 74b5 e1de e9ea 0000 4700 4530 2102 9e00
0000300 3a95 f538 f4cd 9df5 f638 15e9 9292 0677
0000310 b731 897c 1da5 e7aa 87ad 3119 068a 0212
0000320 7b20 2caf 5ca5 7a3a 361e c546 094d 98d9
0000330 db86 0a10 6f69 1eea b124 9462 23eb c383
0000340 0002 0000 58a1 e39f 1006 a1e8 1162 6059
0000350 1efe 23c2 52e6 9f9c 6e4b 2080 cb0d 5c5e
0000360 1c32 f18a b1e2 c1bf 0000 0300 88ee 7928
0000370 1c72 1349 7597 fc3d 97ce 2a07 3000 780c
0000380 6d02 35ca c15c d196 f707 74a3 3edc 8184
0000390 8268 726e 9774 58b8 9262 2cda d51b 4b7b
00003a0 c5fa 5dc7 ec4c c434 f88b e222 6ed7 01a4
00003b0 0301 2027 2106 2058 780c 6d02 35ca c15c
00003c0 d196 f707 9da3 9add c89b 0fc5 67b7 3b99
00003d0 07c4 eb9a 7063 35cf 6ba1 7263 6465 7250
00003e0 746f 6365 0374 0000 0000 0000 0000     
00003ee
$ cat ~/.ssh/id_ed25519_sk.pub 
sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIAx4Am3KNVzBltEH96Od3ZqbyMUPt2eZO8QHmutjcM81AAAABHNzaDo= user@user-pc

After parsing I end up with the following:

• Attestation Certificate (0x308202d9308201c1a003020102020900c8e7894577899dfc300d06092a864886f70d01010b0500302e312c302a0603550403132359756269636f2055324620526f6f742043412053657269616c203435373230303633313020170d3134303830313030303030305a180f32303530303930343030303030305a306f310b300906035504061302534531123010060355040a0c0959756269636f20414231223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e3128302606035504030c1f59756269636f205532462045452053657269616c20313136363636353637323059301306072a8648ce3d020106082a8648ce3d030107034200047296bd1c3793013f969f26acf1330dd42fb0b31ccae7ab21097f63b9d2a8d40cb0a4f903521382f43faf697cea369841539e081c2fc0a40dc83f67faf8edaedda38181307f3013060a2b0601040182c40a0d0104050403050403302206092b0601040182c40a020415312e332e362e312e342e312e34313438322e312e373013060b2b0601040182e51c0201010404030205203021060b2b0601040182e51c01010404120410ee882879721c491397753dfcce97072a300c0603551d130101ff04023000300d06092a864886f70d01010b0500038201010095803a85427458b670e084385540b94aabef1da7ff676dae5c0976927aae915dd0fc747b8a0a52f80163271683ce1fdf0a2082bb4c6a2ac93a701230a46451a831930a10a2ddca75108fc99e0383aca9e76224d49c33276d656e4bd89f9d2d632ccd116136f930cc3c7cdcf25dafe5be4db08e969d7f1e4eb7e1defc3183626a8f3f4af333ccc0204cf4056eb8fb3c70ae6d91ac8a56c917cc0aefae00e20970427dc1d2da65bba123787fab35321120a7e1b18f9d7e912720312bfa4b2e15032d182ffb8403282373a377ec2c2a1a2f931c8215dcac289b2d89728e2cb8d666387b1e64e56a99605d8edff58127f0b424bb6d3b8eaf1a37f386b574dee1eae9)
  • Attestation Public Key (Curve:0x621b40 X:+51829996988999826361111074427871717766286766799575078686124027675104007214092 Y:+79898542893642364734180802405719341187024493089685112639907796389400643743453)
• Enrollment Signature (0x30450221009e953a38f5cdf4f59d38f6e9159292770631b77c89a51daae7ad8719318a061202207baf2ca55c3a7a1e3646c54d09d99886db100a696fea1e24b16294eb2383c302)
  • [71729092125739433043215660182095793205373029707677995427892438655148499797522 55943986747021228777931886971914052798052705163950670367701912611618612822786]
• CBOR-decoded authenticatorData (0xe30610e8a162115960fe1ec223e6529c9f4b6e80200dcb5e5c321c8af1e2b1bfc100000003ee882879721c491397753dfcce97072a00300c78026dca355cc196d107f7a374dc3e848168826e727497b8586292da2c1bd57b4bfac5c75d4cec34c48bf822e2d76ea40101032720062158200c78026dca355cc196d107f7a39ddd9a9bc8c50fb767993bc4079aeb6370cf35a16b6372656450726f7465637403)
• clientDataHash (SHA256("0000000000000000") = 0xfcdb4b423f4e5283afa249d762ef6aef150e91fccd810d43e5e719d14512dec7)

Do any of these values pop out as obviously incorrect to you?

When using these the signature fails to verify. Can you see what I'm doing wrong?

[LDVG]

The values look correct to me. 🙂

$ openssl x509 -pubkey -noout -in attest.cert -inform DER | tee pubkey.pem
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEcpa9HDeTAT+Wnyas8TMN1C+wsxzK
56shCX9judKo1AywpPkDUhOC9D+vaXzqNphBU54IHC/ApA3IP2f6+O2u3Q==
-----END PUBLIC KEY-----

$ xxd -ps data.in  # concatenated authenticatorData || clientDataHash
e30610e8a162115960fe1ec223e6529c9f4b6e80200dcb5e5c321c8af1e2
b1bfc100000003ee882879721c491397753dfcce97072a00300c78026dca
355cc196d107f7a374dc3e848168826e727497b8586292da2c1bd57b4bfa
c5c75d4cec34c48bf822e2d76ea40101032720062158200c78026dca355c
c196d107f7a39ddd9a9bc8c50fb767993bc4079aeb6370cf35a16b637265
6450726f7465637403fcdb4b423f4e5283afa249d762ef6aef150e91fccd
810d43e5e719d14512dec7

$ xxd -ps attest.sig
30450221009e953a38f5cdf4f59d38f6e9159292770631b77c89a51daae7
ad8719318a061202207baf2ca55c3a7a1e3646c54d09d99886db100a696f
ea1e24b16294eb2383c302

$ openssl dgst -verify pubkey.pem -signature attest.sig data.in
Verified OK

However, the usage of ecdsa.Verify looks incorrect. The function signature is

func Verify(pub *PublicKey, hash []byte, r, s *big.Int) bool

You will need to pass the hash of the signed message and not the message itself. If you instead pass SHA256(attestedData), it should verify correctly.

[hochhaus]

Huge thanks @LDVG! That resolved my issue.