bryanjacobs / fido2applet Goto Github PK

Same as #21 .

Test successful: Tests if a PIN auth is rejected without a PIN set in MakeCredential. (id: make_credential_pin_auth_no_pin)
Expected error code `CTAP2_ERR_PIN_NOT_SET`, got `CTAP2_ERR_PIN_AUTH_INVALID`.

INFO:ctap:Received initialization packet
INFO:keep_alive:Start keep-alive called
INFO:bridge:Transmitting CTAP command: AUTHN_MakeCredential
DEBUG:bridge:CBOR command payload: {
  "1": "h'cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd",
  "2": {
    "id": "make_credential_pin_auth_no_pin.example.com"
  },
  "3": {
    "id": "h'1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d",
    "name": "Adam"
  },
  "4": [
    {
      "alg": -7,
      "type": "public-key"
    }
  ],
  "8": "h'9a9a9a9a9a9a9a9a9a9a9a9a9a9a9a9a",
  "9": 1
}
INFO:bridge:CTAP command requires user presence, sending 'waiting for acknowledgment' status
INFO:bridge:APDU command: 189 bytes data
DEBUG:bridge:APDU command: DATA=801000000000b401a6015820cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd02a1626964782b6d616b655f63726564656e7469616c5f70696e5f617574685f6e6f5f70696e2e6578616d706c652e636f6d03a262696458201d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d646e616d65644164616d0481a263616c672664747970656a7075626c69632d6b657908509a9a9a9a9a9a9a9a9a9a9a9a9a9a9a9a09010000
INFO:bridge:APDU response: SW1=0x90, SW2=0x0, 1 bytes data
DEBUG:bridge:APDU response: DATA=33
ERROR:bridge:CTAP error: CTAP_STATUS_CODE.CTAP2_ERR_PIN_AUTH_INVALID
ERROR:ctap.auth:Exception from authenticator: CTAP error response from authenticator
INFO:bridge:Signaling external card reset
INFO:bridge:Disconnecting from card
INFO:bridge:Event: Card disconnected

Hello

Could it be possible to provide APDU logs for cred protect test cases (JAVACARD APDUS for command response).

I am trying to run test cases on windows but there are a lot of issues I am facing , and availability of APDU logs for cred protect extension use cases will help a lot.

Hey Bryan,

I'm trying to test your project through https://webauthn.io/, and I managed to do the "register" by adding the lines below to the build.gradle and executing "gradlew runVSim".

task runVSim(type: JavaExec) { classpath = sourceSets.test.runtimeClasspath main = 'us.q3q.fido2.VSim' }

My problem is that to execute the "Authenticate," I need to close and rerun the VSim class, and this causes the WebAuthN registration data to be lost.

Do you know how I can conduct this test? Is there a way to persist the data?

Thank you!

Hi Bryan,

I'm encountering an issue while trying to use the applet within a web application on Chrome for Android. I consistently receive the following error message:

"An unknown error occurred while talking to the credential manager."

Interestingly, the applet works correctly both in the emulator and on Chrome for Windows (when using a USB NFC reader). The problem seems to be isolated to Android devices.

I was able to replicate the same error on the FIDO page:
https://demo.yubico.com/webauthn-technical

Do you have any idea what might be causing this problem?

https://github.com/BryanJacobs/FIDO2Applet/blob/main/docs/security.md?plain=1#L111

The MITM traffic can just get the 16-bytes with ECDH's shared-secret still, I think this treat should be belong to malware or compromised client parts.

How is user presence handled?

I suggest to implement user presence, as this improves security and compatibility a lot. Since the card is NFC, I suggest to allow one user interaction per power cycle, and use that "NFC tap" as a user presence indicator.

