Fido2 smartcard and user presence

[Moozoo]

Hi

I'm aware there is a java card applet for fido u2f (https://github.com/tsenger/CCU2F based on  https://github.com/LedgerHQ/ledger-u2f-javacard)

and was thinking of working on a full FIDO2 UFA/UF2 applet of my own.

But one thing has bothered me. No security card that I've seen has a capacitive touch sensor for user presence.

ie. like https://www.yubico.com/product/security-key-nfc-by-yubico/ but in a smartcard format with a photo ID etc printed on it.

Why isn't this a thing? People buy rfid shields/jammers for thier credit cards to protect against someone tap and paying their wallet without them knowing.

Wouldn't it be better and not very expensive to add capacitive touch sensors to all credit/smartcards?

Regards Michael

  

[Andreas Müller]

Hi Michael

I find this idea very promising, especially when using a NFC smartcard ring [1]. However, I am not sure wether a button is mandatory for FIDO2. I would consider a button on an NFC card user unfriendly due to the nature of NFC connections: NFC does not connect permanently it's rather tapping. A tap lasts maybe 0.2 seconds. But a browser/OS could interpret tapping (no NFC connection - connection established - connection lost) as equivalent to touching a button on a USB device.

Regards

Andreas

[1] https://store.nfcring.com/products/omni

[Ackermann Yuriy]

The goal of TUP is to ensure that for every operation there is a user action that ensures it's presence. So TUP or Test of User Presence is not just a button. There are security keys that simply power on only for a single operation, and then need to be removed from USB and inserted again. So for smartcards it is the same. The TUP is achieved by the fact that card is tapped and thus only had a single power on. The card then must refuse to continue doing any operations until re-powered.

The User Verification is achieved via ClientPin or built-in fingerprint scanner if you are fancy.

Regards. Yuriy

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

--
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/219912b3-8248-4991-ad2a-27551771e4c9%40fidoalliance.org.

[Fred Le Tamanoir]

yeah, let's resurrect this old post with new replies :)

1) For NFC, user presence is done by approaching the card.

2) even adding capacitive touch to smartcard is expensive (relatively to simple smartcard prices)

3) You don't have the same issue than Payment card (usual motivation for rfid shields) on U2F NFC card : you have to know which server and username is linked to credentials inside the card. 

You simply don't need such "switch sensor" option for U2F NFC card

--

Frédéric

Security Architect

[Andreas Müller]

So Moozoo, go ahead with the FIDO2 Applet, I am ready to test!

I did not get the CCU2F to run because the libraries are not available. It would be cool to use IDEs that are open source so anyone could build the code.

[Jared Vacanti]

I'm really hopeful that there's been some development on Moozoo's FIDO2 applet :)

I'm currently trying to get https://github.com/LedgerHQ/ledger-u2f-javacard or https://github.com/tsenger/CCU2F to work with my spare 2.2.2 cards I have on hand. Are there major issues that would require a 3.0.5 card? I'll place an order for one soon to test in either case.

But perhaps there hasn't been any progress on this front. Does anyone have any advice on where to pick up this project today? Any references or repos to fork?

Also, is there any reason the same ~0.2 second "initialization" period that is used with NFC smartcards for a test of user presence (TUP) cannot be applied to a contact card? Same principle, the applet will only work on the initial connection.

My current end goal is to use these smart cards for a second factor on accounts like AWS. We already use smartcards for other things, so we have the hardware.

Any feedback at all is very appreciated.

[Fan DANG (党凡)]

Basically, U2F requires signing data using ECDSA directly, which is not supported by 2.2.2.

--

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/78d9391e-4acb-473b-94e3-1ef9dbdb48a2%40fidoalliance.org.

[Ackermann Yuriy]

Yes, that's correct. FIDO2 however can use RS1/RS256 so you can implement that on the smart card.

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1a03afb9-0a22-41df-aa7c-dc40e2612c42%40www.fastmail.com.

[Thomas Duboucher]

Hi all,

TL;DR use the list athttps://www.fi.muni.cz/~xsvenda/jcalgtest/table.html
ECDSA is supported in Java Card since at least 2.2. However, as with any
cryptographic algorithm in Java Card, support is optional. So you must
check first with your vendor what cryptographic algorithm is supported.

Also, some cards only support a subset of elliptic curves, but
fortunately the curve required for U2F is the most used, so you
shouldn't worry.

Java Card 3.0.5 added features that makes working with ECC much more
efficient, e.g.:
// create an ECC domain in NVM
ECKey eccNistP256 = KeyBuilder.buildKey(ALG_TYPE_EC_FP_PARAMETERS,
MEMORY_TYPE_PERSISTENT, LENGTH_EC_FP_256, false);
// load NIST P-256 here from static byte arrays
// ...
// create a key pair in RAM using the NIST P-256 domain
ECPrivateKey eccSignaturePrivateKey =
KeyBuilder.buildKeyWithSharedDomain(ALG_TYPE_EC_FP_PRIVATE,
MEMORY_TYPE_TRANSIENT, eccNistP256, false);
ECPublicKey eccSignaturePublicKey =
KeyBuilder.buildKeyWithSharedDomain(ALG_TYPE_EC_FP_PUBLIC,
MEMORY_TYPE_TRANSIENT, eccNistP256, false);
// create the key generator
KeyPair eccSignatureKeyPair = new KeyPair()eccSignaturePPublicKey,
eccSignaturePrivateKey;
// ...
// generate a new key pair
eccSignatureKeyPair.genKeyPair();

Again, you must check with your vendor what is supported. :o)

Le 10/03/2020 à 04:36, Ackermann Yuriy a écrit :
> Yes, that's correct. FIDO2 however can use RS1/RS256 so you can
> implement that on the smart card.
>
>
> Yuriy Ackermann
> FIDO, Identity, Standards
> skype: ackermann.yuriy

> github: @herrjemand <https://github.com/herrjemand>
> twitter: @herrjemand <https://twitter.com/herrjemand>
> medium: @herrjemand <https://medium.com/@herrjemand>

