Menu
▾
▴
opensc-devel — discussion of developement of OpenSC and related projects
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(26) |
Feb
(64) |
Mar
(78) |
Apr
(36) |
May
(51) |
Jun
(40) |
Jul
(43) |
Aug
(102) |
Sep
(50) |
Oct
(71) |
Nov
(42) |
Dec
(29) |
| 2014 |
Jan
(49) |
Feb
(52) |
Mar
(56) |
Apr
(30) |
May
(31) |
Jun
(52) |
Jul
(76) |
Aug
(19) |
Sep
(82) |
Oct
(95) |
Nov
(58) |
Dec
(76) |
| 2015 |
Jan
(135) |
Feb
(43) |
Mar
(47) |
Apr
(72) |
May
(59) |
Jun
(20) |
Jul
(17) |
Aug
(14) |
Sep
(34) |
Oct
(62) |
Nov
(48) |
Dec
(23) |
| 2016 |
Jan
(18) |
Feb
(55) |
Mar
(24) |
Apr
(20) |
May
(33) |
Jun
(29) |
Jul
(18) |
Aug
(15) |
Sep
(8) |
Oct
(21) |
Nov
(5) |
Dec
(23) |
| 2017 |
Jan
(3) |
Feb
|
Mar
(17) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(20) |
Sep
(17) |
Oct
(21) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(62) |
Feb
(4) |
Mar
(4) |
Apr
(20) |
May
(16) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(11) |
Nov
|
Dec
(9) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(5) |
Nov
|
Dec
(5) |
| 2020 |
Jan
(11) |
Feb
(14) |
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(14) |
Feb
(21) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2023 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(8) |
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Douglas E E. <dee...@gm...> - 2021-09-09 16:10:41
|
I don't think the problem is the -d 03. They look the same to me. Note in pkcs11-tool:
807 opt_object_id_len = sizeof(opt_object_id);
808 if (!hex_to_bin(optarg, opt_object_id, &opt_object_id_len)) {
this takes the optarg "03" and expects it to be a hex string and converts to binary 0x03 with length opt_object_id_len=1;
On 9/9/2021 7:20 AM, Muziket via Opensc-devel wrote:
> Hi,
>
> I've been fiddling the codes of pkcs11-tool to understand opensc pkcs11 module.
>
> I installed a RSA and ECC key onto my token. My ECC key is identified with ID: 03 and using pkcs11-tool.exe:
> pkcs11-tool.exe -l -derive --input-file my_ecc_ephemeral_pubkey.der -d 03
> And I could get my token to derive a shared secret.
>
> I then tried to write a sample application by reusing some of the snippets in pkcs11-tool.c with the opensc-libpkcs11.dll.
> It replied:
> C_DeriveKey failed: rv = CKR_FUNCTION_NOT_SUPPORTED (0x54)
>
> I dived into the logs produced by pkcs11-spy and noticed that the CKA_ID is different from when I used the pkcs11-tool.exe:
> 44: C_FindObjectsInit
> 2021-09-09 19:57:08.162
> [in] hSession = 0x12c7bf0
> [in] pTemplate[2]:
> CKA_CLASS CKO_PRIVATE_KEY
> CKA_ID *00000000004a6080 */ 1
> 00000000 03
the "/ 1" says it has length 1.
"0000000 03" is a hex dump starting at offset 000000 for 1 byte which is 0x03
.
> Returned: 0 CKR_OK
>
> In my sample application, instead of using getopt, I chose to hardcode the id to opt_object_id[0], which essentially, gives the same value as when pkcs11-tool.exe was used by looking at the
> pkcs11-tool.c codes.
> Hence, I'm not sure what translations are required to identify the correct ECC object for the shared secret derivation.
>
> Any insight is appreciated.
This works for me:
pkcs11-tool --slot 0 --module /opt/ossl-1.1.1k/lib/pkcs11-spy.so -l --derive -m ECDH1-COFACTOR-DERIVE -O -d 03 -i /tmp/derive.2810.other.pubkey.der
Try adding the equivelent to -m ECDH1-COFACTOR-DERIVE
so the C_DeriveKey looks something like this:
10: C_DeriveKey
2021-09-09 10:36:30.335
[in] hSession = 0x55d971f544a0
[in] pMechanism->type = CKM_ECDH1_COFACTOR_DERIVE
[in] pMechanism->pParameter->kdf = CKD_NULL
[in] pMechanism->pParameter->pSharedData[ulSharedDataLen] = NULL [size : 0x0 (0)]
[in] pMechanism->pParameter->pPublicData[ulPublicDataLen] = 000055d971f556d0 / 97
00000000 04 71 11 01 1A 31 3E C9 C7 2A E2 38 6A 35 1C AD .q...1>..*.8j5..
00000010 FC 61 18 C9 D9 38 B3 47 D4 26 61 A4 52 E7 ED B3 .a...8.G.&a.R...
00000020 B4 B7 08 62 10 2E B1 9F CB 69 49 59 70 69 0C 89 ...b.....iIYpi..
00000030 24 BA 55 AB 17 A1 74 75 95 C5 6E 16 2C 48 5C 81 $.U...tu..n.,H\.
00000040 04 75 EA 14 EF 27 95 6F A1 15 AF DD C7 09 C3 FB .u...'.o........
00000050 2F A6 3D 39 CF 65 7D 9D 3D E7 EA 1D 7B AD 89 16 /.=9.e}.=...{...
00000060 88 .
[in] hBaseKey = 0x55d971f514f0
[in] pTemplate[10]:
CKA_TOKEN False
CKA_CLASS CKO_SECRET_KEY
CKA_KEY_TYPE CKK_GENERIC_SECRET
CKA_SENSITIVE False
CKA_EXTRACTABLE True
CKA_ENCRYPT True
CKA_DECRYPT True
CKA_WRAP True
CKA_UNWRAP True
CKA_VALUE_LEN 00007ffd54a6dcc0 / 8
00000000 30 00 00 00 00 00 00 00 0.......
[out] hKey = 0x55d971f558a0
Returned: 0 CKR_OK
The pPublicData[ulPublicDataLen] in this case is the compressed public key from 384 bit EC key i.e. CKA_EC_POINT
Its the key of the peer, in your case from the "my_ecc_ephemeral_pubkey.der"
See
http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/cs01/pkcs11-curr-v2.40-cs01.pdf or other versions as
v2.20 did not specify the format of the parameter.
>
> Thank you.
> Muziket
>
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
--
Douglas E. Engert <DEE...@gm...>
|
|
From: Muziket <ema...@ya...> - 2021-09-09 12:21:12
|
Hi, I've been fiddling the codes of pkcs11-tool to understand opensc pkcs11 module. I installed a RSA and ECC key onto my token. My ECC key is identified with ID: 03 and using pkcs11-tool.exe: pkcs11-tool.exe -l -derive --input-file my_ecc_ephemeral_pubkey.der -d 03And I could get my token to derive a shared secret. I then tried to write a sample application by reusing some of the snippets in pkcs11-tool.c with the opensc-libpkcs11.dll.It replied: C_DeriveKey failed: rv = CKR_FUNCTION_NOT_SUPPORTED (0x54) I dived into the logs produced by pkcs11-spy and noticed that the CKA_ID is different from when I used the pkcs11-tool.exe: 44: C_FindObjectsInit 2021-09-09 19:57:08.162 [in] hSession = 0x12c7bf0 [in] pTemplate[2]: CKA_CLASS CKO_PRIVATE_KEY CKA_ID 00000000004a6080 / 1 00000000 03 . Returned: 0 CKR_OK In my sample application, instead of using getopt, I chose to hardcode the id to opt_object_id[0], which essentially, gives the same value as when pkcs11-tool.exe was used by looking at the pkcs11-tool.c codes.Hence, I'm not sure what translations are required to identify the correct ECC object for the shared secret derivation. Any insight is appreciated. Thank you.Muziket |
|
From: Jakub J. <jj...@re...> - 2021-08-13 13:08:27
|
Hi all, I am happy to finally announce the new release 0.22.0 of OpenSC. You can read the full summary of the changes and get the release tarballs and binaries on github: https://github.com/OpenSC/OpenSC/releases/tag/0.22.0 This release fixes many bugs reported by oss-fuzz, but adds also many new features including the long-awaited support for PKCS #11 3.0, EdDSA keys, compatiblity with new OpenSSL 3.0 and much more. Regards, Jakub Jelen |
|
From: Paul W. <ma...@al...> - 2021-07-05 10:28:28
|
В Mon, 31 May 2021 21:25:07 +0300
Paul Wolneykien <ma...@al...> пишет:
> Hi!
>
> I think we are ready to release the new version of pam_pkcs11
> (0.6.12). Tomorrow I'm going to test the current master with the
> tokens I have and tag the release at the end of the week if
> everything will be ok.
The release 0.6.12 is out:
https://github.com/OpenSC/pam_pkcs11/releases/tag/pam_pkcs11-0.6.12
|
|
From: Paul W. <ma...@al...> - 2021-05-31 18:25:27
|
Hi! I think we are ready to release the new version of pam_pkcs11 (0.6.12). Tomorrow I'm going to test the current master with the tokens I have and tag the release at the end of the week if everything will be ok. |
|
From: Frank M. <fra...@gm...> - 2021-04-30 15:18:50
|
Hi all! You can find a release candidate for version 0.22.0 for testing on Github: https://github.com/OpenSC/OpenSC/releases/tag/0.22.0-rc1 We are looking forward about your feedback, which we may discuss via mail or here: https://github.com/OpenSC/OpenSC/issues/2247 Advices for systematic testing can be found here: https://github.com/OpenSC/OpenSC/wiki/Smart-Card-Release-Testing Regards, Frank. |
|
From: Ondřej S. <on...@su...> - 2021-03-24 17:06:28
|
Yes, the work by @fabled is being sponsored by ISC :). I am now hoping you and Timo can perhaps merge the changes together, so no effort is lost. Ondrej -- Ondřej Surý (He/Him) on...@su... > On 24. 3. 2021, at 16:44, Harry G. Coin <hg...@gm...> wrote: > > ISC folks might look at https://github.com/OpenSC/libp11/issues/393 > wherein named crashes owing to muli-threaded -E pkcs11 activity arising > from opendnssec / freeipa. A fix is provided. > > Thanks > > Harry Coin > > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel |
|
From: Harry G. C. <hg...@gm...> - 2021-03-24 16:17:03
|
What 'ought' libp11 do in this timeline situation, all in one process: 'Thread 1' logs in via the UI, possibly involving the user and a keypad (meaning, slow), leading to p11 having a 'known good' pin for 'slot 1'. Note the user expects 'their' pin to be active until at least they accomplish 'their' purpose, perhaps even until the process terminates. 'Threads 2, 3, 4, etc.' have need of certificates and/or private/public keys secured by a pin provided via pkcs11:... URI parsing. Perhaps involving permissions / activities not to do with the user's purpose/authority. Much like 'temporary elevated permissions' linux provides suid, etc. Presently as I read eng_back.c 'the last login for any given slot wins'. So the 'currently logged in pin' for any slot could be different than the user expects before the reason the user entered the pin could be accomplished. Also, under the current code, a thread expecting the login done under 'their URI's pin', could fail if (an)other thread(s) logged in after login but before accomplishing the reason for the parsing. I've changed eng_back.c to hold a new lock from just before the login to just after the reason the URI was given. A multi-threaded libp11 heavy package that wouldn't run for more than an hour has now run for 12 (details in the previous post with patch, ISC's bind / named having heavy interaction with opendnssec / freeipa). But that begs the question... Isn't there something of a security hole if a URI's pin has increased authority than the UI provided pin given 'the last pin wins'? And potentially worse security breach in the timeline wherein thread 2+'s provided parsed pkcs11: pin would fail but the UI provided pin 'if timed just right' would succeed? One might imagine situations where that is a security hole, and imagine other situations where that's a feature. I didn't implement this in my patch, but perhaps 'If a user login pin exists for a slot, and later a pkcs11: parsed URI provides a pin, after the certificate/public/private-key purpose of the pkcs11: pin is accomplished the user pin should be re-logged-in' all protected by thread locking? I haven't been involved in lib11 a week yet, so I may have missed something 'obvious' thanks for reading. Harry Coin Quiet Fountain LLC Bettendorf, Iowa, USA |
|
From: Harry G. C. <hg...@gm...> - 2021-03-24 15:44:38
|
ISC folks might look at https://github.com/OpenSC/libp11/issues/393 wherein named crashes owing to muli-threaded -E pkcs11 activity arising from opendnssec / freeipa. A fix is provided. Thanks Harry Coin |
|
From: Douglas E E. <dee...@gm...> - 2021-02-12 15:35:58
|
This is more complicated then it looks.
You want to use the FIPS version of OpenSSL to use its engine capability, and your previous e-mails
say you are using the 1.0.2 version of OpenSSL FIPS.
I don't know where you got it or built it or if you can get the 1.1.1 FIPS version.
Libp11 and pkcs11 are compiled against a specific OpenSSL, which is not a FIPS version.
looking at of the PR:
https://github.com/OpenSC/libp11/pull/388
The 64 bit windows version:
https://ci.appveyor.com/project/LudovicRousseau/libp11/builds/37673828
and the console log:
https://ci.appveyor.com/project/LudovicRousseau/libp11/builds/37673828/job/ycl1eo6mvhmelvpo
shows the "official" i.e. what the https://github.com/OpenSC/libp11 built binaries, libp11.dll and pkcs11.dll uses:
https://slproweb.com/download/Win64OpenSSL-1_1_1i.exe
which is listed in this wiki, built by others, as OpenSSL does not provide Windows binaries itself:
https://wiki.openssl.org/index.php/Binaries
So using the "official" libp11 pkcs11 version would not work with the 1.0.2 FIPS version because of version mismatches.
It *may* work with whatever version of the OpenSSL 1.1.1 FIPS version you might find as the ABI should still be 1.1.
So in my option, you are on you own on Windows at least.
On 2/11/2021 6:48 PM, George wrote:
> Hi,
>
> I am currently using the latest version libp11-0.4.11 <https://github.com/OpenSC/libp11/releases/tag/libp11-0.4.11> but would like to include the changes from the pull request:
> https://github.com/OpenSC/libp11/pull/388
>
> I know I can build it myself with the changes from the pull request, but I prefer to use an "official" load. Does anyone know when a new version of LIBP11 will be built with these changes?
>
>
> Thanks,
> George
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
--
Douglas E. Engert <DEE...@gm...>
|
|
From: George <whi...@gm...> - 2021-02-12 00:48:28
|
Hi, I am currently using the latest version libp11-0.4.11 <https://github.com/OpenSC/libp11/releases/tag/libp11-0.4.11> but would like to include the changes from the pull request: https://github.com/OpenSC/libp11/pull/388 I know I can build it myself with the changes from the pull request, but I prefer to use an "official" load. Does anyone know when a new version of LIBP11 will be built with these changes? Thanks, George |
|
From: Norbert P. <no...@pr...> - 2021-02-08 05:15:52
|
Dear all, I am trying to get a smartcard (company id card used for authentication purposes) to work with Linux. The smart card is not recognized by now. $ opensc-tool --list-readers # Detected readers (pcsc) Nr. Card Features Name 0 Yes Alcor Micro AU9540 01 00 $ opensc-tool --atr Using reader with a card: Alcor Micro AU9540 01 00 3b:f8:18:00:00:81:31:fe:45:00:73:c8:40:13:00:90:00:93 $ opensc-tool --name Using reader with a card: Alcor Micro AU9540 01 00 Unsupported card According to the ATR parsing it might be a card "Giesecke & Devrient Sm@rtCafé Expert 3.0" https://smartcard-atr.apdu.fr/parse?ATR=3BF81800008131FE450073C8401300900093 Is there anything known about this card, and whether there is a way to get it working? I searched the web and found lots of references to StarSign, but that doesn't seem to be a product I can obtain. Any advice would be greatly appreciated. Thanks Norbert -- PREINING Norbert https://www.preining.info Fujitsu Research Labs + IFMGA Guide + TU Wien + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 |
|
From: Douglas E E. <dee...@gm...> - 2021-02-07 14:09:46
|
Here are some observations I have made from the 2 PKCS11 call traces and libp11/engine code and OpenSSL code. trace pkcs11.25371.log has 1,277,023 lines pkcs11.25454.log has 1,312,256 lines There are two keys used in the tests with labels ZSK1 and KSK1. ZSK1 is only used once in each trace, KSK1 is used for all the other C_Sign operations. The test uses the same private key, KSK1, with object handle 0x80000004 in both traces I don't know if this is a real world test for bind9 or not. I would expect multiple keys, but I am not a bind9 expert. Libp11/engine does not start any threads, and uses OpenSSL CRYPTO_ locking routines to lock access to some objects. With both cases C_Initialize is called with CKF_OS_LOCKING_OK and no vendor provided Mutex routines, i.e. the pkcs11 library can use the OS thread locking routines if it wants. I assume it does. https://www.openssl.org/blog/blog/2017/02/21/threads/ Has interesting comments on OpenSSL and threads pkcs11.25371.log uses up to 17 sessions, and I assume 17 threads started by the calling applications which test if all previous threads are active, it will start another. grep --binary-files=text Thread pkcs11.25371.log | sort |uniq shows 17 threads, but also shows the trace code is not locking writing to the log, so many lines are being over written. grep --binary-files=text Thread pkcs11.25454.log | sort |uniq Process Id 25454, Thread Id 25454 Process Id 25454, Thread Id 25455 Process Id 25454, Thread Id 25456 Process Id 25454, Thread Id 25457 Process Id 25454, Thread Id 25458 Process Id 25454, Thread Id 25459 Process Id 25454, Thread Id 25460 Process Id 25454, Thread Id 25461 Process Id 25454, Thread Id 25462 Process Id 25454, Thread Id 25463 Process Id 25454, Thread Id 25464 Process Id 25454, Thread Id 25465 Process Id 25454, Thread Id 25466 Process Id 25454, Thread Id 25467 Process Id 25454, Thread Id 25468 Process Id 25454, Thread Id 25469 Process Id 25454, Thread Id 25470 produces a nice trace with no over written lines, and shows 17 threads are being started. In both cases it is not clear if this is a fixed number or application is starting a new thread if all are waiting. They are only cleaned at the end of the tests. My conclusion is either the OpenSSL code itself is doing a CRYPTO_RWLOCK on the single key before the libp11 engine ever sees the operation and thus is serialize access to the lower code or the libp11 engine code is doing the serialization. Some debugging/tracing would be needed to prove this. Without openssl and the engines, the pkcs11 module or the hardware is doing any serialization to do a sign operation on the device. The hardware device maybe able to due multiple crypto operations using the same key. libp11 engine appears to support only use one session at a time and PKCS11 specs allow more then one session and the pkcs11 module being used supports this, but has problems with it logging. OpenSSL engine with libp11 engine may not be the best choice to use for high performance. It was designed to make it easier to use PKCS11 not to get the best out of it. So finding out where these threads are waiting would be the first thing to look at. As a side note: PKCS11 token info has a ulMaxSessionCount, but most smartcards do not support more then one, and do not even look at this count. a value of 0 is CK_EFFECTIVELY_INFINITE, and so depending on this is a bug waiting to happen. On 2/7/2021 2:38 AM, Timo Teras wrote: > Hi, > > Do you have more detailed project description available yet? What kind > of time schedule expectation you have? > > Also, what I hear as underlying change to use more sessions and cache > them, might require quite big redesign of libp11. And it might be > easier to rewrite. Would this be an option if analysis suggests this is > better approach? > > Timo > > On Fri, 5 Feb 2021 16:00:15 +0100 > Ondřej Surý <on...@su...> wrote: > >> Hi OpenSC folks, >> >> Internet Systems Corporation, Inc. maker of BIND 9 is looking for a >> short-term contractor that would work on engine_pkcs11 performance. >> >> The friendly support staff of Ultra-CIS, the maker of AEP Keeper came >> up with following observation when comparing engine_pkcs11 to the old >> Solaris/Oracle OpenSSL patch: >> >>> • OpenSC libp11 Engine performs 13 more C_FindObjects calls >>> • OpenSC libp11 Engine performs 50 more C_GetAttributeValue >>> calls >>> • OpenSC libp11 Engine performs 1986 more C_SignInit calls >>> • OpenSC libp11 Engine performs 2174 more C_Sign calls >>> • OpenSSL patched version uses 17 sessions and OpenSC >>> libp11 Engine only uses 1 >>> • OpenSC libp11 Engine appears not to close it’s session. >>> >>> I think the most significant thing here is that OpenSC libp11 >>> Engine only uses one session, whereas OpenSSL patched version uses >>> 17. Using multiple sessions can increase throughput and I suspect >>> this is the reason why OpenSSL patched version has a better >>> performance. >> >> ISC would be willing to sponsor further development of engine_pkcs11 >> under the same license as the original code and contributed back to >> OpenSC project. Further details could be discussed with me, but we >> are generally looking at work that would be of benefit to the BIND 9 >> users, but also to the whole OpenSC community. >> >> You can contact me on this email or same username at isc.org. >> >> Cheers, >> Ondrej >> -- >> Ondřej Surý (He/Him) >> on...@su... >> > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Timo T. <tim...@ik...> - 2021-02-07 08:38:35
|
Hi, Do you have more detailed project description available yet? What kind of time schedule expectation you have? Also, what I hear as underlying change to use more sessions and cache them, might require quite big redesign of libp11. And it might be easier to rewrite. Would this be an option if analysis suggests this is better approach? Timo On Fri, 5 Feb 2021 16:00:15 +0100 Ondřej Surý <on...@su...> wrote: > Hi OpenSC folks, > > Internet Systems Corporation, Inc. maker of BIND 9 is looking for a > short-term contractor that would work on engine_pkcs11 performance. > > The friendly support staff of Ultra-CIS, the maker of AEP Keeper came > up with following observation when comparing engine_pkcs11 to the old > Solaris/Oracle OpenSSL patch: > > > • OpenSC libp11 Engine performs 13 more C_FindObjects calls > > • OpenSC libp11 Engine performs 50 more C_GetAttributeValue > > calls > > • OpenSC libp11 Engine performs 1986 more C_SignInit calls > > • OpenSC libp11 Engine performs 2174 more C_Sign calls > > • OpenSSL patched version uses 17 sessions and OpenSC > > libp11 Engine only uses 1 > > • OpenSC libp11 Engine appears not to close it’s session. > > > > I think the most significant thing here is that OpenSC libp11 > > Engine only uses one session, whereas OpenSSL patched version uses > > 17. Using multiple sessions can increase throughput and I suspect > > this is the reason why OpenSSL patched version has a better > > performance. > > ISC would be willing to sponsor further development of engine_pkcs11 > under the same license as the original code and contributed back to > OpenSC project. Further details could be discussed with me, but we > are generally looking at work that would be of benefit to the BIND 9 > users, but also to the whole OpenSC community. > > You can contact me on this email or same username at isc.org. > > Cheers, > Ondrej > -- > Ondřej Surý (He/Him) > on...@su... > |
|
From: Douglas E E. <dee...@gm...> - 2021-02-05 19:57:27
|
Please add comments to the github.com PR https://github.com/OpenSC/libp11/pull/388 Without a github ID, you can start https://github.com/OpenSC/libp11 look at Pull Requests, then 388. (should be the first one.) To make a comment requires a github ID, which is easy to get, and can use Google for authentication too. The login to make a comment. On 2/5/2021 1:23 PM, George wrote: > Hi Doug, > > Thanks again for your help. I am looking at this now. I'll report back my results, once I have tested it. > > > Thanks! > George > > > > On 2021-02-05 1:04 p.m., Douglas E Engert wrote: >> >> George and Anderson, >> Have a look at this proposed fix. >> >> https://github.com/OpenSC/libp11/pull/388 >> >> >> It forces the user/application to deiced if they are in compliance with the FIPS >> based on what PKCS11 modules they trust and what tokens they trust. >> >> Can both of you this PR, and report in github your results? >> >> >> >> On 2/3/2021 12:54 PM, Anderson Sasaki wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "George" <whi...@gm...> >>>> To: ope...@li... >>>> Sent: Wednesday, February 3, 2021 4:30:31 AM >>>> Subject: Re: [Opensc-devel] mutual authentication fails when FIPS enabled >>>> >>>> I just realized that the LIBP11 function RSA_public_encrypt(...) ends up >>>> using a function from the OpenSSL FIPS 2.0.16 module to do the RSA >>>> encryption. Does that mean I can safely configure RSA_FLAG_FIPS_METHOD to be >>>> "true" in >>>> >>>> >>>> >>>> SA_METHOD *PKCS11_get_rsa_method(void) >>>> { >>>> . . . >>>> RSA_meth_set_flags(ops, RSA_FLAG_FIPS_METHOD ); >>>> . . . >>>> } >>>> ? >>> >>> For me, setting this flag will tell OpenSSL that the method obtained from the >>> engine will perform the crypto operations in an approved module. >>> >>> It is more related with the PKCS#11 module you are using than with the OpenSSL >>> binary you are using. >>> >>> To be FIPS compliant, both OpenSSL and the PKCS#11 module you are using have >>> to be approved. But I can't say that is sufficient for FIPS compliance of your >>> whole system. >>> >>>> >>>> >>>> I traced the code for >>>> >>>> >>>> int RSA_public_encrypt(int flen, const unsigned char *from, unsigned char >>>> *to, RSA *rsa, int padding) >>>> { >>>> . . . >>>> return (rsa->meth->rsa_pub_enc(flen, from, to, rsa, padding)); >>>> } down to the code in openssl-fips-2.0.16\crypto\rsa\rsa_eay.c : >>>> >>>> >>>> static int RSA_eay_public_encrypt(int flen, const unsigned char *from, >>>> unsigned char *to, RSA *rsa, int padding) >>>> Since we know this if FIPS certified, does this imply the RSA encryption >>>> function configured in PKCS11_get_rsa_method(void) is also FIPS compliant? >>> >>> I would say it is not sufficient as some crypto operations would be performed >>> outside the crypto boundary considered for the validation of this OpenSSL binary. >>> >>> What I mean is that the OpenSSL binary is validated only for operations performed >>> inside it. Since you are using an external device to perform cryptographic >>> operations, you are not using the module in an approved way. >>> >>> Best regards, >>> Anderson Sasaki >>> >>> >>> >>> _______________________________________________ >>> Opensc-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >> > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel -- Douglas E. Engert <DEE...@gm...> |
|
From: George <whi...@gm...> - 2021-02-05 19:24:09
|
Hi Doug, Thanks again for your help. I am looking at this now. I'll report back my results, once I have tested it. Thanks! George On 2021-02-05 1:04 p.m., Douglas E Engert wrote: > > George and Anderson, > Have a look at this proposed fix. > > https://github.com/OpenSC/libp11/pull/388 > > > It forces the user/application to deiced if they are in compliance > with the FIPS > based on what PKCS11 modules they trust and what tokens they trust. > > Can both of you this PR, and report in github your results? > > > > On 2/3/2021 12:54 PM, Anderson Sasaki wrote: >> >> >> ----- Original Message ----- >>> From: "George" <whi...@gm...> >>> To: ope...@li... >>> Sent: Wednesday, February 3, 2021 4:30:31 AM >>> Subject: Re: [Opensc-devel] mutual authentication fails when FIPS >>> enabled >>> >>> I just realized that the LIBP11 function RSA_public_encrypt(...) >>> ends up >>> using a function from the OpenSSL FIPS 2.0.16 module to do the RSA >>> encryption. Does that mean I can safely configure >>> RSA_FLAG_FIPS_METHOD to be >>> "true" in >>> >>> >>> >>> SA_METHOD *PKCS11_get_rsa_method(void) >>> { >>> . . . >>> RSA_meth_set_flags(ops, RSA_FLAG_FIPS_METHOD ); >>> . . . >>> } >>> ? >> >> For me, setting this flag will tell OpenSSL that the method obtained >> from the >> engine will perform the crypto operations in an approved module. >> >> It is more related with the PKCS#11 module you are using than with >> the OpenSSL >> binary you are using. >> >> To be FIPS compliant, both OpenSSL and the PKCS#11 module you are >> using have >> to be approved. But I can't say that is sufficient for FIPS >> compliance of your >> whole system. >> >>> >>> >>> I traced the code for >>> >>> >>> int RSA_public_encrypt(int flen, const unsigned char *from, unsigned >>> char >>> *to, RSA *rsa, int padding) >>> { >>> . . . >>> return (rsa->meth->rsa_pub_enc(flen, from, to, rsa, padding)); >>> } down to the code in openssl-fips-2.0.16\crypto\rsa\rsa_eay.c : >>> >>> >>> static int RSA_eay_public_encrypt(int flen, const unsigned char *from, >>> unsigned char *to, RSA *rsa, int padding) >>> Since we know this if FIPS certified, does this imply the RSA >>> encryption >>> function configured in PKCS11_get_rsa_method(void) is also FIPS >>> compliant? >> >> I would say it is not sufficient as some crypto operations would be >> performed >> outside the crypto boundary considered for the validation of this >> OpenSSL binary. >> >> What I mean is that the OpenSSL binary is validated only for >> operations performed >> inside it. Since you are using an external device to perform >> cryptographic >> operations, you are not using the module in an approved way. >> >> Best regards, >> Anderson Sasaki >> >> >> >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > |
|
From: Douglas E E. <dee...@gm...> - 2021-02-05 18:05:02
|
George and Anderson, Have a look at this proposed fix. https://github.com/OpenSC/libp11/pull/388 It forces the user/application to deiced if they are in compliance with the FIPS based on what PKCS11 modules they trust and what tokens they trust. Can both of you this PR, and report in github your results? On 2/3/2021 12:54 PM, Anderson Sasaki wrote: > > > ----- Original Message ----- >> From: "George" <whi...@gm...> >> To: ope...@li... >> Sent: Wednesday, February 3, 2021 4:30:31 AM >> Subject: Re: [Opensc-devel] mutual authentication fails when FIPS enabled >> >> I just realized that the LIBP11 function RSA_public_encrypt(...) ends up >> using a function from the OpenSSL FIPS 2.0.16 module to do the RSA >> encryption. Does that mean I can safely configure RSA_FLAG_FIPS_METHOD to be >> "true" in >> >> >> >> SA_METHOD *PKCS11_get_rsa_method(void) >> { >> . . . >> RSA_meth_set_flags(ops, RSA_FLAG_FIPS_METHOD ); >> . . . >> } >> ? > > For me, setting this flag will tell OpenSSL that the method obtained from the > engine will perform the crypto operations in an approved module. > > It is more related with the PKCS#11 module you are using than with the OpenSSL > binary you are using. > > To be FIPS compliant, both OpenSSL and the PKCS#11 module you are using have > to be approved. But I can't say that is sufficient for FIPS compliance of your > whole system. > >> >> >> I traced the code for >> >> >> int RSA_public_encrypt(int flen, const unsigned char *from, unsigned char >> *to, RSA *rsa, int padding) >> { >> . . . >> return (rsa->meth->rsa_pub_enc(flen, from, to, rsa, padding)); >> } down to the code in openssl-fips-2.0.16\crypto\rsa\rsa_eay.c : >> >> >> static int RSA_eay_public_encrypt(int flen, const unsigned char *from, >> unsigned char *to, RSA *rsa, int padding) >> Since we know this if FIPS certified, does this imply the RSA encryption >> function configured in PKCS11_get_rsa_method(void) is also FIPS compliant? > > I would say it is not sufficient as some crypto operations would be performed > outside the crypto boundary considered for the validation of this OpenSSL binary. > > What I mean is that the OpenSSL binary is validated only for operations performed > inside it. Since you are using an external device to perform cryptographic > operations, you are not using the module in an approved way. > > Best regards, > Anderson Sasaki > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Ondřej S. <on...@su...> - 2021-02-05 15:24:51
|
Hi OpenSC folks, Internet Systems Corporation, Inc. maker of BIND 9 is looking for a short-term contractor that would work on engine_pkcs11 performance. The friendly support staff of Ultra-CIS, the maker of AEP Keeper came up with following observation when comparing engine_pkcs11 to the old Solaris/Oracle OpenSSL patch: > • OpenSC libp11 Engine performs 13 more C_FindObjects calls > • OpenSC libp11 Engine performs 50 more C_GetAttributeValue calls > • OpenSC libp11 Engine performs 1986 more C_SignInit calls > • OpenSC libp11 Engine performs 2174 more C_Sign calls > • OpenSSL patched version uses 17 sessions and OpenSC libp11 Engine only uses 1 > • OpenSC libp11 Engine appears not to close it’s session. > > I think the most significant thing here is that OpenSC libp11 Engine only uses one session, whereas OpenSSL patched version uses 17. Using multiple sessions can increase throughput and I suspect this is the reason why OpenSSL patched version has a better performance. ISC would be willing to sponsor further development of engine_pkcs11 under the same license as the original code and contributed back to OpenSC project. Further details could be discussed with me, but we are generally looking at work that would be of benefit to the BIND 9 users, but also to the whole OpenSC community. You can contact me on this email or same username at isc.org. Cheers, Ondrej -- Ondřej Surý (He/Him) on...@su... |
|
From: Douglas E E. <dee...@gm...> - 2021-02-03 23:34:23
|
I understand that this is not an easy problem to solve, given the complexity of libp11, OpenSSL with FIPS which is currently using 1.0.2. I like the suggestion of Christian Heimes. I have been looking at that, but have not got far. On 2/3/2021 12:17 PM, Anderson Sasaki wrote: > > ----- Original Message ----- >> From: "Douglas E Engert" <dee...@gm...> >> To: ope...@li... >> Sent: Tuesday, February 2, 2021 2:48:45 PM >> Subject: Re: [Opensc-devel] mutual authentication fails when FIPS enabled >> >> The point of using a smartcard is the crypto operations are done on the smart >> card, token >> or other hardware like a HSM, or TPS. The point of FIPS is the software and >> hardware has >> been approved and tested to do appropriate crypto operations. >> >> The "fix" to just set RSA_FLAG_FIPS_METHOD is not a fix, it is lie. It in >> effect is saying >> libp11 take the responsibility of saying the PKCS11 modules and the smart >> card, tokens >> or other hardware are FIPS complaint. >> >> The problem today, from the PKCS#11 standpoint, there is no way to prove the >> PKCS#11 modules, >> and hardware meet the FIPS standards. Some PKCS#11 modules are software only, >> designed they can run the cloud and with better performance. Some smart cards >> have applets >> that have never bee approved. (Note: The RedHat comments in the bug fix say >> it is not a proper >> fix.) > > Hello, I am the Red Hat developer who introduced the "fix" there. > > The problem is that the engine don't have a way to ask the module if it is an > approved module or not (at least not yet). > > So the "fix" is basically making the engine to tell OpenSSL that the crypto > operations are being performed in an approved module regardless of the module > being used. > > This makes the previous a lie when the module is not approved. That is why it > is not a proper fix, but a workaround. > > In my understanding, this is transferring the responsibility of checking if > the module is indeed an approved module to the user. > > Ideally, the engine would have a way to be configured so that the user can > explicitly say "I know what I'm doing and I verified the module is approved". > >> >> You as the application developer have a choice, as to what version of OpenSSL >> you use. As >> Petr said, you can split the operations up, so the engine with pkcs11 is used >> with a non >> FIPS mode OpenSSL, and FIPS mode for the rest. Or you can use non-FIPS >> OpenSSL. Or modify >> the code like RedHat did. You also have a choice as to what PKCS11 modules >> and hardware >> you are using. >> >> From an OpenSC developer, I see this is a problem, but would not want to see >> the "fix" >> in the code as it is a lie. But it might be possible to add code that would >> set that flag >> Maybe via env variable? This would let the application developer decide if >> they want to take responsibility. > > For me, this is the closest to a proper fix that is possible to be implemented > for now. > > For the engine, I personally like the suggestion given by Christian Heimes which > is to add a CTRL command to set the flag > (see https://bugzilla.redhat.com/show_bug.cgi?id=1827535#c1). > > What do you think? > > Best regards, > Anderson Sasaki > > . > -- Douglas E. Engert <DEE...@gm...> |
|
From: Anderson S. <ans...@re...> - 2021-02-03 18:54:43
|
----- Original Message -----
> From: "George" <whi...@gm...>
> To: ope...@li...
> Sent: Wednesday, February 3, 2021 4:30:31 AM
> Subject: Re: [Opensc-devel] mutual authentication fails when FIPS enabled
>
> I just realized that the LIBP11 function RSA_public_encrypt(...) ends up
> using a function from the OpenSSL FIPS 2.0.16 module to do the RSA
> encryption. Does that mean I can safely configure RSA_FLAG_FIPS_METHOD to be
> "true" in
>
>
>
> SA_METHOD *PKCS11_get_rsa_method(void)
> {
> . . .
> RSA_meth_set_flags(ops, RSA_FLAG_FIPS_METHOD );
> . . .
> }
> ?
For me, setting this flag will tell OpenSSL that the method obtained from the
engine will perform the crypto operations in an approved module.
It is more related with the PKCS#11 module you are using than with the OpenSSL
binary you are using.
To be FIPS compliant, both OpenSSL and the PKCS#11 module you are using have
to be approved. But I can't say that is sufficient for FIPS compliance of your
whole system.
>
>
> I traced the code for
>
>
> int RSA_public_encrypt(int flen, const unsigned char *from, unsigned char
> *to, RSA *rsa, int padding)
> {
> . . .
> return (rsa->meth->rsa_pub_enc(flen, from, to, rsa, padding));
> } down to the code in openssl-fips-2.0.16\crypto\rsa\rsa_eay.c :
>
>
> static int RSA_eay_public_encrypt(int flen, const unsigned char *from,
> unsigned char *to, RSA *rsa, int padding)
> Since we know this if FIPS certified, does this imply the RSA encryption
> function configured in PKCS11_get_rsa_method(void) is also FIPS compliant?
I would say it is not sufficient as some crypto operations would be performed
outside the crypto boundary considered for the validation of this OpenSSL binary.
What I mean is that the OpenSSL binary is validated only for operations performed
inside it. Since you are using an external device to perform cryptographic
operations, you are not using the module in an approved way.
Best regards,
Anderson Sasaki
|
|
From: Anderson S. <ans...@re...> - 2021-02-03 18:17:38
|
----- Original Message ----- > From: "Douglas E Engert" <dee...@gm...> > To: ope...@li... > Sent: Tuesday, February 2, 2021 2:48:45 PM > Subject: Re: [Opensc-devel] mutual authentication fails when FIPS enabled > > The point of using a smartcard is the crypto operations are done on the smart > card, token > or other hardware like a HSM, or TPS. The point of FIPS is the software and > hardware has > been approved and tested to do appropriate crypto operations. > > The "fix" to just set RSA_FLAG_FIPS_METHOD is not a fix, it is lie. It in > effect is saying > libp11 take the responsibility of saying the PKCS11 modules and the smart > card, tokens > or other hardware are FIPS complaint. > > The problem today, from the PKCS#11 standpoint, there is no way to prove the > PKCS#11 modules, > and hardware meet the FIPS standards. Some PKCS#11 modules are software only, > designed they can run the cloud and with better performance. Some smart cards > have applets > that have never bee approved. (Note: The RedHat comments in the bug fix say > it is not a proper > fix.) Hello, I am the Red Hat developer who introduced the "fix" there. The problem is that the engine don't have a way to ask the module if it is an approved module or not (at least not yet). So the "fix" is basically making the engine to tell OpenSSL that the crypto operations are being performed in an approved module regardless of the module being used. This makes the previous a lie when the module is not approved. That is why it is not a proper fix, but a workaround. In my understanding, this is transferring the responsibility of checking if the module is indeed an approved module to the user. Ideally, the engine would have a way to be configured so that the user can explicitly say "I know what I'm doing and I verified the module is approved". > > You as the application developer have a choice, as to what version of OpenSSL > you use. As > Petr said, you can split the operations up, so the engine with pkcs11 is used > with a non > FIPS mode OpenSSL, and FIPS mode for the rest. Or you can use non-FIPS > OpenSSL. Or modify > the code like RedHat did. You also have a choice as to what PKCS11 modules > and hardware > you are using. > > From an OpenSC developer, I see this is a problem, but would not want to see > the "fix" > in the code as it is a lie. But it might be possible to add code that would > set that flag > Maybe via env variable? This would let the application developer decide if > they want to take responsibility. For me, this is the closest to a proper fix that is possible to be implemented for now. For the engine, I personally like the suggestion given by Christian Heimes which is to add a CTRL command to set the flag (see https://bugzilla.redhat.com/show_bug.cgi?id=1827535#c1). What do you think? Best regards, Anderson Sasaki |
|
From: Douglas E E. <dee...@gm...> - 2021-02-03 18:10:33
|
In OpenSSL 1.1.1g these define using the SAME VALUE.
# define RSA_FLAG_FIPS_METHOD 0x0400
# define RSA_FLAG_NON_FIPS_ALLOW 0x0400
./rsa/rsa_lib.c
93 #if !defined(OPENSSL_NO_ENGINE) && !defined(FIPS_MODULE)
94 ret->flags = ret->meth->flags & ~RSA_FLAG_NON_FIPS_ALLOW;
113 ret->flags = ret->meth->flags & ~RSA_FLAG_NON_FIPS_ALLOW;
On 2/2/2021 9:30 PM, George wrote:
> I just realized that the LIBP11 function RSA_public_encrypt(...) ends up using a function from the OpenSSL FIPS 2.0.16 module to do the RSA encryption. Does that mean I can safely configure
The RSA_public_encrypt used a public key to encrypt. The public key is in the certificate of the peer, who holds the private key.
So the smart card is not involved at all on client side.
That is the normal HTTPS:// check the browser does to verify the web server is OK.
The mutual authentication does the above then web server sends a nounce or other data to the client
over the HTTPS connection. The user then signs the nounce an returns the result to the The web server
that verify the signature against the users certificate.
When the user's smart card is used, that is when libp11 and the engine get involved.
(Web server's can also use a smart card, token or HSM, but I don't think that is what you are talking about.)
So it is not clear why you really need FIPS on the client if you use a smartcard.
It is more a mater of trust: If Server trusts the CA that signed user certificate which has private key
only on the smart card, then the server can be assured a smart card was used to do the crypto.
But if FIPS approved smart cards are used, and and the server trusts that the CA would only use
FIPS approved card. Like government issued smart cards. Then you could claim FIPS is being used
because smart card meets FIPS approval.
> RSA_FLAG_FIPS_METHOD to be "true" in
>
> SA_METHOD *PKCS11_get_rsa_method(void)
> {
> . . .
> RSA_meth_set_flags(ops, *RSA_FLAG_FIPS_METHOD*);
> . . .
> }
>
> ?
>
>
> I traced the code for
>
> int RSA_public_encrypt(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding)
> {
> . . .
> return (rsa->meth->rsa_pub_enc(flen, from, to, rsa, padding));
> }
>
> down to the code in openssl-fips-2.0.16\crypto\rsa\rsa_eay.c :
>
> static int RSA_eay_public_encrypt(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding)
>
> Since we know this if FIPS certified, does this imply the RSA encryption function configured in PKCS11_get_rsa_method(void) is also FIPS compliant?
>
>
>
> Thanks,
> George
>
>
> On 2021-02-02 12:11 p.m., George wrote:
>> I tracked the problem down to the code in OpenSLL, which does the RSA encryption. I had a look at how the LIBP11 function PKCS11_get_rsa_method(void) is being used in OpenSSL and it appears that it
>> will *never* work when FIPS is enabled. There seems to be a problem with the logic.
>>
>> For example, the OpenSSL function to handle RSA encryption is openssl-1.0.2u\crypto\rsa\rsa_crpt.c :
>>
>> int RSA_public_encrypt(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding)
>> {
>> #ifdef OPENSSL_FIPS
>> if (FIPS_mode() && *!(r**sa->meth->flags & RSA_FLAG_FIPS_METHOD**)* <--- rsa->meth->flags = 0, and RSA_FLAG_FIPS_METHOD = 0x400
>> && *!(rsa->flags & RSA_FLAG_NON_FIPS_ALLOW)*) { <--- rsa->flags = 6, and RSA_FLAG_NON_FIPS_ALLOW = 0x400
>> RSAerr(RSA_F_RSA_PUBLIC_ENCRYPT, RSA_R_NON_FIPS_RSA_METHOD);
>> return -1;
>> }
>> #endif
>> return (rsa->meth->rsa_pub_enc(flen, from, to, rsa, padding));
>> }
>>
>>
>> The first part of the logic in the if-check is "!(rsa->meth->flags & RSA_FLAG_FIPS_METHOD)" and will always result in "true" because "rsa->meth->flags" was set to 0 in the LIBP11:
>>
>> SA_METHOD *PKCS11_get_rsa_method(void)
>> {
>> . . .
>> RSA_meth_set_flags(ops, 0);
>> . . .
>> }
>>
>>
>> The second part of the if-check "!(rsa->flags & RSA_FLAG_NON_FIPS_ALLOW)" is also "true" because I do not allow non-FIPS methods. i.e. RSA_FLAG_NON_FIPS_ALLOW is not set.
>>
>> Therefore, the following FIPS error is generated:
>>
>> *error:0409909D:rsa routines:RSA_public_encrypt:non fips rsa method*
>>
>>
>> There does not appear to be any success path for RSA_public_encrypt(...), based on the current logic. Is this the correct behaviour, or have I missed something?
>>
>>
>>
>> Thanks,
>> George
>>
>>
>> On 2021-02-02 1:50 a.m., Petr Pisar wrote:
>>> V Mon, Feb 01, 2021 at 10:15:43PM -0500, George napsal(a):
>>>> I would like to clarify my original problem. The mutual
>>>> authentication is between my application using OpenSSL and another
>>>> server. I am using LIBP11 to with OpenSSL to allow OpenSSL to access the
>>>> certificate and private key on my smart card. i.e. OpenSSL is using
>>>> LIBP11 to get the private key and certificate.
>>>>
>>>> When FIPS is enabled, I see the OpenSSL error:
>>>>
>>>> *error:0409909D:rsa routines:RSA_public_encrypt:non fips rsa method*
>>>>
>>>>
>>>> Since I am not making any calls directly to LIBP11, how can I fix this
>>>> in my code? i.e. OpenSSL is using LIBP11, not my application code.
>>>>
>>> There can be many places which violate FIPS. Your (server or client) X.509
>>> certificate can use a weak digest algorithm. The TLS cipher suite can use
>>> a weak algorithm. Your PKCS11 driver can use a weak algorithm when loging into
>>> a smart card. And probably other places. I recommend you to split your code
>>> into smaller pieces: Establishing a TLS connection without the smart card.
>>> Logging into the smart card without making a TLS connection. Making TLS
>>> connection using keys on the card without libp11 library (libp11 is only an
>>> abstraction layer. You can use OpenSSL engines directly.) And find out where
>>> the problem exactly is.
>>>
>>>> Is the problem related to the actual PIN? If so, how can I fix that?
>>>>
>>> The problem is not a value of the PIN. It might be a way how the card driver
>>> logs into the card with the PIN. If it is so, you would have to look into the
>>> PKCS11 driver of your card.
>>>
>>> -- Petr
>>>
>>>
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
--
Douglas E. Engert <DEE...@gm...>
|
|
From: George <whi...@gm...> - 2021-02-03 03:30:55
|
I just realized that the LIBP11 function RSA_public_encrypt(...) ends up
using a function from the OpenSSL FIPS 2.0.16 module to do the RSA
encryption. Does that mean I can safely configure RSA_FLAG_FIPS_METHOD
to be "true" in
SA_METHOD *PKCS11_get_rsa_method(void)
{
. . .
RSA_meth_set_flags(ops, *RSA_FLAG_FIPS_METHOD*);
. . .
}
?
I traced the code for
int RSA_public_encrypt(int flen, const unsigned char *from, unsigned
char *to, RSA *rsa, int padding)
{
. . .
return (rsa->meth->rsa_pub_enc(flen, from, to, rsa, padding));
}
down to the code in openssl-fips-2.0.16\crypto\rsa\rsa_eay.c :
static int RSA_eay_public_encrypt(int flen, const unsigned char
*from, unsigned char *to, RSA *rsa, int padding)
Since we know this if FIPS certified, does this imply the RSA encryption
function configured in PKCS11_get_rsa_method(void) is also FIPS compliant?
Thanks,
George
On 2021-02-02 12:11 p.m., George wrote:
> I tracked the problem down to the code in OpenSLL, which does the RSA
> encryption. I had a look at how the LIBP11 function
> PKCS11_get_rsa_method(void) is being used in OpenSSL and it appears
> that it will *never* work when FIPS is enabled. There seems to be a
> problem with the logic.
>
> For example, the OpenSSL function to handle RSA encryption is
> openssl-1.0.2u\crypto\rsa\rsa_crpt.c :
>
> int RSA_public_encrypt(int flen, const unsigned char *from,
> unsigned char *to, RSA *rsa, int padding)
> {
> #ifdef OPENSSL_FIPS
> if (FIPS_mode() && *!(r**sa->meth->flags &
> RSA_FLAG_FIPS_METHOD**)* <--- rsa->meth->flags = 0, and
> RSA_FLAG_FIPS_METHOD = 0x400
> && *!(rsa->flags & RSA_FLAG_NON_FIPS_ALLOW)*)
> { <--- rsa->flags = 6, and RSA_FLAG_NON_FIPS_ALLOW
> = 0x400
> RSAerr(RSA_F_RSA_PUBLIC_ENCRYPT, RSA_R_NON_FIPS_RSA_METHOD);
> return -1;
> }
> #endif
> return (rsa->meth->rsa_pub_enc(flen, from, to, rsa, padding));
> }
>
>
> The first part of the logic in the if-check is "!(rsa->meth->flags &
> RSA_FLAG_FIPS_METHOD)" and will always result in "true" because
> "rsa->meth->flags" was set to 0 in the LIBP11:
>
> SA_METHOD *PKCS11_get_rsa_method(void)
> {
> . . .
> RSA_meth_set_flags(ops, 0);
> . . .
> }
>
>
> The second part of the if-check "!(rsa->flags &
> RSA_FLAG_NON_FIPS_ALLOW)" is also "true" because I do not allow
> non-FIPS methods. i.e. RSA_FLAG_NON_FIPS_ALLOW is not set.
>
> Therefore, the following FIPS error is generated:
>
> *error:0409909D:rsa routines:RSA_public_encrypt:non fips rsa method*
>
>
> There does not appear to be any success path for
> RSA_public_encrypt(...), based on the current logic. Is this the
> correct behaviour, or have I missed something?
>
>
>
> Thanks,
> George
>
>
> On 2021-02-02 1:50 a.m., Petr Pisar wrote:
>> V Mon, Feb 01, 2021 at 10:15:43PM -0500, George napsal(a):
>>> I would like to clarify my original problem. The mutual
>>> authentication is between my application using OpenSSL and another
>>> server. I am using LIBP11 to with OpenSSL to allow OpenSSL to access the
>>> certificate and private key on my smart card. i.e. OpenSSL is using
>>> LIBP11 to get the private key and certificate.
>>>
>>> When FIPS is enabled, I see the OpenSSL error:
>>>
>>> *error:0409909D:rsa routines:RSA_public_encrypt:non fips rsa method*
>>>
>>>
>>> Since I am not making any calls directly to LIBP11, how can I fix this
>>> in my code? i.e. OpenSSL is using LIBP11, not my application code.
>>>
>> There can be many places which violate FIPS. Your (server or client) X.509
>> certificate can use a weak digest algorithm. The TLS cipher suite can use
>> a weak algorithm. Your PKCS11 driver can use a weak algorithm when loging into
>> a smart card. And probably other places. I recommend you to split your code
>> into smaller pieces: Establishing a TLS connection without the smart card.
>> Logging into the smart card without making a TLS connection. Making TLS
>> connection using keys on the card without libp11 library (libp11 is only an
>> abstraction layer. You can use OpenSSL engines directly.) And find out where
>> the problem exactly is.
>>
>>> Is the problem related to the actual PIN? If so, how can I fix that?
>>>
>> The problem is not a value of the PIN. It might be a way how the card driver
>> logs into the card with the PIN. If it is so, you would have to look into the
>> PKCS11 driver of your card.
>>
>> -- Petr
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
|
|
From: George <whi...@gm...> - 2021-02-02 17:11:43
|
I tracked the problem down to the code in OpenSLL, which does the RSA
encryption. I had a look at how the LIBP11 function
PKCS11_get_rsa_method(void) is being used in OpenSSL and it appears that
it will *never* work when FIPS is enabled. There seems to be a problem
with the logic.
For example, the OpenSSL function to handle RSA encryption is
openssl-1.0.2u\crypto\rsa\rsa_crpt.c :
int RSA_public_encrypt(int flen, const unsigned char *from, unsigned
char *to, RSA *rsa, int padding)
{
#ifdef OPENSSL_FIPS
if (FIPS_mode() && *!(r**sa->meth->flags &
RSA_FLAG_FIPS_METHOD**)* <--- rsa->meth->flags = 0, and
RSA_FLAG_FIPS_METHOD = 0x400
&& *!(rsa->flags & RSA_FLAG_NON_FIPS_ALLOW)*)
{ <--- rsa->flags = 6, and RSA_FLAG_NON_FIPS_ALLOW =
0x400
RSAerr(RSA_F_RSA_PUBLIC_ENCRYPT, RSA_R_NON_FIPS_RSA_METHOD);
return -1;
}
#endif
return (rsa->meth->rsa_pub_enc(flen, from, to, rsa, padding));
}
The first part of the logic in the if-check is "!(rsa->meth->flags &
RSA_FLAG_FIPS_METHOD)" and will always result in "true" because
"rsa->meth->flags" was set to 0 in the LIBP11:
SA_METHOD *PKCS11_get_rsa_method(void)
{
. . .
RSA_meth_set_flags(ops, 0);
. . .
}
The second part of the if-check "!(rsa->flags &
RSA_FLAG_NON_FIPS_ALLOW)" is also "true" because I do not allow non-FIPS
methods. i.e. RSA_FLAG_NON_FIPS_ALLOW is not set.
Therefore, the following FIPS error is generated:
*error:0409909D:rsa routines:RSA_public_encrypt:non fips rsa method*
There does not appear to be any success path for
RSA_public_encrypt(...), based on the current logic. Is this the correct
behaviour, or have I missed something?
Thanks,
George
On 2021-02-02 1:50 a.m., Petr Pisar wrote:
> V Mon, Feb 01, 2021 at 10:15:43PM -0500, George napsal(a):
>> I would like to clarify my original problem. The mutual
>> authentication is between my application using OpenSSL and another
>> server. I am using LIBP11 to with OpenSSL to allow OpenSSL to access the
>> certificate and private key on my smart card. i.e. OpenSSL is using
>> LIBP11 to get the private key and certificate.
>>
>> When FIPS is enabled, I see the OpenSSL error:
>>
>> *error:0409909D:rsa routines:RSA_public_encrypt:non fips rsa method*
>>
>>
>> Since I am not making any calls directly to LIBP11, how can I fix this
>> in my code? i.e. OpenSSL is using LIBP11, not my application code.
>>
> There can be many places which violate FIPS. Your (server or client) X.509
> certificate can use a weak digest algorithm. The TLS cipher suite can use
> a weak algorithm. Your PKCS11 driver can use a weak algorithm when loging into
> a smart card. And probably other places. I recommend you to split your code
> into smaller pieces: Establishing a TLS connection without the smart card.
> Logging into the smart card without making a TLS connection. Making TLS
> connection using keys on the card without libp11 library (libp11 is only an
> abstraction layer. You can use OpenSSL engines directly.) And find out where
> the problem exactly is.
>
>> Is the problem related to the actual PIN? If so, how can I fix that?
>>
> The problem is not a value of the PIN. It might be a way how the card driver
> logs into the card with the PIN. If it is so, you would have to look into the
> PKCS11 driver of your card.
>
> -- Petr
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
|
|
From: Douglas E E. <dee...@gm...> - 2021-02-02 15:06:19
|
Some additional documentation that might help. https://www.openssl.org/docs/fips/UserGuide-2.0.pdf and https://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf Say: "A subsection of Section 2.1 of the CMVP FAQ entitled "A vendor is selling me a crypto solution - what should I ask?" states: "Verify with the vendor that the application or product that is being offered is either a validated cryptographic module itself (e.g. VPN, SmartCard, etc) or the application or product uses an embedded validated cryptographic module (toolkit, etc). Ask the vendor to supply a signed letter stating their application, product or module is a validated module or incorporates a validated module, the module provides all the cryptographic services in the solution, and reference the modules validation certificate number." "Note that the CMVP FAQ does specify that a FIPS 140-1/2 validated module may be incorporated into another product. It then specifies that making a decision on whether a product is correctly utilizing an embedded module is outside of the scope of the FIPS 140-1 or FIPS 140-2 validation." I can't find the above reference but the following might help. (Note libp11 can't provide such a letter.) http://csrc.nist.gov/cryptval/ http://csrc.nist.gov/groups/STM/cmvp/documents/CMVPFAQ.pdf https://csrc.nist.gov/projects/cryptographic-module-validation-program/cmvp-management-manual-and-faqs https://csrc.nist.gov/Topics/technologies/smart-cards (Government issued PIV smartcards should qualify.) -- Douglas E. Engert <DEE...@gm...> |
5 messages has been excluded from this view by a project administrator.
