User Presence (UP) checks and NFC

226 views
Skip to first unread message

My1

unread,
Jul 8, 2025, 12:45:05 PMJul 8
to FIDO Dev (fido-dev)
Hello again,

I have a clarification question.

CTAP defines for NFC devices that there is supposed to be a user presence flag that
1) can only be used once
2) expires 2 minutes after putting the fido2-device on the reader

now the question who is supposed to observe and enforce this? the authenticator or the platform?

As after some tests none of the (admittedly pretty few) Authenticators that I own that actually have NFC actually observes these on their own e.g. when using fido2-cred/assert or a tool called fido2-hid-bridge (a simple tool bridging NFC devices over to HID so Linux browsers can interact)

meaning that as far as I have seen the enforcement seems to be primarily on the platform, is that correct?

I tested:
Solokeys Solo NFC
Yubikey 5 (5.1.2)
Yubico Security Key NFC (5.2.4)
Token2 PIN+ as well as older NFC-enabled keys


John Bradley

unread,
Jul 8, 2025, 2:12:39 PMJul 8
to My1, Dev FIDO
The authenticator is supposed to enforce it.

The expiry time of UP was under specified in CTAP2.0.   You should be testing CTAP2.1 authenticators to see the behavior enforced. 

CTAP2.1 and later authenticators not implementing an internal 2min timer for UP should fail certification. 

Note CTAP2.1Pre authenticators were tested against CTAP2.0 requirements and should fail the CTAP2.1 conformance tests if they implement the pin protocol. 

John B



Sent from my iPhone

On Jul 8, 2025, at 10:45 AM, My1 <[email protected]> wrote:


--
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 [email protected].
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNpufqWTW15ehwxje15UghzbnYKCK0B9%3DThaKCKF3jTBOw%40mail.gmail.com.

My1

unread,
Jul 8, 2025, 3:20:04 PMJul 8
to John Bradley, Dev FIDO
was the single use part of the flag also just in 2.1 or also in 2.0?

at the very least the PIN+ keys from Token2 are as far as I am aware CTAP2.1 (without pre), on those I also noticed that the authenticatorReset command also as far as I remember works WAY after the 10-15 seconds have passed, something which has been defined as something that shouldnt happen from the earliest version of ctap2.1 I can find (fido-v2.1-rd-20191217)

most of my other FIDO2 keys are in actual use so not really something I'd wanna reset.

John Bradley

unread,
Jul 8, 2025, 10:47:13 PMJul 8
to My1, Dev FIDO
In CTAP2.0 single use was under specified.   

I clarified it in CTAP2.1 based on seeing how loose implementations were.  

Mostly it is a problem in Windows where people were leaving there keys on the CCID attached NFC reader. 
Sent from my iPhone

On Jul 8, 2025, at 1:19 PM, My1 <[email protected]> wrote:



Jean F Galiffo EXX

unread,
Jul 9, 2025, 2:22:01 AMJul 9

My1

unread,
Jul 22, 2025, 4:24:07 AMJul 22
to John Bradley, Dev FIDO
I got some new toys, and so I was able to test some more.

A Yubico Security Key (FW 5.7.4, AAGUID b7d3f68e88a6471e9ecf2df26d041ede)
Cryptnox FIDO2.1 card (AAGUID 1d1b4e3376a147fb97a014b10d0933f1)

and both aside from not running the single use user-presence state as well as very importantly, CTAP2_ERR_PIN_AUTH_BLOCKED (the one about needing to powercycle the device) does not seem to trigger as well when using NFC, which is surprising as the spec is kinda adamant about this.

the 2.0 docs explain why it is needed and the 2.1 docs add specifically in the clientPIN command that you cannot just delegate this function to the platform (as malware will just ignore the platform).


> This field is only valid in response to a getRetries request and authenticators MUST NOT use this field as an alternative to returning CTAP2_ERR_PIN_AUTH_BLOCKED when that is required by this specification: the power cycle behaviour is a security property and cannot be delegated to the platform to enforce.


Reply all
Reply to author
Forward
0 new messages