search

latchset / pkcs11-provider

A pkcs#11 provider for OpenSSL 3.0+
Other
65 stars 39 forks source link

ECDH TLS groups support in Keymgmt #395

Closed simo5 closed 2 months ago

simo5 commented 5 months ago

Hi

This is my openssl.cnf after applying EVP configuration:-

[openssl_init]
providers = provider_sect
alg_section = algorithm_sect

# List of providers to load
[provider_sect]
default = default_sect
pkcs11 = pkcs11_sect

[default_sect]
activate = 1
[pkcs11_sect]
module = /usr/lib/pkcs11.so
pkcs11-module-path = /usr/lib/libckteec.so.0
pkcs11-module-cache-keys = false
pkcs11-module-quirks = no-operation-state
activate = 1

[algorithm_sect]
default_properties = ?provider=pkcs11

Server side command:- openssl s_server -key "pkcs11:model=OP-TEE%20TA;manufacturer=Linaro;serial=0000000000000000;token=kshitiz_test;id=%02;object=ecc-key-521;type=private?pin-value=1234" -cert req_client.crt -accept 443 -Verify 3 -named_curve secp521r1 -ciphersuites 'TLS_AES_256_GCM_SHA384' -tls1_3

Client side command:- ./openssl s_client -connect 10.232.132.242:443 -tls1_3 -ciphersuites 'TLS_AES_256_GCM_SHA384' -cert server.crt -key server.key -CAfile ../ca.crt

Error recieved on server side:-

verify depth is 3, must return a certificate
Using default temp DH parameters
ACCEPT
ERROR
20904DB5FFFF0000:error:40800007:pkcs11:p11prov_common_gen_init:Invalid or improper arguments were provided to the invoked function:/usr/src/debug/pkcs11-provider/0.3/src/keymgmt.c:150:Unsupported selection
20904DB5FFFF0000:error:03000086:digital envelope routines:gen_init:initialization error:/usr/src/debug/openssl/3.2.1/crypto/evp/pmeth_gn.c:52:
20904DB5FFFF0000:error:0A00013A:SSL routines:tls_parse_ctos_key_share:unable to find ecdh parameters:/usr/src/debug/openssl/3.2.1/ssl/statem/extensions_srvr.c:684:

Am I doing something wrong here? And one more thing, that if we are able to reach to optee in sign verification operation without applying EVP configuration change, so why this change is required for exchange operation? Any specific reason?

Originally posted by @kshitizvars in https://github.com/latchset/pkcs11-provider/discussions/389#discussioncomment-9527061

simo5 commented 5 months ago

I am trying to reproduce this error without success.

What confuses me a little is why you give "server" labeled certs and key to the s_client, while use req_client.crt in the server ...

What do you need keys for in the client? Are you trying to perform mutual authentication ? And what kind of key is in the server.* files ?

I get another fatal error unfortunately due to the fact ssh_handshake_hash in openssl relies on being able to copy digest contexts, which is not really support by any pkcs#11 token (even though it is in theory via status operations ...

simo5 commented 5 months ago

@kshitizvars ^

kshitizvars commented 5 months ago

Hi @simo5,

Sorry my mistake, but it's just a naming related issue, if you want, I can change the description.

Yes, we are trying TLS mutual authentication, hence client certificate is required.

Server*file contains ECDSA key and it has been generated using below command:- openssl ecparam -name prime256v1 -genkey -noout -out server.key

Which tool you are using with pkcs#11 token? I am using pkcs11-tool.

simo5 commented 5 months ago

I am just reusing the certs we generate for the tests, so whatever I have handy, it's either softokn or softhsm.

Ok I realized it was mutual TLS later on, but was diverted to fix other issues, I will retry with mutual to see if that triggers the specific issue you see.

simo5 commented 5 months ago

What version of openssl are you testing with? I cannot reproduce with the latest pkcs11-provider code and openssl 3.2.1

kshitizvars commented 5 months ago

I am testing it on openssl 3.2.1 version. Have you checked key exchange operation getting offloaded to optee? And can you please share the commands that you have used?

simo5 commented 5 months ago

I have used the same commands you did, just with prime256v1 as the named_curve, however I need to ensure a proper set of CA signed certs, to exclude the possibility that failed verification makes openssl take different code paths.

In the process I found different issues which I am fixing in #408 so i is also possible that different behavior is triggered by different mechanisms being available between softoken and your token, as some of the operations are conditionally exposed based on the mechanisms returned by the token.

simo5 commented 5 months ago

@kshitizvars I have a patch I was testing at some point that might address some of your problem, any chance you want to test it? https://github.com/simo5/pkcs11-provider/commit/75cc2c3c622e09ce03c86cd4f55a6257bbdcd47f

kshitizvars commented 4 months ago

Hi @simo5,

I am getting below issue while compiling your https://github.com/simo5/pkcs11-provider/commit/75cc2c3c622e09ce03c86cd4f55a6257bbdcd47f repo with yocto:-

Used devtool command for changing source code:- devtool modify --no-same-dir -n pkcs11-provider <pkcs11-provider repo path>

NOTE: Executing Tasks
NOTE: pkcs11-provider: compiling from external source tree /home/nxf69319/data/openssl_pkcs11/pkcs11-provider
ERROR: pkcs11-provider-0.3-r0 do_compile: oe_runmake failed
ERROR: pkcs11-provider-0.3-r0 do_compile: ExecutionError('/opt/samba/nxf69319/imx-linux-bsp/build/tmp/work/armv8a-poky-linux/pkcs11-provider/0.3/temp/run.do_compile.2503221', 1, None, None)
ERROR: Logfile of failure stored in: /opt/samba/nxf69319/imx-linux-bsp/build/tmp/work/armv8a-poky-linux/pkcs11-provider/0.3/temp/log.do_compile.2503221
Log data follows:
| DEBUG: Executing python function externalsrc_compile_prefunc
| NOTE: pkcs11-provider: compiling from external source tree /home/nxf69319/data/openssl_pkcs11/pkcs11-provider
| DEBUG: Python function externalsrc_compile_prefunc finished
| DEBUG: Executing python function autotools_aclocals
| DEBUG: SITE files ['endian-little', 'bit-64', 'arm-common', 'arm-64', 'common-linux', 'common-glibc', 'aarch64-linux', 'common']
| DEBUG: Python function autotools_aclocals finished
| DEBUG: Executing python function fetcher_hashes_dummyfunc
| DEBUG: Python function fetcher_hashes_dummyfunc finished
| DEBUG: Executing shell function do_compile
| NOTE: make -j 12
| make: *** No rule to make target '../../../../../../../../../../../home/nxf69319/data/openssl_pkcs11/pkcs11-provider/Makefile.am', needed by '../../../../../../../../../../../home/nxf69319/data/openssl_pkcs11/pkcs11-provider/Makefile.in'.  Stop.
| ERROR: oe_runmake failed
| WARNING: /opt/samba/nxf69319/imx-linux-bsp/build/tmp/work/armv8a-poky-linux/pkcs11-provider/0.3/temp/run.do_compile.2503221:182 exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|       #1: bbfatal_log, /opt/samba/nxf69319/imx-linux-bsp/build/tmp/work/armv8a-poky-linux/pkcs11-provider/0.3/temp/run.do_compile.2503221, line 182
|       #2: die, /opt/samba/nxf69319/imx-linux-bsp/build/tmp/work/armv8a-poky-linux/pkcs11-provider/0.3/temp/run.do_compile.2503221, line 166
|       #3: oe_runmake, /opt/samba/nxf69319/imx-linux-bsp/build/tmp/work/armv8a-poky-linux/pkcs11-provider/0.3/temp/run.do_compile.2503221, line 161
|       #4: autotools_do_compile, /opt/samba/nxf69319/imx-linux-bsp/build/tmp/work/armv8a-poky-linux/pkcs11-provider/0.3/temp/run.do_compile.2503221, line 156
|       #5: do_compile, /opt/samba/nxf69319/imx-linux-bsp/build/tmp/work/armv8a-poky-linux/pkcs11-provider/0.3/temp/run.do_compile.2503221, line 151
|       #6: main, /opt/samba/nxf69319/imx-linux-bsp/build/tmp/work/armv8a-poky-linux/pkcs11-provider/0.3/temp/run.do_compile.2503221, line 195
ERROR: Task (/opt/samba/nxf69319/imx-linux-bsp/sources/meta-openembedded/meta-oe/recipes-support/pkcs11-provider/pkcs11-provider_0.3.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1191 tasks of which 1184 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /opt/samba/nxf69319/imx-linux-bsp/sources/meta-openembedded/meta-oe/recipes-support/pkcs11-provider/pkcs11-provider_0.3.bb:do_compile
Summary: There were 2 ERROR messages, returning a non-zero exit code.

The token I am using supports below mechanism: -

root@imx8ulp-lpddr4-evk:~# pkcs11-tool --list-mechanisms --module $PKCS11_MODULE_PATH --slot-index 1
Using slot with index 1 (0x1)
Supported mechanisms:
  SHA224-RSA-PKCS-PSS, keySize={256,4096}, sign, verify
  SHA224-RSA-PKCS, keySize={256,4096}, sign, verify
  SHA512-RSA-PKCS-PSS, keySize={256,4096}, sign, verify
  SHA384-RSA-PKCS-PSS, keySize={256,4096}, sign, verify
  SHA256-RSA-PKCS-PSS, keySize={256,4096}, sign, verify
  SHA512-RSA-PKCS, keySize={256,4096}, sign, verify
  SHA384-RSA-PKCS, keySize={256,4096}, sign, verify
  SHA256-RSA-PKCS, keySize={256,4096}, sign, verify
  SHA1-RSA-PKCS-PSS, keySize={256,4096}, sign, verify
  RSA-PKCS-OAEP, keySize={256,4096}, encrypt, decrypt
  SHA1-RSA-PKCS, keySize={256,4096}, sign, verify
  MD5-RSA-PKCS, keySize={256,4096}, sign, verify
  RSA-PKCS-PSS, sign, verify
  RSA-PKCS, keySize={256,4096}, encrypt, decrypt, sign, verify
  RSA-PKCS-KEY-PAIR-GEN, keySize={256,4096}, generate_key_pair
  mechtype-0x1054, encrypt, decrypt, wrap, unwrap
  EDDSA, keySize={256,448}, sign, verify
  ECDSA-SHA512, keySize={160,521}, sign, verify
  ECDSA-SHA384, keySize={160,521}, sign, verify
  ECDSA-SHA256, keySize={160,521}, sign, verify
  ECDSA-SHA224, keySize={160,521}, sign, verify
  ECDSA-SHA1, keySize={160,521}, sign, verify
  ECDSA, keySize={160,521}, sign, verify
  EC-EDWARDS-KEY-PAIR-GEN, keySize={256,448}, generate_key_pair
  ECDSA-KEY-PAIR-GEN, keySize={160,521}, generate_key_pair
  mechtype-0x272, keySize={32,128}, sign, verify
  mechtype-0x262, keySize={32,128}, sign, verify
  mechtype-0x252, keySize={24,128}, sign, verify
  mechtype-0x257, keySize={14,64}, sign, verify
  SHA-1-HMAC-GENERAL, keySize={10,64}, sign, verify
  MD5-HMAC-GENERAL, keySize={8,64}, sign, verify
  SHA512-HMAC, keySize={32,128}, sign, verify
  SHA384-HMAC, keySize={32,128}, sign, verify
  SHA256-HMAC, keySize={24,128}, sign, verify
  SHA224-HMAC, keySize={14,64}, sign, verify
  SHA-1-HMAC, keySize={10,64}, sign, verify
  MD5-HMAC, keySize={8,64}, sign, verify
  SHA512, digest
  SHA384, digest
  SHA256, digest
  SHA224, digest
  SHA-1, digest
  MD5, digest
  GENERIC-SECRET-KEY-GEN, keySize={1,4096}, generate
  AES-KEY-GEN, keySize={16,32}, generate
  ECDH1-DERIVE, keySize={160,521}, derive
  AES-CBC-ENCRYPT-DATA, derive
  AES-ECB-ENCRYPT-DATA, derive
  mechtype-0x108B, keySize={16,32}, sign, verify
  AES-CMAC, keySize={16,32}, sign, verify
  mechtype-0x1089, keySize={16,32}, encrypt, decrypt
  AES-GCM, keySize={16,32}, encrypt, decrypt
  AES-CTR, keySize={16,32}, encrypt, decrypt
  AES-CBC, keySize={16,32}, encrypt, decrypt, wrap, unwrap
  AES-ECB, keySize={16,32}, encrypt, decrypt, wrap, unwrap
root@imx8ulp-lpddr4-evk:~#

So, will I get this issue on my end?

simo5 commented 4 months ago

not sure what devtool is, but it is trying to use autotools when the project has moved to meson ...

kshitizvars commented 4 months ago

[Hi] @simo,

We are trying to check whether key exchange operations are getting offloaded to pkcs11-provider, for this we have added logs in src/exchange.c functions but seems like no function is getting hit.

We are using ECDHE-ECDSA-AES128-GCM-SHA256 cipher suite with tls1.2.

Can you please take a look? Diff in pkcs11-provider code:-

diff_patch.txt Debug_logs:- [Uploading debug_log.txt…]()

Commands used:- Server side:- openssl s_server -key "pkcs11:model=OP-TEE%20TA;manufacturer=Linaro;serial=0000000000000001;token=token0;id=%01;object=ecc-key-256;type=private?pin-value=1234" -cert server.crt -accept 443 -trace

Client side:- openssl s_client -connect 10.232.134.85:443 -tls1_2 -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256'

simo5 commented 4 months ago

Are you still forcing the use of pkcs11 provider via ?provider=pkcs11 ? If not, as usual openssl will not use the provider because ECDH is using ephemeral keys that openssl will generate on the fly in the Default provider.

kshitizvars commented 4 months ago

Hi @simo5

I have tried running below command on server side:-

./openssl s_server -key "pkcs11:model=OP-TEE%20TA;manufacturer=Linaro;serial=0000000000000001;token=token0;id=%01;object=ecc-key-256;type=private?pin-value=1234" -cert server.crt -accept 443 -propquery "?provider=pkcs11"

and below command on client side:- openssl s_client -connect 10.232.134.85:443 -tls1_2 -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256' -debug

Getting Segmentation fault error on server side

And client side stops abruptly.

Also tried adding provider in default properties like below in openssl.cnf file:-

[openssl_init]
providers = provider_sect
alg_section = algorithm_sect

[provider_sect]
default = default_sect
pkcs11 = pkcs11_sect

[default_sect]
 activate = 1

[pkcs11_sect]
module = /usr/lib/ossl-modules/pkcs11.so
pkcs11-module-path = /usr/lib/libckteec.so.0
pkcs11-module-cache-keys = false
pkcs11-module-quirks = no-operation-state
activate = 1

[algorithm_sect]
default_properties = ?provider=pkcs11

But still getting the same segmentation fault.

root@imx8ulp-lpddr4-evk:~# openssl s_server -key "pkcs11:model=OP-TEE%20TA;manufacturer=Linaro;serial=0000000000000001;token=token0;id=%01;object=ecc-key-256;type=private?pin-value=1234" -cert server.crt -accept 443
Using default temp DH parameters
ACCEPT
Segmentation fault (core dumped)

Seems like there is some issue in pkcs11-provider. Can you please comment on this.

debug logs:- debug_log.txt

simo5 commented 4 months ago

It would be nice if you could run the server in gdb --args and capture a backtrace so we can see where it fails.

kshitizvars commented 4 months ago

Hi @simo5,

Please find the below backtrace of openssl s_server command:-

root@imx8ulp-lpddr4-evk:~# gdb --args ./openssl s_server -key "pkcs11:model=OP-TEE%20TA;manufacturer=Linaro;serial=0000000000000001;token=token0;id=%01;object=ecc-key-256;type=private?pin-value=1234" -cert server.crt -accept 443
GNU gdb (GDB) 14.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-poky-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./openssl...
(gdb) r
Starting program: /root/openssl s_server -key pkcs11:model=OP-TEE%20TA\;manufacturer=Linaro\;serial=0000000000000001\;token=token0\;id=%01\;object=ecc-key-256\;type=private\?pin-value=1234 -cert server.crt -accept 443
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Using default temp DH parameters
ACCEPT

Program received signal SIGSEGV, Segmentation fault.
p11prov_session_handle (session=0x0) at /usr/src/debug/pkcs11-provider/0.3/src/session.c:382
warning: 382    /usr/src/debug/pkcs11-provider/0.3/src/session.c: No such file or directory
(gdb) bt
#0  p11prov_session_handle (session=0x0) at /usr/src/debug/pkcs11-provider/0.3/src/session.c:382
#1  0x0000fffff769fdc0 in p11prov_digest_update (ctx=0x5a4eb0,
    data=0xffffffffe9a0 "\207\221Cn\250Xe\255OX&\302\227\322\225O\\\3731\356\003\266\335\203\212\267\235\223j\307\247\341P\352\377\377\377\377", len=32)
    at /usr/src/debug/pkcs11-provider/0.3/src/digests.c:322
