OpenSC Minidriver Does Not Display the Second Key Container of JPKI Card When certutil -scinfo Is Executed #3169
Comments
|
This is deliberate, because the DS certificate requires authentication before read out is permitted: OpenSC/src/libopensc/pkcs15-jpki.c Line 74 in d508726 Not sure if this is supported by Windows in general, but you can try to set the option pin_protected_certificate to declassify. |
|
How can I edit the minidriver.c to make a PIN challenge before read. |
|
Have you tried setting |
|
where is the config file? |
|
Does it prompt for the user PIN at all? In your comment you say: As noted in the code the user sign key has user_consent = 1, but minidriver in not handling this, and it looks like card is enforcing reading of certificate without some PIN authentication. If the vendor's minidriver can work correctly, we can get OpenSC minidriver to work. As I said in some other comment this is very similar to #3159. |
This comment was marked as duplicate.
This comment was marked as duplicate.
1 similar comment
This comment was marked as duplicate.
This comment was marked as duplicate.
|
Try In your comment you say: "Command: 00 20 00 80 06 31 32 33 34 35 36 As noted in the code the user sign key has user_consent = 1, but minidriver in not handling this, and it looks like card is enforcing reading of certificate without some PIN authentication. If the vendor's minidriver can work correctly, we can get OpenSC minidriver to work. As I said in some other comment this is very similar to #3159. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
|
Sorry about multiple posts. Github was very slow and said: "There was a problem saving your comment. Please try again." |
Yes the PIN is a example of 123456 the second slot requires the PIN before reading, the command was copied from another bogs showing the process of auth in Japanese. |
|
@dengert I edited the opensc.conf, but it is not work. |
|
@sdy623 please have a look at: #3167 (comment) |
|
Thank you, I want to try download your form and compile it |
|
You can use I normally do not build on windows, but use the the builds built on github and download 2 msi files for win32 and win64. See #3159 (comment) |
|
@dengert I test with this, unfortunately it didn't work. Same error of I posted |
|
@hamano Can you comment on this issue with JPKI and OpenSC minidriver? The JPKI only card is the only card that not not make certificates and pubkeys readable without having to authenticate. @sdy623 can you try running these commands: We are looking to see if you can read certificates and pubkeys without logging in. |
|
|
Yes, the sign certificate is also protected by a PIN. This certificate contains the name, address, birth, and gender in subject alternative name, and it has a contactless interface. |
|
@sdy623 Please try with "--auth-id The auth ID of the PIN to use"
And looking at the code closer, can you try reading the CA certificates The debug logs shows @hamano And I need to look at |
Add SC_PKCS15_CO_FLAG_PRIVATE on "Digital Signature Public Key" and set pubkey_obj.flags and pubkey_obj.auth_id to use the Sign KEY so minidriver.c can request the pin before reading the public key. Card enforces this as per specs. Possible fix for OpenSC#3169 On branch minidriver-PinCacheAlwaysPrompt Changes to be committed: modified: libopensc/pkcs15-jpki.c
|
For For |
|
I just finished building the minidriver code with the changes proposed in #3169 (comment) See: #3167 If you get the "Please enter PIN [Digital Signature PIN]: PIN code too short, try again." |
|
I used the newer driver |
|
The certutil -scinfo still doesn't works |
|
Looks like the pkcs15 code in |
|
#3167 get further with the JPKI cards, but these cards are the only one I know of that does not make the public key readable. I would suggest you use the card vendor's minidriver on Windows. The problem is there is no easy way to force a PIN verify before trying to read the public key in the minidriver. #3167 does have the code in OpenSC to get the PKCS15 routines to work. #3167 has the code to force a pin prompt before trying to use the Sign KEY for keys marked with user_consent. Maybe @hamano can look at this closer. |
Add SC_PKCS15_CO_FLAG_PRIVATE on "Digital Signature Public Key" and set pubkey_obj.flags and pubkey_obj.auth_id to use the Sign KEY so minidriver.c can request the pin before reading the public key. Card enforces this as perspecs. Partial fix for OpenSC#3169 Only pkcs15-jpki.c is changed. In addition to changes in OpenSC#3167 that address "user_consent" using "PinCacheAlwaysPrompt", The JPKI card forces the user to verify the Sign PIN before the public key is read. But to use the Sign KEY, Windows minidriver specs V7.07 says: the "CCP_CONTAINER_INFO" contains "cbSigPublicKey" and "pbSigPublicKey" which is needed before the key is selected. It might be possible to add bogus information in these and substitute the real values at a later time. But this will require someone with a working card. On branch minidriver-PinCacheAlwaysPrompt Changes to be committed: modified: libopensc/pkcs15-jpki.c On branch JPKI-Improvments Changes to be committed: modified: libopensc/pkcs15-jpki.c
Problem Description
Overview:
When using the OpenSC minidriver with a JPKI card, pkcs15-tool --list-keys correctly displays both key containers. However, when running certutil -scinfo, only the first key container is displayed, and the second key (Digital Signature Key) is not recognized. This issue may relate to the security handling or the minidriver's implementation for the JPKI card.
Details:
Reader and Card Used: Hitachi/Maxell M-500U/M-520U 0
Operating System and Version: Windows 11 22631.3672
OpenSC Version: 0.25.1.0
Other Tools/Aplications: Windows certutil
Error Messages:
certutil -scinfo does not display the Digital Signature Key, although pkcs15-tool --list-keys lists it as available.
Steps to Reproduce
Setup Environment: Insert JPKI card into the reader (Hitachi/Maxell M-500U/M-520U 0).
List Keys Using OpenSC Tool: Run pkcs15-tool --list-keys. Both keys should be displayed as listed in the problem description.
Verify with Windows Tool: Run certutil -scinfo on the same setup.
Observe the Output: Note that only the first key (User Authentication Key) is displayed, and the second key (Digital Signature Key) is missing from the output.
Expected Behavior
certutil -scinfo should display both two JPKI certs as does pkcs15-tool --list-keys, indicating proper interaction and recognition by the minidriver and the OS.
Actual Behavior
Only the first cert is displayed in the certutil -scinfo output, indicating a potential issue in the minidriver’s handling of multiple keys or specific security protocols for the second key container.
Additional Info:
According to the JPKI protocol, reading the Digital Signature Public Key (bContainerIndex=1) before READ BINARY: 00 B0 00 00 04 requires a PIN challenge:
SELECT FILE: Public Personal Authentication Application
Command: 00 A4 04 0C 0A D3 92 F0 00 26 01 00 00 00 01
Response: 90 00
SELECT FILE: Signature PIN
Command: 00 A4 02 0C 02 00 1B
Response: 90 00
VERIFY: Signature PIN (Password=123456)
Command: 00 20 00 80 06 31 32 33 34 35 36
Response: 90 00
SELECT FILE: Signature Certificate
Command: 00 A4 02 0C 02 00 01
Response: 90 00
READ BINARY: Read the first 4 bytes to determine the certificate's byte length
Command: 00 B0 00 00 04
Response: 30 82 06 CA 90 00
READ BINARY: Read the full certificate data (excluding the first 4 bytes, remaining 0x06CA bytes)
Command: 00 B0 00 04 00 06 CA
Response: 30 82 ...certificate data... 90 00
This discrepancy in behavior between pkcs15-tool and certutil -scinfo may indicate an issue with how the OpenSC minidriver is handling the card's security protocols or with the implementation of the JPKI card support.
Logs
https://pastebin.com/fuRSSLeY
The text was updated successfully, but these errors were encountered: