Can't decrypt with pkcs11-tool #765
Comments
|
How big is the encrypted.bin file? Not sure why it worked with 0.11 but not 015. On 5/18/2016 8:28 AM, cesarkuroiwa wrote:
Douglas E. Engert [email protected] |
|
The size of the encrypted file is 128 bytes, but the size of the original message is much smaller (only 8 bytes). The size of the RSA key is 1024 bits. Just ran the command with -vvvvvv and the output was the same: |
|
the -vvvvvvvv should hav we produced a debug trace. On 5/18/2016 1:50 PM, cesarkuroiwa wrote:
Douglas E. Engert [email protected] |
|
actually you must set the debug level in |
|
What is an "OpenSC card"? You upgraded from 0.11? What have you done in the last 7 years??? |
|
Hi, |
|
Hi Since pkcs11-tool still doesn't have the command '--decrypt' in this version, I used the openssl engine, and to my astonishment, it actually worked. So apparently there's something different with the new version 0.15. |
|
What might also be helpful is a opensc debug trace using the older OpenSC 0.11 that used to work for you if you still have a version of it. On 5/19/2016 4:10 PM, cesarkuroiwa wrote:
Douglas E. Engert [email protected] |
|
Unfortunately, I don't have the trace from version 0.11, but what I could get is the trace from the working test with version 0.13, using openssl engine: |
|
Also can you run pkcs11-tool --module /usr/local/lib/opensc-pkcs11.so -O |
|
I'm not sure what's wrong with the OP's installation, but here's what I observe: It may be complicated needlessly, but still demonstrates the basic functionality. I get the same successful results with the current master. |
|
Problem appears to be related to card-starcos.c: The 2 traces sent are only partial traces, and so the max_send_size and max_recv_size With card->max_send_size=128 it looks like apdu.c tries to use chaining in the older version that worked, the APDU sent was: based in the comments to fix read_binary, setting max_send and max_recv_size may be the wrong way to fix read_binary. @frankmorgner @viktorTarasov We have made changes recently to how max_send_size and max_recv_size are handled. Does card-startcos.c need to be updated? |
|
It's very likely that |
|
@cesarkuroiwa you still have not given the type of card you are using. We don't even know which ATR it has. |
|
Hi guys I'm not sure if this will be helpful, but here goes some info on the reader and card: |
|
The ATR maps to SC_CARD_TYPE_STARCOS_GENERIC. But e-mail from 2006 indicates the The max_send_size = 128 was in the code as of 0.11.2 (oldest tag is git). The driver uses the iso7816.c for many functions and the iso7816.c fixup_transceive_length() will use sc_get_max_send_size(card) and set SC_APDU_FLAGS_CHAINING if needed. That appears to be what is happening with the decrypt operation and the card can not handle chaining or a length of 128 with decrypt. The card had no problem with length 129 with pass versions of OpenSC so the Many older card drivers set max_send_size. (card-atrust-acos.c and card-miocos.c have comments about limiting read and write binary.) It looks like in the past, this may have been to control the size used with read and write binary, but not to control the size of a crypto operation. But with newer OpenSC code the meaning of max_send_size is now being applied to the crypto operations too. This appears to be the source of the current problem. sc_write_binary() will use sc_get_max_send_size(card) and break up a write_binary into multiple smaller operations. Do we need a max_send_binary_size and max_recv_binary_size that only used by sc_read_binary and sc_write_binary. These could be less then the max_send_size and max_recv_size? |
|
If that's the case, one solution for starcos would be to set However,. I'd prefer checking the manual over fishing in troubled waters. |
|
I think think there may be more troubled waters then just this card. There are 12 other card drivers is an attempt to setup a framework to solve the problem for all 13 drivers. It is only addressing the card-statrcos.c for now. It needs to be tested. https://github.com/cesarkuroiwa can you try this and see if it fixes your problem? |
|
Hi |
|
@cesarkuroiwa It would be nice if you could track down the problem to a specific commit, e.g. with |
|
@dengert we still need to figure out what the actual problem is, here, before applying any fixes. From a card's perspective it simply does not make much sense to have a low limit for incoming/outgoing data of a read binary, but to have a high limit for signature creation or for deciphering. I suspect that @cesarkuroiwa 's card could safely choose a higher value of |
Douglas E. Engert [email protected] |
|
@dengert [Cesar and I work together] I've also tried it against 0.16.0rc1 and it printed a different error message: |
Using slot 1 with a present token (0x1) Using slot 0 with a present token (0x0) Aborting. Douglas E. Engert [email protected] |
|
@dengert Debug output for patched 0.16.0rc1 and patched towards-0.16.0 are available: opensc-debug-0.16.0rc1.log opensc-debug-towards-0.16.0.log |
|
The read_binary using 128 looks like it worked. card-starcos.c:1709:starcos_pin_cmd: only supported for STARCOS 3.4 cards CHECK_ONLY_SUPPORTED_V3_4(card); This looks like it should not be here. 19bbfc7 https://github.com/fancycode can you suggest a fix for this problem? What is different abont a pin_cmd and a 3.4 pin_cmd? |
|
@cesarkuroiwa @hkkobayashi Could you try decipher without fixing-transceive-length (comment in the line https://github.com/OpenSC/OpenSC/blob/towards-opensc-0.16.0/src/libopensc/iso7816.c#L952) ? Afaik, earlier, the decision to use APDU-CHAIN was made on the card driver level, |
|
I pushed to towards_0.16.0 few debug messages more. @cesarkuroiwa @hkkobayashi Now for the decipher test the line to comment in is https://github.com/OpenSC/OpenSC/blob/towards-opensc-0.16.0/src/libopensc/iso7816.c#L955 |
|
What about line: |
|
@dengert I think yes. Will be waiting for test results from @cesarkuroiwa and @hkkobayashi. |
|
@cesarkuroiwa could you please check whether #765 retrieves the correct maximum of the transceive length for your card? |
|
@frankmorgner, I am not very intimate with the inner workings of OpenSC, so I have to say I don't understand much of what you're saying. What I can say is that we're currently running @dengert 's patch on top of release 0.15, and it seems to be working fine. |
|
I have a starcos card that announces its io buffer length in EF.ATR. With #765 this value is taken for |
|
(Found this hint in my manual, actually) |
|
@cesarkuroiwa, sorry, I posted a bad link. Please check whether #812 gets the correct length of IO buffers for your card (82d6891 should not be needed anymore). |
|
This solution doesn't seem to work with STARCOS SPK 2.3, which needs more than 128 bytes (129 for decryption), but doesn't have an EF.ATR file (verbose logs show I'm thinking of two possible ways to properly fix this:
I have attached two logs, one running in 0.11.4 where the decryption is successful, another in 0.19 which fails because the data field is 128 bytes instead of 129. Any thoughts? |
|
@gabrielmuller please try #1496 |
|
#1496 almost works. It sends 129 bytes of data, but there are some problems:
I'm not sure why the card expects response length zero (or is it 256?) so I'll leave the fix to your best judgement. I've included a log with Le = 0x00 which works and one with the default Le size (max recv size, or 0x80), which doesn't. |
closes OpenSC#765 fixes OpenSC#1495
|
@gabrielmuller should work now |
|
Wrong length again, this time I believe because it's sending Lc in three bytes and Le in two. Here's the relevant part: |
|
Changing |
|
I think the problem is that extended length is not supported, I've adapted the pull request... |
|
Now it's failing This 1024 value comes from |
|
pkcs15-crypt.c is passing in a 1024 byte buffer, big enough for any decipher. (8192 bit RSA for example). So to handle a 2048 bit RSA key and send the padding byte would require 257 bytes. The card must then support either extended APDU or command chaining. It may depend on the card, so this comment may be wrong: says opensc did not like the apdu, as it says it is a short APDU, so lc and le are limited to 255 and 256 |
|
Here's something that works:
Is this a sensible solution? |
|
It may for your card, but break others. The driver can support many cards some older some newer. I do not have any of these cards. Frank has made many changes which make sense. |
|
I've made a change to keep the short length limit... Yes, it could be possible to raise the 128 byte limit, but since I don't have a manual of starcos 2.x for verification, I'd like to leave it as is. |
|
It's working now. Thank you! |
|
Hello everybody. |
Expected behaviour
Should decrypt an encrypted file with the private key from a smartcard
Actual behaviour
PS: We recently update from opensc 0.11 to 0.15 and this stopped working, including when using OpenSSL engine.
The text was updated successfully, but these errors were encountered: