dogtagpki

Clone
Source Code
GIT

#2680 kra unable to extract symmetric keys generated on thales hsm
Closed: fixed 6 years ago Opened 6 years ago by vakwetu.

Closed: fixed
Reopen Issue

This was originally found with barbican, though you do not need barbican to see this issue.
You can reproduce using easily using pki.

pki -h localhost -p 18443 -P https -d ~/alee_certdb/ -c redhat123 -n "PKI Administrator for abc.idm.lab.eng.brq.redhat.com" key-generate "my_symkey1" --key-algorithm AES --key-size 256 --usages encrypt,decrypt

root@vm-107 ~]# pki -h localhost -p 18443 -P https -d ~/alee_certdb/ -c redhat123 -n "PKI Administrator for abc.idm.lab.eng.brq.redhat.com" key-retrieve --keyID 0x10

PKIException: Recovery Failed recoverSymKey() org.mozilla.jss.crypto.TokenException: Failed to unwrap key

This generation succeeds, but the retrieval fails. All this succeeds without HSM.
The exception is coming from the HSM when it fails to unwrap the key.

Some notes:

Because the HSM does not support AES KeyWrap, we are setting allowEncrypt = True
The data is being stored as:

15, keyRepository, kra, pki-tomcat-barbican-KRA
dn: cn=15,ou=keyRepository,ou=kra,o=pki-tomcat-barbican-KRA
objectClass: top
objectClass: keyRecord
keyState: VALID
serialno: 0215
ownerName: kraadmin
keySize: 256
algorithm: AES
privateKeyData:: MIIBNgSCAQB/Bpnt0Fa6j9lUgTeFPex8ovu5fQacB7rgHIGmgNENLo3oYfAzu
Pl5i2ofwUCAWaI4f9xVnbooAqXLfmH8QlF/fpedj55Zom/XPdOM4xeFrRhMklyutx1KSa7ujk9BP3
NNfBPORCj815BIcTQ4qH0QxZZOCSMNhj5WAlMLuZdohEzBWGfvJTtnGNMDDbhdvu2pDA0ue1q5PTe
N2e+nwKgW6G5fzvTmht+DZgFb+XJ5Lipv33EwSAQ6+qffNUSAhuXXs0XhBD4Zr324yH503AdvyPtH
cYjWph/FBrccizux8mv5D1B7VTAWnLs86AznmiYsoZSwsWibJvalOv7w5AWIBDAqRIMzEFjuKjMUe
sE1BOJ87BvXsRJ1JRsMlDQTbGA00juJIQxPcdYsDZXjgMo5XSo=
metaInfo: payloadEncrypted:false
metaInfo: sessionKeyLength:128
metaInfo: sessionKeyWrapAlgorithm:RSA
metaInfo: payloadEncryptionPadding:PKCS5Padding
metaInfo: sessionKeyKeyGenAlgorithm:AES
metaInfo: payloadEncryptionAlgorithm:AES
metaInfo: payloadWrapIV:C7E58b8NhXYwAwFjBa9/cA==
metaInfo: payloadEncryptionIV:3JRSFzm+VzY+Yxdkiu0F/g==
metaInfo: payloadEncryptionMode:CBC
metaInfo: payloadWrapAlgorithm:AES/CBC/PKCS5Padding
metaInfo: sessionKeyType:AES
dateOfCreate: 20170504214552Z
dateOfModify: 20170504214552Z
archivedBy: kraadmin
clientId: 9a422955a21d45e4bf9851e4775bb622
status: active
dataType: symmetricKey
cn: 15

So the data is being wrapped with AES/CBC/PKCS5Padding

Metadata Update from @vakwetu:
- Custom field component adjusted to General
- Custom field feature adjusted to ''
- Custom field origin adjusted to Community
- Custom field proposedmilestone adjusted to ''
- Custom field proposedpriority adjusted to ''
- Custom field reviewer adjusted to ''
- Custom field type adjusted to defect
- Custom field version adjusted to ''
6 years ago

We see the following in the HSM logs:

