-
Notifications
You must be signed in to change notification settings - Fork 72
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
Support for RSA-PSS / RSA-X-509 #18
Comments
Hi, Raw/textbook RSA has many weaknesses, and by exposing it as function of the token, the responsibility to add padding is transferred to the application or middleware. I think it would be better to enforce that there is at least PKCS#1 padding - at the token - to prevent weaknesses resulting from improper configuration or use. But I would be happy to hear other opinions about it. Kind regards, |
Hi, e.g of a post where the same issue is described. Reading on other forums some suggest to use an earlier version of TLS which would use PKCS#1, but that 's not really an option, why would I use old protocols and install an older version of OpenVPN + OpenSSL?! I'm aware that RSA with no padding is not as secure if the data is not passed pre-padded, but that is in my opinion the responsability of the software, not the token to ensure that the message is properly padded. as for me, I just started using smartcards for authentication, not really an expert at all, took me some days to figure out concept of smartcards, different javacard version, which applet can be used for PKI, OpenSC, ecc ecc, which software to patch. I might create a repository based on IsoApplet with javacard version 2.2.1 if you dont mind, where the extended apdu is not supported. Grüsse |
I have a similar issue when using TLS1.3 with Client Certificate authentication, in connection with IsoApplet. With Firefox on 76 on Ubuntu 20.04, I can downgrade to TLS1.2 and authenticate successfully. While TLS1.2 in general is considered "secure" as of today, there is a known issue when using Client Certificates, in that tracking is possible: I see that newer JavaCards support RSA-PSS, would it make more sense for IsoApplet to add support for that? I realize that it would be desirable to support older cards, but I myself have found it more cost effective to just buy newer cards rather than develop backwards compatibility. There is also the added benefit of other enhancements that come with newer cards. As for OpenVPN, I suspect there is an option to downgrade to TLS1.2 and remain secure, although I am not aware of the implications for user tracing in that case when using Client Certificates. Perhaps that is an acceptable compromise until support for RSA-PSS is available. |
I think people will be switching to other applets, like PIV applet, where RSA-PSS is supported in software. Since as you correctly say OpenSSL is using no padding (RSA-PSS) algorithm which they pre-pad before sending it to the card. If you want to use isoapplet, i have patched it so it works with RSA-PSS, you can find it on my repository, including opensc driver. |
I totally agree with this approach - this should be done using the JavaCard API. The ABI at OpenSC can easily be backwards compatible (i.e. new OpenSC can support older applet versions). I think IsoApplet should move towards 3.0+ cards soon (at the main branch). I plan on investigating this next week - I don't have access to my smartcards earlier. |
I just looked at PIVapplet, and it does not support RSA-PSS, even on JC3.0.5 cards (even though it could support it on most JC3.0.1 cards). It allows RSA-X509 (RAW) signatures directly on data from outside the card, which exposes risk of improper use to a larger surface, as Philip has mentioned. It is more accurate to say PIVapplet enables RSA-PSS emulation in OpenSC. This can be useful for testing TLS1.3 with applications such at Firefox and OpenVPN in combination with OpenSC, but I don't see it as a long term solution, since PSS has been developed to enhance (provability) of security. That is likely why TLS1.3 removed support for the older RSA-PKCS1 signatures, which are supported by both IsoApplet and PIVapplet. This article explains: RSA-PSS So, each person can choose for themself, which compromise to use in the short term: TLS1.2 or RSA-X509(RAW). Long term, JC3.0.1 support of RSA-PSS provides enhanced security following industry best practices and mathematical proofs. To be clear, TLS1.2 compromises by allowing tracking when using Client Certificate authentication. OpenSC + PIVapplet compromise by allowing a larger vulnerability field (more software that can have mistakes). Both are tradeoffs. When RSA-PSS support comes to an opensource applet (either one), then no tradeoffs will be required (except waiting!).
Technically, what you have done is enabled RSA RAW in IsoApplet. It is OpenSC (available starting in release 0.20) which is "emulating" RSA-PSS to provide support to pkcs11 using applications such as OpenVPN and OpenSSL(engine_pkcs11). |
you are fully right, I meant that RSA-PSS is done in software and then sent to the token which uses RAW RSA to sign, but this doesn't seem to happen in OpenVPN. http://openssl.6102.n7.nabble.com/Issue-with-smartcard-authentication-for-openvpn-td76415.html
so i'm a little bit lost, also if the applet will support native PSS padding, this will not solve the issue right since OpenVPN is requesting no padding? I think I'm missing something... edit: I should say OpenSSL decides which padding algorithm to use edit2: Please check out this issue. |
to summarize a bit, at the beginning I wasn't really clear what the issue was and confused some things, hopefully this will clarify for other people who are also stumbling on the same issue without spending hours of debugging, researching on the internet, etc etc. my issue was that after upgrading to OpenSSL 1.1.1, I couldn't use IsoApplet in combination with OpenVPN anymore. To solve this issue one has 2 choices:
problem description: in short: if you use OpenSSL 1.1.1 the padding schema is not RSA_PKCS1_PADDING anymore so the smart token won't be able to do the signing any longer if it doesn't expose raw RSA padding algorithm. long version: As a consequence OpenSSL does the pre-padding, it's not OpenVPN, OpenSC or other programs but it's OpenSSL itself which choses the padding algorithm. That said, I'm not sure that supporting the token with native RSA-PSS signature will change anything, until OpenSSL changes their code not to select RSA_NO_PADDING. As for me, i don't see it as a risk if the token exposes raw RSA (RSA_NO_PADDING), it won't expose the private key. if the token is used for signing then the risks are far less (signed data is not secret) if compared to using TLSv1.0. As everyone says, using raw RSA is insecure if padded incorrectly, it could reveal the cipher text with brute force attacks. |
I am not quite sure yet whether supporting RSA-PSS at the token would solve this issue at once. If not, OpenVPN or OpenSSL code should be looked at. After some digging, ALG_RSA_SHA_256_PKCS1_PSS is supported since 3.0.1. But it is optional and not supported by many smart cards. I found a G&D SmartCafe 7.0 card at home that should suffice for testing. I think 3.0.1 should be the next JC version that IsoApplet supports. I started work at https://github.com/philipWendland/IsoApplet/tree/jc301 and https://github.com/philipWendland/OpenSC/tree/jc301. Will take some time though, as I want to make some clean-ups while I'm at it. |
My G&D SmartCafe 7.0 crashes at https://github.com/philipWendland/IsoApplet/blob/jc304/src/net/pwendland/javacard/pki/isoapplet/IsoApplet.java#L1412 No Exception, just 6F00. Maybe I did something wrong, don't know for sure yet. Strangely enough, my card is listed as "c22" here,
Do you happen to have a card that supports E.g. (with https://github.com/philipWendland/IsoApplet/tree/jc304 and https://github.com/philipWendland/OpenSC/tree/jc304):
|
I have #79 NXP J3D081 and testing as requested,
but with SHA256-RSA-PKCS1 it returns a result with no error. I will double check the result against openssl, and also that I am running OpenSC jc304 branch, since I did a half-install only. |
Thank you.
OPENSC_DEBUG=10 pkcs11-tool might help, but you might also be using another
(old) opensc library.
I don't expect it to work yet though, I am more interested whether your
card also crashes (before I order another card).
Jeremy Jackson <notifications@github.com> schrieb am Di., 16. Juni 2020,
22:45:
… I have #79
<https://github.com/crocs-muni/JCAlgTest/tree/master/Profiles/results/NXP_JCOP_J3D081_v242r2_ICFabDate_2012_334_3b%20f9%2013%2000%2000%2081%2031%20fe%2045%204a%2043%204f%2050%2032%2034%2032%2052%2032%20a3.csv_(provided_by_Martin_Paljak_and_Arnis_UT).csv>
and testing as requested,
pkcs11-tool --sign --input-file test.txt -m "SHA256-RSA-PKCS-PSS" --pin $pin
PSS parameters: hashAlg=SHA256, mgf=MGF1-SHA256, salt_len=32 B
error: PKCS11 function C_SignInit failed: rv = CKR_MECHANISM_INVALID (0x70)
Aborting
but with SHA256-RSA-PKCS1 it returns a result with no error. I will double
check the result against openssl, and also that I am running OpenSC jc304
branch, since I did a half-install only.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4R5DAS7SR3ALXAJWZD5EDRW7KWFANCNFSM4IM5ZLIA>
.
|
How do you define a crash? Exception? Brick? |
Good question, I should've been more precise.
The card returns 6F00 on this line of code, without throwing an exception.
It remains responsive after that, but this behavior is still against the
javacard API specification.
(I've seen other cards getting unresponsive on other occasions, with the
need to pull it from the reader to make it work again)
Martin Paljak <notifications@github.com> schrieb am Mi., 17. Juni 2020,
09:51:
… How do you define a crash? Exception? Brick?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4R5DET6K5HPYIPV7I6HF3RXBYXVANCNFSM4IM5ZLIA>
.
|
Are you sure it does not throw some almost-known exception? |
Yes,I think so. I caught "Exception" i.e. all exceptions, and it didn't
make a difference.
Martin Paljak <notifications@github.com> schrieb am Fr., 19. Juni 2020,
13:19:
… Are you sure it does not throw some almost-known exception?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4R5DDXNUSM5VYSPOAKEWLRXNCS3ANCNFSM4IM5ZLIA>
.
|
Closing this one, see #23 or https://github.com/philipWendland/IsoApplet/projects/1. |
OpenVPN currently seems to use the RSA no padding signature algorithm, making it not compatible with a smartcard using IsoApplet.
Debugging openVPN, the call to pkcs11-helper invokes the following padding alg: CKM_RSA_X_509 which is not supported by IsoApplet.
Pkcs11-helper has been patched to support this recently.
I patched the IsoApplet code on my local PC, to add the signature use case for ALG_RSA_NOPAD and modified the openSC driver card-isoApplet.c to include this new option.
This has been tested on a JCOP 41 card (javacard 2.2.1) card, and I now can sucessfully connect to my VPN server.
(since my card is 2.2.1 I also had to remove the apdu extended stuff for this to work with my card.)
Was wondering if it would make sense to add the no padding code to your official repository?
The text was updated successfully, but these errors were encountered: