1

I have exported a 3DES key from my SafeNet HSM to a file using a tool named KMU. This tool wraps the key before extraction using another 3DES key. I have access to the plain-text value of the second key.

The question is "how can I decrypt the wrapped file to obtain plain-text value of the wrapped key?"

Update:

FYI: The final exported file looks like this:

L1: 000001f4 000001a800000001000001a0
L2: 00000020 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
L3: 00000140 0000001b0000010300000001010100000162000000010101800001290000000101010000016500000001010000000164000000010100000000010000000101010000000200000001010100000170000000010101000000030000000f014949494949494949494949494949490000010c000000010101000001040000000101010000010a000000010101000001060000000101010000010500000001010100000108000000010101000001070000000101018000012b000000010100000001610000000401000000100000000000000004010000000400000100000000040100000014800001030000000000000001020000000000000001100000000000000001110000000000800001280000000101000000016300000001010080000102000000100132303131313232383136323032313030000000000000000000000000
L4: 00000010 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
L5: 00000020 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxx
L6: 00000020 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
L7: 00000020 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The parts which are 'x' are the data which looks encrypted in the original file and so I replaced them with 'x'. Line numbers, spaces and new-lines are also added by me to make the content more readable!

Ebrahim Ghasemi
  • 5,850
  • 10
  • 52
  • 113
  • If you are able to export a key using a tool, you might be able to decrypt (unwrap) the exported key using the tool (provided it supports it). Check if the tool has option to `unwrap` key. If it doesn't, you need to write code to do the unwrapping operation. – always_a_rookie Aug 24 '20 at 13:54
  • Manual unwrapping as described in my answer is not necessary if all you need to do is to import keys to HSM. You can import your "second key" via the "Enter key from components" functionality (if you have plaintext value use 2 components and type zeroes for the second component) and then use this key for "Import Key(s)" – vlp Aug 25 '20 at 12:29

1 Answers1

2

See chapter "Key Backup Feature Tutorial" in the document Key Management Utility User (KMU) Reference for overall scheme description.

Unfortunately this document has not been updated to the last version of the scheme which uses AES tK and HMAC for M_mK.

As far as I remember it is possible to tell KMU to use the older DES3 scheme with the -3 command line option.

I have a working implementation but unfortunately can not provide the code.

Key restoration steps summary:

  • Check overall file structure (magic 0x000001f4 | varLen encoded payload | 4 byte MAC | varLen wrapped MAC key | varLen wrapped transport key)

  • unwrap AES transport key (using the wrap key and it's key type specific algorithm, e.g. CKM_RSA_PKCS)

  • unwrap generic secret MAC key (using AES transport key and CKM_AES_ECB. Length is 32)

  • verify MAC of encoded payload (using MAC key with CKM_SHA512_HMAC_GENERAL)

  • unwrap all backed-up keys from the payload (using AES transport key with CKM_WRAPKEY_AES_CBC and zero IV)

You might want to use PKCS#11 logger library (see PTK-C Programming Guide) and record the activity of the KMU utility during key restore to verify the fine details of the algorithm.

Good luck with your project!

EDIT> Overall structure of file (given your example data):

000001f4 // Magic
000001a8 // Length of encoded payload
    00000001 // Number of keys
    000001a0 // Wrapped key #1 length
        xxxx...xxxx // Wrapped key #1 data for CKM_WRAPKEY_AES_CBC
xxxxxxxx // Payload MAC
00000020 // Wrapped MAC key cryptogram length
    xxxx...xxxx // Wrapped MAC key cryptogram
00000020 // Wrapped transport key cryptogram length
    xxxx...xxxx // // Wrapped transport key cryptogram

See CKM_WRAPKEY_AES_CBC and CKM_WRAPKEY_DES3_CBC for format used to encode individual exported key data (#1..#n) inside encoded payload.

vlp
  • 7,811
  • 2
  • 23
  • 51
  • Thank you very much dear vlp. I've updated the question with a censored view of the exported file. It seems that my file have much more sections than the structure which you mentioned in your answer. Am I missed something? Moreover, the original key and also the wrapping key in my case are both 3DES keys. Does the KMU tool use another key of type AES in the back-up process too? Why should it write the Transport Key in the file? – Ebrahim Ghasemi Aug 24 '20 at 20:19
  • 1
    @Abraham Read the *Summary of Key Backup Feature* section (and please note that it switched from DES3 to AES+HMAC some years ago -- in case your documentation is older or Thales has not updated it yet). Using a random transport key is a common practice. Your exported keys are wrapped using this this random AES transport key which is attached in the file under your "real" export key (which is 3DES in your case). – vlp Aug 25 '20 at 08:24
  • 1
    @Abraham The KMU document is public so I added [link to it](https://thalesdocs.com/gphsm/ptk/5.0/docs/PTK-C_KMU_User%20Guide.pdf). They have not fixed the DES3 vs. AES+HMAC change. I will update the answer accordingly... – vlp Aug 25 '20 at 08:30
  • Thank you again dear vlp. My wrapped export file have +7 years old. (More precisely, the file is from 2013!). Do you know which year Thales replaces 3DES with AES+HMAC? – Ebrahim Ghasemi Aug 25 '20 at 18:32
  • And please take another look at the file-view which I've been added to the question. It seems that there is a minor inconsistency between the structure of my file and the structure which you have mentioned in your answer. Last part of L5 and also whole the L6 and L7 in my file-structure are out of the structure which you have provided. (All other sections and sizes fields are correct though). Do you have any idea what are those bytes? – Ebrahim Ghasemi Aug 25 '20 at 18:36
  • 1
    Dear @Abraham, my bet is that L1-L5 contain magic+payload+mac (mac being the last part of L5). I suppose you wrongly interpret L1-L5 as separate blocks, but actually they are blocks inside the payload block which starts in L1 and has length of 0x1a0 (424 bytes). Pay attention to the indentation in my answer -- encoded payload (424 bytes) contains number of keys(4 bytes), length of first key data(4 bytes) and first key data(416 bytes). See linked description of `CKM_WRAPKEY_DES3_CBC`. If your magic matches mine than AES+HMAC should be used. – vlp Aug 25 '20 at 19:19
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/220456/discussion-between-abraham-and-vlp). – Ebrahim Ghasemi Aug 25 '20 at 19:48