-
Notifications
You must be signed in to change notification settings - Fork 711
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No certificates recognized on a Gemalto IDPrime 940 #2956
Comments
Hi. Thank you for the interest in the OpenSC project! We are adding support for the IDPrime cards slowly over last couple of releases with the cards we have access to so any new input is very useful for us. Good thing is that the card is correctly detected. On the first review of the log, it sounds like there is some logical error in reading the certificate (unless that is the part you were heavily redacting, but I assume you removed just the part with the PIN). Can you confirm, there were no removed likes around the line 711 of the log? The reading failure sounds suspicious as it looks like the reading is not called at all:
There is a logic to parse compressed certificates, but if the certificate is not compressed, the read is kept on 0, leading to this failure. Can you try the following patch if it helps?
|
Thank you for the quick reply! I did not remove any lines of the log, no - I just blacked out the value of the PIN code. The suggested patch did not resolve the issue, but the errors appeared to change. Here's the new log. https://gist.github.com/Nihlus/2bb99bdf6d1b04cb0a880d6dbee7a281 |
I dug into the code a little myself, and realized that there were other instances of direct use of I'm remiss to share those logs unless I have to since they contain live certificates, but I suspect it has to do with the size of the object being read - it's only ever reading 256 bytes, which seems incorrect to me. |
Do you have a patch and debug log towards the error? It might be that for the uncompressed certificates, we need to skip some bytes in the beginning too, which might not be done now. |
I went ahead and removed the certificates from the logs, though I suspect it may cause some trouble when trying to determine the cause. I'll see if I can get my hands on a test card instead of a live one so I can share unredacted logs. https://gist.github.com/Nihlus/34662a779b86aca913ddb7f3f9edd4e8 Patch is as below; I'm not all that familiar with OpenSC so I may have made some silly mistakes. --- a/src/libopensc/card-idprime.c
+++ b/src/libopensc/card-idprime.c
@@ -886,30 +886,31 @@
if (!priv->cached && offset == 0) {
/* Read what was reported by FCI from select command */
- int left = priv->file_size;
+ int left = priv->file_size > 0 ? priv->file_size : count;
+ int file_size = left;
size_t read = 0;
// this function is called to read and uncompress the certificate
u8 buffer[SC_MAX_EXT_APDU_BUFFER_SIZE];
u8 *data_buffer = buffer;
- if (sizeof(buffer) < count || sizeof(buffer) < priv->file_size) {
+ if (sizeof(buffer) < count || sizeof(buffer) < (size_t)file_size) {
LOG_FUNC_RETURN(card->ctx, SC_ERROR_INTERNAL);
}
while (left > 0) {
- r = iso_ops->read_binary(card, read, buffer + read, priv->file_size - read, flags);
+ r = iso_ops->read_binary(card, read, buffer + read, file_size - read, flags);
if (r <= 0) {
LOG_FUNC_RETURN(card->ctx, r);
}
left -= r;
read += r;
}
- if (read < 4 || read != priv->file_size) {
+ if (read < 4 || read != (size_t)file_size) {
LOG_FUNC_RETURN(card->ctx, SC_ERROR_INVALID_DATA);
}
if (buffer[0] == 1 && buffer[1] == 0) {
/* Data will be decompressed later */
data_buffer += 4;
- r = priv->file_size - 4;
+ r = file_size - 4;
if (flags)
*flags |= SC_FILE_FLAG_COMPRESSED_AUTO;
} |
Ah, now I see what's going on. It's only reading a single chunk of the file in |
Got it to work! If you unconditionally cache the real file size in On top of that, I found a likely bug with the cache allocation - Subject: [PATCH] card-idprime.c: unconditionally cache real file size
---
Index: src/libopensc/card-idprime.c
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/libopensc/card-idprime.c b/src/libopensc/card-idprime.c
--- a/src/libopensc/card-idprime.c (revision d43cfd8afc59c872f13226b7076cdd2d817aca32)
+++ b/src/libopensc/card-idprime.c (date 1702395880220)
@@ -861,13 +861,8 @@
r = iso_ops->select_file(card, in_path, file_out);
if (r == SC_SUCCESS && file_out != NULL) {
- /* Try to read first bytes of the file to fix FCI in case of
- * compressed certififcate */
- len = iso_ops->read_binary(card, 0, data, data_len, 0);
- if (len == HEADER_LEN && data[0] == 0x01 && data[1] == 0x00) {
- /* Cache the real file size for the caching read_binary() */
- priv->file_size = (*file_out)->size;
- }
+ /* Cache the real file size for the caching read_binary() */
+ priv->file_size = (*file_out)->size;
}
/* Return the exit code of the select command */
return r;
@@ -912,7 +907,9 @@
r = priv->file_size - 4;
if (flags)
*flags |= SC_FILE_FLAG_COMPRESSED_AUTO;
- }
+ } else {
+ r = priv->file_size;
+ }
priv->cache_buf = malloc(r);
if (priv->cache_buf == NULL) {
return SC_ERROR_OUT_OF_MEMORY;
Unfortunately, the troubles don't seem to end there, as signing with the certificate (
I've saved debug logs for this, but I need to scrub them first. Will get back to you once I either do that or get that test card. |
Good to hear that! You can also isolate the signature operation with pkcs11-tool to get cleaner log without running the whole tests: https://github.com/OpenSC/OpenSC/wiki/Using-pkcs11-tool-and-OpenSSL I think not much more than the content of the certificates and the PIN values should have possible confidential content. Feel free to open (even WIP) PR. |
PR opened! Here are the scrubbed logs for the signing operation: https://gist.github.com/Nihlus/1c78a04cc80f04857757fa8b97045407 |
this sounds the card returns some invalid data after request for the signature (its different from the previous error which was saying OpenSC/src/libopensc/card-idprime.c Lines 447 to 471 in 6b568b1
This is used in the set security environment APDU before making signature. If you have the proprietary driver and you can intercept APDUs it is using to see what key reference is used for your key (and then try to adjust the guessing to work for your card, ideally without breaking it for other cards). |
I've got the driver now (downloadable from https://service.secmaker.com/download-access.aspx) - how would I intercept APDUs in this case? |
on linux, it will most probably use pcsc-lite as the PCSC so the simplest thing is to stop the pcscd service, run it in forerground in the debug mode (with |
That did it, thanks. It looks like the proprietary module is also having trouble with the signing operation on the card, producing a Could you test with one of the IDPrime cards with a compressed certificate that you have on hand using the linked-to module? I'd like to rule out an issue with the card itself before going too deep into any one rabbit hole. I've found several PKCS#11 modules from various sources that claim to support the IDPrime 940, but none of them have fully worked. |
Aha, nevermind - there was a mostly-hidden patch version available too which works correctly (https://supportportal.thalesgroup.com/csm?id=kb_restricted&sysparm_article=KB0026523). I'll use this library as a reference point in future work. |
Okay, after some fiddling I've got the key reference for my certificate sniffed out (using a modified version of https://github.com/eIDuy/apdu-parser - quite a nice program).
I'm quite a bit out of my depth here, I'm afraid. I can't see any selection of file 0005 in the logs from the proprietary module, which - if I'm understanding the code correctly - should be the file with the key reference map. Instead, it looks at the following files in order: 0201 (16 bytes) Whatever it finds in those files are apparently enough, as after that it can list out all the objects on the card. There are a couple of Interestingly, the IDs used appear to be GUIDs with an extra 8 bytes on the end - the object labels are properly formatted GUIDs, and the ID is that GUID without dashes and with the extra data appended. Example output:
|
The data is TLV encoded (INS=0x22, P1,P2=0x41,0xB6, data len 6B). https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L976 We are mostly up for the key references, which is the last block While in the debug log from previous comments, we read it as
This looks like the code goes through the default branch of the switch: OpenSC/src/libopensc/card-idprime.c Lines 469 to 472 in 53f81e7
The card is detected as |
Changing the ATR mask helped! We're now past that problem, and there's seemingly just one more to go. Proprietary:
OpenSC:
It should be noted that the proprietary module requires libssl1.1, so there's probably some limitation in this card regarding the available hash algorithms or how to request them. |
Good to hear that it worked for you! I have the test cards in the office so I will be able to test your changes next week. The PKCS-OAEP encryption is not very widely used. For most of the logging into your infrastructure, you should be good with signatures. Given the large variety of OAEP parameters, the
The error with the proprietary driver is probably related to the old version of openssl as you mention. And given the card does not support SHA1 digestst with signatures/mgf, it looks like it is not even tried. |
Ah, excellent - p11test produces the following output, which looks pretty good to my untrained eyes. https://gist.github.com/Nihlus/90a244b35a8d700430900724bfcdb06c |
Right. There are three working OAEP combinations:
I am not sure why the SHA256 did not work from the pkcs11-tool though. If you want to dig into this deeper, you can see what the pkcs11-tool does differently. But I think you have mostly working card by now for what you need :) I will update the PR with the test results next week (please update also the ATR matching in the PR as we discussed above). |
Yup, I've pushed those changes! |
Problem Description
I have a company-issued Gemalto IDPrime 940 (allegedly) with a user certificate on it used for logging into our infrastructure. I've been given the task of investigating integration with Linux without the use of proprietary modules to interface with the card, and am currently experimenting with OpenSC 0.24.0-rc2.
The card is properly recognized as an IDPrime 940 by OpenSC, and I can successfully authenticate with it using my PIN. However, none of the tools available (pkcs11-tool, pkcs15-tool, opensc-tool, etc) display any certificates on the card.
There should be a single RSA2048 certificate issued to me with the appropriate attributes for smartcard login on the card, and I've verified that that is the case on a Windows machine running Net iD Access (the proprietary module currently in use).
Steps to reproduce
pkcs11-tool --login -O
Logs
https://gist.github.com/Nihlus/cdc6cea6d051a732952a0f4e2e6c3075
I believe I've redacted any sensitive data in the logs; however, I'd very much appreciate a heads-up if I haven't.
The text was updated successfully, but these errors were encountered: