native-pkcs11 and smartcard-hsm
FUSTE Emmanuel
emmanuel.fuste at thalesgroup.com
Thu May 26 12:21:42 UTC 2016
Le 26/05/2016 12:20, FUSTE Emmanuel a écrit :
> Le 25/05/2016 16:27, FUSTE Emmanuel a écrit :
>> Le 25/05/2016 14:29, FUSTE Emmanuel a écrit :
>>> Le 24/05/2016 16:36, FUSTE Emmanuel a écrit :
>>>> Le 23/05/2016 16:40, FUSTE Emmanuel a écrit :
>>>>> Hello,
>>>>>
>>>>> I'm trying to use a smartcard-hsm usb stick (v1.2) with BIND 9.10.3-P4.
>>>>> This stick is working with powerdns and support all crypto operations
>>>>> required for basic DNSSEC support.
>>>>>
>>>>> But I get this warning/error:
>>>>> "PKCS#11 provider has no digest service".
>>>>> "This HSM will not work with BIND 9 using native PKCS#11."
>>>>>
>>>>> Bind version:
>>>>> BIND 9.10.3-P4-Debian <id:ebd72b3>
>>>>> built by make with '--prefix=/usr' '--mandir=/usr/share/man'
>>>>> '--libdir=/usr/lib/i386-linux-gnu' '--infodir=/usr/share/info'
>>>>> '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/'
>>>>> '--enable-threads' '--enable-largefile' '--with-libtool'
>>>>> '--enable-shared' '--enable-static' '--with-openssl=/usr'
>>>>> '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no'
>>>>> '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa'
>>>>> '--enable-native-pkcs11'
>>>>> '--with-pkcs11=/usr/lib/i386-linux-gnu/softhsm/libsofthsm2.so'
>>>>> 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat
>>>>> -Werror=format-security -fno-strict-aliasing
>>>>> -fno-delete-null-pointer-checks -DNO_VERSION_DATE' 'LDFLAGS=-fPIE -pie
>>>>> -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
>>>>> -DDIG_SIGCHASE'
>>>>> compiled by GCC 5.3.1 20160429
>>>>> compiled with OpenSSL version: OpenSSL 1.0.2h 3 May 2016
>>>>> linked to OpenSSL version: OpenSSL 1.0.2h 3 May 2016
>>>>> compiled with libxml2 version: 2.9.3
>>>>> linked to libxml2 version: 20903
>>>>>
>>>>> pkcs11-torens informations:
>>>>> pkcs11-tokens -m /usr/lib/i386-linux-gnu/opensc-pkcs11.so
>>>>> Warning: PKCS#11 provider has no digest service
>>>>> This HSM will not work with BIND 9 using native PKCS#11.
>>>>>
>>>>> DEFAULTS
>>>>> rand_token=0x80300368
>>>>> best_rsa_token=0x80300368
>>>>> best_dsa_token=(nil)
>>>>> best_dh_token=(nil)
>>>>> digest_token=(nil)
>>>>> best_ec_token=(nil)
>>>>> best_gost_token=(nil)
>>>>> aes_token=(nil)
>>>>>
>>>>> TOKEN
>>>>> address=0x80300368
>>>>> slotID=0
>>>>> label=SmartCard-HSM (UserPIN)
>>>>> manufacturerID=www.CardContact.de
>>>>> model=PKCS#15 emulated
>>>>> serialNumber=DECC0100872
>>>>> supported operations=0x6 (RAND,RSA)
>>>>>
>>>>> PKCS11 mechanism returned by pkcs11-tool:
>>>>> pkcs11-tool -M
>>>>> Using slot 0 with a present token (0x0)
>>>>> Supported mechanisms:
>>>>> SHA-1, digest
>>>>> SHA256, digest
>>>>> SHA384, digest
>>>>> SHA512, digest
>>>>> MD5, digest
>>>>> RIPEMD160, digest
>>>>> GOSTR3411, digest
>>>>> ECDSA, keySize={192,320}, hw, sign, other flags=0x1d00000
>>>>> ECDSA-SHA1, keySize={192,320}, hw, sign, other flags=0x1d00000
>>>>> ECDH1-COFACTOR-DERIVE, keySize={192,320}, hw, derive, other
>>>>> flags=0x1d00000
>>>>> ECDH1-DERIVE, keySize={192,320}, hw, derive, other flags=0x1d00000
>>>>> ECDSA-KEY-PAIR-GEN, keySize={192,320}, hw, generate_key_pair, other
>>>>> flags=0x1d00000
>>>>> RSA-X-509, keySize={1024,2048}, hw, decrypt, sign, verify
>>>>> RSA-PKCS, keySize={1024,2048}, hw, decrypt, sign, verify
>>>>> SHA1-RSA-PKCS, keySize={1024,2048}, sign, verify
>>>>> SHA256-RSA-PKCS, keySize={1024,2048}, sign, verify
>>>>> SHA384-RSA-PKCS, keySize={1024,2048}, sign, verify
>>>>> SHA512-RSA-PKCS, keySize={1024,2048}, sign, verify
>>>>> MD5-RSA-PKCS, keySize={1024,2048}, sign, verify
>>>>> RIPEMD160-RSA-PKCS, keySize={1024,2048}, sign, verify
>>>>> RSA-PKCS-KEY-PAIR-GEN, keySize={1024,2048}, generate_key_pair
>>>>>
>>>>> Perhaps Bind require more, but all needed digest services are here.
>>>>> Is something that will be fixed ? How could I help to get it fixed ?
>>>>> Does anyone have any insights or suggestions?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Emmanuel.
>>>>
>>>> Ok, digging into docs and code give me some answers:
>>>>
>>>> In native PKCS11 mode, all crypto operations are offhanded to the HSM.
>>>> This is totally crazy nowadays. HSM are HSM not PKCS11 crypto
>>>> accelerators, a concept from the past on actual hardware for 99.99% of
>>>> real use.
>>>> If something like "sign-only" and "crypto-accelerator" OpenSSL-based
>>>> PKCS#11 is not implemented too in the future, native-pkcs11 is a dead
>>>> end. Option that should be select-able at runtime and which eventually
>>>> permit to chose what to offload to the device in the crypto-accelerator
>>>> mode (and perhaps on different devices etc ...).
>>>>
>>>> Will try to compile a modified openssl in sign-only mode for my token.
>>>> I already successfully created keys with the pkcs11-keygen command and
>>>> the used debian/ubuntu package already include native pkcs11 and openssl
>>>> versions of named and dnssec tools (-pkcs11 variants).
>>>> I was misguided by the "named -V" command which return the
>>>> --enable-native-pkcs11 flag on the two binary but they are linked with
>>>> different
>>>> libisc libraries (cosmetic packaging problem).
>>>>
>>>> Will report results.
>>>>
>>>> Emmanuel.
>>>>
>>>
>>> Latest progress:
>>>
>>> OpenSSL PKCS#11 patch does not permit to build a shared version of the
>>> "pkcs11" engine.
>>> Will try now do do that manually.
>>>
>>> In the mean time, I try to use native mode with p11-kit.
>>> The idea was to use softhsm2 pkcs11 lib as the main provider and my
>>> token via opensc-pkcs11 for the sign operations.
>>> Bind would use openssl for all it crypto operations via softhsm and
>>> pkcs11 uri would transparently point to my token via opensc-pkcs11 for
>>> sign operations.
>>> But neither pkcs11 commands or dnssec- command work with
>>> p11-kit-proxy.so : "fatal: could not initialize dst: PKCS#11
>>> initialization failed" or "Unrecoverable error initializing PKCS#11:
>>> PKCS#11 initialization failed"
>>>
>>> As a last resort, if the dynamic engine is a dead end, I will try to
>>> build rebuild bind with a static version of openssl before giving up.
>>> Not an appealing thing from a maintenance point of view, but it will
>>> permit to validate if bind could work NOW one way or another in
>>> auto-dnssec maintain mode with a smartcard-hsm.
>>>
>>> Emmanuel.
>>>
>>
>> Dynamic engine support is broken and disabled in the code.
>> When re-enabling I get segfault:
>> Starting program: /opt/pkcs11/usr/bin/openssl
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
>> OpenSSL> engine -pre SO_PATH:/opt/pkcs11/usr/lib/engines/libhw_pk11so.so
>> -pre LOAD
>> (dynamic) Dynamic engine loading support
>> [Success]: SO_PATH:/opt/pkcs11/usr/lib/engines/libhw_pk11so.so
>> [Failure]: LOAD
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:62
>> 62 ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S: No such file
>> or directory.
>> (gdb) bt
>> #0 __strlen_sse2_bsf () at
>> ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:62
>> #1 0xb7e0b718 in _dopr () from /opt/pkcs11/usr/lib/libcrypto.so.1.0.0
>> #2 0xb7e0bf14 in BIO_vsnprintf () from
>> /opt/pkcs11/usr/lib/libcrypto.so.1.0.0
>> #3 0xb7e0bf75 in BIO_snprintf () from
>> /opt/pkcs11/usr/lib/libcrypto.so.1.0.0
>> #4 0xb7e16d6a in ERR_print_errors_cb () from
>> /opt/pkcs11/usr/lib/libcrypto.so.1.0.0
>> #5 0xb7e16e1f in ERR_print_errors () from
>> /opt/pkcs11/usr/lib/libcrypto.so.1.0.0
>> #6 0x080a3dba in util_do_cmds.isra ()
>> #7 0x080a412c in engine_main ()
>> #8 0x0805b7cd in do_cmd ()
>> #9 0x0805b4a4 in main ()
>>
>> Even if it is surely fixable, I don't have skills to fix it in a timely
>> manner.
>>
>> So next plan Z: static patched openssl and bind rebuild.
>>
>> Emmanuel.
>>
>
> New day, new progress:
> Static patched openssl build in sign-only mode.
> Old school 'congigure/make/make install' Bind9 builded and installed in
> /usr/local
>
> Key generation : no problem as before.
> dnssec-keyfromlabel segfault ..... new bug in the openssl engine :
> (gdb) r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /usr/local/sbin/dnssec-keyfromlabel -l test -f KSK
> fuste.org
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
> Enter PIN:
> Enter PIN:
> Kfuste.org.+005+03032
> [Inferior 1 (process 4187) exited normally]
> (gdb) r
> Starting program: /usr/local/sbin/dnssec-keyfromlabel -l test -f KSK
> fuste.org
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
> Enter PIN:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x081922db in RSA_free ()
> (gdb) bt
> #0 0x081922db in RSA_free ()
> #1 0x081a438c in EVP_PKEY_free ()
> #2 0x081ec557 in pk11so_load_pubkey ()
> #3 0x081983d9 in ENGINE_load_public_key ()
> #4 0x08179a6c in opensslrsa_fromlabel (key=0xb5b3b008, engine=0x82acbf3
> "pkcs11", label=0xb5b37058 "pkcs11:test", pin=0x0) at opensslrsa_link.c:1414
> #5 0x08112a12 in dst_key_fromlabel (name=0xbffff5c4, alg=5, flags=257,
> protocol=3, rdclass=1, engine=0x82acbf3 "pkcs11", label=0xb5b37058
> "pkcs11:test",
> pin=0x0, mctx=0x8443a10, keyp=0xbffff458) at dst_api.c:892
> #6 0x0805218f in main (argc=6, argv=0xbffffc74) at
> dnssec-keyfromlabel.c:570
>
>
> As you could see, before finding the culprid, the workaround is to enter
> a blank pin and next the real pin.
> Key extraction is OK when the RSA_free don't segfault:
>
> #cat Kfuste.org.+005+03032.private
> Private-key-format: v1.3
> Algorithm: 5 (RSASHA1)
> Modulus:
> phXlRn4tqEcZBmams1fnhmFmxJqJGp+e0s1hUHTsNJt3QT84J8CKv8FHPv1JP5v4j2Wua9rXq/vlmqsRs70Rk6ojQ+dorkegxZQBJqHBxNtuOPQq53c3EZMCf4EpmQ8eqbQFePOEP4yKFtm5lImK+sxZEjkjXyq3+29VhDQ787U=
> PublicExponent: AQAB
> Engine: cGtjczExAA==
> Label: cGtjczExOnRlc3QA
> Created: 20160526095813
> Publish: 20160526095813
> Activate: 20160526095813
>
> # cat Kfuste.org.+005+03032.key
> ; This is a key-signing key, keyid 3032, for fuste.org.
> ; Created: 20160526095813 (Thu May 26 11:58:13 2016)
> ; Publish: 20160526095813 (Thu May 26 11:58:13 2016)
> ; Activate: 20160526095813 (Thu May 26 11:58:13 2016)
> fuste.org. IN DNSKEY 257 3 5
> AwEAAaYV5UZ+LahHGQZmprNX54ZhZsSaiRqfntLNYVB07DSbd0E/OCfA
> ir/BRz79ST+b+I9lrmva16v75ZqrEbO9EZOqI0PnaK5HoMWUASahwcTb
> bjj0Kud3NxGTAn+BKZkPHqm0BXjzhD+MihbZuZSJivrMWRI5I18qt/tv VYQ0O/O1
>
> Next to come: manual zone signing.
> If the same bug is hit, will try to rebuild all with other openssl/patch
> as it compromise auto-dnssec maintain mode. I should have done something
> wrong.
>
> Emmanuel.
>
Hurray !!!
Signing work without segfault!
# dnssec-signzone -S example.net
Enter PIN:
Fetching ZSK 1888/RSASHA1 from key repository.
Fetching KSK 3032/RSASHA1 from key repository.
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
example.net.signed
So auto-dnssec maintain should work too.
There is some work left to build a proper package from a maintenance and
realworld usage stand point, but it is doable.
The actual bind pkcs11 state is really a pity.
Separating dnssec signing crypto calls from the other crypto calls and
be able to redirect the firsts (signing-only) and/or the others
(crypto-accel) to bind native pkcs11 support would be a fantastic hudge
step forward and could permit to kill the openssl hack.
Don't miss interpret my approach, this is not a bad review/criticism.
I'm a big big ... big fan of Bind9 and all the ISC work. If I could
personally sponsor the ISC to carry out such evolution/development, I will.
If some ISC developers could comment too, it will be very interesting.
Thank you.
Emmanuel.
More information about the bind-users
mailing list