#2  0x0000fffff7ac897c in EVP_DigestUpdate (ctx=0x5a4dc0, data=0xffffffffe9a0, count=32) at crypto/evp/digest.c:424
#3  0x0000fffff7b04d0c in HMAC_Update (ctx=0x5a4f10,
    data=0xffffffffe9a0 "\207\221Cn\250Xe\255OX&\302\227\322\225O\\\3731\356\003\266\335\203\212\267\235\223j\307\247\341P\352\377\377\377\377", len=32) at crypto/hmac/hmac.c:114
#4  0x0000fffff7c657cc in hmac_update (vmacctx=0x5a4ce0,
    data=0xffffffffe9a0 "\207\221Cn\250Xe\255OX&\302\227\322\225O\\\3731\356\003\266\335\203\212\267\235\223j\307\247\341P\352\377\377\377\377", datalen=32)
    at providers/implementations/macs/hmac_prov.c:210
#5  0x0000fffff7aefc48 in EVP_MAC_update (ctx=0x5a4c60,
    data=0xffffffffe9a0 "\207\221Cn\250Xe\255OX&\302\227\322\225O\\\3731\356\003\266\335\203\212\267\235\223j\307\247\341P\352\377\377\377\377", datalen=32)
    at crypto/evp/mac_lib.c:123