>
>
> On Tue, 10 Mar 2020 at 04:12, Fan DANG (党凡) <dan...@gmail.com

> <mailto:dan...@gmail.com>> wrote:
>
> __

>> <mailto:fido-dev+u...@fidoalliance.org>.

>> To view this discussion on the web visit
>> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/78d9391e-4acb-473b-94e3-1ef9dbdb48a2%40fidoalliance.org

>> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/78d9391e-4acb-473b-94e3-1ef9dbdb48a2%40fidoalliance.org?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:fido-dev+u...@fidoalliance.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1a03afb9-0a22-41df-aa7c-dc40e2612c42%40www.fastmail.com
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1a03afb9-0a22-41df-aa7c-dc40e2612c42%40www.fastmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:fido-dev+u...@fidoalliance.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CALRyZMrCymxg_7dny9QLtgUZDjrVzOw0JvvxrSv9hUZ2yyqmJw%40mail.gmail.com
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CALRyZMrCymxg_7dny9QLtgUZDjrVzOw0JvvxrSv9hUZ2yyqmJw%40mail.gmail.com?utm_medium=email&utm_source=footer>.


--
Thomas Duboucher

[Robert Quattlebaum]

I realize this is an old thread, but just wanted to throw my $0.02 in. Comments inline below:

On Sunday, January 19, 2020 at 12:53:45 AM UTC-8, Andreas Müller wrote:

I find this idea very promising, especially when using a NFC smartcard ring [1]. [1] https://store.nfcring.com/products/omni

 

Note that the OMNI ring that is currently for sale is pre-personalized for 14443 Type-B. Every platform that I've tested so far that supports NFC FIDO authenticators requires that the authenticator use 14443 Type-A. This is super unfortunate, and hopefully NFC|Ring will re-release a Type-A version soonish.

Personally, I couldn't wait, so I made my own: https://medium.com/@darconeous/authentication-rings-part-1-2fe85c5d9d1b

 

However, I am not sure wether a button is mandatory for FIDO2. I would consider a button on an NFC card user unfriendly due to the nature of NFC connections: NFC does not connect permanently it's rather tapping. A tap lasts maybe 0.2 seconds. But a browser/OS could interpret tapping (no NFC connection - connection established - connection lost) as equivalent to touching a button on a USB device.

A button on an NFC FIDO device would be better than nothing (it would at least prevent someone from attempting to scan the authenticator without you knowledge while sitting next to you on the bus), but they do have NFC-powered fingerprint sensors embedded into passive NFC cards: https://youtu.be/_HxHvPm_NFE?t=73

With FIDO2 authenticators this becomes a bigger problem, because some prankster could do a denial-of-service attack by exhausting PIN retries or even resetting the authenticator over NFC, all without my knowledge. I really wish I could disable PIN entry and resets per-interface on my yubikey...

But I digress. Back to the original issue...

ledger-u2f-javacard, when initialized with flags of 0x00, will allow only one signing operation to happen per card reset. While not the theoretically ideal mechanism for a device without a button (which would be to only allow one signing request within two seconds of power-up, independent of card resets), there is no way to implement the better way without using proprietary APIs under NDA. This really only improves the security of no-button plug-in-presence USB authenticators, because NFC authenticators can always be easily powered down via software by turning off the field.

[Thomas Duboucher]

Thanks Robert for these feedbacks. :)

Le 28/03/2020 à 05:04, Robert Quattlebaum a écrit :
> Note that the OMNI ring that is currently for sale is pre-personalized
> for 14443 Type-B. Every platform that I've tested so far that supports
> NFC FIDO authenticators requires that the authenticator use 14443
> Type-A. This is super unfortunate, and hopefully NFC|Ring will
> re-release a Type-A version soonish.
>

It's true that Android has a well-known bug regarding ISO 14443 Type-B.
Has soon as the FIDO UI kicks in, Android stops sending REQB. You can
easily spot this behavior using a protocol spy.

However, support for Type-A and B is a requirement for NFC compliance
for readers, extended length unfortunately isn't. I haven't had any
issue with any other platform so far. On which other platform did you
encounter issues with Type-B?

> A button on an NFC FIDO device would be better than nothing (it would at
> least prevent someone from attempting to scan the authenticator without
> you knowledge while sitting next to you on the bus), but they do have
> NFC-powered fingerprint sensors embedded into passive NFC
> cards: https://youtu.be/_HxHvPm_NFE?t=73
>

NFC FIDO devices are usually smartcards, and they require high
resistance to physical constraints, e.g. twisting. Adding a capacitive
sensor is not so straightforward, but we are aware of these issues.

> With FIDO2 authenticators this becomes a bigger problem, because some
> prankster could do a denial-of-service attack by exhausting PIN retries
> or even resetting the authenticator over NFC, all without my knowledge.
> I really wish I could disable PIN entry and resets per-interface on my
> yubikey...
>

Yup, but we haven't come yet with a solution that can work as a standard.

> ledger-u2f-javacard, when initialized with flags of 0x00, will allow
> only one signing operation to happen per card reset. While not the
> theoretically ideal mechanism for a device without a button (which would
> be to only allow one signing request within two seconds of power-up,
> independent of card resets), there is no way to implement the better way
> without using proprietary APIs under NDA. This really only improves the
> security of no-button plug-in-presence USB authenticators, because NFC
> authenticators can always be easily powered down via software by turning
> off the field.
>

Everyone seems to forget you can power-off the field in NFC. :]

--
Thomas Duboucher

[Robert Quattlebaum]

Hello Thomas, comments inline below.

On Saturday, March 28, 2020 at 3:18:25 AM UTC-7, Thomas Duboucher wrote:

Le 28/03/2020 à 05:04, Robert Quattlebaum a écrit :
> Note that the OMNI ring that is currently for sale is pre-personalized
> for 14443 Type-B. Every platform that I've tested so far that supports
> NFC FIDO authenticators requires that the authenticator use 14443
> Type-A. This is super unfortunate, and hopefully NFC|Ring will
> re-release a Type-A version soonish.
>

