search

OpenSC / libp11

PKCS#11 wrapper library
GNU Lesser General Public License v2.1
305 stars 186 forks source link

Pass RSA-PSS operation to the token *when it supports it* #176

Closed mouse07410 closed 6 years ago

mouse07410 commented 7 years ago

This is not a bug report (at least I don't think it's a bug). MacOS Sierra 10.12.6, Xcode-8.3.3.

Current Github version of libp11, p11-kit v0.23.2.

I have a USB PKCS#11 device that currently cannot be served by OpenSC opensc-pkcs11.so.

My system has p11-kit installed. The library that serves this device is /usr/local/lib/yubihsm_pkcs11.so.

Could you please help me configuring p11-kit or libp11 or OpenSSL so that libp11 would use the above library upon request?

Thank you!

@nmav perhaps you could step in too?

nmav commented 7 years ago

Most likely you only need to register yubihsm_pkcs11.so with p11-kit. See https://p11-glue.freedesktop.org/doc/p11-kit/config-example.html

mouse07410 commented 7 years ago

Most likely you only need to register yubihsm_pkcs11.so with p11-kit.

@nmav thank you! But it looks like I need to do more. I know that this module should not be initialized "in advance". The README for adding this module to OpenSSL said to add "init = 0". Is there any way to do the same with p11-kit?

$ p11-kit list-modules
yubihsm_pkcs11: Error opening configuration file '(null)'
p11-kit: yhsm2: module failed to initialize, skipping: The operation failed
p11-kit-trust: p11-kit-trust.so
    library-description: PKCS#11 Kit Trust Module
    library-manufacturer: PKCS#11 Kit
    library-version: 0.23
    token: Default Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.23
        flags:
               write-protected
               token-initialized
    token: System Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.23
        flags:
               write-protected
               token-initialized
pkcs11: /Library/OpenSC/lib/opensc-pkcs11.dylib
    library-description: OpenSC smartcard framework
    library-manufacturer: OpenSC Project
    library-version: 0.17
softhsm: /opt/local/lib/softhsm/libsofthsm2.dylib
    library-description: Implementation of PKCS11
    library-manufacturer: SoftHSM
    library-version: 2.3
    token: Botan PKCS#11 tests
        manufacturer: SoftHSM project
        model: SoftHSM v2
        serial-number: b158018a21bc4979
        hardware-version: 2.3
        firmware-version: 2.3
        flags:
               rng
               login-required
               user-pin-initialized
               restore-key-not-needed
               token-initialized
    token: test
        manufacturer: SoftHSM project
        model: SoftHSM v2
        serial-number: 02b891b82879828e
        hardware-version: 2.3
        firmware-version: 2.3
        flags:
               rng
               login-required
               user-pin-initialized
               restore-key-not-needed
               token-initialized
    token: 
        manufacturer: SoftHSM project
        model: SoftHSM v2
        serial-number: 
        hardware-version: 2.3
        firmware-version: 2.3
        flags:
               rng
               login-required
               restore-key-not-needed
               so-pin-locked
               so-pin-to-be-changed
ykcs11: /usr/local/lib/libykcs11.dylib
    library-description: PKCS#11 PIV Library (SP-800-73)
    library-manufacturer: Yubico (www.yubico.com)
    library-version: 1.44
$ cat ~/.config/pkcs11/modules/yhsm2.module 
module: /usr/local/lib/yubihsm_pkcs11.dylib
$
mouse07410 commented 7 years ago

Update Looks like adding critical: no to the yhsm2.module resolved the problem...?

$ p11-kit list-modules
p11-kit-trust: p11-kit-trust.so
    library-description: PKCS#11 Kit Trust Module
    library-manufacturer: PKCS#11 Kit
    library-version: 0.23
    token: Default Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.23
        flags:
               write-protected
               token-initialized
    token: System Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.23
        flags:
               write-protected
               token-initialized
pkcs11: /Library/OpenSC/lib/opensc-pkcs11.dylib
    library-description: OpenSC smartcard framework
    library-manufacturer: OpenSC Project
    library-version: 0.17
softhsm: /opt/local/lib/softhsm/libsofthsm2.dylib
    library-description: Implementation of PKCS11
    library-manufacturer: SoftHSM
    library-version: 2.3
    token: Botan PKCS#11 tests
        manufacturer: SoftHSM project
        model: SoftHSM v2
        serial-number: b158018a21bc4979
        hardware-version: 2.3
        firmware-version: 2.3
        flags:
               rng
               login-required
               user-pin-initialized
               restore-key-not-needed
               token-initialized
    token: test
        manufacturer: SoftHSM project
        model: SoftHSM v2
        serial-number: 02b891b82879828e
        hardware-version: 2.3
        firmware-version: 2.3
        flags:
               rng
               login-required
               user-pin-initialized
               restore-key-not-needed
               token-initialized
    token: 
        manufacturer: SoftHSM project
        model: SoftHSM v2
        serial-number: 
        hardware-version: 2.3
        firmware-version: 2.3
        flags:
               rng
               login-required
               restore-key-not-needed
               so-pin-locked
               so-pin-to-be-changed
yhsm2: /usr/local/lib/yubihsm_pkcs11.dylib
    library-description: YubiHSM PKCS#11 Library
    library-manufacturer: Yubico (www.yubico.com)
    library-version: 0.9
    token: YubiHSM
        manufacturer: Yubico (www.yubico.com)
        model: YubiHSM
        serial-number: 056xxxxx
        hardware-version: 0.100
        firmware-version: 0.100
        flags:
               rng
               login-required
               user-pin-initialized
               token-initialized
ykcs11: /usr/local/lib/libykcs11.dylib
    library-description: PKCS#11 PIV Library (SP-800-73)
    library-manufacturer: Yubico (www.yubico.com)
    library-version: 1.44
$

But when I try to use this yhsm2 engine, I'm getting error from OpenSSL:

$ OPENSSL_CONF=~/src/openssl.cnf openssl engine -t -c pkcs11
(pkcs11) pkcs11 engine
 [RSA]
     [ available ]
$ OPENSSL_CONF=~/src/openssl.cnf openssl engine -t -c yhsm2
bad engine id
140736391603208:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:545:
140736391603208:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:390:id=yhsm2
$

I symlinked libpkcs11.dylib to libyhsm2.dylib because I wanted libp11 to take care of this... Here's the tail of my openssl.cnf:

. . . . .
[engine_section]
pkcs11 = pkcs11_section
yhsm2  = yhsm2_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /opt/local/lib/engines/libpkcs11.so
MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so
init = 0