#6  0x0000fffff7c54a20 in tls1_prf_P_hash (ctx_init=warning: could not convert 'evp_mac_ctx_st' from the host encoding (ANSI_X3.4-1968) to UTF-32.
This normally should not happen, please file a bug report.
0x5a49f0, sec=0x587900 "P\004\343\341=\332\016oF\f+\365\347\222\020,K\311\310C@\357\3614\016\022Z\363\322\v H", sec_len=32,
    seed=0x5a2758 "extended master secret3d\271VE\246\337RQv\323\211V\307\311\302\025\316\340\257\270Q\2516\325(\f\a\223\326\340l", seed_len=54, out=0x572410 "", olen=48)
    at providers/implementations/kdfs/tls1_prf.c:371
#7  0x0000fffff7c54d34 in tls1_prf_alg (mdctx=0x5a49f0, sha1ctx=0x0, sec=0x587900 "P\004\343\341=\332\016oF\f+\365\347\222\020,K\311\310C@\357\3614\016\022Z\363\322\v H", slen=32,
    seed=0x5a2758 "extended master secret3d\271VE\246\337RQv\323\211V\307\311\302\025\316\340\257\270Q\2516\325(\f\a\223\326\340l", seed_len=54, out=0x572410 "", olen=48)
    at providers/implementations/kdfs/tls1_prf.c:455
#8  0x0000fffff7c54600 in kdf_tls1_prf_derive (vctx=0x5a2730, key=0x572410 "", keylen=48, params=0xffffffffeb78) at providers/implementations/kdfs/tls1_prf.c:210
#9  0x0000fffff7ae8870 in EVP_KDF_derive (ctx=0x5a2710, key=0x572410 "", keylen=48, params=0xffffffffeb78) at crypto/evp/kdf_lib.c:144
#10 0x0000fffff7eccc00 in tls1_PRF (s=0x58c370, seed1=0xfffff7f62be8, seed1_len=22, seed2=0xffffffffed68, seed2_len=32, seed3=0x0, seed3_len=0, seed4=0x0, seed4_len=0, seed5=0x0,
    seed5_len=0, sec=0x584cd0 "P\004\343\341=\332\016oF\f+\365\347\222\020,K\311\310C@\357\3614\016\022Z\363\322\v H", slen=32, out=0x572410 "", olen=48, fatal=1) at ssl/t1_enc.c:74
#11 0x0000fffff7ecd6ac in tls1_generate_master_secret (s=0x58c370, out=0x572410 "",
    p=0x584cd0 "P\004\343\341=\332\016oF\f+\365\347\222\020,K\311\310C@\357\3614\016\022Z\363\322\v H", len=32, secret_size=0x5723c8) at ssl/t1_enc.c:376
#12 0x0000fffff7ea424c in ssl_generate_master_secret (s=0x58c370, pms=0x584cd0 "P\004\343\341=\332\016oF\f+\365\347\222\020,K\311\310C@\357\3614\016\022Z\363\322\v H", pmslen=32,
    free_pms=0) at ssl/s3_lib.c:4722
#13 0x0000fffff7ea47b8 in ssl_gensecret (s=0x58c370, pms=0x584cd0 "P\004\343\341=\332\016oF\f+\365\347\222\020,K\311\310C@\357\3614\016\022Z\363\322\v H", pmslen=32)
    at ssl/s3_lib.c:4862