It's true that Android has a well-known bug regarding ISO 14443 Type-B.
Has soon as the FIDO UI kicks in, Android stops sending REQB. You can
easily spot this behavior using a protocol spy.

However, support for Type-A and B is a requirement for NFC compliance
for readers, extended length unfortunately isn't. I haven't had any
issue with any other platform so far. On which other platform did you
encounter issues with Type-B?

iOS similarly refuses to use a Type-B FIDO authenticator. It DOES send out REQB, but it seems to refuse to actually engage with a Type-B FIDO authenticator. Otherwise, iOS seems to support Type-B just fine (works for Yubico Authenticator, NDEF tags, etc).

 

> A button on an NFC FIDO device would be better than nothing (it would at
> least prevent someone from attempting to scan the authenticator without
> you knowledge while sitting next to you on the bus), but they do have
> NFC-powered fingerprint sensors embedded into passive NFC
> cards: https://youtu.be/_HxHvPm_NFE?t=73
>

NFC FIDO devices are usually smartcards

Is that really true? I would think most NFC FIDO devices would be key fobs. The only NFC FIDO authenticators in a card form factor I see on Amazon are combo cards that support BLE and sport an integrated battery. I know there is SurePass ID, but I've never seen one in the wild, nor seen it offered for sale to consumers.

 

Adding a capacitive
sensor is not so straightforward, but we are aware of these issues.

I agree that it is certainly not a trivial addition, whatever the form-factor.

 

> With FIDO2 authenticators this becomes a bigger problem, because some
> prankster could do a denial-of-service attack by exhausting PIN retries
> or even resetting the authenticator over NFC, all without my knowledge.
> I really wish I could disable PIN entry and resets per-interface on my
> yubikey...
>

Yup, but we haven't come yet with a solution that can work as a standard.

My solution is this:

• If the authenticator has other transports (like USB or BLE), then only allow four PIN attempts via NFC and disallow CTAP2 resets over NFC without some other authentication (like a pin). The idea is that there is no reason to allow permanently destructive actions to occur over NFC when there are other transports available that are much better indications of physical control over the device.
  
• If the authenticator is NFC-only, then add a significant (10+second) delay for each PIN attempt after PIN attempt 3, perhaps doubling in length after each attempt. Also require a significant delay for attempting a reset (45+seconds). This should make it significantly more difficult to perform such a denial of service attack because the attack would need to keep their reader in place for an extended period of time (and likely be noticed in the process).

-- RQ

[Christian Kahlo]

Hi Robert,

Am Sa., 28. März 2020 um 23:19 Uhr schrieb Robert Quattlebaum
<darco...@gmail.com>:

>> > A button on an NFC FIDO device would be better than nothing (it would at
>> > least prevent someone from attempting to scan the authenticator without
>> > you knowledge while sitting next to you on the bus), but they do have
>> > NFC-powered fingerprint sensors embedded into passive NFC
>> > cards: https://youtu.be/_HxHvPm_NFE?t=73
>> >
>> NFC FIDO devices are usually smartcards
> Is that really true? I would think most NFC FIDO devices would be key fobs. The only NFC FIDO authenticators in a card form factor I see on Amazon are combo cards that support BLE and sport an integrated battery. I know there is SurePass ID, but I've never seen one in the wild, nor seen it offered for sale to consumers.

A keyfob with NFC is basically a smartcard. And yes in other
environments you'll have different devices.
We're deploying lots of NFC-only smartcards with FIDO for use with
Android or Win10 + NFC readers.

>> Adding a capacitive sensor is not so straightforward, but we are aware of these issues.
> I agree that it is certainly not a trivial addition, whatever the form-factor.

It's quite expensive and still error prone. (bends, torsions while carrying)

>> > With FIDO2 authenticators this becomes a bigger problem, because some
>> > prankster could do a denial-of-service attack by exhausting PIN retries
>> > or even resetting the authenticator over NFC, all without my knowledge.
>> > I really wish I could disable PIN entry and resets per-interface on my
>> > yubikey...
>> Yup, but we haven't come yet with a solution that can work as a standard.
> My solution is this:
>
> If the authenticator has other transports (like USB or BLE), then only allow four PIN attempts via NFC and disallow CTAP2 resets over NFC without some other authentication (like a pin). The idea is that there is no reason to allow permanently destructive actions to occur over NFC when there are other transports available that are much better indications of physical control over the device.

Managed environments like FIDESMO could allow management commands only
over GP secured
channels. I.e. reset, initialize, etc. (regarding your medium article
this is also an option for OATH and
any other application)

> If the authenticator is NFC-only, then add a significant (10+second) delay for each PIN attempt after PIN attempt 3, perhaps doubling in length after each attempt. Also require a significant delay for attempting a reset (45+seconds). This should make it significantly more difficult to perform such a denial of service attack because the attack would need to keep their reader in place for an extended period of time (and likely be noticed in the process).

How to count systicks? With proprietary APIs you can set the frequency
of the CPU and implement a
counter. Gemalto/THALES did something similar in the Smart Guardian
(USB stick with flash and smartcard).
This is implementation dependent. And yes some implementations already
improved this processes,
but there is no standardized consensus yet.

>> > ledger-u2f-javacard, when initialized with flags of 0x00, will allow
>> > only one signing operation to happen per card reset. While not the
>> > theoretically ideal mechanism for a device without a button (which would
>> > be to only allow one signing request within two seconds of power-up,
>> > independent of card resets), there is no way to implement the better way
>> > without using proprietary APIs under NDA. This really only improves the
>> > security of no-button plug-in-presence USB authenticators, because NFC
>> > authenticators can always be easily powered down via software by turning
>> > off the field.
>> >
>>
>> Everyone seems to forget you can power-off the field in NFC. :]

This is against multiple requests during intended use. NFC blockers
exist and should be used.
In the EU we got payment, transport, student cards etc. pp. that could
be attacked as well, so
people are already buying wallets with NFC shielding or add cards with
active blocking functionality.

If you put your dollars in a bus on the seat next to you without
keeping an eye on them, they might
be gone as well...