[yhsm2_section]
engine_id = yhsm2
dynamic_path = /opt/local/lib/engines/libyhsm2.dylib
MODULE_PATH = /usr/local/lib/yubihsm_pkcs11.dylib
init = 0

Another thing I haven't figured out is how exactly to tie all these together. I.e., how to inform p11-kit and/or libp11 when I want to use pkcs11.module, when ykcs11.module, and when - yhsm2.module. I tried to explicitly define module yhsm2 by symlinking libpkcs11.dylib to libyhsm2.dylib, but it did not quite work.

It looks like I have to stick with engine pkcs11 definition if I want to use libp11 - unless there's some config trick that I'm now aware of. How can I choose and then verify which library (opensc-pkcs11.dylib or yubihsm_pkcs11.dylib) is used for a request, such as $ openssl rand -engine pkcs11 128 -hex?

nmav commented 7 years ago

Does p11tool show anything for that module? My experience with yubi pkcs11 modules is that they are often incomplete and half baked.

On August 20, 2017 4:23:37 AM GMT+02:00, Mouse notifications@github.com wrote:

Update Looks like adding critical: no to the yhsm2.module resolved the problem...?

$ p11-kit list-modules
p11-kit-trust: p11-kit-trust.so
   library-description: PKCS#11 Kit Trust Module
   library-manufacturer: PKCS#11 Kit
   library-version: 0.23
   token: Default Trust
       manufacturer: PKCS#11 Kit
       model: p11-kit-trust
       serial-number: 1
       hardware-version: 0.23
       flags:
              write-protected
              token-initialized
   token: System Trust
       manufacturer: PKCS#11 Kit
       model: p11-kit-trust
       serial-number: 1
       hardware-version: 0.23
       flags:
              write-protected
              token-initialized
pkcs11: /Library/OpenSC/lib/opensc-pkcs11.dylib
   library-description: OpenSC smartcard framework
   library-manufacturer: OpenSC Project
   library-version: 0.17
softhsm: /opt/local/lib/softhsm/libsofthsm2.dylib
   library-description: Implementation of PKCS11
   library-manufacturer: SoftHSM
   library-version: 2.3
   token: Botan PKCS#11 tests
       manufacturer: SoftHSM project
       model: SoftHSM v2
       serial-number: b158018a21bc4979
       hardware-version: 2.3
       firmware-version: 2.3
       flags:
              rng
              login-required
              user-pin-initialized
              restore-key-not-needed
              token-initialized
   token: test
       manufacturer: SoftHSM project
       model: SoftHSM v2
       serial-number: 02b891b82879828e
       hardware-version: 2.3
       firmware-version: 2.3
       flags:
              rng
              login-required
              user-pin-initialized
              restore-key-not-needed
              token-initialized
   token: 
       manufacturer: SoftHSM project
       model: SoftHSM v2
       serial-number: 
       hardware-version: 2.3
       firmware-version: 2.3
       flags:
              rng
              login-required
              restore-key-not-needed
              so-pin-locked
              so-pin-to-be-changed
yhsm2: /usr/local/lib/yubihsm_pkcs11.dylib
   library-description: YubiHSM PKCS#11 Library
   library-manufacturer: Yubico (www.yubico.com)
   library-version: 0.9
   token: YubiHSM
       manufacturer: Yubico (www.yubico.com)
       model: YubiHSM
       serial-number: 05684076
       hardware-version: 0.100
       firmware-version: 0.100
       flags:
              rng
              login-required
              user-pin-initialized
              token-initialized
ykcs11: /usr/local/lib/libykcs11.dylib
   library-description: PKCS#11 PIV Library (SP-800-73)
   library-manufacturer: Yubico (www.yubico.com)
   library-version: 1.44
$

But when I try to use this yhsm2 engine, I'm getting error from OpenSSL:

$ OPENSSL_CONF=~/src/openssl.cnf openssl engine -t -c pkcs11
(pkcs11) pkcs11 engine
[RSA]
    [ available ]
$ OPENSSL_CONF=~/src/openssl.cnf openssl engine -t -c yhsm2
bad engine id
140736391603208:error:260B606D:engine routines:DYNAMIC_LOAD:init
failed:eng_dyn.c:545:
140736391603208:error:2606A074:engine routines:ENGINE_by_id:no such
engine:eng_list.c:390:id=yhsm2
$

I symlinked libpkcs11.dylib to libyhsm2.dylib because I wanted libp11 to take care of this... Here's the tail of my openssl.cnf:

. . . . .
[engine_section]
pkcs11 = pkcs11_section
yhsm2  = yhsm2_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /opt/local/lib/engines/libpkcs11.so
MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so
init = 0

[yhsm2_section]
engine_id = yhsm2
dynamic_path = /opt/local/lib/engines/libyhsm2.dylib
MODULE_PATH = /usr/local/lib/yubihsm_pkcs11.dylib
init = 0

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

dengert commented 7 years ago

https://www.yubico.com/products/yubihsm/ says: "Offers encryption with a Message Authentication Code (MAC), HMAC-SHA1 hashing, AES encryption/decryption, and cryptographic True Random Number Generation."

This sounds like it only supports symmetric keys.

AFAIK libp11 and its engine only support the use of asymmetric keys RSA and EC via the engine. (Sounds like a future project.)

Can you get OpenSC pkcs11-tool to list the mechanisms supported by the /usr/local/lib/yubihsm_pkcs11.so?

I don't see on github.com/yubico a yubihsm so it may not be open source.

To see if trying it with p11-kit, can you get a PKCS#11 trace. You could use opensc-spy in front of yubihsm_pkcs11. This might show it fails to support RSA, which I suspect is why it the engine code is failing.

On 8/18/2017 3:45 PM, Mouse wrote:

This is not a bug report (at least I don't think it's a bug). MacOS Sierra 10.12.6, Xcode-8.3.3.

Current Github version of |libp11|, |p11-kit| v0.23.2.

I have a USB PKCS#11 device that currently cannot be served by OpenSC |opensc-pkcs11.so|.

My system has |p11-kit| installed. The library that serves this device is |/usr/local/lib/yubihsm_pkcs11.so|.

Could you please help me configuring |p11-kit| or |libp11| or OpenSSL so that |libp11| would use the above library upon request?

Thank you!

@nmav https://github.com/nmav perhaps you could step in too?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenSC/libp11/issues/176, or mute the thread https://github.com/notifications/unsubscribe-auth/AA00MV7a1Ka5zESct7b1K7hycuUBxCEfks5sZffigaJpZM4O8BoA.

--

Douglas E. Engert DEEngert@gmail.com

mouse07410 commented 7 years ago

My experience with yubi pkcs11 modules is that they are often incomplete and half baked.

No argument from me here! ;-)

Does p11tool show anything for that module?

Yep:

$ p11tool --list-tokens
Token 0:
    URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=Default%20Trust
    Label: Default Trust
    Type: Trust module
    Manufacturer: PKCS#11 Kit
    Model: p11-kit-trust
    Serial: 1
    Module: p11-kit-trust.so

Token 1:
    URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
    Label: System Trust
    Type: Trust module
    Manufacturer: PKCS#11 Kit
    Model: p11-kit-trust
    Serial: 1
    Module: p11-kit-trust.so

Token 2:
    URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=b158018a21bc4979;token=Botan%20PKCS%2311%20tests
    Label: Botan PKCS#11 tests
    Type: Generic token
    Manufacturer: SoftHSM project
    Model: SoftHSM v2
    Serial: b158018a21bc4979
    Module: /opt/local/lib/softhsm/libsofthsm2.dylib

Token 3:
    URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=02b891b82879828e;token=test
    Label: test
    Type: Generic token
    Manufacturer: SoftHSM project
    Model: SoftHSM v2
    Serial: 02b891b82879828e
    Module: /opt/local/lib/softhsm/libsofthsm2.dylib

Token 4:
    URL: pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM
    Label: YubiHSM
    Type: Hardware token
    Manufacturer: Yubico (www.yubico.com)
    Model: YubiHSM
    Serial: 056xxxxx
    Module: /usr/local/lib/yubihsm_pkcs11.dylib

$ p11tool --login --list-all "pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM"
Token 'YubiHSM' with URL 'pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM' requires user PIN
Enter PIN: 
Object 0:
    URL: pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM;id=%00%01;object=DEFAULT%20AUTHKEY%20CHANGE%20THIS%20ASAP;type=secret-key
    Type: Secret key
    Label: DEFAULT AUTHKEY CHANGE THIS ASAP
    Flags: CKA_PRIVATE; CKA_EXTRACTABLE; CKA_SENSITIVE; 
    ID: 00:01

Object 1:
    URL: pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM;id=%8a%17;object=label%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00;type=secret-key
    Type: Secret key
    Label: label
    Flags: CKA_PRIVATE; CKA_NEVER_EXTRACTABLE; CKA_SENSITIVE; 
    ID: 8a:17

Object 2:
    URL: pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM;id=%8f%b8;object=label%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00;type=private
    Type: Private key
    Label: label
    Flags: CKA_PRIVATE; CKA_NEVER_EXTRACTABLE; CKA_SENSITIVE; 
    ID: 8f:b8

Object 3:
    URL: pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM;id=%8f%b8;object=label%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00;type=public
    Type: Public key
    Label: label
    Flags: CKA_EXTRACTABLE; 
    ID: 8f:b8

Object 4:
    URL: pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM;id=%8f%b8;object=label%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00;type=cert
    Type: X.509 Certificate
    Label: label
    Flags: CKA_PRIVATE; 
    ID: 8f:b8

Object 5:
    URL: pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM;id=%d7%41;object=label%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00;type=private
    Type: Private key
    Label: label
    Flags: CKA_PRIVATE; CKA_NEVER_EXTRACTABLE; CKA_SENSITIVE; 
    ID: d7:41

Object 6:
    URL: pkcs11:model=YubiHSM;manufacturer=Yubico%20%28www.yubico.com%29;serial=056xxxxx;token=YubiHSM;id=%d7%41;object=label%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00;type=public
    Type: Public key
    Label: label
    Flags: CKA_EXTRACTABLE; 
    ID: d7:41

$

https://www.yubico.com/products/yubihsm/ says: ...

Yes, that was their first attempt to sell an HSM device, and indeed it was rather limited (aka unsuitable for my needs - no asymmetric, etc.).

This is their 2nd version, and it's still in Beta - so you can't find it on a product site yet. They are still enhancing and improving it ("it" applies to hardware, software, and documentation).

Can you get OpenSC pkcs11-tool to list the mechanisms supported by the /usr/local/lib/yubihsm_pkcs11.so?

Yep, you bet:

$ pkcs11-tool --module $YUBIHSM_PKCS11_MODULE -M
Using slot 0 with a present token (0x0)
Supported mechanisms:
  RSA-PKCS, keySize={2048,4096}, hw, decrypt, sign
  SHA1-RSA-PKCS, keySize={2048,4096}, hw, decrypt, sign
  SHA256-RSA-PKCS, keySize={2048,4096}, hw, decrypt, sign
  SHA384-RSA-PKCS, keySize={2048,4096}, hw, decrypt, sign
  SHA512-RSA-PKCS, keySize={2048,4096}, hw, decrypt, sign
  RSA-PKCS-PSS, keySize={2048,4096}, hw, sign
  SHA1-RSA-PKCS-PSS, keySize={2048,4096}, hw, sign
  SHA256-RSA-PKCS-PSS, keySize={2048,4096}, hw, sign
  SHA384-RSA-PKCS-PSS, keySize={2048,4096}, hw, sign
  SHA512-RSA-PKCS-PSS, keySize={2048,4096}, hw, sign
  RSA-PKCS-KEY-PAIR-GEN, keySize={2048,4096}, hw, generate_key_pair
  ECDSA-KEY-PAIR-GEN, keySize={256,521}, hw, generate_key_pair, other flags=0x1500000
  SHA-1-HMAC, keySize={1,512}, hw, sign, verify
  SHA256-HMAC, keySize={1,512}, hw, sign, verify
  SHA384-HMAC, keySize={1,1024}, hw, sign, verify
  SHA512-HMAC, keySize={1,1024}, hw, sign, verify
  ECDSA, keySize={256,521}, hw, sign, other flags=0x1500000
  ECDSA-SHA1, keySize={256,521}, hw, sign, other flags=0x1500000
  ECDSA-SHA256, keySize={256,521}, hw, sign, other flags=0x1500000
  ECDSA-SHA348, keySize={256,521}, hw, sign, other flags=0x1500000
  ECDSA-SHA512, keySize={256,521}, hw, sign, other flags=0x1500000
  RSA-PKCS-OAEP, keySize={2048,4096}, hw, decrypt
  mechtype-0x80000004, keySize={128,128}, hw, wrap
  SHA-1, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  GENERIC-SECRET-KEY-GEN, keySize={128,128}, hw, generate
