Add another known Idemia ID-One PIV card

[Jakuje]

My Idemia ID-One PIV 2.4 cards have different ATR than the one that is listed in the PIV driver (but works regardless this). We should probably introduce some mask to be able to match them better (probably for the third byte and last two).

@dengert can you check your idemia cards have this ATR or some different?

Checklist

• Documentation is added or updated
• New files have a LGPL 2.1 license statement
• PKCS#11 module is tested
• Windows minidriver is tested
• macOS tokend is tested

[dengert]

Looks OK.

The first PIV 800-73-4 card I have is labeled "ID-ONE PIV 2.4 on Cosmo v8.1" from Dec 10, 2018 with ATR 3b:d6:97:00:81:b1:fe:45:1f:87:80:31:c1:52:41:1a:2b

Then in June 12, 2020 I received a set of 5 cads labeled "ID-One PIV 2.4.1 CIV configuration" with ATR "3b:d6:97:00:81:b1:fe:45:1f:87:80:31:c1:52:41:12:23" The same as the one you have. These are the cards I used to do most of my PIV SM testing. The cards have different combinations of keys, PIV SM cipher Suites, PIN Policies and VCI Pairing code requirements. One card can actually do Fingerprint OCC which I did not add to OpenSC as testing would require loading my fingerprint to card.

different ATR than the one that is listed in the PIV driver (but works regardless this).

The PIV driver is designed to check ATRs first then (matched or not) check card for the PIV applet by selecting PIV AID and/or testing for Discovery object See comment here: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L5455-L5468

The only place the ATR is used is for cards with issues or in the minidriver. But all PIV manufactures I have seen provide a minidriver, or can work with the Microsoft PIV support. So by default the OpenSC minidriver ATRs do not include ones for PIV cards.

[Jakuje]

Updated the atr list with mask to match wider list of "common" ATRs. I see that the type is based on the discovery object, but I recently got reports about PIV cards without discovery object (or empty?), that OpenSC fails to work with so I wanted to try if this could solve the issue. I do not have the cards to play with yet though. I am not sure if there is some change in the applet or the card side so I hope I will come with some updated

[dengert]

Yubico by, default does not have a discovery object but card-piv.c will try to read discovery object:
Outgoing APDU (9 bytes):
00 CB 3F FF 03 5C 01 7E 00
Incoming APDU (2 bytes):
6D 00
then since it failed, will try SELECT AID:
Outgoing APDU (15 bytes):
00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00
Incoming APDU (21 bytes):
61 11 4F 06 00 00 10 00 01 00 79 07 4F 05 A0 00 a.O.......y.O...
00 03 08 90 00

The response to SELECT AID or Discovery must contain the short AID A0 00 00 03 08
to indicate PIV applet is present or in Discovey case PIV is active applet

Some cards (muscle in particular) would respond 90 00 to any select aid!

[frankmorgner]

Some cards (muscle in particular) would respond 90 00 to any select aid!

muscle detection happens bevor PIV - is this really still a problem?

[Jakuje]

In the log I have with the ATR 3b:d6:96:00:81:b1:fe:45:1f:87:80:31:c1:52:41:1a:2a (the one in the current piv driver) the discovery object is missing or empty (get data returning just 90 00, but being interpreted as file not found:

card-piv.c:2773:piv_find_discovery: returning with: -1201 (File not found)

and subsequent AID selection not returning FCI (again only 90 00) causing the initialization to fail.

So this change is likely not going to fix this problem, but I wanted to have the ATRs we are using recorded somewhere.

Some cards (muscle in particular) would respond 90 00 to any select aid!

muscle detection happens bevor PIV - is this really still a problem?

I think the muscle cards are less common these days making this less of an issue. Just a note that this card returns failures for selection of unknown objects (for example as the CAC detection continues, selection of CAC files fails with 6A 82.

[dengert]

and subsequent AID selection not returning FCI (again only 90 00) causing the initialization to fail.

Sounds like card does not have a PIV applet.

sp800-73-4 says the response should have a:
"Data Objects in the PIV Card Application Property Template (Tag '61')" with "Application identifier of application '4F' | Mandatory | The PIX of the AID includes the encoding of the version of the PIV Card Application. See Section 2.2, Part 1."
and "Coexistent tag allocation authority | '79' | Mandatory | Coexistent tag allocation authority template. See Table 4."

Are these cards initialized? Do they have a PIV applet?
Idemia sells these cards with an NIST approved PIV applet. They may also sell the cards without a PIV Applet. and anyone could install a "PIV like" or other applet on the card.

In the log I have with the ATR 3b:d6:96:00:81:b1:fe:45:1f:87:80:31:c1:52:41:1a:2a (the one in the current piv driver) the discovery object is missing or empty (get data returning just 90 00, but being interpreted as file not found:

Discovery object is optional, but if present must have PIV AID

3.3.2 Discovery Object
The Discovery Object, if implemented, is the 0x7E interindustry ISO/IEC 7816-6 template that nests interindustry data objects. For the Discovery Object, the 0x7E template nests two mandatory BER-TLV structured interindustry data elements: 1) tag 0x4F contains the AID of the PIV Card Application and 2) tag 0x5F2F lists the PIN Usage Policy.

[dengert]

And if you think the card does have a PIV applet, look at:
#2242

[Jakuje]

I was likely wrong regarding the missing discovery object. The new logs I got show that there is discovery, but there are no key/certificate objects except for the SM signer certificate. I am still working on getting more logs and information, but it takes time. So in any case, merging this should not hurt and as I will have more information, I will open a new issue/PR.