#14 0x0000fffff7ea4a24 in ssl_derive (s=0x58c370, privkey=0x57f6f0, pubkey=0x5862a0, gensecret=1) at ssl/s3_lib.c:4907
#15 0x0000fffff7f55f58 in tls_process_cke_ecdhe (s=0x58c370, pkt=0xffffffffeff0) at ssl/statem/statem_srvr.c:3162
#16 0x0000fffff7f56a84 in tls_process_client_key_exchange (s=0x58c370, pkt=0xffffffffeff0) at ssl/statem/statem_srvr.c:3431
#17 0x0000fffff7f5136c in ossl_statem_server_process_message (s=0x58c370, pkt=0xffffffffeff0) at ssl/statem/statem_srvr.c:1289
#18 0x0000fffff7f3a1b0 in read_state_machine (s=0x58c370) at ssl/statem/statem.c:684
#19 0x0000fffff7f39b98 in state_machine (s=0x58c370, server=1) at ssl/statem/statem.c:478
#20 0x0000fffff7f396d0 in ossl_statem_accept (s=0x58c370) at ssl/statem/statem.c:307
#21 0x0000fffff7ebcec0 in SSL_do_handshake (s=0x58c370) at ssl/ssl_lib.c:4746
#22 0x0000fffff7eb6ac0 in SSL_accept (s=0x58c370) at ssl/ssl_lib.c:2188
#23 0x00000000004743f0 in init_ssl_connection (con=0x58c370) at apps/s_server.c:2972
#24 0x0000000000473e4c in sv_body (s=6, stype=1, prot=0, context=0x0) at apps/s_server.c:2827
#25 0x00000000004a768c in do_server (accept_sock=0x50e6d0 <accept_socket>, host=0x0, port=0x532700 "443", family=0, type=1, protocol=0, cb=0x472cec <sv_body>, context=0x0,
    naccept=-1, bio_s_out=0x544c30, tfo=0) at apps/lib/s_socket.c:423
#26 0x00000000004726d0 in s_server_main (argc=7, argv=0xfffffffffa40) at apps/s_server.c:2319
#27 0x0000000000454bd8 in do_cmd (prog=0x52fc80, argc=7, argv=0xfffffffffa40) at apps/openssl.c:426
#28 0x0000000000454754 in main (argc=7, argv=0xfffffffffa40) at apps/openssl.c:307

--Type <RET> for more, q to quit, c to continue without paging--
simo5 commented 4 months ago

Ah ok, this is the bug I also found and fixed here: https://github.com/latchset/pkcs11-provider/commit/138ce6caa4fea2da138388d9b2684bcae26ea155

In this PR: https://github.com/latchset/pkcs11-provider/pull/408

You want to use the code and also use:

pkcs11-module-block-operations = digest

from that PR in your config.

kshitizvars commented 4 months ago

I have used your repo with PR https://github.com/latchset/pkcs11-provider/pull/408, I was able to resolve seg fault issue with your changes, after doing some changes in recipe file:-

diff --git a/meta-oe/recipes-support/pkcs11-provider/pkcs11-provider_0.3.bb b/meta-oe/recipes-support/pkcs11-provider/pkcs11-provider_0.3.bb
index 816ee967c..4aaa3ffdf 100644
--- a/meta-oe/recipes-support/pkcs11-provider/pkcs11-provider_0.3.bb
+++ b/meta-oe/recipes-support/pkcs11-provider/pkcs11-provider_0.3.bb
@@ -11,7 +11,6 @@ SECTION = "libs"
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b53b787444a60266932bd270d1cf2d45"
 DEPENDS = "\
-    autoconf-archive \
     openssl \
     p11-kit \
 "
@@ -22,6 +21,6 @@ SRC_URI = "git://github.com/latchset/${BPN}.git;branch=main;protocol=https"

 S = "${WORKDIR}/git"

-inherit autotools pkgconfig
+inherit meson pkgconfig

Now, I am not getting any segmentation fault, but still not able to offload key exchange operations (ECDHE) on pkcs11-provider code. Btw, I have also applied https://github.com/simo5/pkcs11-provider/commit/75cc2c3c622e09ce03c86cd4f55a6257bbdcd47f patch on the top of above seg fault related changes, but still no luck.

debug logs:- debug_logs.txt

simo5 commented 4 months ago

The log ends with a successful signature and no other operations, would you be able to provide a minimal reproducer, perhaps a script and instructions on how to set up the Tee ?

kshitizvars commented 4 months ago

Hi @simo5,

For TEE build steps, follow https://optee.readthedocs.io/en/latest/building/index.html. And below are the setup changes:-

Conf changes:-

[openssl_init]
providers = provider_sect

# List of providers to load

[provider_sect]
default = default_sect
pkcs11 = pkcs11_sect

[default_sect]
activate = 1

[pkcs11_sect]
module = /usr/lib/ossl-modules/pkcs11.so
pkcs11-module-path = /usr/lib/libckteec.so.0
pkcs11-module-cache-keys = false
pkcs11-module-quirks = no-operation-state
pkcs11-module-block-operations = digest
activate = 1

Commands Used:-

export PKCS11_MODULE_PATH="/usr/lib/libckteec.so.0"
export PIN="1234"
export SO_PIN="1234"
export TOKEN_NAME="token0"
export PKCS11_PROVIDER_DEBUG=file:/tmp/debug.log

#for listing slots
pkcs11-tool --list-slots --module $PKCS11_MODULE_PATH

#for initializing token
pkcs11-tool --init-token --slot-index=1 --label=$TOKEN_NAME --so-pin $SO_PIN --module $PKCS11_MODULE_PATH

#for initializing user pin
pkcs11-tool --init-pin --pin $PIN --slot-index=1 --label=$TOKEN_NAME --so-pin $SO_PIN --module $PKCS11_MODULE_PATH

#generate EC key pair
pkcs11-tool --keypairgen --key-type EC:secp256r1 --label "ecc-key-256" --id 1 --login --slot-index=1 --pin $PIN --module $PKCS11_MODULE_PATH

#server side certificate
openssl req -new -x509 -key "<token_url_private>?pin-value=<your user pin>" -days 365 -subj /O=NXP-CLIENT-521/CN=10.232.132.242/emailAddress=test@nxp-server.com -out server.crt

# TLS 1.2 connection
openssl s_server -key "pkcs11:model=OP-TEE%20TA;manufacturer=Linaro;serial=0000000000000001;token=token0;id=%01;object=ecc-key-256;type=private?pin-value=1234" -cert server.crt -accept 443

Run openssl s_client from another machine:-
#Client side command:-
$ openssl s_client -connect 10.232.132.188:443 -tls1_2 -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256'
kshitizvars commented 4 months ago

Hi @simo5,

Any update on this?

simo5 commented 4 months ago

Sorry I am caught up on other things at the moment, I will try to get to this soonish, thanks for the instructions, should make things simpler to try to reproduce and then find the actual issue.

kshitizvars commented 4 months ago

Hi @simo5, We tried to run the initial commands on which this discussion started.

Server side command:- ./openssl s_server -key "pkcs11:model=OP-TEE%20TA;manufacturer=Linaro;serial=0000000000000001;token=token0;id=%01;object=ecc-key-521-r1;type=private?pin-value=1234" -cert server.crt -accept 443 -named_curve secp521r1

Client side command:- openssl s_client -connect 10.232.132.113:443 -tls1_3 -ciphersuites 'TLS_AES_256_GCM_SHA384' -debug

Getting segmentation fault.

GDB trace:-

Program received signal SIGSEGV, Segmentation fault.
0x0000fffff778d5d8 in malloc_consolidate (av=av@entry=0xfffff78a0a40 <main_arena>) at malloc.c:4872
warning: 4872   malloc.c: No such file or directory
(gdb) bt
#0  0x0000fffff778d5d8 in malloc_consolidate (av=av@entry=0xfffff78a0a40 <main_arena>) at malloc.c:4872
#1  0x0000fffff778fcf8 in _int_malloc (av=av@entry=0xfffff78a0a40 <main_arena>, bytes=bytes@entry=3232) at malloc.c:4041
#2  0x0000fffff7791290 in __GI___libc_malloc (bytes=3232) at malloc.c:3328
#3  0x0000fffff7b1b270 in CRYPTO_malloc (num=3232, file=0xfffff7d3f1a0 "crypto/core_namemap.c", line=156) at crypto/mem.c:202
#4  0x0000fffff7b16340 in ossl_namemap_doall_names (namemap=0x518e50, number=109, fn=0xfffff7afa214 <help_get_legacy_alg_type_from_keymgmt>, data=0xffffffffeb6c)
    at crypto/core_namemap.c:156
#5  0x0000fffff7ae0984 in evp_names_do_all (prov=warning: could not convert 'ossl_provider_st' from the host encoding (ANSI_X3.4-1968) to UTF-32.
This normally should not happen, please file a bug report.
0x52cc70, number=109, fn=0xfffff7afa214 <help_get_legacy_alg_type_from_keymgmt>, data=0xffffffffeb6c) at crypto/evp/evp_fetch.c:647
#6  0x0000fffff7aec954 in EVP_KEYMGMT_names_do_all (keymgmt=0x544e40, fn=0xfffff7afa214 <help_get_legacy_alg_type_from_keymgmt>, data=0xffffffffeb6c) at crypto/evp/keymgmt_meth.c:310
#7  0x0000fffff7afa284 in get_legacy_alg_type_from_keymgmt (keymgmt=0x544e40) at crypto/evp/pmeth_lib.c:150
#8  0x0000fffff7afa6fc in int_ctx_new (libctx=0x0, pkey=0x53fa00, e=0x0, keytype=0xfffff7d46500 "id-ecPublicKey", propquery=0x0, id=408) at crypto/evp/pmeth_lib.c:291
#9  0x0000fffff7afa9d8 in EVP_PKEY_CTX_new_from_pkey (libctx=0x0, pkey=0x53fa00, propquery=0x0) at crypto/evp/pmeth_lib.c:369
#10 0x0000fffff7aedc28 in do_sigver_init (ctx=0x589340, pctx=0x0, type=0x0, mdname=0xfffff7d47e28 "SHA256", libctx=0x0, props=0x0, e=0x0, pkey=0x53fa00, ver=0, params=0x0)
    at crypto/evp/m_sigver.c:60
