search for: sk_sign_response

Hi, Sometimes, users might find that the `ssh-sk-helper` crashes after enrolling a new key when using external SK libraries. Currently, the memory returned by SK APIs is freed by the host, but external libraries may have their own methods of handling memory. For instance some external libraries are linked against a foreign libc statically. As a result, the `ssh-sk-helper` would have issues if

...a/ssh-sk.c +++ b/ssh-sk.c @@ -153,7 +153,7 @@ sshsk_free_enroll_response(struct sk_enroll_response *r) freezero(r->signature, r->signature_len); freezero(r->attestation_cert, r->attestation_cert_len); freezero(r, sizeof(*r)); -}; +} static void sshsk_free_sign_response(struct sk_sign_response *r) @@ -163,7 +163,7 @@ sshsk_free_sign_response(struct sk_sign_response *r) freezero(r->sig_r, r->sig_r_len); freezero(r->sig_s, r->sig_s_len); freezero(r, sizeof(*r)); -}; +} #ifdef WITH_OPENSSL /* Assemble key from response */ -- 2.24.0

I was recently looking at verifying the attestation data (ssh-sk-attest-v00) for a SK key, but I believe the data saved in this structure is insufficient for completing verification of the attestation. While the structure has enough information for U2F devices, FIDO2 devices sign their attestation over a richer "authData" blob [1] (concatenated with the challenge hash). The authData blob