Aventra MyEID cards fail to sign data with more than 51 bytes #2173
Comments
|
I can reproduce this on MyEID 4.0.1. Just for completeness, MSE APDU: TAG 80, value 02 corresponds to "no hash mechanism, only pad data to key modulus" From MyEID documentation (2.3.0, page 31): This corresponds to about 51 bytes for 1024 RSA key.. There is way to run RAW RSA operation .. but data len must match key modulus. I can't comment on how exactly |
|
Using an RSA 1024 bit key is not considered secure these days. When it was considered secure, these was no SHA-512. See: This shows the APDUs and card capabilities. The APDU in the trace is This would be the APDU before the the one you sent above. |
|
I agree that 1024 bits is hardly recommended these days, but unfortunately users are still using it. That's how we initially got this bug report. Hashing is already done in software with Still, those two should work together if not for MyEID's odd restriction of 40% of the key size. And since we've seen this in the wild some handling in OpenSC would be better. Or at least a check and better error message. |
|
There is way to use RSA-X-509 mechanism, but message must be constructed in software, by concatenating parts:
1st part size is to be calculated from modulus size. BTW 40% payload size is used to prevent padding oracle attack.... |
|
Based on @popovec APDU of SHA-512 is not involved at all. And your test pkcs11-test is doing the same. Best I can tell, the driver does check for the 40% limitation. And it could not do this until runtime after the key is selected. And error message would have to fit within PKCS11 CKR_* values. And other cards might start doing the same. There is a why in PKCS11 to limit mechanisms to individual keys. "CKA_ALLOWED_MECHANISMS - But it looks like OpenSC does not support this at the PKCS11 layer, or driver layer. /pkcs11-tool.c has 4 references to it. When you say "we" do you mean https://www.cendio.com/ ? Pull requests are always welcome. |
|
Correction : Best I can tell, the driver does NOT check for the 40% limitation |
Yes, this is checked by card..... for example same driver (myeid) with OsEID card is able to sign modulus - 11 bytes in this mode. |
|
You said: "Discovered when trying to use SHA512 as the hash algorithm." So does this only happen when the user specifies a specific hash? |
|
Supported RSA padding/hashes (from card-myeid.c): This is indicated by What card really can do before real RSA operation is done:
SHA1 is never computed in card. (BTW, I am missing "hw" flag in lines reported by pkcs11-tool if there is SHA1 operation - is this because SHA1 is computed outside card ?, If this is the case, why there is "hw" in RSA-PKCS-PSS ? there is no PSS support internally in card.. ) There is a way to add support SHA256-RSA-PKCS and other hashes into card-myeid.c. Driver only need to signalize support for this hash. If sign with this hash is requested, driver insert internally SHA256 prefix and request the card to do PKCS#1 padding before RSA sign operation. Of course, for small key and SHA512 this fail, because limit of 40% payload .. in this case driver must add PKCS#1 padding and request the card to do RAW RSA operation. IMHO, it is better to accept 40% limit and not force this operation... |
|
Here draft for SHA256-RSA-PKCS support in MyEID driver: Now Now I can use This patch is draft, but if this is acceptable method to extend MyEID functionality, I create PR with more error checking and support for more hashes. @hhonkanen What is your opinion? |
|
Your patch looks like a nice addition. The PKCS11 "hw" bit means the mechanism is done in hardware. But there is no clear way to map this to what some cards can or can not do in hardware. Some can actually do the hash or the last round of the hash if presented with all the data to be hashed. From what you have said, the MyEID card will expects either a SHA1 or SHA256 to be done in software and the card will add the digest and do the PKCS1.5 padding on the card. Your card appears to only support key up to 2048. I have a MYEID Aventra card from 2017.
One could assume if card supports RSA 3072, then it supports SHA384, and if it supports RSA 4096 it supports SHA512. So your mod could be extended to support SHA384-RSA-PKCS and SHA512-RSA-PKCS. Someone with a newer card, and documentation could say if the assumption is correct and worth adding code for it. Going back to the original question, Your mod with SHA384-RSA-PKCS and SHA512-RSA-PKCS could help address the misuse, by indicating which of the hash/key sizes are supported by the card. But the 40% of key size with RSA_RAW will still be enforced by the card. I don't see any easy fix for this. |
|
40% is limit is forced by card, only if card is requested to do PKCS#1 v1.5 padding. If I have 1024 bit RSA key, then RAW RSA operation is running for 128 bytes (64 bytes SHA512, 19 bytes SHA512 prefix, 45 bytes padding) , .. but PKCS#1 padding and SHA512 prefix handling must be done in driver - and this is no problem, only IMHO any assumption (related to MyEID card) about SHA512 SHA384 etc. is irrelevant .. we doing HASH inside opensc, not inside card, card is requested only for padding and prefix handling. Because this can be done in driver, we can ignore the RFU algo references in Aventra doc. For example (used patch above, MyEID 4.0.1, max 2048 bit key), SHA256-RSA-PKCS-PSS and SHA256-RSA-PKCS is not working for 512 and 768 bit RSA KEY - but that, of course, was to be expected - and this is not problem, using RSA keys below 1024 bit is really deprecated and unsecure.
Yes, I deduced this from MyEID doc and card-myeid.c - I analyzed it when I wrote the OsEID implementation. |
|
The patch above is only partial workaround.. it doesn't solve another important thing.
There is already support for adding digest info prefix in opensc code: src/libopensc/padding.c, function sc_pkcs1_encode(). For example card-starcos.c uses them. But why this is not done globally for all cards (or at least for cards that have support for RSA RAW)? Any card with RAW RSA support can run SHA256-RSA-PKCS or SHA512-RSA-PKCS etc .. The same goes for padding - if SC_ALGORITHM_RSA_RAW is set, there is no problem to run PKCS1 or PSS or OAEP padding.. But after reading the comment in I made a new patch and now if I run Tested by OpenSC interprets SC_ALGORITHM_RSA_HASHES in a strange way. Hashes and digest info prefixes are mixed ..
It is necessary to distinguish mainly points 1 and 2. According to the flags, we then present which mechanisms are supported by hw / sw For example the MyEID card then need flags by categories:
|
|
The simplest way to use 1024 bit key and SHA512 with MyEID is recompiling OpenSC, here patch: Tested, MyEID 4.0.1 SHA512-RSA-PKCS is now working for key size 1024,1536 2048 ..
SHA512-RSA-PKCS-PSS is now working for key size 1536 and bigger, Patch above affect only MyEID card, there is not used card hardware for PKCS#1 v1.5 padding, this padding is now inserted in software. (MSE APDU This patch does not affect normal functionality i.e. RSA decipher, RSA raw signature or RSA signature with SHA1 etc.. However, this is only a temporary fix for the strange behavior of OpenSC to the SC_ALGORITHM_RSA_HASH_* flags. |
|
Removing SC_ALGORITHM_RSA_HASH_SHA1 is reasonable, but that is only my option. The 40% size is enforced by the card when doing PKCS1. I am not convinced this is to thwart a RSA padding oracle attack or some other reason. I consider using RSA 1024 is more of a security risk. This could be an option in opensc.conf. (4 drivers do Then change your patch to something like: Anyone else have a thought on the 40% rule? |
|
In short, I don't see benefits in 40% rule. |
|
Making MyEID driver configurable - to disable/enable internal PKCS#1 padding function and disable/enable internal digest info prefix insertion - from opensc.conf or environment variable make a sense. There is bigger problem .., all HASH functions except SHA1 are currently blocked with SC_ALGORITHM_RSA_HASH_SHA1 enabled. And this has nothing to do with 40% payload limit. SHA256-RSA-PKCS can be used with this limit but is not listed in I wonder which other cards are affected by this problem. |
|
What happens if you add SC_ALGORITHM_RSA_HASH_SHA256 to the flags in the card driver and 128, 384 and 512. pkcs11/framework-pkcs15.c register_mechanisms is where the PKCS11 Mechanisms are created from see The point here is that later pkcs15-sec.c calls sc_get_encoding_flags in padding.c which tries to separate the padding, digest, hash, and crypto operations in to what need to be done in software and what is done on the card. look in debug logs for this message https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-sec.c#L670 This is some of the more complicated code in OpenSC and should not be changed if at all possible. All cards depend on this code. One problem is there are only 32 SC_ALGORITHM_* bits. I think 30 are used. Some future change need to make this 64. |
|
@dengert I did the test as you suggested: debug info: SHA1 is working but SHA256 no .. for SHA256-RSA-PKCS wrong signature is returned (missing sha256 digest info) Why this is not working is clear from the code in In another place of OpenSC code if I repeat, one flag is used for two different purposes.
What about separate flags for padding ..
|
|
Have a look at: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-myeid.c#L722
Debug info from above comment looks correct:
The card driver's Have a look at A debug log, gdb debugging could show more. More code maybe needed in the card driver to indicate which digest is to be passed i.e. the '42 And there is a also a But the original bug report was to allow handling of RSA 1024 with SHA512 and avoid the 40% restriction by doing RSA_RAW. It might also be possible to use one of the two unused Questions for debugging to help answer what is going on:
|
|
@dengert As I said, we have a bigger problem (related to this issue)... except for SHA1, no other hash works if SC_ALGORITHM_RSA_HASH_SHA1 is set. Setting the SC_ALGORITHM_RSA_HASH_SHA256 flag does not help either, I will document once more: Tests below with patched driver .. problematic part: (padding.c line 490... and this is consequence of mixing SC_ALGORITHM_RSA_HASH_* flag functions..) Here is already prepared message for card and in wrong format .. (without digest info, see below) MSE: verification: For completeness ..... edited, appended .. MSE: signature: |
|
OK, I think we are close: Note that tag 80 01 XY is really from table 49 and consists of 2 - 4 bit values. Y is 2 = PSO: COMPUTE DIGITAL SIGNATURE which says what it will do. I would expect that for the SHA256 if this was set to XY was set 42 it would work. I think the card driver is setting both in line This should only be a test. The real code should involve what is output of This problem is very similar to #1987 where key refs was a combination of algrothms and key ref. |
|
TAG 0x80 with value 0x42 is not accepted by MyEID card, because this value is RFU (from Aventra doc .. ).. and even if this add this prefix, we need to do this for all (in card) supported and unsupported hashes. Be aware if I block SC_ALGORITHM_RSA_HASH_SHA1, i have lot of mechanisms available #2173 (comment) and fully functional ! If I add SC_ALGORITHM_RSA_HASH_SHA256 .. only SHA256-RSA-PKCS algo is added and I miss sha384, sha512 which in the previous case will be added. Before I try any tests and document anything else, I would like you to explain to me, which of the following points is marked with the SC_ALGORITHM_RSA_HASH_* flag. The card run RSA operation on concatenated:
If some of card driver set the SC_ALGORITHM_RSA_HASH_SHA1 flag.. what is affected ? point 2. or 3. or both ? |
|
The above was meant to be a test, to see if the 042 value really is RFU. So you tried the patch to send 0x42? And card did not accept it? If it does not work, then we are back to using RSA RAW. The other logic that might help is pkcs15-sec.c lines 605-619 where opensc uses sc_pkcs15_decipher to in effect do a RSA_RAW sign. Has Aventra be contacted on these issues. The wrote the driver. https://github.com/hhonkanen any comments? |
|
@dengert You forgot to answer me ..
|
|
I did not answer, as I said this is very complicated and I have not looked at it in years. #2173 (comment) showed how if user asked for SC_ALGORITHM_RSA_HASH_SHA256, how the opensc code (other then driver) would need to do via run a test using RSA SHA1 debug and look for the DEE flags:0x00002002 alg_info->flags:0xxxxxxxxx pad:0xxxxxxxxx sec:0xxxxxxxxx |
|
@dengert Thank you for your opinion. |
|
@fabled Can you comment on this discussion? Your commit 3f832ca#diff-37e30f9c78a5e1d99108d1466121e487527aa413eb132b7738345b20452923cf in April, 2019 made some changes for newer cards and included a "use the 2K signing kludge only on cards that need it" Some of the issues we are having with this discussion include using 2K keys. Also is the MYEID 4.5+ documentation available? Is this "MyEID PKI JavaCard Applet Reference manual Can you say anything about Table 49 and the RFU? If these are really reserved and not supported on any card then the card must do RSA_RAW when the hash is not SHA1. |
|
I think @hhonkanen is in better position to answer the above questions. |
Warning, working only with patched opensc.. OpenSC/OpenSC#2173 modified: tools/OsEID-tool
This patch enables using of: SHA224-RSA-PKCS, SHA256-RSA-PKCS, SHA384-RSA-PKCS, SHA512-RSA-PKCS and PSS variants of these mechanism for MyEID users. (This patch is related to issue OpenSC#2173.) CI tests for these mechanisms are also enabled (using OsEID emulation).
|
Newest MyEID reference manual, which covers also 4.5, is now available at OpenSC's MyEID wiki page. MyEID cards didn't officially support raw RSA signature with 2K keys before version 4.5, but it could be done using Decipher APDU. Since 4.5 MyEID cards support APDU chaining, which can be used to calculate raw RSA with key lengths up to 4096 bits, using PSO: Compute Digital Signature APDU. 4.5 is backwards compatible, so also the old way can be used. Decipher can be done using two alternative ways in 4.5, either using the old way of splitting the ciphered data to two APDUs, or by using the new APDU chaining mechanism. |
Warning, working only with patched opensc.. OpenSC/OpenSC#2173 modified: tools/OsEID-tool
|
@hhonkanen Is for You acceptable to enable more pkcs11 mechanisms, even if the generating padding and digest info would be moved from card to opensc? Please look at #2178, travis CI check for RSA-PKCS is already fixed (due different locale - utf8/posix - settings). Relevant log at https://travis-ci.org/github/OpenSC/OpenSC/jobs/748304326 line 1800 - 2033 |
|
@popovec I think it's good to support as many mechanisms as possible and I see no problem in doing digestinfo and padding in software. The card's functionality on them is quite limited, as it can only make digestinfo for SHA1 and do PKCS#1 padding. If it is significant for someone whether they are done on card or in software, the card's capabilities can be found from the reference manual. |
This patch enables using of: SHA224-RSA-PKCS, SHA256-RSA-PKCS, SHA384-RSA-PKCS, SHA512-RSA-PKCS and PSS variants of these mechanism for MyEID users. (This patch is related to issue #2173.) CI tests for these mechanisms are also enabled (using OsEID emulation).
|
I am trying to fix this issue in MyEID driver. If I turn off the hardware PKCS1 padding (by removing the SC_ALGORITHM_RSA_PAD_PKCS1 flag from the driver), then RAW RSA is applied to all operations and the size of the signature data is not limited in any way. I would like this feature to be enabled and disabled according to user requirements (not just from opensc.conf). Does anyone have any idea how to do this? For example, use an environment variable that describes what will be done? OPENSC_MyEID_DISABLE_PKCS1_PADDING = 0 |
|
Card drivers card-edo.c and card-piv.c both use getenv() Not sure why you want to do this. If PKCS11 says use RSA_RAW i.e. CKM_RSA_X_509, that is what it will do as it expects the caller has done some padding or knows what they are doing. RSA padding is a security feature, which lets the recipient know the signature or encrypted data is valid. It should not be bypassed. Some form of padding should be done. |
|
I may have misunderstood your last post. PKCS11 V2.40 (and older versions) in section "2.1.6 PKCS #1 v1.5 RSA" says size of the data to be padded is limited to k-11 bytes. |
|
My suggestion:
The user is not deceived, it is his choice how to set the specified variable. If OpenSC does not offer this option, the user can recompile OpenSC with disabled SC_ALGORITHM_RSA_PAD_PKCS1. I'm just suggesting a simplification so that users who need this option don't have to recompile OpenSC. But I expect someone to say whether the name of the variable is acceptable and if this is a reasonable solution. Or someone has a idea about another option than the user can turn on / off HW padding according to his requirements....
RSA operation security: If the card has an RSA RAW operation (regardless of whether it is a PSO: decipher or PSO: compute signature operation), it is possible to send any data to the card. The card will still perform a private operation with the data and the result for the PSO: decipher and the PSO: compute signature will end with the same result. If an attacker tries to extract the private key using a RAW RSA operation (using specially prepared messages), it doesn't matter which operation (decipher/sign) he uses. MyEID restriction (versions without official support for RAW RSA signature 2048 bit) only applies to APDU transport for PSO: compute signature) not RSA operation itself. |
|
Setting environment variable will not work for login. Most users have one smart card (usually gov issued) and use only one computer and don't know how to compile anything. So if you are going to provide a choice it should be via opensc.conf. This is a EID issue and the developers who use EID cards should make the decision. I am not one of them. |
|
Thanks for the warning. As you indicated, login will be a problem, of course for applications like ssh and openvpn the environment variable could be used but it is less convenient than using opensc.conf. The user can use the environment variable to set his own opensc.conf.... |
|
I think it's important that the default options, which don't required modifying opensc.conf, work in most use cases. It has been a problem that mechanism SHA256-RSA-PKCS or SHA512-RSA-PKCS have been missing with MyEID and it's a good improvement to add them. In most cases the 40% of modulus length limitation doesn't matter, as SHA512 is rarely used with 1024 bit RSA keys. Legacy systems which still use 1024 bit RSA typically also use SHA1 or sometimes SHA256 which still fits in. Typical use cases are using SHA256 or SHA512 with 2048 bit or 4096 bit keys, and they work fine even if you let MyEID do PKCS1 padding. I don't know where the 40% limitation originally came from, it might be to prevent Oracle attack as @popovec suggested, or from some recommendation - or even from the Javacard platform. If you consider it important that PKCS1 padding is done by hardware if possible, I suggest the following:
Regardless of the setting, users could always use CMK_RSA_X509 if they need full control of the data to be signed. |
As a FYI, in our scenario it was a legacy card setup, but they were using the cards to connect to non-legacy systems. The newer systems couldn't do much about the size of the RSA key, but they could request better hash algorithms. I don't know how common this is, but it might be dangerous to assume that just because one part is old that all parts are. |
|
Here possible solution for your problem: opensc.conf |
|
@CendioOssman I see. I don't object against resolving it so that OpenSC and MyEID driver would automatically use raw RSA in case the data is too long for on card padding. As it seems that the 40% limitation is MyEID specific (not only, I found that at least older Finnish official EID cards have this too, according to FINEID v2.1 specification), the logic should be in the MyEID driver I think. Does anybody know, could it be significant for someone in sense of security, whether the PKCS#1 padding is done by card or by OpenSC? Increasingly users want to use PSS padding instead of PKCS#1 and MyEID doesn't do that on card, so it has to be done in software anyway. PKCS#11 compliance is another thing to consider. Is it clearly defined, if we announce some mechanism is done in hardware, which parts of it must be done in hardware? The signature calculation of course, but hashing is not usually done on card anyway. |
|
As a FYI, this also happens with SetCOS 4 cards. More modern SetCOS cards don't seem to have this restriction though. |
|
This issue can be considered resolved (since pull request #2193 is already part of opensc). @CendioOssman are you satisfied with the solution to this problem? Can we close this issue? |
|
I'll try to find some time to test, but the description sounds like that PR is sufficient, yes. Does it cover the SetCOS cards as well, though? |
|
No, #2193 does not apply to SetCOS cards, this PR is sprecific only for MyEID cards. If there is a similar problem with the SetCOS card, I suggest closing this issue (since it is resolved) and opening a new issue for the SetCOS card. |
|
Sorry for the delay. I've tested #2193 now, and it seems to resolve the issue with the cards I have here. :) I seem to have misplaced that old SetCOS card, unfortunately. I'll add a new issue if it becomes an issue in practice. |
Problem Description
Aventra MyEID cards fail to sign data with more than 51 bytes when the key size is 1024 bits. The card reports
0x6700/"Wrong Length" at this point.Discovered when trying to use SHA512 as the hash algorithm.
Tested with MyEID 3.3.3, 4.0.0 and 4.5.5.
opensc-0.20.0-6.fc32.x86_64
This limit seems to scale with the key size. For 2048 bit keys the limit is 102 bytes, and for 4096 bit keys the limit is 204 bytes.
Proposed Resolution
No idea.
Steps to reproduce
echo -n 0123456789012345678901234567890123456789012345678901 | pkcs11-tool --login --pin <PIN> --mechanism RSA-PKCS --signLogs
Relevant snippet:
Complete log can be arranged if desired.
The text was updated successfully, but these errors were encountered: