Using custom FIDO2 Authenticator as Windows Sign-in option

307 views
Skip to first unread message

Andrey Ovcharov

unread,
Jun 19, 2020, 9:21:15 PM6/19/20
to FIDO Dev (fido-dev)
Hello everyone!

I'm working on a FIDO2 Authenticator project. Recently I've tried to use the device as Windows Sign In option.

The Windows "sees" the device and sends the MakeCredential command.

First of all, the rp and user fields of the request look very strange: 

2: {"id": "SelectDevice", "name": "SelectDevice"},
3: {"id": h'112233445544332211', "name": "SelectDevice", "displayName": "SelectDevice"}


Apparently the values are incorrect. How do I set up the Windows to send correct ones?

Second, after responding to this request I see the following:



The only option is the device reset. How do I proceed from here?

Thank you in advance!

nuno sung

unread,
Jun 20, 2020, 2:21:06 AM6/20/20
to FIDO Dev (fido-dev)
Hi Andrey,

For your 1st question, the special payload is just used to select device. You can check the description of the procedure step.1
https://fidoalliance.org/specs/fido2/fido-client-to-authenticator-protocol-v2.1-rd-20191217.html#authenticatorMakeCredential

For your 2nd quesiton, the current Windows Settings only support BioEnrollment(0x09), CilentPIN management(0x06) and Reset(0x07) features on its UI and will only show up based on your authenticator's response for GetInfo(0x04) commnad.

Andrey Ovcharov於 2020年6月20日星期六 UTC+8上午9時21分15秒寫道:

Andrey Ovcharov

unread,
Jun 20, 2020, 3:50:31 AM6/20/20
to FIDO Dev (fido-dev)
Hi, nuno sung,

Thank you for your answer! 

I see now - device selection makes sense when you have more than one authenticator.

However, trying to update GetInfo(0x04) command di not help me much. I'm sending the following response, as described in the Feature Detection section of authenticatorBioEnrollment (0x09) command:

{
 
1: ["FIDO_2_0", "FIDO_2_1_PRE"],
 
2: ["hmac-secret"],
 
3: h'D0042464AB1087969A440A4ED5B28D8F',
 
4: {"plat": false, "rk": true, "up": false, "uv": true, "bioEnroll": true},
 
5: 2048,
 
6: [1]
}


Unfortunately, it does not give me any result and the command is not called at all.

nuno sung

unread,
Jun 20, 2020, 7:09:57 AM6/20/20
to FIDO Dev (fido-dev)
Hi Andrey,

1. For "bioEnroll", you may try another word instead.
2. I think you miss the option "clientPin" still.
3. Besides, for better compatibility with clients/platforms, it needs to comply ctap2-canonical-cbor-encoding-form in your options.

Andrey Ovcharov於 2020年6月20日星期六 UTC+8下午3時50分31秒寫道:

Andrey Ovcharov

unread,
Jun 20, 2020, 1:54:02 PM6/20/20
to FIDO Dev (fido-dev)
Hi, nuno sung,

I'm very sorry but it did not help. I tried version "FIDO_2_1_PRE" with the option "bioEnroll", like stated in the specification, and version "FIDO_2_1" in combination with option "userVerificationMgmtPreview" as stated in the chrome sources. No success.

I've added "clientPin" option, and, yes, I get the option the change PIN in the security dialogue. However, it's pretty useless to me as my device does not have an interface to enter the PIN. Option for biometric enrollment is still missing.

I'm returning option "clientPin" set to true, which means "it indicates that the device is capable of accepting a PIN from the client and PIN has been set.". However, it does not allow me to continue.

As an addition - now I'm receiving undocumented command 0x40.


I find it very frustrating when the code written according to the documentation does not work and I have to search for the correct values in some sources, without any luck though :(

John Bradley

unread,
Jun 20, 2020, 8:39:58 PM6/20/20
to fido...@fidoalliance.org

You can only use "bioEnroll" in "Fido_2_1" final and that is in early alpha in Chrome Canary.

For urrent platforms you need version  string FIDO_2_1_PRE and the option userVerificationMgmtPreview

EG
{1: ["U2F_V2", "FIDO_2_0", "FIDO_2_1_PRE"], 2: ["credProtect", "hmac-secret"], 3: h'F8A011F38C0A4D15800617111F9EDC7D', 4: {"rk": true, "up": true, "uv": true, "plat": false, "uvToken": true, "clientPin": true, "credentialMgmtPreview": true, "userVerificationMgmtPreview": true}, 5: 1200, 6: [1], 7: 8, 8: 128, 9: ["nfc", "usb"], 10: [{"alg": -7, "type": "public-key"}, {"alg": -8, "type": "public-key"}], 13: 4, 14: 1537}

The preview commands are inplimented on 0x40 and 0x41

The review draft with the 0x09 and 0x0A versions of the commands that contain breaking changes from the preview versions should be published in July ish.

I am not going to claim that the FIDO IPR of only publishing RD snapshots and final versions is ideal for developers trying to play along unless they join Fido.

Sorry
John B.
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/2ea7468f-2514-4465-bebd-8c88971198d9o%40fidoalliance.org.

William

unread,
Jun 22, 2020, 12:16:06 AM6/22/20
to FIDO Dev (fido-dev)
Hi Andrey
1. If your device is FIDO_2_0 authenticator, to use your device as Windows Sign-in option,
your security key must implement the following features and extensions : 
- Resident key
- Client PIN
- hmac-secret
- Multiple accounts per RP
And your Windows device must be AzureAD Join device/ Hybrid AzureAD Join device.

2. Windows settings/Accounts/Security Option : Only use to manage clientPIN ( Set PIN/Change PIN/Reset factory)
The PIN is entered in Windows dialog (as my picture) so your device needn't have an interface to enter PIN.

3. In the MakeCredential command, If platform sends zero length pinAuth, authenticator needs to wait for user touch and then returns either CTAP2_ERR_PIN_NOT_SET if pin is not set or CTAP2_ERR_PIN_INVALID if pin has been set
You can see 5.5.8.1. Using pinToken in authenticatorMakeCredential
SetPIN.PNG

Andrey Ovcharov

unread,
Jun 22, 2020, 4:19:29 AM6/22/20
to FIDO Dev (fido-dev)
Hello Everyone!

Thank you very much for the valuable information. Sorry for maybe stupid questions - the authentication in the browser works way simpler. Now the functionality looks much more clear to me and I think I can continue with my implementation.
Reply all
Reply to author
Forward
0 new messages