2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 Unsafe assumption: CKA_DECRYPT should be in template, not assumed to be based on CKA_ENCRYPT
2017-05-05 17:41:11 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 Error: Generic stub command DeriveKey returned 54
2017-05-05 17:41:11 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 Error: Status_InvalidData
2017-05-05 17:41:11 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 Error: DeriveMech_DecryptMarshalled of wrapped key failed

Also , before that ..

2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 >> C_UnwrapKey
2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 > pMechanism->mechanism 0x00001085 (CKM_AES_CBC_PAD)
2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 > hSession 0x000008D3
2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 > hUnwrappingKey 0x00000490
2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 >
pWrappedKey= 48 bytes
7dc6f50f e92ae04e e39a8d9c 27d61422 f825be30 6f3a4964 c62cef0b 5cf2b5f6
cc7e1a74 441be89b b53a3176 d25d7568

2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 > CKA_CLASS: CKO_SECRET_KEY
2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 > CKA_KEY_TYPE: CKK_AES
2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 > CKA_UNWRAP: true
2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 > 256
2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 Unsafe assumption: CKA_DECRYPT should be in template, not assumed to be based on CKA_ENCRYPT
2017-05-05 17:41:10 [31620] t00975ca0aa7f0000: pkcs11: 000008D3 Application error: Unwrapped length 32 != template length 256

Metadata Update from @mharmsen:
- Issue priority set to: critical
- Issue set to the milestone: 10.4
6 years ago

Metadata Update from @mharmsen:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1448521
6 years ago

Metadata Update from @mharmsen:
- Issue priority set to: blocker (was: critical)
6 years ago

commit bea446868e282955d9c70028be657530eaccbe29
Author: Ade Lee alee@redhat.com
Date: Mon May 1 18:25:59 2017 -0400

Use AES-CBC in storage unit for archival in key wrapping

When AES-KW or AES-KWP is not available, we need to be sure to use
a key wrap algorithm that is available for keywrap.  This would
be AES-CBC.  Removes some TODOs.

Refactor so that getWrappingParams is only defined on the StorageUnit,
which is where it makes sense in any case.

Part of Bugzilla BZ# 1386303

Change-Id: I28711f7fe0a00e9d12d26c6e170fb125418d6d51

commit f84bfab30647ae1492fcdca0a026bfa4d91350c9
Author: Ade Lee alee@redhat.com
Date: Mon May 1 15:56:58 2017 -0400

Make sure generated asym keys are extractable

In HSMs, we were not able to retrieve asym keys that were
generated from the AsymKeyGenService, because the right
flags were not set (ie. set like in the server side
keygen case).

To do this, I extracted the key generation function from
NetKeygenService to KeyRecoveryAuthority, so that it could
be used by both services.

Bugzilla BZ# 1386303

Change-Id: I13b5f4b602217a685acada94091e91df75e25eff

Metadata Update from @vakwetu:
- Issue assigned to vakwetu
6 years ago

Metadata Update from @vakwetu:
- Issue status updated to: Closed (was: Open)
6 years ago

commit 00c17b3e2f81c9df12e1a89fc85dc2e3d4c3a2b1
Author: Ade Lee alee@redhat.com
Date: Fri May 5 21:30:15 2017 -0400

Fix symmetic key retrieval in HSM

When using an HSM, AES KeyWrapping is not available and so
some different code paths were exercised.  Fixing bugs in those
paths uncovered a case where we were calling unwrapSymmetric()
with bits and not bytes for the key length.

This does not matter for 3DES, where JSS expects a length of 0,
but very much matters for AES.  Fixing this - and the KeyClient
to actually use the returned wrapping algorithm to unwrap, allows
us now to return generated symmetric keys correctly.

Bugzilla BZ#1448521
Pagure: 2690

Change-Id: I2c5c87e28f6f36798b16de238bbaa21da90e7890

Metadata Update from @vakwetu:
- Issue close_status updated to: fixed
6 years ago

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.4.4 (was: 10.4)
6 years ago

Metadata Update from @mharmsen:
- Custom field fixedinversion adjusted to pki-core-10.4.1-4.el7
6 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/2800

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata
None
None
None
blocker
None
None
defect
''
None
None
None
''
Community
''
pki-core-10.4.1-4.el7
None
None
None
''
General
''
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.