fido2-token under windows

[ntwerdochlib]

Is fido2-token expected to work under Windows using Hello?

When I try to use options like, -L -k, -I -k, -I -c I consistently get the following error:
fido_credman_get_dev_metadata: FIDO_ERR_INTERNAL

It seems that the ability to enum the attached FIDO2 devices is no longer supported under Windows. Does this hold true for enumerating RK's?

Windows Hello just doesn't allow enumeration in any form? I am guessing the answer is "yes" given the small number of functions in the windows hello API.

[LDVG]

The vast majority of fido2-token functions will not work under the Windows Hello backend since its API does not expose the functionality required. Indeed, there is no direct equivalent of the credential management API that the referenced options use.

[ntwerdochlib]

@LDVG Would you be open to me providing a pull request to make the fido2 tools a little more windows friendly?

Some of the changes I have in mind are:

• fido2-cred -M
• The input file needs a base64 encoded client data value
• Need to call fido_cred_set_clientdata(), the CD is expected to be not null when the cred is converted to a windows hello cred
• read_string()
• Test for '\r' and adjust size accordingly
• maybe supporting unicode input files, such as when running under Powershell
• update the man page for fido2-cred and fido2-assert accordingly

One remaining question is would adding the CD apply to non windows platforms? Probably not since it seems to be a code requirement for the windows hello credential

Final question: Would it be better to create a new issue specifying all of this?

[LDVG]

We'd be happy to review patches to improve fido2-{assert,cred} under the Windows Hello backend. A starting point could indeed be to create a set of issues elaborating on and demonstrating what doesn't work.

One remaining question is would adding the CD apply to non windows platforms? Probably not since it seems to be a code requirement for the windows hello credential

Without having thought about this for very long: This should preferably not be something dependent on the platform/backend but toggled via a flag to the tools.