#11 0x0000fffff7aee7c0 in EVP_DigestSignInit_ex (ctx=0x589340, pctx=0x0, mdname=0xfffff7d47e28 "SHA256", libctx=0x0, props=0x0, pkey=0x53fa00, params=0x0) at crypto/evp/m_sigver.c:374
#12 0x0000fffff7af56e0 in EVP_PKEY_digestsign_supports_digest (pkey=0x53fa00, libctx=0x0, name=0xfffff7d47e28 "SHA256", propq=0x0) at crypto/evp/p_lib.c:1379
#13 0x0000fffff7ed6214 in check_cert_usable (s=0x58e3d0, sig=0x581360, x=0x54d7c0, pkey=0x53fa00) at ssl/t1_lib.c:3573
#14 0x0000fffff7ed63bc in has_usable_cert (s=0x58e3d0, sig=0x581360, idx=3) at ssl/t1_lib.c:3625
#15 0x0000fffff7ed6508 in find_sig_alg (s=0x58e3d0, x=0x0, pkey=0x0) at ssl/t1_lib.c:3675
#16 0x0000fffff7ed66e0 in tls_choose_sigalg (s=0x58e3d0, fatalerrs=1) at ssl/t1_lib.c:3721
#17 0x0000fffff7f53a90 in tls_post_process_client_hello (s=0x58e3d0, wst=WORK_MORE_B) at ssl/statem/statem_srvr.c:2333
#18 0x0000fffff7f51440 in ossl_statem_server_post_process_message (s=0x58e3d0, wst=WORK_MORE_A) at ssl/statem/statem_srvr.c:1327
#19 0x0000fffff7f3a2f8 in read_state_machine (s=0x58e3d0) at ssl/statem/statem.c:712
#20 0x0000fffff7f39b98 in state_machine (s=0x58e3d0, server=1) at ssl/statem/statem.c:478
#21 0x0000fffff7f396d0 in ossl_statem_accept (s=0x58e3d0) at ssl/statem/statem.c:307
#22 0x0000fffff7ebcec0 in SSL_do_handshake (s=0x58e3d0) at ssl/ssl_lib.c:4746
#23 0x0000fffff7eb6ac0 in SSL_accept (s=0x58e3d0) at ssl/ssl_lib.c:2188
#24 0x00000000004743f0 in init_ssl_connection (con=0x58e3d0) at apps/s_server.c:2972
#25 0x0000000000473e4c in sv_body (s=6, stype=1, prot=0, context=0x0) at apps/s_server.c:2827
#26 0x00000000004a768c in do_server (accept_sock=0x50e6d0 <accept_socket>, host=0x0, port=0x532610 "443", family=0, type=1, protocol=0, cb=0x472cec <sv_body>, context=0x0,
    naccept=-1, bio_s_out=0x545900, tfo=0) at apps/lib/s_socket.c:423
#27 0x00000000004726d0 in s_server_main (argc=9, argv=0xfffffffffa10) at apps/s_server.c:2319
#28 0x0000000000454bd8 in do_cmd (prog=0x52fd10, argc=9, argv=0xfffffffffa10) at apps/openssl.c:426
#29 0x0000000000454754 in main (argc=9, argv=0xfffffffffa10) at apps/openssl.c:307
kshitizvars commented 4 months ago

Hi @simo5

During debugging, I have some observations to share:-

  1. when we run below commands with provider support, issue is observed:-

Server side:- ./openssl s_server -key "pkcs11:model=OP-TEE%20TA;manufacturer=Linaro;serial=0000000000000001;token=token0;id=%02;object=ecc-key-256-r1-1;type=private?pin-value=1234" -cert server.crt -accept 443

client side:- openssl s_client -connect 10.232.132.113:443 -tls1_2 -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256' -debug -groups secp256r1

Issue observed:-

ERROR
2070FEF7FFFF0000:error:0A080010:SSL routines:tls_construct_server_key_exchange:EC lib:ssl/statem/statem_srvr.c:2651:
shutting down SSL

Logs:- debug.txt

whereas no issue is observed when we run it without provider.

  1. In pkcs11-provider code, inside src/keymgmt.c file, there are DEF_EC_PARAM entries, I don't see any x25519 curve entry here, what if client-server wants to run operations on x25519 curve? does it mean that it will not be handled by pkcs11-provider or it will fallback to openssl default code or how the flow will go? The reason I am asking this question is that in our case it is hitting openssl default x25519 key exchange implementation, when we use provider.

Please share your observations on the same.

kshitizvars commented 4 months ago

Hi @simo5

any updates?

Jakuje commented 4 months ago

I tried looking into this and reproducing the issue, but I did not see any crashes when running against either of the three software tokens we have. I created a reproducer based on your configuration in #422, where it works as expected until I add the following configuration snippet, which forces all operations to the token:

[algorithm_sect]
default_properties = ?provider=pkcs11

then it starts failing on the problems with signatures using RSA-PSS:

001EA288117F0000:error:40800070:pkcs11:p11prov_rsasig_set_ctx_params:An invalid mechanism was specified to the cryptographic operation:../src/signature.c:1532:CKM_RSA_PKCS_PSS unavailable^M
001EA288117F0000:error:0A080006:SSL routines:tls_process_cert_verify:EVP lib:ssl/statem/statem_lib.c:513:^M

Looking into that a bit further (in kryoptic run), it goes a bit further, managing to create signature, but fails to verify it (or some other?):

[../src/interface.gen.c:853] p11prov_SignFinal(): Calling C_SignFinal
[../src/objects.c:433] p11prov_obj_free(): Free Object: 0x5612e300c270 (handle:1)
[../src/objects.c:440] p11prov_obj_free(): object free: reference held
[../src/objects.c:433] p11prov_obj_free(): Free Object: 0x5612e300c270 (handle:1)
[../src/objects.c:440] p11prov_obj_free(): object free: reference held
[../src/keymgmt.c:710] p11prov_rsa_new(): rsa new
[../src/keymgmt.c:771] p11prov_rsa_import(): rsa import 0x5615de423160
[../src/keymgmt.c:902] p11prov_rsa_get_params(): rsa get params 0x5615de423160
[../src/keymgmt.c:737] p11prov_rsa_has(): rsa has 0x5615de423160 4
[../src/signature.c:1257] p11prov_rsasig_digest_verify_init(): rsa digest verify init (ctx=0x5615de407760, key=0x5615de409c00, params=(nil))
[../src/objects.c:402] p11prov_obj_ref_no_cache(): Ref Object: 0x5615de409c00 (handle:0)
[../src/provider.c:607] p11prov_ctx_cache_keys(): cache_keys = 0
[../src/signature.c:1460] p11prov_rsasig_set_ctx_params(): rsasig set ctx params (ctx=0x5615de407760, params=(nil))
[../src/signature.c:1279] p11prov_rsasig_digest_verify_update(): rsa digest verify update (ctx=0x5615de407760, data=0x5615de4237b0, datalen=555)
[../src/signature.c:784] p11prov_sig_operate_init(): called (sigctx=0x5615de407760, digest_op=true)
[../src/signature.c:794] p11prov_sig_operate_init(): Error: 0x00000060; Provided key has invalid handle

Not sure if I got into another different rabbit hole or it is something you/Simo saw before.

Jakuje commented 4 months ago

The debug log you posted has a path pkcs11-provider/0.3, does it mean you run on the version 0.3 (with some patches on top?) or is it just red herring and you execute the tests with master version of pkcs11-provider?

kshitizvars commented 4 months ago

Hi @Jakuje , I am running test on latest pkcs11-provider code.

kshitizvars commented 3 months ago

Hi @simo5 @Jakuje , We have more observations to share with you:-

  1. When we try to establish TLS connection, x25519 is successfully negotiated, but as there is no support of x25519 in provider's code, it fallbacks to openssl default code. Specifically, we observed that there is no entry of x25519 in tls_params list, that can be one reason.
  2. When we try with secp256r1 group, we get encoding related error from openssl, On further debugging we found that openssl tries to find OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY param in params list and as there is no such implementation of this functionality in provider's code, hence this error arrives.

Is our observation correct?

simo5 commented 3 months ago

Yes, at the moment we can set OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY but it cannot be retrieved, that will have to be fixed.

simo5 commented 3 months ago

Ok #423 should address returning OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY @kshitizvars any chance you can check if this allows you to move forward ?

kshitizvars commented 3 months ago

Hi @simo5 @Jakuje

We checked the provider code, we didn't find any implementation of symmetric ciphers and HMAC operations (required for deriving master secret in TLS1.2). So, Am I correct here?

simo5 commented 3 months ago

@kshitizvars you are correct, we focused first on Asymmetric algorithms which are what is commonly used from Hardware tokens. Adding support for symmetric ciphers is something that we definitely want to add though, it just needs to be done. Key derivation for TLS 1.3 requires only HKDF, key derivation for TLS1.2 requires a bunch of TLS KDF calls, and some clever craft because openssl's providers assume direct access to the TLS PRF, but PKCS#11 instead provides various calls depending on what label is used, although a generic Key Derivation (CKM_TLS12_KDF) is available, so it may be possible to use that on some tokens.

kshitizvars commented 2 months ago

Hi @simo5

We are able to run ECDH key exchange operations on tls1.2, but facing some issues in tls1.3.

ERROR
2070FEF7FFFF0000:error:40800002:pkcs11:p11prov_DeriveKey:Host out of memory error:/usr/src/debug/pkcs11-provider/0.3/src/interface.gen.c:1011:Error returned by C_DeriveKey
2070FEF7FFFF0000:error:0A0C0103:SSL routines:ssl_derive:internal error:ssl/s3_lib.c:4901:
shutting down SSL

Program received signal SIGSEGV, Segmentation fault

On further debugging, it is because of wrong client public key point (EC_POINT) and its length:-

TLS1.3 logs


(gdb) p *((P11PROV_OBJ *)0x587920).attrs
$11 = {type = 16462464871219690244, pValue = 0xeed50f6aa03e120d, ulValueLen = 14520826335356353610}
(gdb) p *((P11PROV_OBJ *)0x587920)->attrs
$12 = {type = 16462464871219690244, pValue = 0xeed50f6aa03e120d, ulValueLen = 14520826335356353610}

TLS1.2 logs

(gdb) p *(CK_ATTRIBUTE *) 0x588b20
$24 = {type = 2152681555, pValue = 0x5ca280, ulValueLen = 65}
(gdb) p ((P11PROV_OBJ *)0x587920)->attrs[0]
$25 = {type = 2152681555, pValue = 0x5ca280, ulValueLen = 65}
(gdb) p ((P11PROV_OBJ *)0x587920)->attrs[1]

Do you have any comments? Debug logs:- debug_tls1_2.log debug_tls1_3.log

simo5 commented 2 months ago

@kshitizvars sounds like this is a new issue, do you mind if we close this current bug as resolved and open a new bug for the latter issue?

Looking at the log I see that the last few steps for both cases are similar until the crash, but in the TLS 1.3 I also see different steps before getting to the ECDH derive.

If you can open a new bug about the crash specifically and provide me a reproducer script (openssl commands with s_client and s_server like before is fine) I can investigate what is happening.

kshitizvars commented 2 months ago

Sure, you can close this bug. opened https://github.com/latchset/pkcs11-provider/issues/437 new issue with more details.

simo5 commented 2 months ago

Thanks!