kra unable to extract symmetric keys generated on thales hsm

[pki-bot]

This issue was migrated from Pagure Issue #2680. Originally filed by vakwetu (@vakwetu) on 2017-05-05 11:45:02:

• Closed at 2017-05-06 10:17:02 as fixed
• Assigned to vakwetu (@vakwetu)
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1448521

---

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.

[pki-bot]

Comment from vakwetu (@vakwetu) at 2017-05-05 11:47:41

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

[pki-bot]

Comment from vakwetu (@vakwetu) at 2017-05-05 11:47:45

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 ''

[pki-bot]

Comment from vakwetu (@vakwetu) at 2017-05-05 11:50:31

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

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-05-05 12:02:39

Metadata Update from @mharmsen:

• Issue priority set to: critical
• Issue set to the milestone: 10.4

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-05-05 12:07:05

Metadata Update from @mharmsen:

• Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1448521

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-05-05 12:18:16

Metadata Update from @mharmsen:

• Issue priority set to: blocker (was: critical)

[pki-bot]

Comment from vakwetu (@vakwetu) at 2017-05-06 10:12:26

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

[pki-bot]

Comment from vakwetu (@vakwetu) at 2017-05-06 10:13:10

Metadata Update from @vakwetu:

• Issue assigned to vakwetu

[pki-bot]

Comment from vakwetu (@vakwetu) at 2017-05-06 10:17:05

Metadata Update from @vakwetu:

• Issue status updated to: Closed (was: Open)

[pki-bot]

Comment from vakwetu (@vakwetu) at 2017-05-06 10:38:25

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 BZ1448521
Pagure: 2690

Change-Id: I2c5c87e28f6f36798b16de238bbaa21da90e7890

[pki-bot]

Comment from vakwetu (@vakwetu) at 2017-05-06 10:38:52

Metadata Update from @vakwetu:

• Issue close_status updated to: fixed

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-05-09 12:47:54

Metadata Update from @mharmsen:

• Issue set to the milestone: 10.4.4 (was: 10.4)

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-05-09 23:39:31

Metadata Update from @mharmsen:

• Custom field fixedinversion adjusted to pki-core-10.4.1-4.el7