Cheers,
CK

[Robert Quattlebaum]

Hello Christian, comments inline below:

On Saturday, March 28, 2020 at 5:17:43 PM UTC-7, Christian Kahlo wrote:

Am Sa., 28. März 2020 um 23:19 Uhr schrieb Robert Quattlebaum

>> NFC FIDO devices are usually smartcards
> Is that really true? I would think most NFC FIDO devices would be key fobs. The only NFC FIDO authenticators in a card form factor I see on Amazon are combo cards that support BLE and sport an integrated battery. I know there is SurePass ID, but I've never seen one in the wild, nor seen it offered for sale to consumers.

A keyfob with NFC is basically a smartcard.

I try to avoid calling things that aren't actually cards "smart cards", it gets especially confusing when the conversation also includes form factors. Form factor makes a huge difference in how practical and robust adding a button would be. I call the chips in smart cards "secure elements". I fill like this language makes intent more clear.

Taking a step back: The reason I mentioned it was because I was curious if there was something I was missing. If the most common type of FIDO NFC tokens were (actual) smart cards then there must have been something I was missing, or the market outside of the US must look a lot different. Either way I figured I would want to know more.

 

We're deploying lots of NFC-only smartcards with FIDO for use with Android or Win10 + NFC readers.

As actual cards? Or as some other form factor? Are they (going to be) available for consumers to buy, or are they being sold to institutional buyers only? I'm curious.

  

>> > With FIDO2 authenticators this becomes a bigger problem, because some
>> > prankster could do a denial-of-service attack by exhausting PIN retries
>> > or even resetting the authenticator over NFC, all without my knowledge.
>> > I really wish I could disable PIN entry and resets per-interface on my
>> > yubikey...
>> Yup, but we haven't come yet with a solution that can work as a standard.
> My solution is this:
>
> If the authenticator has other transports (like USB or BLE), then only allow four PIN attempts via NFC and disallow CTAP2 resets over NFC without some other authentication (like a pin). The idea is that there is no reason to allow permanently destructive actions to occur over NFC when there are other transports available that are much better indications of physical control over the device.

Managed environments like FIDESMO could allow management commands only over GP secured channels. I.e. reset, initialize, etc. (regarding your medium article this is also an option for OATH and any other application)

Indeed it would be! I'd consider that in the category of "some other authentication". I think it's a great idea, although with Fidesmo specifically you can simply uninstall and reinstall the app to the same effect.

> If the authenticator is NFC-only, then add a significant (10+second) delay for each PIN attempt after PIN attempt 3, perhaps doubling in length after each attempt. Also require a significant delay for attempting a reset (45+seconds). This should make it significantly more difficult to perform such a denial of service attack because the attack would need to keep their reader in place for an extended period of time (and likely be noticed in the process).

How to count systicks? With proprietary APIs you can set the frequency of the CPU and implement a counter. Gemalto/THALES did something similar in the Smart Guardian (USB stick with flash and smartcard).

In the absence of any timing APIs, I implemented it as a for loop that does busy work a certain number of times. The number of iterations is calibrated to the hardware it is running on. No fancy NDA'd APIs are required. You do have to calibrate it for each secure element model, but that's a straightforward process that can be easily automated to happen at personalization.

 

This is implementation dependent. And yes some implementations already 

improved this processes, but there is no standardized consensus yet.

Yes, not necessarily trying to say this should be a standardized approach—I'm just posting this to fido-dev. I'm just saying this is an issue I identified, this is how I addressed this issue for my implementation, and here is another example how I would address it in other circumstances. The most standardized I could imagine this approach being is just a set of suggestions.

This is against multiple requests during intended use. NFC blockers exist and should be used.

NFC blockers are not available for all form factors: specifically rings, key fobs, and implants. In the cases where you could fashion some sort of RFID blocking solution it would seriously effect usability. In my case (rings) there is no reasonable way to use an RFID blocker, so having some sort of mitigation strategy for some form factors seems prudent.

 

In the EU we got payment, transport, student cards etc. pp. that could be attacked as well, so people are already buying wallets with NFC shielding or add cards with active blocking functionality.

Super useful for cards. Less so for other form factors.

 

If you put your dollars in a bus on the seat next to you without keeping an eye on them, they might  be gone as well...

I don't think this is a useful analogy. Almost everyone would agree putting money on the bus seat next to you is a bad idea if you want to keep the money. Putting a card in your pocket (the same place you would put your money if you didn't want it quickly stolen) is not an action that most average people would intuitively consider dangerous. I mean, that's why we are getting rid of passwords: human intuition is geared toward thinking in terms of physical security, not electronic security.

All I'm saying is that it may be worthwhile to consider mitigation strategies for destructive actions performed over NFC for certain form factors. Maybe a card needs them less because they are usually held in RFID-blocking wallets. That's a logical, reasonable conclusion you could come to. But that logic doesn't apply to USB/NFC key fobs, or authentication rings, or implants.

-- RQ

[Christian Kahlo]

Hi Robert,

Am So., 29. März 2020 um 04:26 Uhr schrieb Robert Quattlebaum <darco...@gmail.com>:
>> >> NFC FIDO devices are usually smartcards
>> > Is that really true? I would think most NFC FIDO devices would be key fobs. The only NFC FIDO authenticators in a card form factor I see on Amazon are combo cards that support BLE and sport an integrated battery. I know there is SurePass ID, but I've never seen one in the wild, nor seen it offered for sale to consumers.
>> A keyfob with NFC is basically a smartcard.
> I try to avoid calling things that aren't actually cards "smart cards", it gets especially confusing when the conversation also includes form factors. Form factor makes a huge difference in how practical and robust adding a button would be. I call the chips in smart cards "secure elements". I fill like this language makes intent more clear.

Your wording, your meaning. Other people - esp. standards papers, other wording, other meaning.
If you mean a "form factor" call it "form factor". Even smartcards don't have the ID-1 form factor all the time,

think of ID-2 in passports and there are also "half-sized" ID-1.

"secure elements" are mostly meant to be (embedded) chips. (in my world)

> Taking a step back: The reason I mentioned it was because I was curious if there was something I was missing. If the most common type of FIDO NFC tokens were (actual) smart cards then there must have been something I was missing, or the market outside of the US must look a lot different. Either way I figured I would want to know more.

US market is different indeed. US consumer behaviour is different, product acceptance of users is different.

>> We're deploying lots of NFC-only smartcards with FIDO for use with Android or Win10 + NFC readers.
> As actual cards? Or as some other form factor? Are they (going to be) available for consumers to buy, or are they being sold to institutional buyers only? I'm curious.

As ID-1 cards and as "keyfobs" as they are used in public transport. Basically you can buy those cards and

different form factors (as well as different non-Java chips, EEPROM sizes) but not with this firmware completion.

We issued some hundred of them at security conferences and in several hack-spaces since 2017.

Indeed we started it as an eye catcher for a con.

>> Managed environments like FIDESMO could allow management commands only over GP secured channels. I.e. reset, initialize, etc. (regarding your medium article this is also an option for OATH and any other application)
> Indeed it would be! I'd consider that in the category of "some other authentication". I think it's a great idea, although with Fidesmo specifically you can simply uninstall and reinstall the app to the same effect.

May be you want to unblock your PIN without losing all your data. This is a valid use-case too.
But there are more managed environments. Think of (embedded) UICCs, their Trust Service Providers,
public transport, logical and physical access control systems for enterprises, etc.

>> > If the authenticator is NFC-only, then add a significant (10+second) delay for each PIN attempt after PIN attempt 3, perhaps doubling in length after each attempt. Also require a significant delay for attempting a reset (45+seconds). This should make it significantly more difficult to perform such a denial of service attack because the attack would need to keep their reader in place for an extended period of time (and likely be noticed in the process).
>> How to count systicks? With proprietary APIs you can set the frequency of the CPU and implement a counter. Gemalto/THALES did something similar in the Smart Guardian (USB stick with flash and smartcard).
> In the absence of any timing APIs, I implemented it as a for loop that does busy work a certain number of times. The number of iterations is calibrated to the hardware it is running on. No fancy NDA'd APIs are required. You do have to calibrate it for each secure element model, but that's a straightforward process that can be easily automated to happen at personalization.

These variants exist already and as you mention they are not portable without measurements and modifications.
Modern chips have power management, possibly dependent from available external energy. This will affect your
clock frequency. At least in the NXP chips we're using.

The "it works for me" approach doesn't scale for standards bodies like FIDO Alliance. As we've seen with the
Ledger applet.

>> This is implementation dependent. And yes some implementations already
>> improved this processes, but there is no standardized consensus yet.
> Yes, not necessarily trying to say this should be a standardized approach—I'm just posting this to fido-dev. I'm just saying this is an issue I identified, this is how I addressed this issue for my implementation, and here is another example how I would address it in other circumstances. The most standardized I could imagine this approach being is just a set of suggestions.

Thanks a lot for your input. Those thoughts are recurring and a new perspective might change the
way to handle them.

>> This is against multiple requests during intended use. NFC blockers exist and should be used.
> NFC blockers are not available for all form factors: specifically rings, key fobs, and implants. In the cases where you could fashion some sort of RFID blocking solution it would seriously effect usability. In my case (rings) there is no reasonable way to use an RFID blocker, so having some sort of mitigation strategy for some form factors seems prudent.

Esp. rings and implants should use some kind of secure management functionality and not left "open".
Global Platform enables applications to utilize a secure communication path for PIN resets, re-initializations, etc.

(As another example from Ledger: the Ledger nano-s / nano-x integrates a) PIN verification, b) PIN blocking

after 3 attempts, c) device deletion, d) device recovery. It doesn't need FIDO2 (or GP) to make things more secure.)

On the other side you should notice some prankster fumbling around with your ring. Unless you're i.e. unconscious

or lost your ring. FIDO tried already to make things more secure with FIDO2, but some parts are left up to the token

implementers at the moment.

>> In the EU we got payment, transport, student cards etc. pp. that could be attacked as well, so people are already buying wallets with NFC shielding or add cards with active blocking functionality.
> Super useful for cards. Less so for other form factors.

Yay, you need to define the attack scenario (unconscious/lost = every form factor is at risk, going by public transport =

user should keep an eye on his stuff - esp. if the user wants comfort on the other hand), because comfort vs. security.

>> If you put your dollars in a bus on the seat next to you without keeping an eye on them, they might  be gone as well...
> I don't think this is a useful analogy. Almost everyone would agree putting money on the bus seat next to you is a bad idea if you want to keep the money. Putting a card in your pocket (the same place you would put your money if you didn't want it quickly stolen) is not an action that most average people would intuitively consider dangerous. I mean, that's why we are getting rid of passwords: human intuition is geared toward thinking in terms of physical security, not electronic security.

We had the discussion already for a couple of years in the EU since contactless payment with cards is well

established due to EMV. People who don't want to take the risk can disable the contactless feature. I wrote

the first Android app back in these days to demonstrate how to attack the "ec"-card in public >7 years ago.

People are super skeptical about implants and rings here. Some buy those rings, some build rings for fun,

this isn't new - but every time also as nothing more than just a toy without any risk. Except it breaks.

I asked a friend, Tesla model 3 owner by himself. He leads the security team of one our largest banks here.

I forwarded him your medium article. He laughed, says it's fun but was super scary when I asked "lets try it?".

> All I'm saying is that it may be worthwhile to consider mitigation strategies for destructive actions performed over NFC for certain form factors. Maybe a card needs them less because they are usually held in RFID-blocking wallets. That's a logical, reasonable conclusion you could come to. But that logic doesn't apply to USB/NFC key fobs, or authentication rings, or implants.

Every device and every form factor has its peculiarities and we're still learning which form factors are used

out there since technology has moved forward rapidly since the last 6 years, use cases changed (see crypto

currencies and their impact on hardware tokens), requirements change, etc. It's the same with the EU eIDAS

token specification and its predecessor the German national electronic ID. Technology changes, use cases

