Test of PKCS # 11 yields CKR_USER_NOT_LOGGED_IN (0x101)

[dpmcgonigle]

Problem Description

When testing PKCS #11 with your commands: """ You may test the PKCS#11 support of your card with

"C:\Program Files\OpenSC Project\OpenSC\tools\pkcs11-tool.exe" --login --test "C:\Program Files (x86)\OpenSC Project\OpenSC\tools\pkcs11-tool.exe" --login --test """, I get the log errors reproduced below. (error: PKCS11 function C_SignFinal failed: rv = CKR_USER_NOT_LOGGED_IN (0x101))

I installed both the 32 and 64 bit msi files as directed on the install page. I am running windows 10 on an Acer Aspire7. For a card reader, I have IOGEAR GSR202.

Logs

C:\Users\Dan>"C:\Program Files (x86)\OpenSC Project\OpenSC\tools\pkcs11-tool.exe" --login --test Using slot 0 with a present token (0x0) Logging in to "MCGONIGLE.DANIEL.PATRICK.JR.1291". Please enter User PIN: C_SeedRandom() and C_GenerateRandom(): seeding (C_SeedRandom) not supported ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20) Digests: all 4 digest functions seem to work MD5: OK SHA-1: OK RIPEMD160: OK Signatures (currently only for RSA) testing key 0 (PIV AUTH key) error: PKCS11 function C_SignFinal failed: rv = CKR_USER_NOT_LOGGED_IN (0x101) Aborting.

[dengert]

What version of OpenSC are you running? The PIV card enforces on the card that the PIN must be verified just before a SIGN operation. It does this for the PIV SIGN key. This could be an issue, but 0.19.0 should work with the PIV card and should have ask for the PIN a second time.

Some debugging would be helpful. See https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC Note the debug output may have your PIN. i.e. A PIN of 123456 will show up as 31 32 33 34 35 36 in an outgoing APDU line in the log.

Windows has its own driver for PIV and so there can be interference from multiple applications. The debug log should help.

[dpmcgonigle]

Thank you for getting back to me so promptly!

I am running 0.19.0, the latest stable release advertised by the website yesterday.

I don't really know how to follow the page you provided.

• "On windows the opensc config file is found using the registry key HKML\Software\OpenSC Project\OpenSC\ConfigFile." ---I know how to get to "regedit", but there is no registry key for "ConfigFile". There is one for "OpenSC smartcard framework" (one for 32 and one for 64 bit). Do I create "ConfigFile" in this folder? Or do I create "opensc.conf"?
• "Also users can use the OPENSC_CONF environment variable to override both registry settings." ---Not sure how to do this.
• "OPENSC_DEBUG=9 pkcs11-tool --list-slots" ---This does not work for me (on Windows 10)
• "On windows the read PKCS#11 Module is found using HKLM\Software\OpenSC Project\PKCS11-Spy\Module and the output is written to the file specified in HKLM\Software\OpenSC Project\PKCS11-Spy\Output (Default: TEMP\pkcs11-spy.log)." ---There is just a dll file in that folder. I'm not sure what I'm supposed to be doing in this step either...

Sorry that I am not fluent in this! Are you able to break it down for me at all? Thanks.

-Dan

[dengert]

Here is what I get on Windows 10 with 0.19.0.0 installed on 8.30/18. This is using NIST demo card 1.

Microsoft Windows [Version 10.0.17134.345]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Users\Doug>"C:\Program Files (x86)\OpenSC Project\OpenSC\tools\pkcs11-tool.exe" --login --test
Using slot 0 with a present token (0x0)
Logging in to "Test Cardholder".
Please enter User PIN: C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20)
Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
Signatures (currently only for RSA)
  testing key 0 (PIV AUTH key)

Your command gets an error here. My command continues...

  all 4 signature functions seem to work
  testing signature mechanisms:
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
    MD5-RSA-PKCS: OK
    RIPEMD160-RSA-PKCS: OK
    SHA256-RSA-PKCS: OK
  testing key 1 (2048 bits, label=SIGN key) with 1 signature mechanism
Logging in to "Test Cardholder".
Please enter context specific PIN:     RSA-X-509: OK
  testing key 2 (2048 bits, label=KEY MAN key) with 1 signature mechanism -- can't be used to sign/verify, skipping
  testing key 3 (2048 bits, label=CARD AUTH key) with 1 signature mechanism
    RSA-X-509: OK
Verify (currently only for RSA)
  testing key 0 (PIV AUTH key)
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
    MD5-RSA-PKCS: OK
    RIPEMD160-RSA-PKCS: OK
  testing key 1 (SIGN key) with 1 mechanism
Logging in to "Test Cardholder".

I then cancelled it here;

This sounds very similar to: #1460 The card appears to have lost the login state or its a DUAL CAC/PIV card.

What is the output (the card's ATR) from running: "C:\Program Files (x86)\OpenSC Project\OpenSC\tools\opensc-tool" -a We can then look it up at: https://smartcard-atr.appspot.com/

Can you try https://github.com/OpenSC/OpenSC/issues/1460#issuecomment-418923302

0.19.0 simplified the opensc.conf and on my windows system has two versions

C:\Program Files (x86)\OpenSC Project\OpenSC\opensc.conf and C:\Program Files\OpenSC Project\OpenSC\opensc.conf containing:

    # debug = 3;
    # debug_file = opensc-debug.txt
    framework pkcs15 {
        # use_file_caching = true;
    }
}

Previous versions of OpenSC had a fully commented version of opensc.conf but that is not installed. (I see the old one in my directory as opensc - Copy.conf from a previous install. ) The source of the file can be found at: https://github.com/OpenSC/OpenSC/blob/master/etc/opensc.conf.example.in But all the "@name@'' fields need to be changed to match the OS.

This could be a good starting opensc.conf to use for debugging this problem:

    # debug = 3;
    # debug_file = %TEMP%\opensc-debug.txt;

    #card_atr 3b:7d:96:00:00:80:31:80:65:b0:83:11:17:d6:83:00:90:00 {
        #            driver = "PIV-II";
        #            type = 14005;
        #  }

    framework pkcs15 {
        # use_file_caching = true;

        # Use PIN caching?
        # Default: true
        # use_pin_caching = false;

        # Older PKCS#11 applications not supporting CKA_ALWAYS_AUTHENTICATE
        # may need to set this to get signatures to work with some cards.
        # Default: false
        # pin_cache_ignore_user_consent = true; 
    }
}

To get debuging output uncomment the debug = 3; and debug_file = %TEMP%\opensc-debug.txt; lines. (change the file location if you want. )

To treat your card differently, uncomment the card_atr lines and replace the ATR with the ATR of your card.

To see if it is a problem with the PIN_always/user_consent uncomment the pin_cache_ignore_user_consent = true; line

[dengert]

The above example opensc.conf should have a first line: app default { corrected version:

app default {
    # debug = 3;
    # debug_file = %TEMP%\opensc-debug.txt;

    #card_atr 3b:7d:96:00:00:80:31:80:65:b0:83:11:17:d6:83:00:90:00 {
        #            driver = "PIV-II";
        #            type = 14005;
        #  }

    framework pkcs15 {
        # use_file_caching = true;

        # Use PIN caching?
        # Default: true
        # use_pin_caching = false;

        # Older PKCS#11 applications not supporting CKA_ALWAYS_AUTHENTICATE
        # may need to set this to get signatures to work with some cards.
        # Default: false
        # pin_cache_ignore_user_consent = true; 
    }
}

[dpmcgonigle]

dengert,

adding: card_atr 3b:7d:96:00:00:80:31:80:65:b0:83:11:17:d6:83:00:90:00 { driver = "PIV-II"; type = 14005; }

fixed it for me! I do have a dual cac/piv card, so that worked. Thank you!

[dengert]

OK, I will look at checking for this ATR in the code.

[Jakuje]

It looks like I have got very similar report that dual CAC/PIV card is no longer detected by the PIV driver:

https://bugzilla.redhat.com/show_bug.cgi?id=1651748

It has also attached a debug log if somebody would like to peek into that.

If I see right, the PIN is properly verified, but then the login state is lost which results in the failure of the signature (no always_authenticate is involved here).

The old card from 2012 (which I talked about in #1533) is not detected at all in PIV driver, but I do not think it was ever detected nor the workaround here helps.

[dengert]

Yes it does look similar. The circumvention was to tell the PIV driver to assume the card type = 1405` SC_CARD_TYPE_PIV_II_GI_DE This was added by 0911982bef3aba1da24c2d70b4942d19ceb6ae78

It was found that some cards can lose the login state when a SELECT AID was done for the PIV AID even though the NIST 800-73-* says this shall not happen. The SELECT AID was being done to make sure the the PIV applet was/is the current applet. (interference avoidence).

There may be other cards that have this compliance issue. But how to identify them?

I found this: CAC-utilziation-and-variation-matrix-v2.03-20May2016.doc which list current and obsolete CAC cards with their ATRs. All the current applets are all V2.6.2b.

So far the 1 card with the problem as fixed in 0911982bef3aba1da24c2d70b4942d19ceb6ae78 and the card in question are listed as current. These are

Giesecke & Devrient (PIV Endpoint) 3B 7A 18 00 00 73 66 74 65 20 63 64 31 34 34 (exp 6 2019 SHA1) Giesecke & Devrient (PIV Endpoint) 3B 7A 18 00 00 73 66 74 65 20 63 64 31 34 34 (ongoing SHA2) Gemalto (PIV Endpoint) 3B 7D 96 00 00 80 31 80 65 B0 83 11 17 D6 83 00 90 00 (ongoing)

All of these are running CAC Applet Package V2.6.2b

The other ongoing card is Oberthur Card System (PIV Endpoint) 3B DB 96 00 80 1F 03 00 31 C0 64 B0 F3 10 00 07 9000 80 Could it have the problem too?

The ATR in https://bugzilla.redhat.com/show_bug.cgi?id=1651748#c3 is not listed.

It looks like it loses the login state after SELECT_AID or the 9A key is being treated as "PIN Always"

Look for the Verify 00 20 00 80 08 ...

then later: 10 87 07 9A FF 7C 82 01 06 82 00 81 82 01 00 00 ... first part of chained command 90 00 00 87 07 9A 0B 69 E6 23 D0 1A DA 69 6A 7E 4C 7E last part 69 82 Security status not satisfied pkcs15-pin.c:791:sc_pkcs15_pincache_revalidate: called but it looks like it did not try a cached pin.

I can't tell from the log which it might be.

So some possible ways to handle a card that returns

NIST 800-73-2 was released in Sept 2008 and "Added optional Discovery Object." So any card that returns something other then 61xx, 6982, 6A82 or 9000 is out of date or not compliant and can have the CI_DISCOVERY_USELESS set, which is already in the code. It could also have CI_OTHER_AID_LOSE_STATE much like the the code for SC_CARD_TYPE_PIV_II_GI_DE

Sunflower 3_2 AI Applet v2.6.2b Security Policy Card_v1.2 Final_PDM1.1.doc says: "PIV EP Wrapper Applet – This applet implements the Personal IdentityVerification services from NIST SP800-73-1". This implies Discovery object is not implemented.

I will submit a PR to tighten up the setting up of the card issues flags so any of these cards will look like SC_CARD_TYPE_PIV_II_GI_DE type 14005 which does not try and do any interference prevention.

[mouse07410]

I suspect the current CAC (dual) exhibits this problem too.

[Jakuje]

The ATR from the card in the previous comment (Red Hat bugzilla) is 3b:7d:96:00:00:80:31:80:65:b0:83:11:17:d6:83:00:90:00

Therefore exactly the same as from the @dpmcgonigle . The same workaround works also for this card.

@dengert let me know if there is something I can help in some way, I should test something or get some data from the card

Just checking the content of the card, the CCC looks this way: (TL file)

Outgoing APDU (5 bytes):
00 C0 00 00 30 ....0
0x7f0ec06e9740 04:38:34.595 [opensc-pkcs11] reader-pcsc.c:213:pcsc_internal_transmit: called
0x7f0ec06e9740 04:38:34.602 [opensc-pkcs11] reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (50 bytes):
F0 15 F1 01 F2 01 F3 10 F3 10 F3 10 F3 10 F3 10 ................
F3 10 F3 10 F3 10 F3 10 F3 10 F3 10 F3 10 F4 01 ................
F5 01 F6 11 F7 00 FA 00 FB 00 FC 00 FD 00 FE 00 ................
90 00                                           ..

(Value File)

Outgoing APDU (5 bytes):
00 C0 00 00 EA .....
0x7f0ec06e9740 04:38:34.652 [opensc-pkcs11] reader-pcsc.c:213:pcsc_internal_transmit: called
0x7f0ec06e9740 04:38:34.666 [opensc-pkcs11] reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (236 bytes):
A0 00 00 00 79 03 02 40 70 50 72 84 00 00 A7 A5 ....y..@pPr.....
AA 00 A7 A5 AA 21 21 A0 00 00 00 79 01 02 00 01 .....!!....y....
00 00 00 00 00 00 00 A0 00 00 00 79 01 02 01 01 ...........y....
00 00 00 00 00 00 00 A0 00 00 00 79 04 01 00 01 ...........y....
00 00 00 00 00 00 00 A0 00 00 00 79 04 01 01 01 ...........y....
00 00 00 00 00 00 00 A0 00 00 00 79 04 01 02 01 ...........y....
00 00 00 00 00 00 00 A0 00 00 01 16 01 30 00 30 .............0.0
00 00 00 00 00 00 00 A0 00 00 01 16 01 60 10 30 .............`.0
00 00 00 00 00 00 00 A0 00 00 01 16 01 60 30 30 .............`00
00 00 00 00 00 00 00 A0 00 00 01 16 01 90 00 30 ...............0
00 00 00 00 00 00 00 A0 00 00 00 79 01 12 01 12 ...........y....
01 00 00 00 00 00 00 A0 00 00 00 79 01 12 02 12 ...........y....
01 00 00 00 00 00 00 A0 00 00 01 16 04 A0 01 A0 ................
01 00 00 00 00 00 00 00 10 07 A0 00 00 00 79 03 ..............y.
00 00 00 00 00 00 00 00 00 00 90 00             ............

From manual parsing, the 0xF5 tag is also 0x10. Otherwise I did not find anything interesting that would differ from the old car I have here (only the manufacturer and the card id part of CUID).

Where did you find what version of applet is used on the card?

[dengert]

http://www.cac.mil/Portals/53/Documents/CAC-utilziation-and-variation-matrix-v2.03-20May2016.doc

(I also found a 2013 version but can not find it anymore.)

It appears to be a DoD list of all DoD CAC cards with ATR, version, card vendor, and most interestingly
"Operational Intro Date","Operational Sunset Date" and "Expiration of last card issued".

Many of the "Obsolete Platforms" are using 1024 bit keys and the card with SHA1 signed certificates are due to expire June 2019.

All the "Current Platforms" support "PIV Endpoint". i.e. Dual CAC/PIV.

Are there any other CAC cards out there? (I am more interested in are there any other Dual CAC/PIV cards out there?)

You had said there was some need for the CACv1 cards. CACv1 Appear to only use 1024 RSA.

As a side note: I also found in some document (I will look for it if you want) that says "PIV Transitional" presents the CAC Sign cert/key as the PIV auth cert/key. Not until 2008 v2.6.2 was there a separate PIV Auth cert/key. But these should have been retired by 2010.

Depending on how the applet was written could lead to "PIN Always" being enforced on the PIV auth. cert/key. Don't know if we have ever run into this.

It is also possible that since accessing the CAC Sign key via CAC does not enforce "PIN Always" but accessing the same key via PIV enforces the "PIN Always" or it might not.

@mouse07410 while typing this comment: As best I can tell the PIV Auth cert/key was added to be used for login and web authentication, in place of using the SIGN cert/key for login and web authentication and signatures. The PIV Sign cert/key where then meant to be uses for other signatures like e-mail. But CAC users and DoD web sites were originally setup using the CAC Sign cert/key, so when a DoD website is accessed by using the PIV applet it ends up is using the PIV Sign cert/key and "PIN Always" which is one of the complaints.

Is there anyway to start using the PIV Auth cert/key with those sites? How do the certificates differ? Do they differ?

What ATR are your Dual CAC/PIV cards?

[Jakuje]

The need for the CACv1 were the Alt Tokens -- not actual CAC tokens, but to some extent compatible cards. They do not carry everything you will find in CAC and they do not need to be the classical identity cards. They usually have just one or two certificates provisioned for special use case as far as I understand it. The official CACv1 were indeed with small keys, but there was nothing preventing vendors to use the same protocol and increase the key size. From time to time some of our customer comes with a card like this. The last we have encountered were models manufactured by HID. But that is off topic here.

[dengert]

@Jakuje can you run this command using the PIV driver? pkcs11-tool -r -y data --application-id 2.16.840.1.101.3.7.1.219.0 | od -t x1

It should show the same CCC but with combined tag length values.

If it does, looking for F3 with CAC RID of a0 00 00 00 79 means it is a dual CAC/PIV (The RID A0.00.00.01.16 (Hex) for the GSC-IS Data Model Dont know if there are any cards with PIV and GSC-IS that are causing problems.

I would like to avoid a list of ATR in the code unless http://www.cac.mil/Portals/53/Documents/CAC-utilziation-and-variation-matrix-v2.03-20May2016.doc contains all of them. I would like to fall back on the CCC if present via PIV to test if it is a CAC card too without having to do a SELECT AID if possible.

This has some good stuff to: http://www.cac.mil/Portals/53/Documents/Technical-Bulletin_CAC-Data-Model-Change_CAC-2-6-2b-Applet-Structure_June2009UPDATED.pdf

[Jakuje]

Here you are:

#  pkcs11-tool -r -y data --application-id 2.16.840.1.101.3.7.1.219.0 |hexdump -C
Using slot 0 with a present token (0x0)
00000000  53 82 01 1a f0 15 a0 00  00 00 79 03 02 40 70 50  |S.........y..@pP|
00000010  72 84 00 00 a7 a5 aa 00  a7 a5 aa f1 01 21 f2 01  |r............!..|
00000020  21 f3 10 a0 00 00 00 79  01 02 00 01 00 00 00 00  |!......y........|
00000030  00 00 00 f3 10 a0 00 00  00 79 01 02 01 01 00 00  |.........y......|
00000040  00 00 00 00 00 f3 10 a0  00 00 00 79 04 01 00 01  |...........y....|
00000050  00 00 00 00 00 00 00 f3  10 a0 00 00 00 79 04 01  |.............y..|
00000060  01 01 00 00 00 00 00 00  00 f3 10 a0 00 00 00 79  |...............y|
00000070  04 01 02 01 00 00 00 00  00 00 00 f3 10 a0 00 00  |................|
00000080  01 16 01 30 00 30 00 00  00 00 00 00 00 f3 10 a0  |...0.0..........|
00000090  00 00 01 16 01 60 10 30  00 00 00 00 00 00 00 f3  |.....`.0........|
000000a0  10 a0 00 00 01 16 01 60  30 30 00 00 00 00 00 00  |.......`00......|
000000b0  00 f3 10 a0 00 00 01 16  01 90 00 30 00 00 00 00  |...........0....|
000000c0  00 00 00 f3 10 a0 00 00  00 79 01 12 01 12 01 00  |.........y......|
000000d0  00 00 00 00 00 f3 10 a0  00 00 00 79 01 12 02 12  |...........y....|
000000e0  01 00 00 00 00 00 00 f3  10 a0 00 00 01 16 04 a0  |................|
000000f0  01 a0 01 00 00 00 00 00  00 f4 01 00 f5 01 10 f6  |................|
00000100  11 07 a0 00 00 00 79 03  00 00 00 00 00 00 00 00  |......y.........|
00000110  00 00 f7 00 fa 00 fb 00  fc 00 fd 00 fe 00        |..............|
0000011e

This looks the same as the CCC from the CAC driver.

Standard PIV cards do not have these, neither any of f3, but also the RID is empty:

$  pkcs11-tool -r -y data --application-id 2.16.840.1.101.3.7.1.219.0 | hexdump -C
Using slot 0 with a present token (0x0)
00000000  53 1b f0 00 f1 00 f2 00  f3 00 f4 00 f5 01 10 f6  |S...............|
00000010  00 f7 00 fa 00 fb 00 fc  00 fd 00 fe 00           |.............|
0000001d

This sounds like a good pointer where to start for detecting these cards.

[erick-orozco]

Hello,

I'm having the same issue with my card. Meaning, that when I run the command: "pkcs11-tool -t -l" It fails as described by dpmcgonigle. I tried adding the attributes provided to the opensc.conf file, however that didn't work. So I'm wondering, how can I double check my cards attributes? Is there a way using the pkcs11-tool to get them?

Thanks!

Here is the command output: OPENSC_DEBUG=9 pkcs11-tool -t -l 0x76f33b30 01:01:23.211 [opensc-pkcs11] ctx.c:708:process_config_file: Used configuration file '/etc/opensc.conf' Using slot 0 with a present token (0x0) Logging in to "PIVKey A7B6487D0C572F46BCBBE3352". Please enter User PIN: C_SeedRandom() and C_GenerateRandom(): seeding (C_SeedRandom) not supported ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20) Digests: all 4 digest functions seem to work MD5: OK SHA-1: OK RIPEMD160: OK Signatures (currently only for RSA) testing key 0 (CARD AUTH key) error: PKCS11 function C_SignFinal failed: rv = CKR_USER_NOT_LOGGED_IN (0x101) Aborting.

[dengert]

The ATR would help us. Use opensc-tool -a Please sent the ATR. You can look it up at https://smartcard-atr.appspot.com/ The problem is with Dual CAC/PIV cards which are issued by the governments like US and NATO.

Did you add to opensc.conf the stanza as in: https://github.com/OpenSC/OpenSC/issues/1531#issuecomment-439518939 but with your ATR?

This forces the card driver to assume a card has certain properties.

What version of OpenSC are you running?

[erick-orozco]

Woow, thanks for the prompt response! I changed the attribute to the one returned when running opensc-tool -a. I don't get that error anymore, however I'm getting this: "ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20)". This is the full output:

pkcs11-tool -t -l Using slot 0 with a present token (0x0) Logging in to "PIVKey A7B6487D0C572F46BCBBE3352". Please enter User PIN: C_SeedRandom() and C_GenerateRandom(): seeding (C_SeedRandom) not supported ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20) Digests: all 4 digest functions seem to work MD5: OK SHA-1: OK RIPEMD160: OK Signatures (currently only for RSA) testing key 0 (CARD AUTH key) all 4 signature functions seem to work testing signature mechanisms: RSA-X-509: OK RSA-PKCS: OK SHA1-RSA-PKCS: OK MD5-RSA-PKCS: OK RIPEMD160-RSA-PKCS: OK SHA256-RSA-PKCS: OK Verify (currently only for RSA) testing key 0 (CARD AUTH key) RSA-X-509: OK RSA-PKCS: OK SHA1-RSA-PKCS: OK MD5-RSA-PKCS: OK RIPEMD160-RSA-PKCS: OK Unwrap: not implemented Decryption (currently only for RSA) testing key 0 (CARD AUTH key) RSA-X-509: OK RSA-PKCS: OK 1 errors

I'm using opensc 0.19.0

[dengert]

What was the ATR of your card? I would like to know if it is a CAC card or not.

CKR_DATA_INVALID (0x20) happens on some PIV cards Depends on what was implemented in the applet.

[erick-orozco]

the card attribute is: "3b:fc:18:00:00:81:31:80:45:90:67:46:4a:00:64:2d:70:c1:72:fe:e0:fe". As you mentioned, it is a PIV card that runs a JAVA applet. I'll look on the closed issues to solve the CKR_DATA_INVALID (0x20).

Thank you!

[dengert]

Your card appears to be a PIVKEY card or token from Taglio. I have a few of these but not with the same ATR, and I have not done much with them.

So I am not sure why your card fails as it is not a CAC. An opensc-debug.log would be very useful.

They appear to support the Discovery Object, but there is no Discovery object on the card. Its optional.

(Blank cards have a CARD AUTH cert/key signed by Tiglio. Note: PIV standards does not require a PIN to be entered so this should not be used to authenticate a user, only a card.)

[mouse07410]

@erick-orozco if you have time and don't mind a potentially unnecessary experiment, perhaps you could try building OpenSC from my fork https://GitHub.com/mouse07410/OpenSC.git ?

One of the differences is that my fork disables ALWAYS_AUTHENTICATE enforcement by software, and I suspect your problem could be related to that.

If your card works with my fork, it would prove my theory and give you a usable solution. If it doesn't - well, then I'm wrong and I apologize.

@dengert my apologies for a delayed response. No, in my experience no browser would actually force using SIGN cert, regardless of how the web site is configured. In fact, my problem with such sites was the opposite: the browser would not ask me what cert to pick, and automatically choose PIV AUTH (which then was promptly rejected by the server). I think the incessant prompting for the PIN it's not related to the ALWSYS_AUTHENTICATE, but to the erroneous (IMHO) way the software tried to enforce it.

No, there's no way to convince those servers to accept AUTH cert instead of SIGN cert. I don't think they differ between PIV and CAC. I know that SIGN includes SAN email attribute, and NON-REPUDIATION flag - which AUTH cert lacks. Might also be the fact that they're issued by different CAs, but both chain-link to the same DoD root...

[dengert]

I agree with: "No, in my experience no browser would actually force using SIGN cert, regardless of how the web site is configured." It has more to do with the certificate keyUsage and other extensions along with and who signed it. I was suggesting is there a way to register the PIV Auth cert as the one to use at a specific web site. Not having access to a real CAC card and reluctance of users to expose their certs in these issue I can only suggest.

In regards to the PIN. there are some possible issues:

1. PIV 800-73-1 and 800-73-3 differ in what is the pin reference to be used I see @Jakuje responded to this in #1460 this morning. I need to look at it closer.

2. PIV Applet loses login state when any SELECT AID is issued even though 800-73-* says if a SELECT AID for any applet not on the card or the AID for the PIV is received, the login state will not change. This is a major problem from an OpenSC perspective, but a non issue for a vendor developing a PIV Applet for a single card using the vendor's middleware. They just assume there is no interference so no need to support the spec.

3. You said: " but to the erroneous (IMHO) way the software tried to enforce it." IMHO, I think it has more to do with trying to use a PIV applet on a card that may have multiple applets. Most of the enforcement code was added to support Yubico with PIV and OpenPGP to make sure the correct applet was selected, and depends on "2." above.

4: There is no way to test if a card supports the "PIN Always" on a key, other then to try it. 800-73-* says the SIGN key is protected, and a compliant card applet will enforce it.

You might note that the solution to many of these problems is to treat the card as a "SC_CARD_TYPE_PIV_II_GI_DE" type 14005. in 0911982bef3aba1da24c2d70b4942d19ceb6ae78 and sets

 priv->card_issues |= CI_VERIFY_LC0_FAIL
                | CI_PIV_AID_LOSE_STATE
                | CI_OTHER_AID_LOSE_STATE;;

which in effect turns off trying to check for the login state of a card before any transaction.

My intention at this time is to have the PIV driver use a list of ATR of known CAC cards or cards that can return a CCC object that says there are CAC type objects on the card as a 1405. (The card must still allow a SELECT AID for PIV to be considered a PIV card.)

[erick-orozco]

Hello, this is the best support I've ever had from an open source project!! Attached are the logs. @mouse07410 I'll build it from the fork, and send you the logs.

Thanks! opensc_debug.txt

[mouse07410]

@dengert

I agree with: "No, in my experience no browser would actually force using SIGN cert, regardless of how the web site is configured." It has more to do with the certificate keyUsage and other extensions along with and who signed it...

I don't know about KU and EKU - as I said, I rather suspect it's the SAN extension that differentiates between the AUTH and SIGN certs for those "special" web sites. I also don't know if the CA chain matters. The only KU attribute that I think could matter is "Non-Repudiation". Everything else shouldn't matter, IMHO.

I was suggesting is there a way to register the PIV Auth cert as the one to use at a specific web site.

Alas, no. I found three kinds of sites:

• Allows you to select which certificate to use for login. I almost always pick AUTH, and it works fine.
• Tells you to not use "Email" certificate (meaning, "don't use SIGN cert"). Again, this kind doesn't cause any problem: browsers that ask to pick a cert, I just point at AUTH; and browsers that insist of figuring out by themselves which cert to offer, again prefer AUTH as the most suitable for TLS client and Web Login.
• Finally, there are sites that insist on using "Email" certificate. In that case, if a browser doesn't allow you to select, and pushes his choice (AUTH), the login fails. Thankfully, there aren't many of these - but those that are are unavoidable (e.g., Outlook Web Access - can hardly avoid doing business with this one).

In regards to the PIN. there are some possible issues... (1)...

I do not know. Hopefully you can make sense of it. It's beyond my expertise and experience.

(2) PIV Applet loses login state when any SELECT AID is issued even though 800-73-* says if a SELECT AID for any applet not on the card or the AID for the PIV is received, the login state will not change...

Somehow I suspect that this is the case, though I can't be sure.

(3)...

Thankfully, at least Yubikey seems to work fine (and people at work are thanking me for introducing them to this nifty device ;). You're probably right about the cause, and as you said, it's probably related to (2). Maybe we'll figure how to deal with it. For now I'm reasonably happy to just forget about "cac" driver, and use PIV driver for everything I got (except the OpenPGP applet on Yubikeys, of course ;).

(4) There is no way to test if a card supports the "PIN Always" on a key, other then to try it. 800-73-* says the SIGN key is protected, and a compliant card applet will enforce it.

Frankly and bluntly - I couldn't care less. If the card "meant" to have ALWAYS_AUTHENTICATE but lacked hardware support for it, I don't need software to fix that at the cost of inconveniencing user (by making him type PIN twice) or risking the problem we seem to experience with CAC and Firefox. The card is supposed to hardware-enforce that property, and that's a fundamental enough property to expect compliance. If it doesn't - too bad.

You might note that the solution to many of these problems is to treat the card as a "SC_CARD_TYPE_PIV_II_GI_DE" type 14005...

So far it seems to work.

My intention at this time is to have the PIV driver use a list of ATR of known CAC cards or cards that can return a CCC object that says there are CAC type objects on the card as a 14005.

I don't know. All the newer CAC are PIV-compliant, AFAICT. For the older stuff, why not just use the old driver and be done with it?

(The card must still allow a SELECT AID for PIV to be considered a PIV card.)

That's one big concern.

@erick-orozco thanks, I got the log. I'm afraid I'm not as skilled at getting nuggets of it as @dengert is. All that I saw of interest was that (a) it seemed to be a Feitan card, and (b) it kept failing attempts to SELECT objects on it. Perhaps @dengert can tell if things look right there.

Also, what did you try to do? And did it work? I.e., is this a log of a problem, or a record of success?

Re. support - yes, I find that Open Source in general provides much better support than many commercial products, and OpenSC package (including some "daughter-packages" like libp11) is supported better than most.

[mouse07410]

@dengert to emphasize my point about "OpenSC trying to play cop". We all know that vendors do screw up their implementations of the standard, and in general exhibit non-compliance to various degree. Understandably, we're trying to accommodate and make our middleware work with as many tokens as we can.

The question is how far we should go. IMHO, some properties are so fundamental that if they're not present, it doesn't make sense to use such a token at all. For example, a card that allows extracting private keys in the clear, or but enforcing PIN access when it is configured. Such tokens wouldn't offer security that people associate with use of hardware tokens compared to, e.g., software tokens.

[erick-orozco]

@mouse07410 I'm running the pkcs11-tool -t -l command. And it is returning with the following error: C_SeedRandom() and C_GenerateRandom(): seeding (C_SeedRandom) not supported ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20)

The same issue happened with the forked repo you suggested. opensc-debug.txt

Thanks!

[dengert]

In regards to playing "cop": This belongs in #1533.

[dengert]

@erick-orozco Your token is a PIVKey token from Taglio. It has the PIV applet on a Feitian eJAVA Token. I have a T600 and T800 with same ATR, but have not done much with them.

See http://pivkey.zendesk.com and http://pivkey.com/pkadmin.zip for info and their admin software.

The command that is failing is a GENERAL AUTHENTICATE command defined by NIST SP800-73-3 PART2, " 3.2.4 GENERAL AUTHENTICATE Card Command". Then in: "A.1 Authentication of the PIV Card Application Administrator" is an example: "Table 11. Authentication of PIV Card Application Administrator" it shows:

" '00 87 00 9B 04 7C 02 81 00', Client application requests a challenge from the PIV Card Application"

This is the APDU in line 2296 of your debug log that is failing with 6A 82 "Incorrect parameters P1-P2"

Based on their documentation it looks like they don't support a 9B key and all card administration must be done on Windows using their minidriver or pkadmin program.

This is interesting: https://pivkey.zendesk.com/hc/en-us/articles/203862605-Device-API

I will look at mapping their devices to new card->type that will have a card_issue saying can not be used for a challenge. i.e. no random number generation. For now you will have to live the error.

[dengert]

https://pivkey.zendesk.com/hc/en-us/articles/360002596891-Getting-Started

also says: "PIVKey can be used on Linux or Mac OSX with the installation of additional middleware, however, for these environments PIVKey is read-only! The standard PIVKey admin tool on Windows must be used to load certificates to the card.

Using PIVKey with the Firefox browser also requires an additional PKCS11 component that supports the PIV interface. OpenSC is an open source package that can do so."

[erick-orozco]

@dengert I knew that the token we are using is read-only on Linux, but I thought that it will only behave like that when loading certificates and keys to the token. Let me take a step back, and ask what is the test trying to do when it fails (I know is trying to generate random numbers, but for what purpose)?

Thanks!

[dengert]

Some applications may want to use a hardware decice to generate a random number via PKCS#11. The PIV can do that via the APDU that is failing. Not all PIV cards have a 9B key. Looks like PIVKEY can not. I plan to submit a PR for this problem.

On Thu, Nov 29, 2018, 1:26 PM erick-orozco <notifications@github.com wrote:

@dengert https://github.com/dengert I knew that the token we are using is read-only on Linux, but I thought that it will only behave like that when loading certificates and keys to the token. Let me take a step back, and ask what is the test trying to do when it fails (I know is trying to generate random numbers, but for what purpose)?

Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenSC/OpenSC/issues/1531#issuecomment-442960016, or mute the thread https://github.com/notifications/unsubscribe-auth/AA00MeKfsaASvkCE5uWtbcmXUUujxYS-ks5u0DTYgaJpZM4Yapw7 .

[frankmorgner]

What's the status of this issue? Is there anything to do?

[dengert]

I would say it could be closed. There is circumvention for @dpmcgonigle and @erick-orozco is trying to do something the PIVKEY card can not do.

[liamh]

I had the same problem with a DoD CAC/PIV on Linux. While I could do every other function (Firefox, Thunderbird, Chromium, LibreOffice, Openconnect VPN) with the CAC, I could not sign PDF forms with PDF Studio. For the benefit of others, and for possible revision of software, here is what I did:

1. Initially, result of pkcs11-tool --login --test

   Using slot 0 with a present token (0x0)
   Logging in to "LASTNAME.FIRSTNAME.MIDDLE.0123456789"
   Please enter User PIN:
   C_SeedRandom() and C_GenerateRandom():
    seeding (C_SeedRandom) not supported
    ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20)
   Digests:
    all 4 digest functions seem to work
    MD5: OK
    SHA-1: OK
    RIPEMD160: OK
   Signatures (currently only for RSA)
    testing key 0 (PIV AUTH key)
   error: PKCS11 function C_SignFinal failed: rv = CKR_USER_NOT_LOGGED_IN (0x101)
   Aborting.

2. Run opensc-tool -a with the card in the slot, this the result:

     Using reader with a card: Broadcom Corp 5880 [Contacted SmartCard] (0123456789ABCD) 00 00
     3b:db:96:00:80:1f:03:00:31:c0:64:b0:f3:10:00:07:90:00:80

3. Create/edit /etc/opensc/opensc.conf with the second line of the previous result in the card_atr line.
4. Result of pkcs11-tool --login --test (I had to supply PIN multiple times)

     Using slot 0 with a present token (0x0)
     Logging in to "LASTNAME.FIRSTNAME.MIDDLE.0123456789".
     Please enter User PIN:
     C_SeedRandom() and C_GenerateRandom():
       seeding (C_SeedRandom) not supported
       ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20)
     Digests:
       all 4 digest functions seem to work
       MD5: OK
       SHA-1: OK
       RIPEMD160: OK
     Signatures (currently only for RSA)
       testing key 0 (PIV AUTH key)
       all 4 signature functions seem to work
       testing signature mechanisms:
         RSA-X-509: OK
         RSA-PKCS: OK
         SHA1-RSA-PKCS: OK
         MD5-RSA-PKCS: OK
         RIPEMD160-RSA-PKCS: OK
         SHA256-RSA-PKCS: OK
       testing key 1 (2048 bits, label=SIGN key) with 1 signature mechanism
     Logging in to "LASTNAME.FIRSTNAME.MIDDLE.0123456789".
     Please enter context specific PIN:
         RSA-X-509: OK
       testing key 2 (2048 bits, label=KEY MAN key) with 1 signature mechanism -- can't be used to sign/verify, skipping
     Verify (currently only for RSA)
       testing key 0 (PIV AUTH key)
         RSA-X-509: OK
         RSA-PKCS: OK
         SHA1-RSA-PKCS: OK
         MD5-RSA-PKCS: OK
         RIPEMD160-RSA-PKCS: OK
       testing key 1 (SIGN key) with 1 mechanism
     Logging in to "LASTNAME.FIRSTNAME.MIDDLE.0123456789".
     Please enter context specific PIN:
         RSA-X-509: OK
       testing key 2 (KEY MAN key) with 1 mechanism -- can't be used to sign/verify, skipping
     Unwrap: not implemented
     Decryption (currently only for RSA)
       testing key 0 (PIV AUTH key)
         RSA-X-509: OK
         RSA-PKCS: OK
       testing key 1 (SIGN key)
         RSA-X-509: Logging in to "LASTNAME.FIRSTNAME.MIDDLE.0123456789".
     Please enter context specific PIN:
     OK
         RSA-PKCS: Logging in to "LASTNAME.FIRSTNAME.MIDDLE.0123456789".
     Please enter context specific PIN:
     OK
       testing key 2 (KEY MAN key)
         RSA-X-509: OK
         RSA-PKCS: OK
     1 errors

5. Result is that I can now digitally sign PDF forms with PDF Studio.

[liamh]

I request that this issue be reopened. It was closed by @frankmorgner on the basis that the submitter found a workaround. While that workaround (which I have summarized) is effective, it is not a solution. Perhaps these cards do not comply with standards, but given the number of CAC/PIV cards in use, there are almost certainly more that potentially exhibit this problem, and most users will have no idea what OpenSC is, never mind find their way to this issue.

[Jakuje]

AFAIK the issue of CAC/PIV cards losing login state was already addressed too. What OpenSC version are you using?

[liamh]

This is from Debian 10; it is quite possible that it is addressed as Debian stable tends to be old.

ii  opensc                                0.19.0-1                                     amd64        Smart card utilities with support for PKCS#15 compatible cards
ii  opensc-pkcs11:amd64                   0.19.0-1                                     amd64        Smart card utilities with support for PKCS#15 compatible cards

Do you know what issue addressed it? It is not evident here that it was ever addressed, only, as I said, that the submitter had a workaround so the issue was closed.

[frankmorgner]

Change opensc.conf to something like this:

app default {
    # debug = 3;
    # debug_file = %TEMP%\opensc-debug.txt;

    card_atr 3b:db:96:00:80:1f:03:00:31:c0:64:b0:f3:10:00:07:90:00:80 {
                    driver = "PIV-II";
                    type = 14005;
          }
    }
}

Note that those ATRs are already included in the most recent stable version, which doesn't require any modification to opensc.conf

[Jakuje]

AFAIK, it was fixed with PR #1549 which is in 0.20.0, but not in 0.19.0 yet.

[dengert]

Keeping up with what versions of CAC/PIV are in in current use is not easy. They changed the name of the document from 2016. I have found a newer version at https://www.cac.mil/Common-Access-Card/Developer-Resources/

https://www.cac.mil/Portals/53/Documents/DoD%20Token%20utilziation%20and%20variation%20matrix%20v2_06_17October2019.docx?ver=2019-10-18-102519-120

https://github.com/liamh Look this over to see if your CAC card is listed, as current or obsolete.

I will review the table and update card-piv.c

[liamh]

It's the second column "Oberthur ID One 128 v5.5" (mine is v5.5a). It is listed as both current (first page) and obsolete (last page, as "Dual"). They have the same ATR listed. My card expiration is JAN 2022.

I believe that keeping up is not easy - when they required us to add PIVs to our cards, they didn't tell us that some models didn't support that, and that we had to get new cards if our card wouldn't take it. I wasted much time trying to figure out why their instructions didn't work.

Would it help to consult CACKey? I had been using that for years. It works for my current card for applications that support it (but not all do, which is one reason why I moved to OpenSC for everything).

[dengert]

If you want to use the CAC applet vs the PIV applet you can change the order of the drivers in opensc.conf, something like card_drivers = cac, PIV-II; or use environment variable OPENSC_DRIVER=cac if you want to switch back and forth.

OpenSC does not have a way to allow pkcs11 to access more then one one applet on the card at the same time. But I had modification from 2 years ago, but there was no interest in it then. There are cards with OpenPGP and PIV too.

https://github.com/dengert/OpenSC/tree/pkcs11-multi-application-2

In the DOD table look close at the current table vs obsolete, the difference is most likey RSA 2048 with SHA-256 signatures are now (required) current and obsolete had RSA 1024 SHA-1 which are not consifered secure by everyone.

[chadr]

I'm having the same problems as others in this thread.

I'm using the latest build of OpenSC on MacOS.

My ATR is: 3b:f8:13:00:00:81:31:fe:45:50:49:56:4b:45:59:37:30:ff

➜  ~ pkcs11-tool --login --test --verbose
Using slot 0 with a present token (0x0)
Logging in to "Smart Card".
Please enter User PIN: 
C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  ERR: C_GenerateRandom failed: CKR_FUNCTION_NOT_SUPPORTED (0x54)
Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
Signatures (currently only for RSA)
  testing key 0 (CARD AUTH key) 
error: PKCS11 function C_SignFinal failed: rv = CKR_USER_NOT_LOGGED_IN (0x101)
Aborting.

I've tried adding my ATR to the conf file as discussed above, but no luck. This card works fine on Windows.

I appreciate any help you can offer.

[dengert]

The ATR says it is a "PIVKey CP70 (PKI)" https://pivkey.com/ There are several models: https://shop.pivkey.com/products/C70-Series/ Some are Dual contact/contactless: https://shop.pivkey.com/c70-dp-dual-pki-smart-card-with-prox/ "PIVKey implements NIST SP 800-73 Part 3, the PIV Card Command Interface."

NIST SP 800-73 does not allow a PIN to be sent over a contactless interface. Are you using a contact or contactless reader? (NIST SP 800-73-4 can over VCI with secure messaging but I don't think they support version 4".

OpenSC can handle some PIVKey cards, but I have not seen/ a CP70 card.

What version of OpenSC? opensc-tool --info

When you say it works over windows do you mean with pkcs11-tool --test --login? (You maybe using the Microsoft built-in PIV driver, or the vendor provided plug-and-play driver.)

Can you get a debug log: (Note it might expose your PIN and certificates): https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC

[chadr]

Here's the debug log: Gist

Using the default Windows driver.

Using contact mode.

OpenSC 0.22.0

Thanks!

[dengert]

The driver does not recognize the ATR but finds it has a PIV applet on card, so treats it as SC_CARD_TYPE_PIV_II_GENERIC (14001).

Try adding something like the following to opensc.conf to map your ATR to SC_CARD_TYPE_PIV_II_PIVKEY (14011) like other PIVkey cards at https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L243-L254

app default {
    # debug = 3;
    # debug_file = %TEMP%\opensc-debug.txt;

    card_atr 3b:f8:13:00:00:81:31:fe:45:50:49:56:4b:45:59:37:30:ff {
                    driver = "PIV-II";
                    type = 14011;
          }
    }
}

From the debug log, It looks like there is one zipped certificate on the card. pkcs11-tool --test then tries to use the associated key at line 3662: by issuing an RSA sign operation using key 9E: 10 87 07 9E FF 7C 82 01 06 82 00 81 82 01 00 00 ... Then in line 3683 the status returned is 69 82 "Security status not satisfied"

NIST 800-73 Part 1 says: Table 3: "Card Authentication key" (i.e. 9E key) "Security Condition for use" "Always" which means it does not require a PIN. The certificate and key are meant to be used without a PIN so the card can authenticate itself to the host or physical security device as outlined in: B.1.5 Authentication using Card Authentication Key. It appears the card comes with such a certificate and key. https://shop.pivkey.com/c70-dp-dual-pki-smart-card-with-prox/

In other words the PIVKey card is not following the PIV standard and requiring the PIN to be verified to use this key.

This is complicated because the the PIN was verified in line 2965, if the security status on the card is not lost, it may work.

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L3426-L3433 for PIV_Key cards sets a card issue flag:CI_PIV_AID_LOSE_STATE so a select of PIV will not be done once the card is matched to avoid a reset of login state selected. NIST 800-73 says a select of the PIV AID or an attempt to select some AID not recognized by the card will not reset the PIV login state. The PIVKey card is not following the standard in this case.

For other cards to avoid interference of other applications trying to access the card the driver will make sure the PIV applet is selected but AFAIK the PIVKey cards do not have other applets. Thus the select AID is not needed for these card once the card is recognized to get around non compliance issues. This is at the trade off of user must avoid having two applications accessing the card at the same time.

pkcs11-test tries to test all the features of a card to meet the standards. The opensc.conf changes may not be needed if you never really use the "Card Authentication key" with OpenSC. As defined by NIST the key and cert are not intended to be used from a host, as the security is not very strong. But by PIVKey requiring a PIN to use the certificate it gives some stronger security, but not what NIST intended, as the 9A key and the "X.509 Certificate for PIV Authentication" are for authentication of the card holder and the card. For example to authenticate to Windows AD. You should reconsider how you intend to use these cards. Are you planning on using the card without adding additional keys and certificates?

Future releases of OpenSC the PIVKey ATR could be added to the driver to avoid having to modify 'opensc.conf'.

[chadr]

That worked!

So, based on your explanation. Is this a problem with how the cards are being configured by our team? Or is this a problem with this brand of PIV card?

[mouse07410]

Offhand, IMHO, it's how you're team misconfigured (mis-provisioned) the card.

[dengert]

That worked!

I will get the ATR into the driver for next release.

Also found this: https://pivkey.zendesk.com/hc/en-us/articles/208029123-PIVKey-and-OpenSC-Middleware Which says: "OpenSC may not support the PIVKey X.509 Certificate for Card Authentication (9E Key). That is because with PIVKey this certificate is secured with the User PIN." I am sending PIVKey a note on this and how OpenSC can add future cards.

So, based on your explanation. Is this a problem with how the cards are being configured by our team? Or is this a problem with this brand of PIV card?

You did not say how you are configuring the cards, or that you have a team. Since one can buy a single card, you could be doing this for yourself. Based on your github account, looks like you work for the state of Louisiana.

The card has a zipped certificate. https://shop.pivkey.com/products/C70-Series/ says: "Converged Physical & Logical Access in One Smart Card" and has 4 versions and come with or without a "pre programmed certificate" So I assume the card came with a "pre programmed certificate".

It is not clear if you intend to use these for "Physical access" or "Logical access" or both. "Physical access" would include things like door locks. "Logical access" would include authentication to network services like web servers, Active Directory login, email services including signed and/or encrypted email and signed documents. Here the certificates and key are issued by a trusted CA, like a government agency or even a local Active Directory Domain.

NIST PIV specifications can support both. PIVKey has added some additions and has two "issues" that differ with the NIST standards.

The "pre programmed certificate" (and the 9E key) are set by the card vendor and usable for Physical Access. but could be over written, or if not need buy the cards without a pre programmed certificate, or issue the key and certificate locally.

With logical access cards are usually issued by some organization or government agency as part of an ID card with the 9A authentication certificate and key for authentication, with a user ID, and a 9C signature key and certificate used for signatures with an e-mail extension and a 9D key and certificate used for encryption. The 9D key be held by a key escrow system so as to recover encrypted data. https://csrc.nist.gov/glossary/term/key_escrow_system. The 9E key and certificate are usually not used with Logical access.

Depending on your needs you may want to look at the federal government approved cards at: https://www.idmanagement.gov/approved-products-list-piv/#approved-piv-cards

In addition to the approved PIV cards many vendors or open source versions of PIV cards or applets are out there.one.

[chadr]

Appreciate the help and knowledge tranfer! Would it helpful to you if I donated one of our new cards to the project?