Add FIDO2Applet to ACardEmulator?

[jo-bitsch]

Expected behaviour

As there are a bunch of included excellent Smartcard applets for cryptographic functions already included, I was wondering, if you might want to add FIDO2Applet as well to ACardEmulator.

It follows the same spirit as the included applets and is a very widely supported standard, used for logging into Websites and systems, and even for disk encryption. I guess, ACardEmulator is really more for experimentation than for production use, but it would give people the chance to see if this technology works for them and play around with it, before buying dedicated devices (e.g. nitrokeys, solokeys or yubikeys)

This applet is already known to work well with jcardsim, so there wouldn't be additional infrastructure required. It's released under an MIT license, so that should be ok as well.

If you are open to the idea, I could prepare a PR myself.

Actual behaviour

not installed

Steps to reproduce

run the following with fido2-tools installed

fido-token -L -d

Logs

$ fido-token -L -d
run_manifest: found 0 hid devices
run_manifest: found 0 nfc devices
copy_info: SCardConnect 0x8010000c
fido_tx: dev=0x647fbcea5500, cmd=0x06
fido_tx: buf=0x647fbcea5500, len=8
0000: aa 6d b0 64 13 ba 76 d7
fido_pcsc_write: writing: buf=0x7ffcb40c44d0, len=14
0000: 00 a4 04 00 08 a0 00 00 06 47 2f 00 01 00
fido_pcsc_write: read: buf=0x647fbce9c390, len=2
0000: 6a 82
fido_rx: dev=0x647fbcea5500, cmd=0x06, ms=-1
fido_pcsc_read: reading: buf=0x647fbce9c390, len=2
0000: 6a 82
rx_init: read
fido_dev_open_rx: fido_rx
nfc_is_fido: fido_dev_open: 0xfffffffe
copy_info: nfc_is_fido: pcsc://slot1
run_manifest: found 0 pcsc devices

[frankmorgner]

Yes, that should be possible, feel free to create a PR. If I understand correctly, the the AID 0xA0, 0x00, 0x00, 0x06, 0x47, 0x2F, 0x00, 0x01 is always used to SELECT the FIDO2Applet so it doesn't even need to be default selected, right?

In your log, what's the purpose of this command?

0000: aa 6d b0 64 13 ba 76 d7

[dengert]

Yubikey can have a FIDO applet, PIV applet and OpenPGP applet. So the selected applet may not be the FIDO applet.
Yubico docs talk about PIV and OpenPGP as "CCID" applets but it looks like FIDO uses PCSC too.

[jo-bitsch]

Your understanding is correct. Selecting the AID is always the first step, so this does definitely not need to be the default selected applet.

For the log, I was just posting the output from fido2-token -L -d (list available tokens and show debug information). The SELECT APDU is the only APDU that actually got send. The other part is an implementation detail of the ctap2 protocol that gets encapsulated into APDUs after the applet got selected.

NB: fido2-tools does support access to NFC based tokens in two separate ways:

1. Via the Linux NFC subystem (that's the log line run_manifest: found 0 nfc devices.
2. Via PCSC (which is rather new in the implementation, actually)

In my particular setup, I blacklisted my NFC reader from the native Linux NFC subsystem, so that I can communicate via PCSC, as the software support for other smartcard related stuff is much better via PCSC right now. There are some projects like https://github.com/jurajsarinay/ifdnlnfc that make the native system available also via NFC, but this is not yet properly packaged for Ubuntu, so this was easier for now.

As for "CCID" applet. Yubikeys appear as a USB card readers following the CCID protocol spec, so the default libccid driver can handle communication. Technically, via USB, the CTAP2 protocol of Fido uses its own HID based protocol and the card reader interface is exposed to support the other applets such as PIV and OpenPGP. Via NFC, yubikeys also use the APDU transport for CTAP2/FIDO2.

I will give it a try to prepare a PR.

[dengert]

fido_pcsc_write: writing: buf=0x7ffcb40c44d0, len=14
0000: 00 a4 04 00 08 a0 00 00 06 47 2f 00 01 00
fido_pcsc_write: read: buf=0x647fbce9c390, len=2
0000: 6a 82

in the above, 6a 82 is "file not found" which is not what SELECT FILE for a valid AID should return.
I can get the same response using Ybikey 5 NFC using USB with FIDO and OpenPGP interfaces enabled via Yubikey Manager.

opensc-tool -c default -s "00 a4 04 00 08 a0 00 00 06 47 2f 00 01 00
Using reader with a card: Yubico YubiKey FIDO+CCID 00 00
Sending: 00 A4 04 00 08 A0 00 00 06 47 2F 00 01 00 
Received (SW1=0x6A, SW2=0x82)

https://www.eftlab.com/knowledge-base/complete-list-of-application-identifiers-aid

[jo-bitsch]

Well, the log output I sent, was the current output with the FIDO2 Applet not installed in ACardEmulator. So 6A 82 would actually be expected.

As for a Yubikeys connected via USB:
The output from fido2-token is:

$ fido2-token -L -d
run_manifest: found 1 hid device
run_manifest: found 0 nfc devices
copy_info: SCardConnect 0x8010000c
copy_info: SCardConnect 0x8010000c
fido_tx: dev=0x5e0b6610fab0, cmd=0x06
fido_tx: buf=0x5e0b6610fab0, len=8
0000: 9a 5a 31 2a a1 53 45 63
fido_pcsc_write: writing: buf=0x7fffac0b0b60, len=14
0000: 00 a4 04 00 08 a0 00 00 06 47 2f 00 01 00
fido_pcsc_write: read: buf=0x5e0b660f20a0, len=2
0000: 6a 82
fido_rx: dev=0x5e0b6610fab0, cmd=0x06, ms=-1
fido_pcsc_read: reading: buf=0x5e0b660f20a0, len=2
0000: 6a 82
rx_init: read
fido_dev_open_rx: fido_rx
nfc_is_fido: fido_dev_open: 0xfffffffe
copy_info: nfc_is_fido: pcsc://slot2
run_manifest: found 0 pcsc devices
/dev/hidraw5: vendor=0x1050, product=0x0407 (Yubico YubiKey OTP+FIDO+CCID)

Explanation:
The Yubikey was found as a HID device (that's the first line). Specification of the HID protocol

via the integrated USB card reader interface, it was not found, as Yubikeys are programmed to make FIDO2 available only via the dedicated HID-based protocol.

However, now via the NFC interface (not USB but an external NFC reader to which I hold the Yubikey):

$ opensc-tool -c default -s "00 a4 04 00 08 a0 00 00 06 47 2f 00 01 00"
Using reader with a card: ACS ACR122U PICC Interface 01 00
Sending: 00 A4 04 00 08 A0 00 00 06 47 2F 00 01 00 
Received (SW1=0x90, SW2=0x00):
55 32 46 5F 56 32 U2F_V2

and fido2-token:

$ fido2-token -L -d
run_manifest: found 0 hid devices
run_manifest: found 0 nfc devices
copy_info: SCardConnect 0x8010000c
fido_tx: dev=0x5ecaf3247500, cmd=0x06
fido_tx: buf=0x5ecaf3247500, len=8
0000: 5c 39 7a 1f 7f a1 56 4f
fido_pcsc_write: writing: buf=0x7fff1c3708b0, len=14
0000: 00 a4 04 00 08 a0 00 00 06 47 2f 00 01 00
fido_pcsc_write: read: buf=0x5ecaf323e390, len=8
0000: 55 32 46 5f 56 32 90 00
fido_rx: dev=0x5ecaf3247500, cmd=0x06, ms=-1
fido_pcsc_read: reading: buf=0x5ecaf323e390, len=8
0000: 55 32 46 5f 56 32 90 00
fido_dev_get_cbor_info_tx: dev=0x5ecaf3247500
fido_tx: dev=0x5ecaf3247500, cmd=0x10
fido_tx: buf=0x7fff1c370b17, len=1
0000: 04
fido_pcsc_write: writing: buf=0x7fff1c370840, len=7
0000: 80 10 00 00 01 04 00
fido_pcsc_write: read: buf=0x5ecaf323e390, len=88
0000: 00 a6 01 82 66 55 32 46 5f 56 32 68 46 49 44 4f
0016: 5f 32 5f 30 02 81 6b 68 6d 61 63 2d 73 65 63 72
0032: 65 74 03 50 fa 2b 99 dc 9e 39 42 57 8f 92 4a 30
0048: d2 3c 41 18 04 a4 62 72 6b f5 62 75 70 f5 64 70
0064: 6c 61 74 f4 69 63 6c 69 65 6e 74 50 69 6e f5 05
0080: 19 04 b0 06 81 01 90 00
fido_dev_get_cbor_info_rx: dev=0x5ecaf3247500, ci=0x5ecaf323e0b0, ms=-1
fido_rx: dev=0x5ecaf3247500, cmd=0x10, ms=-1
fido_pcsc_read: reading: buf=0x5ecaf323e390, len=88
0000: 00 a6 01 82 66 55 32 46 5f 56 32 68 46 49 44 4f
0016: 5f 32 5f 30 02 81 6b 68 6d 61 63 2d 73 65 63 72
0032: 65 74 03 50 fa 2b 99 dc 9e 39 42 57 8f 92 4a 30
0048: d2 3c 41 18 04 a4 62 72 6b f5 62 75 70 f5 64 70
0064: 6c 61 74 f4 69 63 6c 69 65 6e 74 50 69 6e f5 05
0080: 19 04 b0 06 81 01 90 00
fido_dev_open_rx: FIDO_MAXMSG=2048, maxmsgsiz=1200
run_manifest: found 1 pcsc device
pcsc://slot1: vendor=0x0000, product=0x0000 (PC/SC ACS ACR122U PICC Interface 01 00)

Specification of the APDU protocol

[dengert]

OK, thanks for the info.
In iso7816-4 The leading 0x80 in the APDU commands say it is vendor "proprietary class" APDU. The SELECT FILE 00 a4 04 00` with an AID is standard.

[jo-bitsch]

you are absolutely right about the 0x80 for the later calls being proprietary class, but that is exactly the specification of the FIDO2 NFC command framing spec