change over time (>10 years now from beta phase), requirements define life spans of ~10 years and you

need to address a 100 million people.

(one follow-up is i.e. https://www.bundesdruckerei.de/en/Unternehmen/Innovation/Optimos)

While it seemed like a good idea to think about PIN unblocking keys (PUK) and the SO (security officer) role

for FIDO tokens it makes it hard for the average end-user to understand the implications and manage them.

FIDO is "security for the masses" and specifically rings and implants are still a very small subgroup.

From my point of view rings and implants should utilize a managed environment by default. Esp. because

FIDO couldn't handle all use-cases and applications contained on the device. OATH, wallets, access control,

etc. All of these applications need a simple to understand and to handle secure management as well.

We can take such thoughts into consideration and write down recommendations. For some scenarios we

can make them mandatory and include them in a test-suite and flag it as a requirement for certification.

Cheers,

CK

[Thomas Duboucher]

Hi Robert, Christian,

Comments inline

Le 29/03/2020 à 07:25, Christian Kahlo a écrit :
> Hi Robert,
>
> Am So., 29. März 2020 um 04:26 Uhr schrieb Robert Quattlebaum

> <darco...@gmail.com <mailto:darco...@gmail.com>>:

When I mentioned /smartcards/, I really meant ISO 7810 ID-1 cards or
equivalent. You have a visible market of FIDO key fobs on Amazon for
direct buyers. But bear in mind the huge market share of smartcards,
payment cards, public transportation, electronic ID or passport,
corporate badge, etc, and some are already starting shifting to FIDO.

If I remember correctly, ICAO eMRTD requires after a few failed attempts
to solve a proof of work game with increased difficulty/time.

Yet I've never heard on the field of prankster having fun blocking
biometric passports at airports, so maybe this is an unlikely attack.

I'm pretty sure that FIDO for the masses will be mostly platform
authenticators /or/ second factory roaming authenticators.

The pin use cases will be mostly used in managed environment, e.g.
corporate where a SO can reset and setup again a token.

Still, let's see how people will use this technology.

> We can take such thoughts into consideration and write down
> recommendations. For some scenarios we
> can make them mandatory and include them in a test-suite and flag it as
> a requirement for certification.
>
> Cheers,
> CK
>

--
Thomas Duboucher

[Robert Quattlebaum]

Comments inline below. I'm responding

to two people here, so I'm going to prepend

the name intended person before my comment.

Le 29/03/2020 à 07:25, Christian Kahlo a écrit : 

> Hi Robert, 

> 

> Am So., 29. März 2020 um 04:26 Uhr schrieb Robert Quattlebaum 

> <darco...@gmail.com <mailto:darco...@gmail.com>>: 

>>> >> NFC FIDO devices are usually smartcards 

>>> > Is that really true? I would think most NFC FIDO devices would be 

>>> > key fobs. The only NFC FIDO authenticators in a card form factor I see 

>>> > on Amazon are combo cards that support BLE and sport an integrated 

>>> > battery. I know there is SurePass ID, but I've never seen one in the 

>>> > wild, nor seen it offered for sale to consumers. 

>>> A keyfob with NFC is basically a smartcard. 

>> I try to avoid calling things that aren't actually cards "smart 

>> cards", it gets especially confusing when the conversation also includes 

>> form factors. Form factor makes a huge difference in how practical and 

>> robust adding a button would be. I call the chips in smart cards "secure 

>> elements". I fill like this language makes intent more clear. 

> 

> Your wording, your meaning. Other people - esp. standards papers, other 

> wording, other meaning. 

> If you mean a "form factor" call it "form factor". Even smartcards don't 

> have the ID-1 form factor all the time, 

> think of ID-2 in passports and there are also "half-sized" ID-1. 
> "secure elements" are mostly meant to be (embedded) chips. (in my world)

[Re: Christian] I'm glad we clarified though, it's always

more productive to know precisely what each other is

referring to. 

On Sunday, March 29, 2020 at 2:41:47 AM UTC-7, Thomas Duboucher wrote:

>>> We're deploying lots of NFC-only smartcards with FIDO for use with
>>> Android or Win10 + NFC readers.
>> As actual cards? Or as some other form factor? Are they (going to be)
>> available for consumers to buy, or are they being sold to institutional
>> buyers only? I'm curious.
>
> As ID-1 cards and as "keyfobs" as they are used in public transport.
> Basically you can buy those cards and
> different form factors (as well as different non-Java chips, EEPROM
> sizes) but not with this firmware completion.
> We issued some hundred of them at security conferences and in several
> hack-spaces since 2017.
> Indeed we started it as an eye catcher for a con.

When I mentioned /smartcards/, I really meant ISO 7810 ID-1 cards or
equivalent. You have a visible market of FIDO key fobs on Amazon for
direct buyers. But bear in mind the huge market share of smartcards,
payment cards, public transportation, electronic ID or passport,
corporate badge, etc, and some are already starting shifting to FIDO.

[Re: Thomas] Interesting. I hadn't really seriously considered

using FIDO2 for physical access control, but that makes sense.

[Re: Christian] Luckily, this sort of mitigation isn't timing critical.

If it takes longer because the chip isn't fully powered (as would likely

be the case in an attack scenario) that's actually a good thing.

 

> The "it works for me" approach doesn't scale for standards bodies like
> FIDO Alliance. As we've seen with the Ledger applet.

[Re: Christian] I agree, which is why I'm not suggesting a

one-size-fits-all approach be standardized.

If I remember correctly, ICAO eMRTD requires after a few failed attempts
to solve a proof of work game with increased difficulty/time.

[Re: Thomas] That's an interesting approach, but I'm not sure what

concrete benefit it would have over a delay. A delay wouldn't be

dependent on the processing power of the attacker like a proof-of-work

challenge would be. It would also be easier to implement. Maybe they

were concerned about reader hardware having time limits?

 

Yet I've never heard on the field of prankster having fun blocking
biometric passports at airports, so maybe this is an unlikely attack.

[Re: Thomas] At least with US passports, it is significantly more

difficult (but not impossible) to read it when it is closed. This likely

makes such attacks rather impractical in practice. Additionally, if the

passport really is using a steadily increasing proof-of-work challenge,

then the damage that could be caused by such an attack (which

could only be performed for a rather short amount of time) would

be limited. Also, airports tend to be highly monitored, secure areas.

Anyone acting suspiciously would likely be noticed, which likely

further makes such attacks unlikely (at least at an airport).

I'd be more worried about my Yubikey FIDO2 credentials and

OATH codes being reset while attending Defcon or Blackhat.

Those apps can both be reset over NFC in less than a second

on a Yubikey 5. Audacious, yes, but easy to execute and easy

to get away with.

 

>>> This is against multiple requests during intended use. 

>>> NFC blockers exist and should be used.
>> NFC blockers are not available for all form factors: specifically
>> rings, key fobs, and implants. In the cases where you could fashion some
>> sort of RFID blocking solution it would seriously effect usability. In
>> my case (rings) there is no reasonable way to use an RFID blocker, so
>> having some sort of mitigation strategy for some form factors seems prudent.
>
> Esp. rings and implants should use some kind of secure management
> functionality and not left "open".

[Re: Christian] Agreed, except I would also include fobs in that list.

Fobs are often on keychains, which are often in pockets—which is just

as easy (if not easier) to clandestinely interact with as ring being worn

on a finger.

 

> Global Platform enables applications to utilize a secure communication
> path for PIN resets, re-initializations, etc.
>
> (As another example from Ledger: the Ledger nano-s / nano-x integrates
> a) PIN verification, b) PIN blocking
> after 3 attempts, c) device deletion, d) device recovery. It doesn't
> need FIDO2 (or GP) to make things more secure.)

[Re: Christian] Neither the nano-s nor nano-x support NFC, so I'm

a little confused as to what specifically you are suggesting.

I keep getting the impression that you think I'm asking for the

specific behavior I described to be mandated/standardized.

I really wasn't.

But since it keeps coming up, here is a suggestion for language

that might be helpful to add to the standard:

"Authenticators are discouraged from allowing 

unauthenticated NFC sessions to perform permanent, 

irreversibly destructive actions instantaneously, 

except when an additional physical interaction is 

necessary to assert user presence (such as removing 

a RFID shield or pressing a button)."

It could use some refinement and elaboration, but truthfully I

have no expectations of such an addition and I have no

intention of making an extended effort of trying to convince

anyone that it is a good idea. It's either obvious or it's not.

If not, that's OK, happy to move on.

 

> On the other side you should notice some prankster fumbling around with
> your ring. Unless you're i.e. unconscious or lost your ring.

[Re: Christian] Yep! This is why I like the idea of a ring

more than a key fob. Key fobs are easier to lose. I don't

always know where mine is. But I will always know where

my ring is, or if it is lost.

  

> FIDO tried already to make things more secure with FIDO2, 

> but some parts are left up to the token 

> implementers at the moment.

[Re: Christian] For what it's worth, the typical FIDO U2F

authenticator implementation is immutable, and as a result

already satisfies the language I described above. So at

least in that sense, the typical FIDO2 authenticator implementation

(supporting PINs and reset) feels less secure unless it

implements some sort of mitigation.

 

> Yay, you need to define the attack scenario (unconscious/lost = every
> form factor is at risk, going by public transport =
> user should keep an eye on his stuff - esp. if the user wants comfort on
> the other hand), because comfort vs. security.

[Re: Christian] I absolutely agree. I'm covering this in detail in

my next Medium article.

  

> People are super skeptical about implants and rings here.

[Re: Christian] Same here in the US, if not more so.

 

> Some buy those rings, some build rings for fun, this 

> isn't new - but every time also as nothing more than just a toy
> without any risk.

[Re: Christian] What would make something not a toy?

 

> Except it breaks.

[Re: Christian] Anything can break. Build quality will

always vary between manufacturers. Some things will

break more often, others less. Rings are no different.

 

> I asked a friend, Tesla model 3 owner by himself. 

> He leads the security team of one our largest banks here.
> I forwarded him your medium article. He laughed, says 

> it's fun but was super scary when I asked "lets try it?".

[Re: Christian] I would love to hear more. What was his

concerns? What are yours? Perhaps getting off-topic,

though, but I'd love to hear more if you care to reach out

directly.

 

>> All I'm saying is that it may be worthwhile to consider mitigation
>> strategies for destructive actions performed over NFC for certain form
>> factors. Maybe a card needs them less because they are usually held in
>> RFID-blocking wallets. That's a logical, reasonable conclusion you could
>> come to. But that logic doesn't apply to USB/NFC key fobs, or
>> authentication rings, or implants.
>
> Every device and every form factor has its peculiarities and we're still
> learning which form factors are used
> out there since technology has moved forward rapidly since the last 6
> years, use cases changed (see crypto
> currencies and their impact on hardware tokens), requirements change,
> etc. It's the same with the EU eIDAS
> token specification and its predecessor the German national electronic
> ID. Technology changes, use cases
> change over time (>10 years now from beta phase), requirements define
> life spans of ~10 years and you
> need to address a 100 million people.
>
> (one follow-up is
> i.e. https://www.bundesdruckerei.de/en/Unternehmen/Innovation/Optimos)
>
> While it seemed like a good idea to think about PIN unblocking keys
> (PUK) and the SO (security officer) role
> for FIDO tokens it makes it hard for the average end-user to understand
> the implications and manage them.

[Re: Christian] 100% agree. Better to leave these details

to the implementors.

 

> FIDO is "security for the masses" and specifically rings and implants
> are still a very small subgroup.

> From my point of view rings and implants should utilize a managed
> environment by default. Esp. because
> FIDO couldn't handle all use-cases and applications contained on the
> device. OATH, wallets, access control, 

> etc. All of these applications need a simple to understand and to handle
> secure management as well.

[Re: Christian] But NFC-capable fobs, which are not a small

subgroup, have the same challenges. Why would your logic

not apply to fobs?

I'm pretty sure that FIDO for the masses will be mostly platform
authenticators /or/ second factory roaming authenticators.

[Re: Thomas] Interesting. Not "and"?

The pin use cases will be mostly used in managed environment, e.g.
corporate where a SO can reset and setup again a token.

[Re: Thomas] I personally don't see this being the case.

Yubico's dedicated FIDO2 Security Keys support PINs for

user verification and have no SO or PUK. You can wipe

them clean with a practically instantaneous NFC swipe.

I bet other NFC FIDO2 implementations are similar, because

the existing language in the standard doesn't appear to

give a lot of room for interpretation. 8 pin retries max, after

which the token is locked:

Once the retries counter reaches 0, the authenticator has to be reset before any further operations can happen that require a PIN.

That's from the CTAP spec, section 5.5.1. It doesn't appear

to give a lot of room for interpretation. Granted, it uses the

wishy-washy "has to" instead of "MUST" or "SHOULD". But

still, it isn't at all clear that this is intended for managed

environments as you imply. This is being implemented on

consumer roaming authenticators, I assume largely because

this is the only way to assert user verification without

expensive things like biometrics or a keypad.

 

-- RQ

[Thomas Duboucher]

I'm going to answer only some remarks then, else it will become too
difficult to follow. :)

Le 30/03/2020 à 01:01, Robert Quattlebaum a écrit :
> >>> We're deploying lots of NFC-only smartcards with FIDO for use with
> >>> Android or Win10 + NFC readers.
> >> As actual cards? Or as some other form factor? Are they (going to
> be)
> >> available for consumers to buy, or are they being sold to
> institutional
> >> buyers only? I'm curious.
> >
> > As ID-1 cards and as "keyfobs" as they are used in public transport.
> > Basically you can buy those cards and
> > different form factors (as well as different non-Java chips, EEPROM
> > sizes) but not with this firmware completion.
> > We issued some hundred of them at security conferences and in several
> > hack-spaces since 2017.
> > Indeed we started it as an eye catcher for a con.
>
> When I mentioned /smartcards/, I really meant ISO 7810 ID-1 cards or
> equivalent. You have a visible market of FIDO key fobs on Amazon for
> direct buyers. But bear in mind the huge market share of smartcards,
> payment cards, public transportation, electronic ID or passport,
> corporate badge, etc, and some are already starting shifting to FIDO.
>
>

> *[Re: Thomas] *Interesting. I hadn't really seriously considered

> using FIDO2 for physical access control, but that makes sense.
>  

Not FIDO2 for access control, even though some companies are working on
it. I was more thinking of multi-application ISO 7816 smartcards, e.g.
corporate badge with DESFire V2 for access control and coffee machine,
EMV purse for company food court, PIV for PKI and FIDO for authentication.

>
> If I remember correctly, ICAO eMRTD requires after a few failed
> attempts
> to solve a proof of work game with increased difficulty/time.
>
>

> *[Re: Thomas] *That's an interesting approach, but I'm not sure what

> concrete benefit it would have over a delay. A delay wouldn't be
> dependent on the processing power of the attacker like a proof-of-work
> challenge would be. It would also be easier to implement. Maybe they
> were concerned about reader hardware having time limits?
>  

Clocks are easy to attack using fault-injections. This kind of games can
be hardened against fault-injection and requires little computing power
from the smartcard, leaving all the burden to the attacker. A genuine
reader won't have to do the game since they aren't brute-forcing.

>
> Yet I've never heard on the field of prankster having fun blocking
> biometric passports at airports, so maybe this is an unlikely attack.
>
>

> *[Re: Thomas] *At least with US passports, it is significantly more

> difficult (but not impossible) to read it when it is closed. This likely
> makes such attacks rather impractical in practice. Additionally, if the
> passport really is using a steadily increasing proof-of-work challenge,
> then the damage that could be caused by such an attack (which
> could only be performed for a rather short amount of time) would
> be limited. Also, airports tend to be highly monitored, secure areas.
> Anyone acting suspiciously would likely be noticed, which likely
> further makes such attacks unlikely (at least at an airport).
>

Every e-passports are using the same standards, whichever country they
are from, which is ICAO eMRTD. Even though some are more up-to-date,
e.g. from BAC to PACE+EACv2. Reading any e-passport requires first to
prove that you can read the MRZ on the first page, which means that the
passport is open and you can perform an optical read. And what you can
read electronically is the - authenticated - content of the MRZ.

Else you're left with brute-forcing as discussed earlier. :)

>
> I'm pretty sure that FIDO for the masses will be mostly platform
> authenticators /or/ second factory roaming authenticators.
>
>

> *[Re: Thomas] *Interesting. Not "and"?
>

Sorry, "or" in French is inclusive. :o)

What I have in mind is that FIDO for the masses will be:
- Windows Hello when login to Google or Amazon, and
- using a token provided by e.g. your bank to login on your bank account.

I'm not sure that people will actually *buy* a FIDO token.

> The pin use cases will be mostly used in managed environment, e.g.
> corporate where a SO can reset and setup again a token.
>
>

> *[Re: Thomas] *I personally don't see this being the case.

> Yubico's dedicated FIDO2 Security Keys support PINs for
> user verification and have no SO or PUK. You can wipe
> them clean with a practically instantaneous NFC swipe.
> I bet other NFC FIDO2 implementations are similar, because
> the existing language in the standard doesn't appear to
> give a lot of room for interpretation. 8 pin retries max, after
> which the token is locked:
>

Yes, you can wipe a FIDO token with a few seconds of physical access.
But then you can also block any EMV application, or the Card Manager, or
the PIV application. Or you can attempt to use the FIDO token to login.
So in any case, you need a little bit of physical security.

That being said, I'm thinking that it should be possible to require a
small proof-of-work for resetting a token over NFC to prevent those kind
of attacks, but I don't think it is really necessary outside of pranksters.

For now, the only kind of security we have is a big warning from Win10
that you are going to do something really bad, and you should think -
and tap, twice.

Best regards,

--
Thomas Duboucher