Hash challenge supplied by client during FIDO key enrollment prior to
authordjm <djm@openbsd.org>
Mon, 31 May 2021 06:48:42 +0000 (06:48 +0000)
committerdjm <djm@openbsd.org>
Mon, 31 May 2021 06:48:42 +0000 (06:48 +0000)
passing it to libfido2, which does expect a hash.

There is no effect for users who are simply generating FIDO keys using
ssh-keygen - by default we generate a random 256 bit challenge, but
people building attestation workflows around our tools should now have
a more consistent experience (esp. fewer failures when they fail to
guess the magic 32-byte challenge length requirement).

ok markus@

usr.bin/ssh/sk-usbhid.c

index da1706e..3e6ab45 100644 (file)
@@ -1,4 +1,4 @@
-/* $OpenBSD: sk-usbhid.c,v 1.29 2021/02/18 02:15:07 djm Exp $ */
+/* $OpenBSD: sk-usbhid.c,v 1.30 2021/05/31 06:48:42 djm Exp $ */
 /*
  * Copyright (c) 2019 Markus Friedl
  * Copyright (c) 2020 Pedro Martelletto
@@ -635,7 +635,7 @@ sk_enroll(uint32_t alg, const uint8_t *challenge, size_t challenge_len,
 {
        fido_cred_t *cred = NULL;
        const uint8_t *ptr;
-       uint8_t user_id[32];
+       uint8_t user_id[32], chall_hash[32];
        struct sk_usbhid *sk = NULL;
        struct sk_enroll_response *response = NULL;
        size_t len;
@@ -687,8 +687,13 @@ sk_enroll(uint32_t alg, const uint8_t *challenge, size_t challenge_len,
                skdebug(__func__, "fido_cred_set_type: %s", fido_strerr(r));
                goto out;
        }
-       if ((r = fido_cred_set_clientdata_hash(cred, challenge,
-           challenge_len)) != FIDO_OK) {
+       if (sha256_mem(challenge, challenge_len,
+           chall_hash, sizeof(chall_hash)) != 0) {
+               skdebug(__func__, "hash challenge failed");
+               goto out;
+       }
+       if ((r = fido_cred_set_clientdata_hash(cred, chall_hash,
+           sizeof(chall_hash))) != FIDO_OK) {
                skdebug(__func__, "fido_cred_set_clientdata_hash: %s",
                    fido_strerr(r));
                goto out;