See also the specification (https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#sctn-terminology) at §5:

For authenticators without a method to collect a user gesture inside the authenticator boundary other than through a power on gesture, the act of a user placing an NFC authenticator into the NFC reader’s field is considered a user gesture that establishes user presence and provides evidence of user interaction.

For CI testing, this behavior should be able to be turned off (i.e. "user is always present") via an install parameter option.

when i execute FIDO Conformance Tools v1.7.18, i see lot of errors, i am investigating it. Let me know if this is any known issue?

First of all, thank you for this project – this is amazing!

Something I'm having trouble wrapping my head around after reading the documentation (specifically the point on CTAP 2.1 hmac-secret compliance) and peeking at the code:

Does "Implemented with one secret (requiring UV) not two" mean that hmac-secret will only work when a PIN is provided during get() (and will reject either the extension or the entire get() operation otherwise)? Or will it just derive the same secret whether or not a PIN is provided during get()?

If the optional "transports" key is set in on of the PublicKeyCredentialDescriptors in the allowList of authenticatorGetAssertion , the consumeMapAndGetID fails.

Stacktrace:

FIDO2Applet.consumeMapAndGetID(APDU,byte[],short,short,boolean,boolean,boolean,boolean) (FIDO2Applet.java:3401)
FIDO2Applet.getAssertion(APDU,short,byte[],short) (FIDO2Applet.java:2134)
FIDO2Applet.process(APDU) (FIDO2Applet.java:3646)

Example CBOR:

{
    1: "demo.yubico.com",
    2: h'f30fe8c6c1d50a207511523fa63402c144de5d981a340b9e8cd88db6af8c3312',
    3: [
        {
            "id": h'0847d61f95f2b5fa7743510d61401c3379c4a2cffe8b108cd35be7aba52e991ec759309db9ddc6407c09ddf6dba3e189ef0e0ee617c0f9d98c24ee6676b11a773fc52955a836d423df2ae4a5c4d1e7761632a01316c821ca5213f2ef922649ea010a7b7a3f9daae4de28da44160c9cff',
            "type": "public-key",
            "transports": ["usb", "ble", "nfc", "usb", "internal"],
        },
    ],
    5: {},
}

This request was sent by the MicroG FIDO2 service, via Google Chrome and demo.yubico.com.

The private key of the attestation certificate (S) is currently loaded using the vendor command.

However, in field deployment (e.g. Fidesmo), regular communication channels with the card are not encrypted like the installation session is (via Global Platform).

I have installed FIDO2Applet on real smart card.
But I am not able to run python_tests on the smart card.
I tried following steps on ws2 ubuntu because apparently on windows I cannot start the tests due to some dependency of fnctl library which is not there on windows. So I installed wsl and ubuntu and I am trying to build and run the python_tests.
But I am facing many challenges related to libraries and stuff. Which I am trying to solve but I feel I am still a long way to run the python_tests.

Is it somehow possible on guiding on (I believe I am asking for a lot, but its worth a shot):

1. what configuration/file to change in the project so that I am able to connect to smart card (I am using Gemalto USB smart card reader)
2. in order to run the python_tests on windows, is there any possibility ? to avoid wsl and ubuntu stuff ? if yes then how?
3. Apparently, some compatibility issues are also coming between different python libraries, most resent with pyscard. Is it somehow possible to find which libraries other then mentioned in requirements.txt are requried to execute the tests on windows?

The Google test suite (https://github.com/google/CTAP2-test-tool) found a bug.

According to the CTAP2.1 spec, §6.1 (https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#authenticatorMakeCredential):

Note: [WebAuthn-2] has removed the optional icon member. Authenticators MUST not error if the icon member is present, they may optionally not store this value.

Test output:

Failed test: Tests bad parameters in user parameter of MakeCredential. (id: make_credential_user_entity) - Optional entry icon not recognized.
The failing error code is `CTAP1_ERR_INVALID_PARAMETER`.

Log trace from the bridge:

INFO:bridge:Transmitting CTAP command: AUTHN_MakeCredential
DEBUG:bridge:CBOR command payload: {
  "1": "h'cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd",
  "2": {
    "id": "make_credential_user_entity.example.com"
  },
  "3": {
    "id": "h'1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d",
    "icon": "http://icon.png"
  },
  "4": [
    {
      "alg": -7,
      "type": "public-key"
    }
  ]
}
INFO:bridge:CTAP command requires user presence, sending 'waiting for acknowledgment' status
INFO:bridge:APDU command: 176 bytes data
DEBUG:bridge:APDU command: DATA=801000000000a701a4015820cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd02a162696478276d616b655f63726564656e7469616c5f757365725f656e746974792e6578616d706c652e636f6d03a262696458201d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d6469636f6e6f687474703a2f2f69636f6e2e706e670481a263616c672664747970656a7075626c69632d6b65790000
INFO:bridge:APDU response: SW1=0x90, SW2=0x0, 1 bytes data
DEBUG:bridge:APDU response: DATA=02
ERROR:bridge:CTAP error: CTAP_STATUS_CODE.CTAP1_ERR_INVALID_PARAMETER
ERROR:ctap.auth:Exception from authenticator: CTAP error response from authenticator

Something is very odd with J3H145 cards. One of the cards crashed entirely when I was testing the recent E-APDU fixes. Now I've took another card and loaded the master branch, it exhibits the same crash behavior. Steps to reproduce:

1. Register on https://demo.yubico.com/webauthn-technical/registration , that would create a normal FIDO2 authenticator (not resident credential)
2. Test authenticator on https://demo.yubico.com/webauthn-technical/login for once
3. Repeat step 1
4. Card goes entirely dead

I'm not able to talk to the card neither through contactless nor contact interface, it fails super early (on ISO 14443 selection). This doesn't happen with the exact same CAP file loaded on A40CR card.

For now I'm just dropping a report there, I need to order some more J3H145 cards and check if this is also reproducible.

First, thank you for endless hard work on the FIDO2 applet!

Currently I'm loading the cap to JCOP3 and JCOP4 cards without any issue, and using "aa00f504f50505061820071904000818200918fe0a1904000b1904000e04" for the params to enable attestation.

The issue comes up when running install_attestation_cert.py.

D:\FIDO2Applet>python install_attestation_cert.py Generated CA private key: b'MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgZRlzq/r/3zddxdyh7BcBg4pJZ6/U0bxPRi6XB2s2zaihRANCAAQJRuzh7RqU7fRysOQ70cubsuEBZggBEYK/dSXzeDecM3rxp9Jl/3sl+va5rmYPKbgyNNYsUc7N32ircIi02EFM' Generated CA cert: b'MIIBPzCB5qADAgECAhQwNyvXraQ2xo9TGjpwAHHIMPBGMTAKBggqhkjOPQQDAjAgMQ0wCwYDVQQKDARBQ01FMQ8wDQYDVQQDDAZBdXRoQ0EwHhcNMjQwNTIwMTYxNzEzWhcNMzQwNTE5MTYxNzEzWjAgMQ0wCwYDVQQKDARBQ01FMQ8wDQYDVQQDDAZBdXRoQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQJRuzh7RqU7fRysOQ70cubsuEBZggBEYK/dSXzeDecM3rxp9Jl/3sl+va5rmYPKbgyNNYsUc7N32ircIi02EFMMAoGCCqGSM49BAMCA0gAMEUCIFlTZBnwirnPyLwY1mMVGic2GanMK+HJMjRlcAdFR9wKAiEA4iLswfgJ/mmHsGptwBJkhS6E3Yibx8MXfaO7cY6ryfU=' Using AAGUID: 837b664326e0d505c5918fa1c3ff5cc4 b'837b664326e0d505c5918fa1c3ff5cc42fff19422f2c7498def28f27cbcf0836bd52f94860772f44db13fd28e80544bb01908159018c308201883082012ea00302010202145e99d41b6556135db5ef307144cbfcb1a03d40dc300a06082a8648ce3d0403023020310d300b060355040a0c0441434d45310f300d06035504030c06417574684341301e170d3234303532303136313731335a170d3334303531393136313731335a3056310b3009060355040613025553310d300b060355040a0c0441434d4531223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e3114301206035504030c0b4649444f324170706c65743059301306072a8648ce3d020106082a8648ce3d030107034200046791aff30daa286049f5dd6544abea4eb926413e0b1ec2b5e121c727a001d4ae407474fdd31cf8c117aacf03e26c9e7eff2c54daea57497d649d815bb2b686cfa310300e300c0603551d130101ff04023000300a06082a8648ce3d0403020348003045022040e9893e38e90fa4bd8af676479a47cdc011d807b5988afaa1da97de0f75ac1d022100f2f6ffc7b2d5675894c678f197b636ea7b946deb6fc482a8687fa1d5becd279f' Could not find any FIDO PC/SC devices!

It doesn't seem to matter what PCSC reader I use. I know the readers themselves are working because I did some testing in the console:

>>> list(System.readers()) ['Identiv uTrust 4701 F CL Reader 1', 'Identiv uTrust 4701 F Contact Reader 0', 'Microsoft IFD 0', 'Windows Hello for Business 1']

I suspect the issue is somewhere in the Ctap library but I'm not sure how to debug it.

Any thoughts?

Test successful: Tests if the PIN protocol parameter is checked in MakeCredential. (id: make_credential_pin_auth_protocol)
Expected error code `CTAP2_ERR_PIN_AUTH_INVALID`, got `CTAP1_ERR_INVALID_PARAMETER`.

This is one of the cases where the test suite is quite opinionated. The test succeeds, but there can be some discussion bout what error code is the correct one.

INFO:ctap:Received initialization packet
INFO:keep_alive:Start keep-alive called
INFO:bridge:Transmitting CTAP command: AUTHN_MakeCredential
DEBUG:bridge:CBOR command payload: {
  "1": "h'cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd",
  "2": {
    "id": "make_credential_pin_auth_protocol.example.com"
  },
  "3": {
    "id": "h'1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d",
    "name": "Adam"
  },
  "4": [
    {
      "alg": -7,
      "type": "public-key"
    }
  ],
  "8": "h'9a9a9a9a9a9a9a9a9a9a9a9a9a9a9a9a",
  "9": 123456
}
INFO:bridge:CTAP command requires user presence, sending 'waiting for acknowledgment' status
INFO:bridge:APDU command: 195 bytes data
DEBUG:bridge:APDU command: DATA=801000000000ba01a6015820cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd02a1626964782d6d616b655f63726564656e7469616c5f70696e5f617574685f70726f746f636f6c2e6578616d706c652e636f6d03a262696458201d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d646e616d65644164616d0481a263616c672664747970656a7075626c69632d6b657908509a9a9a9a9a9a9a9a9a9a9a9a9a9a9a9a091a0001e2400000
INFO:bridge:APDU response: SW1=0x90, SW2=0x0, 1 bytes data
DEBUG:bridge:APDU response: DATA=02
ERROR:bridge:CTAP error: CTAP_STATUS_CODE.CTAP1_ERR_INVALID_PARAMETER
ERROR:ctap.auth:Exception from authenticator: CTAP error response from authenticator
INFO:bridge:Signaling external card reset
INFO:bridge:Disconnecting from card

Just as a reminder for future support:

https://sec-certs.org/fips/8b2e933923a78a5d/

Hi,

I have been testing your applet recently, thanks for this impressive work!

I have a few questions that I could not find in the FAQ:

• What happens if I loose/break/brick my card? Are there recovery options?
• Is it possible to make a bakup of the applet state (resident keys,...)?
• If it is not (yet) possible to make a backup, could this be implemented in the future?
• What would be the minimum applet data to export to backup the card (to be able to recreate a new card with same credentials)?
• How many resident keys can be stored on a card typically? I guess it depends on the card: for example, I have NXP J3R110.
• Is it possible to get a list of the resident keys stored on the card, or delete a specific key, or get the available/total number of slots in the card
• Is there a command line/management tool to configure the card?

Sorry if I missed some answers in the documentation!

Once the applet is selected, it receives any subsequent commands, including further select commands.

For unknown / non-FIDO AIDs it should respond with 6a 82 File not found response code instead of 90 00(success).

Rationale, we scan cards for installed applets by pinging each known AID. If the FIDO app is not properly rejecting unknown AIDs, it appears to the reader as if a subsequently pinged app is installed, despite it not being installed.

First of all, thank you for providing the APDUS I requested in last issue. Much appreciated.

Could you help me out with the part of specification of FIDO 2.1 that you have referred to to implement the credProtect mechanism in the javacard applet that you have ? I am trying to understand the implementation but so far not able to find which part of specification refer for credProtect?

Again, your help is much appreciated on the matter

Another issue found by the test suite, somehow the PIN is found to be invalid when requesting an auth token, even after it has been set successfully right before. I tested this both with force_always_uv and without, no difference.

INFO:ctap:Received initialization packet
INFO:keep_alive:Start keep-alive called
INFO:bridge:Transmitting CTAP command: AUTHN_ClientPIN
DEBUG:bridge:CBOR command payload: {
  "1": 1,
  "2": 2
}
INFO:bridge:APDU command: 15 bytes data
DEBUG:bridge:APDU command: DATA=8010000000000606a2010102020000
INFO:bridge:APDU response: SW1=0x90, SW2=0x0, 81 bytes data
DEBUG:bridge:APDU response: DATA=00a101a501020338182001215820a003abd0900dfccaad02c11416a7a1a6cb110c000cd6a1ff13f1d43f7b3b7532225820db7e78556a9fb4b4fa1c9326d4a5e3283cc4de8a67e9066018a867f40036b39f
DEBUG:bridge:CBOR response payload: {
  "1": {
    "1": 2,
    "3": -25,
    "-1": 1,
    "-2": "h'a003abd0900dfccaad02c11416a7a1a6cb110c000cd6a1ff13f1d43f7b3b7532",
    "-3": "h'db7e78556a9fb4b4fa1c9326d4a5e3283cc4de8a67e9066018a867f40036b39f"
  }
}
INFO:ctap:Received initialization packet
INFO:keep_alive:Start keep-alive called
INFO:bridge:Transmitting CTAP command: AUTHN_ClientPIN
DEBUG:bridge:CBOR command payload: {
  "1": 1,
  "2": 3,
  "3": {
    "1": 2,
    "3": -25,
    "-1": 1,
    "-2": "h'71ed1ea23815f143b361a6833ab61b30dba01832e3d7446a9027c09c8b78b138",
    "-3": "h'08e1aaf31c905416875cce0a2262f7521bbe81e756c346a2f4fe721074fb7d03"
  },
  "4": "h'c132ccf990e4f555bb3e5db25e8e6cc8",
  "5": "h'78f027630dab04cda2e0cca6788f45578df51add15f3698d2fb4ac454eaa33c6cb7bc13c915e7f9de60a21b2e5d23eb6b03b175730769d20c819f0014a126ff3"
}
INFO:bridge:APDU command: 179 bytes data
DEBUG:bridge:APDU command: DATA=801000000000aa06a50101020303a50102033818200121582071ed1ea23815f143b361a6833ab61b30dba01832e3d7446a9027c09c8b78b13822582008e1aaf31c905416875cce0a2262f7521bbe81e756c346a2f4fe721074fb7d030450c132ccf990e4f555bb3e5db25e8e6cc805584078f027630dab04cda2e0cca6788f45578df51add15f3698d2fb4ac454eaa33c6cb7bc13c915e7f9de60a21b2e5d23eb6b03b175730769d20c819f0014a126ff30000
INFO:bridge:APDU response: SW1=0x90, SW2=0x0, 1 bytes data
DEBUG:bridge:APDU response: DATA=00
DEBUG:bridge:No CBOR response payload
INFO:ctap:Received initialization packet
INFO:keep_alive:Start keep-alive called
INFO:bridge:Transmitting CTAP command: AUTHN_ClientPIN
DEBUG:bridge:CBOR command payload: {
  "1": 1,
  "2": 5,
  "3": {
    "1": 2,
    "3": -25,
    "-1": 1,
    "-2": "h'71ed1ea23815f143b361a6833ab61b30dba01832e3d7446a9027c09c8b78b138",
    "-3": "h'08e1aaf31c905416875cce0a2262f7521bbe81e756c346a2f4fe721074fb7d03"
  },
  "6": "h'ccaebeee8e6a210fa702c0c85de8383a"
}
INFO:bridge:APDU command: 112 bytes data
DEBUG:bridge:APDU command: DATA=8010000000006706a40101020503a50102033818200121582071ed1ea23815f143b361a6833ab61b30dba01832e3d7446a9027c09c8b78b13822582008e1aaf31c905416875cce0a2262f7521bbe81e756c346a2f4fe721074fb7d030650ccaebeee8e6a210fa702c0c85de8383a0000
INFO:bridge:APDU response: SW1=0x90, SW2=0x0, 1 bytes data
DEBUG:bridge:APDU response: DATA=31
ERROR:bridge:CTAP error: CTAP_STATUS_CODE.CTAP2_ERR_PIN_INVALID
ERROR:ctap.auth:Exception from authenticator: CTAP error response from authenticator
INFO:ctap:Received initialization packet
INFO:keep_alive:Start keep-alive called
INFO:bridge:Transmitting CTAP command: AUTHN_ClientPIN
DEBUG:bridge:CBOR command payload: {
  "1": 1,
  "2": 2
}
INFO:bridge:APDU command: 15 bytes data
DEBUG:bridge:APDU command: DATA=8010000000000606a2010102020000
INFO:bridge:APDU response: SW1=0x90, SW2=0x0, 81 bytes data
DEBUG:bridge:APDU response: DATA=00a101a501020338182001215820a93c4745dd41037b6008c284870925a25c04163cc4dd9c727a4dde8bc10ff49e225820899b1822473de8ca4842af19d8274a925f7536a3c6270117004d12bb9378ca10
DEBUG:bridge:CBOR response payload: {
  "1": {
    "1": 2,
    "3": -25,
    "-1": 1,
    "-2": "h'a93c4745dd41037b6008c284870925a25c04163cc4dd9c727a4dde8bc10ff49e",
    "-3": "h'899b1822473de8ca4842af19d8274a925f7536a3c6270117004d12bb9378ca10"
  }
}
WARNING:keep_alive:Max keep-alive exceeded - will stop