$

AFAIK libp11 and its engine only support the use of asymmetric keys RSA and EC via the engine. (Sounds like a future project.)

Are you sure? Can it access RNG that the token provides? I.e., if I'm accessing a token programmatically via OpenSSL+libp11, and want to get some randomness from its RNG - I should be able to, right?

I don't see on github.com/yubico a yubihsm so it may not be open source.

No, not yet at least (but that's up to Yubico to decide).

To see if trying it with p11-kit, can you get a PKCS#11 trace. You could use opensc-spy in front of yubihsm_pkcs11.

To do that I would need to set YUBIHSM_PKCS11_MODULE=/Library/OpenSC/lib/opensc-spy.dylib and PKCS11SPY=/usr/local/lib/yubihsm_pkcs11.dylib, and run p11-kit? Right?

dengert commented 7 years ago

It looks like you have two ways to use the yubihsm with OpenSSL as an engine. You refer to trying: 

[yhsm2_section]
engine_id = yhsm2
dynamic_path = /opt/local/lib/engines/libyhsm2.dylib
MODULE_PATH = /usr/local/lib/yubihsm_pkcs11.dylib
init = 0

Is libyhsm2.dylib an engine module? Does it call PKCS#11? Does it need to load other libs? What does ldd or MacOS version show what it needs to load.

The other choice is to use libp11's engine, and let it use p11-kit or a PKCS#11 module. It also looks like yubihsm_pkcs11.dylib does not support any symmetric mechanisms.

But I don't think symmetric keys or random are supported by libp11 either. Look for ENGINESET functions or ENGINE_set_RAND and ENGNE_SET_ciphers in libp11 or the yubi libs.

mouse07410 commented 7 years ago

Is libyhsm2.dylib an engine module? Does it call PKCS#11? Does it need to load other libs?

Wel, that's my ugly hack. I took pkcs11.dylib (the PKCS#11 engine/library from libp11) and copied it to libyhsm2.dylib. One reason why - because ultimately I want the libp11 engine to handle this, as a part of all the PKCS#11 token support (CAC, PIV, Yubikey, and this new Yubico HSM2 device).

What does ldd or MacOS version show what it needs to load.

All the normal things - it's a copy of working libp11... The MacOS version is $ otool -L /path/to/libyhsm2.dylib.

The other choice is to use libp11's engine, and let it use p11-kit or a PKCS#11 module.

Since my current installation has libp11 using p11-kit, I think this is the path I'd like to follow.

It also looks like yubihsm_pkcs11.dylib does not support any symmetric mechanisms.

Could you give an example of a symmetric mechanism, so I know what to look/check for? I.e., how would I tell pkcs11-tool to do something "symmetric", and what would pkcs11-tool -M report for symmetric mechanisms?

Thanks!

mtrojnar commented 7 years ago

Could you give an example of a symmetric mechanism

libp11 does not support symmetric algorithms.

mouse07410 commented 7 years ago

libp11 does not support symmetric algorithms.

OK, thanks. I still would like to know what OpenSC would report if the token itself supported symmetric algorithms, and what would those algorithms (typically) be, besides hash (SHA-x) and HMAC.

dengert commented 7 years ago

@mouse you asked: "what would pkcs11-tool -M report for symmetric mechanisms:

pkcs11-tool.c maps CKM_* via the static struct mech_info p11_mechanisms or prints the HEX value of the mechanism. So look for CKM_AES_ (The table appears to have all the PKCS#11 symmetric key mechanisms in the table.)_

You said you were working with some beta version of the yubihsm.

https://www.yubico.com/products/yubihsm/ says it supports AES.

So why does it not support AES? (If the module supported it, pkcs11-tool -M should have listed it.) Or why does the web page say it supports AES?

In addition, If you have any input with Yubico on this have them do something to make the 0x80000004 mechanism Yubico specific, like what Netscape did.

dengert commented 7 years ago

@mouse you also asked: " how would I tell pkcs11-tool to do something "symmetric".

Just because pkcs11-tool.c can list all the mechanisms, it does not mean it can use them.

mouse07410 commented 7 years ago

You said you were working with some beta version of the yubihsm.

Yep. It is pre-production. Exact specs not finalized yet.

https://www.yubico.com/products/yubihsm/ says it supports AES. So why does it not support AES? (If the module supported it, pkcs11-tool -M should have listed it.)

Yeah, but that page is for a different HSM. Maybe this one would be able to do the same, or maybe it would be more in line with the "big guns" HSM that mostly do audited asymmetric things like CA operations... As it is highly unlikely one would use a USB-connected HSM with Yubikey-Nano form-factor to off-load bulk encryption to.

In addition, If you have any input with Yubico on this have them do something to make the 0x80000004 mechanism Yubico specific, like what Netscape did.

I cannot claim to have a pull with them, but I certainly can inform of issues and recommend solutions. In your opinion, what should be done? I.e., what should be changed and where? Is it what the physical device reports? Or is it what the supporting library (the "driver") maps it to? And what should it (whatever "it" is) be mapped to instead?

dengert commented 7 years ago

@mouse07410 See: https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738 as to how a vendor can make vendor_defined PKCS#11 types. I see you have given it a "thumbs up" already.

I would suggest Yubico use 59554200 for YUB This gives then up to 256 different types. It has a better change of being unique when use with p11-kit for example.

And these could be added to pkcs11-tool to at least list them. I would never add 0x80000004 to pkcs11-tool, as it has little chance of being unique across multiple modules.

mouse07410 commented 7 years ago

@dengert so if I understand correctly, you suggest

Correct? (If so, I will certainly pass this to Yubico, and hopefully they'd do the right thing...)

dengert commented 7 years ago

Yes.

dengert commented 7 years ago

Except we were talking mechanisms, so it would be:

define CKM_YUBICO_WHATEVER_MECH ( CKM_VENDOR_DEFINED | YUBICO_VENDOR_DEFINED | 4UL)

mouse07410 commented 7 years ago

Submitted. Let's wait and see now. ;-)

mouse07410 commented 7 years ago

I can close this issue. Here's what I learned:

The problem: YubiHSM2 can sign using RSA-PSS, for example with SHA384-RSA-PKCS-PSS algorithm, via yubihsm-shell. But trying to access it via libp11 or OpenSC fails:

$ openssl dgst -sha384 -engine pkcs11 -keyform engine -sign "pkcs11:token=YubiHSM;id=%03%01;type=private" -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -out t2570.dat.sig4 t2570.dat
engine "pkcs11" set.
Enter PKCS#11 token PIN for YubiHSM:
Error Signing Data
140736391603208:error:8207A070:PKCS#11 module:pkcs11_private_encrypt:Mechanism invalid:p11_rsa.c:120:
$

Doing the same thing with Yubikey NEO works:

$ openssl dgst -sha384 -engine pkcs11 -keyform engine -sign "pkcs11:manufacturer=piv_II;object=SIGN%20key;type=private" -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -out t2570.dat.sig4 t2570.dat
engine "pkcs11" set.
Enter PKCS#11 token PIN for PIV Card Holder pin (PIV_II):
Enter PKCS#11 key PIN for SIGN key:
$ openssl dgst -sha384 -engine pkcs11 -keyform engine -verify "pkcs11:manufacturer=piv_II;object=SIGN%20pubkey;type=public" -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature t2570.dat.sig4 t2570.dat
engine "pkcs11" set.
Verified OK
$

Verifying SHA384-RSA-PKCS-PSS signature made by yubihsm-shell with private key stored in YubiHSM2 also works fine:

$ openssl dgst -sha384 -verify 301-rsa.pem -keyform PEM -sigopt rsa_padding_mode:pss -signature t2570.dat.sig t2570.dat
Verified OK
$ openssl dgst -sha384 -engine pkcs11 -keyform engine -verify "pkcs11:token=YubiHSM;id=%03%01;type=public" -sigopt rsa_padding_mode:pss -signature t2570.dat.sig t2570.dat
engine "pkcs11" set.
Enter PKCS#11 token PIN for YubiHSM:
Verified OK
$

RSASSA PKCS v1.5 signatures also work with YubiHSM2:

$ openssl dgst -sha384 -engine pkcs11 -keyform engine -sign "pkcs11:token=YubiHSM;id=%03%01;type=private" -sigopt rsa_padding_mode:pkcs1 -out t2570.dat.sig2 t2570.dat
engine "pkcs11" set.
Enter PKCS#11 token PIN for YubiHSM:
$ openssl dgst -sha384 -engine pkcs11 -keyform engine -verify "pkcs11:token=YubiHSM;id=%03%01;type=public" -sigopt rsa_padding_mode:pkcs1 -signature t2570.dat.sig2 t2570.dat
engine "pkcs11" set.
Enter PKCS#11 token PIN for YubiHSM:
Verified OK
$

Any recommendations here?

dengert commented 7 years ago

Most likely the problem has to do with differences in the card's or libp11's capabilities. The PIV type devices support mechanism RSA-X509. The YubiHSM does not based on pkcs11-tool -M list above. With RSA-X509 (i.e. RAW RSA) upper levels of software (like OpenSSL) can do the padding. But the YubiHSM only supports RSA-PKCS and RSA-PKCS-PSS.

Run both PIV and YubiHSM with SPY traces to see what is going on.

dengert commented 7 years ago

And it looks like p11 does not support PSS. look at p11_rsa.c: pkcs11_mechanism() It only understands CKM_RSA_PKCS, CKM_RSA_X_509 and CKM_RSA_X9_31.

mouse07410 commented 7 years ago

Most likely the problem has to do with differences in the card's or libp11's capabilities.

What I think you're saying is:

Correct?

And a naive question: why it does not fail on signature verification, only on signing? Because the verification is actually done always in software (aka public key is extracted from the card, unlike private key operations)?

And it looks like p11 does not support PSS.

@mtrojnar what would it take to add CKM_RSA_PKCS_PSS mechanism in? With some kind of a check that would not abort the operation or try to ask the token to do PSS if all it supports is RSA-X509? So it won't break RSA-PSS for tokens (like PIV and Yubikey NEO) that do only RSA-X509 where it works now?

Run both PIV and YubiHSM with SPY traces to see what is going on.

Will do and post here.

Update Successful RSA-PSS spy log with Yubikey NEO: spy-neo.txt

Failing RSA-PSS spy log with YubiHSM2: spy-yhsm2.txt

@mtrojnar So what I'm essentially after is libp11 enhancement to pass RSA-PSS requests to the token when the token supports it, and to keep requesting RSA-X509 with the tokens that don't support RSA-PSS. Is it feasible?

mouse07410 commented 7 years ago

@mtrojnar ?

mtrojnar commented 7 years ago

The spy logs confirm what I found during my investigation of the OpenSSL source code in March 2016: OpenSSL never requests the PSS padding from an engine. Instead, it requests RSA_NO_PADDING (which translates into CKM_RSA_X_509 for PKCS#11), and handles the padding internally.

Apparently, YubiHSM2 doesn't support CKM_RSA_X_509:

[in] hSession = 0x0
pMechanism->type=CKM_RSA_X_509                
[in] hKey = 0x30301
Returned:  112 CKR_MECHANISM_INVALID

I don't think we can change the OpenSSL's implementation from within libp11 or the engine.

mtrojnar commented 7 years ago

@mouse07410: We already discussed a very similar topic: https://github.com/OpenSC/libp11/issues/70#issuecomment-192337326

mouse07410 commented 7 years ago

@mtrojnar yes indeed, thank you for reminding me. It was a great work!

Apparently, YubiHSM2 doesn't support CKM_RSA_X_509

I'm trying to convince the developers of HSM2 to add support for RSA-X-509.

I envision difficulties because HSM2 is capabilities-based. Each key is assigned immutable capabilities, such as asymmetric_sign_pss and/or asymmetric_sign_pkcs. So if they add support for RSA-X-509, one would be unable to restrict the key to PSS signatures only, and use OpenSSL/libp11 with it...

What's your opinion on this problem?

Thanks!

mtrojnar commented 7 years ago

Allowing CKM_RSA_X_509 (raw RSA) for existing signature-only keys would be a bad idea. It would be better to use separate keys, which have a capability allowing for CKM_RSA_X_509.

An alternative approach would be to extend the OpenSSL engine API to optionally invoke additional mechanisms, such as RSA_PKCS1_PSS_PADDING, directly from an engine. Preferably, engines should be able to declare which mechanisms they directly support for a specific key. We would also need to extend libp11 to translate OpenSSL RSA_PKCS1_PSS_PADDING parameters into PKCS#11 CKM_RSA_PKCS_PSS parameters.

dengert commented 7 years ago

Here is another approach that does not require OpenSSL mods.

When the engine and/or libp11 sees an encryption to use CKM_RSA_X_509 but the PKCS#11 module does not support it, the block to be encrypted could be examined to see if it is looks like RSA_PKCS1_PSS_PADDING. Since it is not encrypted at this point it might be possible to get the information needed for CKM_RSA_PKCS_PSS parameters much like a verify operation does.

https://tools.ietf.org/html/rfc8017#section-9.1.2 shows what is needed to do a verify EMSA-PSS-VERIFY (M, EM, emBits)

This might require implementing ENGINE_set_digests so as to trap M, EM, and Hash. But this would need to be done before the engine knew it would be a PSS operation, so every digest would be traped, and at least the last one saved.

(It might be easier to "extend the OpenSSL engine API" as @mtrojnar suggested and get OpenSSL to accept the changes. )

Another approach is to use LD_PRELOAD to replace RSA_padding_add_PKCS1_PSS to pass the parameters to populate the CKM_RSA_PKCS_PSS. But this may not work on all OSes.

But to develop this would require a PKCS#11 module that supported PSS in software or hardware. And it is not clear if this would work.

@mouse07410 how bad do you need this?

mouse07410 commented 7 years ago

Allowing CKM_RSA_X_509 (raw RSA) for existing signature-only keys would be a bad idea.

Not just bad - impossible. :-) Capabilities are immutable. Once a key has been created with a set of capabilities - it cannot add or shed any.

An alternative approach would be to extend the OpenSSL engine API to optionally invoke additional mechanisms, such as RSA_PKCS1_PSS_PADDING, directly from an engine.

Is it likely to happen? How complicated would this extension interface be?

Here is another approach that does not require OpenSSL mods. When the engine and/or libp11 sees an encryption to use CKM_RSA_X_509 but the PKCS#11 module does not support it, the block to be encrypted could be examined to see if it is looks like RSA_PKCS1_PSS_PADDING.

I like this idea!

This might require implementing ENGINE_set_digests so as to trap M, EM, and Hash. But this would need to be done before the engine knew it would be a PSS operation, so every digest would be traped, and at least the last one saved.

May I ask why? Is it to prevent OpenSSL itself from running the hash over the data to sign? If not - we can figure out the hash from the mechanism code.

(It might be easier to "extend the OpenSSL engine API" as @mtrojnar suggested and get OpenSSL to accept the changes. )

I don't know which of the two parts of the above is scarier. ;-)

@mouse07410 how bad do you need this?

Moderately. Right now it is a beta device, with interface and functionality still not cast in stone. Once it is ready for "real" evaluation by people who can buy in volume - I don't know for sure what their requirements would be... :-(

dengert commented 7 years ago

You asked: "May I ask why? Is it to prevent OpenSSL itself from running the hash over the data to sign? If not - we can figure out the hash from the mechanism code."

The way I read the OpenSSL code, the hash is done first by OpenSSL , then the padding is done in https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_pmeth.c in lines 163-172:

        } else if (rctx->pad_mode == RSA_PKCS1_PSS_PADDING) {
            if (!setup_tbuf(rctx, ctx))
                return -1;
            if (!RSA_padding_add_PKCS1_PSS_mgf1(rsa,
                                                rctx->tbuf, tbs,
                                                rctx->md, rctx->mgf1md,
                                                rctx->saltlen))
                return -1;
            ret = RSA_private_encrypt(RSA_size(rsa), rctx->tbuf,
                                      sig, rsa, RSA_NO_PADDING);

RSA_padding_add_PKCS1_PSS_mgf1 creates the tbuf, then RSA_private_encrypt is called with RSA_private_encrypt, and RSA_NO_PADDING. The RSA_PKCS1_PSS_PADDING is not passed to the engine.

Note that the engine/libp11 never sees the padding (thus no PKCS#11 mechanism is available) even though this is a sign operation, RSA_private_encrypt is called to do RAW RSA.

It is not clear to me that one could examine the tbuf to see if it is PSS, and get all the info need to pass to PKCS#11 to do CKM_RSA_PKCS_PSS. Best I can tell reading RFC 8017, one can not determine if the data is a PSS pad, without knowing more info.

In your spy-neo.txt it looks like the the tbuf would be in lines 793 to 795, but not all of it in in the trace. 

103: C_Sign
2017-08-25 18:50:38.254
[in] hSession = 0x7fa60d6041d0
[in] pData[ulDataLen] 00007fa60d6057e0 / 256
    00000000  79 94 00 6E 98 3B AD C7 B8 72 48 B9 33 7E 55 AB  y..n.;...rH.3~U.
    . . . . .
    000000F0  A1 77 86 1D 86 8A 9B 90 CA EE 17 78 5A DA 76 BC  .w.........xZ.v.

Best I can tell reading RFC 8017, one can not determine if the data is a PSS pad.

mouse07410 commented 7 years ago

The way I read the OpenSSL code, the hash is done first by OpenSSL , then the padding is done... Best I can tell reading RFC 8017, one can not determine if the data is a PSS pad.

I'm afraid you're 100% right.

What are the implications? That OpenSSL would have to make changes to its engine interface to get HSM-like devices that use combined algorithms working?

nmav commented 7 years ago

If you manage to use RSA-PSS through the engine and would like to test it with softhsm, I've sent a patch to it for the RSA-PKCS-PSS mechanism: https://github.com/opendnssec/SoftHSMv2/pull/335

dengert commented 7 years ago

If the weather turns bad, and I can't play golf next week, I will look at OpenSSL mods for an engine. and libp11/engine changes to use it.

dengert commented 7 years ago

@mouse07410 You had suggested some defaults for the PSS parameters,

RFC 8017, 4055 and 5756 and IEEE Std 1363a-2004 address many of these issue, and include ASN.1 for the parameters are where they can and can not be placed in certificates and public keys.

I would suggest that the defaults should be based on these RFCs.

I have only glanced at these RFCs and the OpenSSL code to see if they agree. I do see that the OpenSSL code has i2d_RSA_PSS_PARAMS and d2i_RSA_PSS_PARAMS. but have not looked to see where they are used or if they follow these RFCs.

I would hope you would review these RFC and would suggest that the defaults should be based on the RFCs.

I am continuing to look at OpenSSL mods to pass the PSS parameters to an engine.

mouse07410 commented 7 years ago

I am continuing to look at OpenSSL mods to pass the PSS parameters to an engine.

@dengert thank you for looking into this.

The real trick in my opinion is sending PSS method and parameters to the engine when the underlying token supports it, and doing what OpenSSL is doing now when it doesn't. Because on the one hand I'd love to see devices like YubiHSM2 supported directly by OpenSSL (with engines) - but on the other hand I'd really hate if that support came at the cost of being able to do RSA-PSS on tokens like Yubikey and CAC that can only do the raw RSA (aka RSA-X-509).

RFC 8017, 4055 and 5756 and IEEE Std 1363a-2004 address many of these issues...

OK, I'll check the RFC 8017, 4055 and 5756. Might also check IEEE Std 1363a-2004 - no promise here.

I would suggest that the defaults should be based on these RFCs. ... I would hope you would review these RFC and would suggest that the defaults should be based on the RFCs.

If there's disagreement between these RFCs and OpenSSL, I'd suggest following the de-facto standard (aka OpenSSL) than the "paper standard". But apriori I'd expect them to match. Will report here anyway.

dengert commented 7 years ago

You have been using the YubiHSM2, with their PKCS#11 module. The module says the device does not support RAW, but is that really the case? Are they actually doing the PSS is software rather than on the HSM? If they are then the device is no better then a smart card that does RSA_RAW. What does a pcscd trace show? Do they use some secure channel?

mouse07410 commented 7 years ago

You have been using the YubiHSM2, with their PKCS#11 module.

Yes. Note that both are "beta", meaning they can change significantly before entering production.

The module says the device does not support RAW, but is that really the case?

AFAIK, yes it is. Tested myself, and verified with the developers. The developers actually refused to add support for the raw mode, citing security considerations.

Are they actually doing the PSS is software rather than on the HSM?

AFAIK, no. They do PSS on the HSM, and all that their software does it sending the default PSS parameters (compatible with OpenSSL) to the HSM. I validated the compatibility by creating an RSA-PSS signature on the HSM with their tools, and validating it with OpenSSL.

HSM attaches immutable "capabilities" to each key it generates or stores. Those capabilities define what kind of signature this key is allowed to perform (operations that try to violate those - fail).

What does a pcscd trace show?

Don't have it.

Do they use some secure channel?

I think so. Traffic between their software (connector) and the device is encrypted.

But again, one observable difference between their smart cards (tokens) and this device is: their smart cards do only raw RSA, and require PSS and OAEP done by the calling software. Their HSM2 device does not do raw RSA at all, and only does PSS and OAEP (and PKCS1 v1.5).

dengert commented 7 years ago

I think if OpenSSL was willing to add to the RSA_METHOD 

  int (*rsa_sign_ctx) (int type,
                     const unsigned char *m, unsigned int m_length,
                     unsigned char *sigret, unsigned int *siglen,
                     const RSA *rsa, EVP_PKEY_CTX *rctx);

And called it at the right place in rsa_pmethod.c then the engine would have access to all it needs for PSS. It could return, continue doing the old way: do the padding in software and call (*rsa_sign) or do the whole sign operation within the engine which coiuld be pass the PSS parameter to PKCS#11. I a still looking at the code.

The main problem is the EVP_PKEY_CTX is not passed to an engine.

mouse07410 commented 7 years ago

Checked RFC 8017. It does not force default values, it only recommends them:

These are the only parameters in question, AFAIK.

RFC 4055 is pretty dated now. It concurs with salt Len issue. Regarding hash - it says that one must support SHA-1 (i.e., SHA1-RSA-PKCS-PSS), and may support other hash functions.

I suggest sticking with RFC 8017, being more current.

dengert commented 7 years ago

I have looked at OpenSSL-1.1.0f and the main problem is rsa_pmeth.c in pkey_rsa_sign(), does not give the engine a chance to see the RSA_PSS parameters and does padding internally then does: 178 ret = RSA_private_encrypt(RSA_size(rsa), rctx->tbuf, 179 sig, rsa, RSA_NO_PADDING);

Thus to the engine it appears to be an RSA RAW operation of some data.

I am attaching some mods to OpenSSL-1.1.0f that add (*rsa_sign_evp_pkey_ctx) to the RSA_METHOD and its related functions and definitions.

Also attached is a proof of concept for a pkcs11_rsa_sign_evp_pkey_ctx_method in p11_rsa.c that prints the parameters to stderr, then returns to let OpenSSL do what it does now in software.

For a token that does not support CKM_RSA_X_509 a mechanism could be derived from PSS parameters, hash, hash size and key size. If the token can do the mechanism PKCS#11 would be called to do it and the results returned. (I will leave this up to someone else.)

The biggest problem will getting OpenSSL to accept these mods or provide their own mods to get around the problem.

No attempt was made to see if this would work in any other version of OpenSSL. I don't want to go any further if OpenSSL is not interested in these mods.

I am asking the OpenSC/libp11 developers to look his over before I submit this problem and solution to OpenSSL. If it looks promising, a full functioning version of the libp11 code with a real token would go a long way to help convince OpenSSL there is a problem and a solution.

rsa_sign_evp_pkey_ctx-1.txt pkcs11_rsa_sign_evp_pkey_ctx_method-1.txt

mouse07410 commented 7 years ago

@dengert it's a very good start. Unfortunately, it didn't work yet. For some reason it still sends RSA-X-509 command down to the engine.

I applied both patches. The one for OpenSSL had a problem (which I remedied manually):

cat util/libcrypto.num.rej
***************
*** 4230,4232 ****
  UINT32_it                               4214  1_1_0f  EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
  ZINT64_it                               4215  1_1_0f  EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
  ZINT64_it                               4215  1_1_0f  EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
--- 4230,4234 ----
  UINT32_it                               4214  1_1_0f  EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
  ZINT64_it                               4215  1_1_0f  EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
  ZINT64_it                               4215  1_1_0f  EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
+ RSA_meth_set_sign_evp_pkey_ctx          4216    1_1_0f  EXIST::FUNCTION:RSA
+ RSA_sign_evp_pkey_ctx                   4217    1_1_0f  EXIST::FUNCTION:RSA
$

Note that the OpenSSL-1.1 version I keep is OpenSSL_1_1_0-stable, but it cannot differ so much from 1.1.0f as to invalidate your patch.

$ ~/openssl-1.1/bin/openssl dgst -engine pkcs11 -keyform engine -sha384 -sign "pkcs11:token=YubiHSM;id=%03%01;type=private" -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -out ~/src/t3072.dat.sigpss ~/src/t3072.dat
engine "pkcs11" set.
Enter PKCS#11 token PIN for YubiHSM:
 pkcs11_rsa_sign_ctx_method called
RSA_PSS
saltlen=48 sigmd=673 mdf1=673 
Error Signing Data
140736009962432:error:8207A070:PKCS#11 module:pkcs11_private_encrypt:Mechanism invalid:p11_rsa.c:120:
$

Here's the SPY excerpt:

. . . . .
151: C_GetAttributeValue
2017-09-12 15:05:06.964
[in] hSession = 0x0
[in] hObject = 0x30301
[in] pTemplate[1]:
    CKA_ALWAYS_AUTHENTICATE  00007fc0f16366d0 / 1
[out] pTemplate[1]:
    CKA_ALWAYS_AUTHENTICATE  False
Returned:  0 CKR_OK
 pkcs11_rsa_sign_ctx_method called
RSA_PSS
saltlen=48 sigmd=673 mdf1=673

152: C_SignInit
2017-09-12 15:05:06.964
[in] hSession = 0x0
pMechanism->type=CKM_RSA_X_509
[in] hKey = 0x30301
Returned:  112 CKR_MECHANISM_INVALID
Error Signing Data
140736009962432:error:8207A070:PKCS#11 module:pkcs11_private_encrypt:Mechanism invalid:p11_rsa.c:120:

153: C_CloseSession
2017-09-12 15:05:06.965
[in] hSession = 0x0
Returned:  0 CKR_OK

Here's the full SPY: dengert-spy1.txt

The token itself signs fine using SHA384-RSA-PSS:

$ yhsm2-tool -s -m SHA384-RSA-PKCS-PSS --id 0301 -i ~/src/t3072.dat -o ~/src/t3072.dat.sigpss-opensc
Using slot 0 with a present token (0x0)
Logging in to "YubiHSM".
Please enter User PIN: 
Using signature algorithm SHA384-RSA-PKCS-PSS
PSS parameters: hashAlg=SHA384, mgf=MGF1-SHA384, salt=48 B
$ ~/openssl-1.1/bin/openssl dgst -engine pkcs11 -keyform engine -sha384 -verify "pkcs11:token=YubiHSM;id=%03%01;type=public" -sigopt rsa_padding_mode:pss -signature ~/src/t3072.dat.sigpss-opensc ~/src/t3072.dat
engine "pkcs11" set.
Enter PKCS#11 token PIN for YubiHSM:
Verified OK
$

yhsm2-tool is merely an alias for pkcs11-tool --module /usr/local/lib/yubihsm_pkcs11.0.1.0.dylib --login

dengert commented 7 years ago

Don't know why it would reject the patch, other then the changes are the last 2 lines.

As I said: "Also attached is a proof of concept for a pkcs11_rsa_sign_evp_pkey_ctx_method in p11_rsa.c that prints the parameters to stderr, then returns to let OpenSSL do what it does now in software."

It shows OpenSSL can pass in the PSS parameters. It only prints them for now.

I expect @mouse07410 , @mtrojnar , @Jakuje or someone would add the libp11 code to test if the card could only do RSA_PSS with on the card with the selected hash, then use the parameters to fill in a CK_RSA_PKCS_PSS_PARAMS and CK_MECHANISM pointing to it and call C_SignInit, then pass back the results.

mouse07410 commented 7 years ago

As I said: "Also attached is a proof of concept for...

Darn... I misunderstood... :-(

So the bulk of the missing stuff is in the libp11 sample? It's there where it needs to check the token's capabilities, and either proceed with PSS, or just return to let OpenSSL do its thing in software?

dengert commented 7 years ago

Correct. I think all the missing code is in libp11.

Determine from the parameters the what hash was used, and from the key what is RSA_size.

Probable also need these: PKCS11_KEY key = RSA_get_ex_data(rsa, rsa_ex_index); PKCS11_SLOT slot = KEY2SLOT(key); PKCS11_CTX ctx = KEY2CTX(key); PKCS11_KEY_private kpriv = PRIVKEY(key); PKCS11_SLOT_private *spriv = PRIVSLOT(slot); CK_MECHANISM mechanism;

You will also the defination of the CK_RSA_PKCS_PSS_PARAMS which I think was in @jakuje https://github.com/OpenSC/OpenSC/pull/1146 it updates pkcs11.h to add CK_RSA_PKCS_PSS_PARAMS and other flags.

Tell you what, if you don't get very far, I will look at in a few days.

mtrojnar commented 7 years ago

I reviewed the OpenSSL patch submitted by @dengert. The proposed solution is simple and flexible. I love the way it ensures backward compatibility.

I noticed a few trivial issues that need to be addressed before submitting a PR to OpenSSL:

mouse07410 commented 7 years ago

@mtrojnar thank you! @dengert it looks like this call can be used for OAEP as well, right? Let's update it so?

dengert commented 7 years ago

I have done some more research and we may not need any changes to OpenSSL!

1.1.0 implements a stack of EVP_PKEY_METHODs with rsa_pkey_meth being for RSA. which ends up calling the pkey_rsa_sign that I modified. See ./rsa/rsa_pmeth.c

So rather the adding changes to the pkey_rsa_sign, the libp11 replacement for it would look first if it wanted to do the operation. If not, call the original pkey_rsa_sign.

This has some info on it.

https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_meth_add0.html

But I don't see any examples.

These look promising: EVP_PKEY_meth_copy EVP_PKEY_meth_add0 EVP_PKEY_meth_find

EVP_PKEY_meth_set_signctx would set our routine.

On 9/13/2017 6:54 AM, Mouse wrote:

@mtrojnar https://github.com/mtrojnar thank you! @dengert https://github.com/dengert it looks like this call can be used for OAEP as well, right? Let's update it so?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenSC/libp11/issues/176#issuecomment-329144506, or mute the thread https://github.com/notifications/unsubscribe-auth/AA00MWxSLwkbl2MdSBzYB0QfKvBcurPTks5sh8J_gaJpZM4O8BoA.

--

Douglas E. Engert DEEngert@gmail.com

mouse07410 commented 7 years ago

All these changes are for OpenSSL-1.1+, correct? So in the libp11 code I'm adding guards for OpenSSL version >= than 1.1.0.

dengert commented 7 years ago

Remember this was a proof of concept. I only looked at 1.1.0. And it looks like there will be no need for OpenSSL mods. The p11_rsa.c mods will look different too. So don't commit any of this.

mouse07410 commented 7 years ago

The p11_rsa.c mods will look different too. So don't commit any of this.

Too late. ;-)

But I'm sure (or at least I hope ;) I'll be able to revert those commits.

P.S. OpenSSL-1.1.1-devel does not have file crypto/rsa/rsa_null.c any more.