Is it mandatory for a U2F authenticator to support 'extended APDU' format?

[Yoo Byeongcheol]

I'm trying to develop a U2F authenticator using NFC protocol based on a java card.

As far as I know, there are few smart cards that support extended APDU in the market.

And many smart cards don't support extended APDU format yet and neither does my java card.

I read this statement that "In this current version of U2F, the framing is defined based on the ISO7816-4:2005 extended APDU format" in the U2F raw message formats specification.

And I also found this this algorithm below in the U2F NFC protocol specification.

case 1 : If the request was of extended length (i.e., had 3 length bytes), the authenticator MUST respond using the extended length APDU format.

case 2 : If the request was not of extended length (i.e., had 1 length byte), the authenticator MUST respond using ISO 7816-4 APDU chaining.

And I'm wondering if it is mandatory for a U2F authenticator to support extended APDU.

or is it possible that my U2F authenticator just uses short APDU format (using GET Response method) instead of extended APDU?

I think maybe it's possible if the U2F client notices that a U2F authenticator doens't support extended APDU via ATR(answer to reset) from a smart card and sends command APDUs in short APDU format.

please help me find out a way to apply my old java card to FIDO U2F protocol.

Thanks.

[Thomas Duboucher]

Hi,

Sorry for not answering this one earlier,

Le 14/07/2016 à 08:14, Yoo Byeongcheol a écrit :
> I'm trying to develop a U2F authenticator using NFC protocol based on a
> java card.
> As far as I know, there are few smart cards that support extended APDU
> in the market.
> And many smart cards don't support extended APDU format yet and neither
> does my java card.
>
> I read this statement that "In this current version of U2F, the framing

> is defined based on the ISO7816-4:2005*extended APDU format*" in the U2F

> raw message formats specification.
>
> And I also found this this algorithm below in the U2F NFC protocol
> specification.
>
> case 1 : If the request was of extended length (i.e., had 3 length
> bytes), the authenticator MUST respond using the extended length APDU
> format.
> case 2 : If the request was not of extended length (i.e., had 1 length
> byte), the authenticator MUST respond using ISO 7816-4 APDU chaining.
>
> And I'm wondering if it is mandatory for a U2F authenticator to support
> extended APDU.
> or is it possible that my U2F authenticator just uses short APDU format
> (using GET Response method) instead of extended APDU?
>

The wording implies it is mandatory to support both.

Currently the Google Authenticator only uses ISO 7816-4 chaining.

> I think maybe it's possible if the U2F client notices that a U2F
> authenticator doens't support extended APDU via ATR(answer to reset)
> from a smart card and sends command APDUs in short APDU format.
>

Contactless smartcard do not have an ATR. You could parse the historical
bytes if present in the ATS of Type A cards, but that won't give you
much info. Type B cards do not return their historical bytes in the
protocol layer.

> please help me find out a way to apply my old java card to FIDO U2F
> protocol.
>
> Thanks.
>

Best regards,

--
Thomas Duboucher

[Fred Le Tamanoir]

1 - Yes, extended APDU support is mandatory, your Java Card is probably really old if not compatible

2 - If you consider using recent Java Cards, you can try/use this already certified U2F/NFC Java Card implementation : https://github.com/LedgerHQ/ledger-u2f-javacard

Bye

--

Frederic

--
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 post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/fbda6b0d-24f9-4942-9359-e03339b6e0f7%40fidoalliance.org.

[Yoo Byeongcheol]

Thanks Thomas for the reply.

I have a question about your answer.

you said "Currently the Google Authenticator only uses ISO 7816-4 chaining."

And I'm trying 'U2F Transport Layer Testing' as part of Conformance Self-Validation Testing.

and it seems that the tool sends Command APDUs in both short and extended APDU formats in turn, which makes my java card respond with error codes (SW_WRONG_LENGTH, '6700') since my java card doesn't support extended APDUs.

And if the Google Authenticator only uses ISO 7816-4 chaining method (which is only for short APDUs), how can this Google Authenticator pass the 'U2F Transport Layer Testing' without supporting extended APDUs?

So does my java card have to support both short and extended APDUs after all?

please help me understand this problem.

Best,

Byeongcheol Yoo

2016년 7월 19일 화요일 오후 7시 15분 56초 UTC+9, Fred Le Tamanoir 님의 말:

[Yoo Byeongcheol]

Thanks Thomas for the reply.

I have a question about your answer.

you said "Currently the Google Authenticator only uses ISO 7816-4 chaining."

And I'm trying 'U2F Transport Layer Testing' as part of Conformance Self-Validation Testing.

and it seems that the tool sends Command APDUs in both short and extended APDU formats in turn, which makes my java card respond with error codes (SW_WRONG_LENGTH, '6700') since my java card doesn't support extended APDUs.

And if the Google Authenticator only uses ISO 7816-4 chaining method (which is only for short APDUs), how can this Google Authenticator pass the 'U2F Transport Layer Testing' without supporting extended APDUs?

So does my java card have to support both short and extended APDUs after all?

please help me understand this problem.

Best,

Byeongcheol Yoo

2016년 7월 19일 화요일 오전 8시 37분 53초 UTC+9, Thomas Duboucher 님의 말:

[Yoo Byeongcheol]

Sorry Frederic for calling you Thomas.

 

I was actually asking both of you and Thomas, and I mixed it up by mistake.

I apologize for that.

But the question I sent with the wrong name was also supposed to be asked to you.

Would you help me please?

Thanks,

Byeongcheol Yoo

[Juan Lang]

Sorry for the confusion! Google Authenticator is not a FIDO U2F Authenticator (we know, the name is confusing!), it's a FIDO U2F Client. According to the FIDO U2F NFC framing specification, the Client gets to choose which format it will use with an Authenticator, and Google Authenticator (again, a Client) always chooses short encoding at this time.

Hope that clears things up.

--Juan

--

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 post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/0e2e3641-4662-4af4-bb1b-86adce6e5d5a%40fidoalliance.org.

[Arshad Noor]

Why not just rename it, Juan? People who come in after this thread
tapers off are going to get confused all over again; better to fix the
problem at the source once and for all.

Arshad

[Juan Lang]

There's branding around that name, and our use of Authenticator precedes the fido alliance's existence ;)

--
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 post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/578FB98F.5000907%40strongauth.com.

[Alexei Czeskis]

What Juan said,

Also, at this point, we don't foresee Google Authenticator being the permanent home for FIDO functionality on Android.

Thanks!

-Alexei

________________

 . Alexei Czeskis .:. Securineer .:. 317.698.4740 .

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAN4h8Jaewpp%2BpHnJ2Cqj6%3DxCtOf63Mo7R74tFV%3DK4oasvd5Sqw%40mail.gmail.com.

[Thomas Duboucher]

Le 20/07/2016 à 20:04, 'Alexei Czeskis' via FIDO Dev (fido-dev) a écrit :
> What Juan said,
>
> Also, at this point, we don't foresee Google Authenticator being the
> permanent home for FIDO functionality on Android.
>

You can't tease us without saying a little bit more!

While we are at it, there is a fully working implementation of U2F over
BLE in the current Google Authenticator, but I haven't found out how to
use it yet. Is it available, or is it currently just some dead code
lying around?

[Fred Le Tamanoir]

>> Also, at this point, we don't foresee Google Authenticator being the
>> permanent home for FIDO functionality on Android.
>>
>You can't tease us without saying a little bit more!

It is not a secret: in the future, U2F support will be built-in inside Chrome for Android (that won't need Google Authenticator anymore)

BLE support inside recent public and/or private releases of Google Authenticator already works with few prototypes that are currently being developped/certified. With the same FIDO U2F server, we'll soon be able to accept users from desktops/laptops (USB) and mobile platforms (NFC/BLE).

--

Frédéric MARTIN
Security Architect

NEOWAVE

--
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 post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/5cd40361-0d1b-3910-b17b-38924649c5b8%40duboucher.eu.