1
$\begingroup$

I have a Luna G5 Safenet HSM and I want to encrypt a text file containing testtest with 3DES-ECB algorithm. So in the first step I generate a 3DES key on the HSM:

A view of the key generator tool:

Select type of key to generate
[ 1] DES     [ 2] DES2   [ 3] DES3             [ 5]  CAST3
[ 6] Generic [ 7] RSA    [ 8] DSA   [ 9] DH    [10]  CAST5
[11] RC2     [12] RC4    [13] RC5   [14] SSL3  [15]  ECDSA
[16] AES     [17] SEED   [18] KCDSA-1024   [19] KCDSA-2048
[20] DSA Domain Param    [21] KCDSA Domain Param
[22] RSA X9.31                                 [24] ARIA
[25] DH PKCS Domain Param [26] RSA 186-3 Aux Primes
[27] RSA 186-3 Primes
> 3

Enter Is Token Attribute [0-1]: 1
Enter Is Sensitive Attribute [0-1]: 1
Enter Is Private Attribute [0-1]: 1
Enter Encrypt Attribute [0-1]: 1
Enter Decrypt Attribute [0-1]: 1
Enter Sign Attribute [0-1]: 1
Enter Verify Attribute [0-1]: 1
Enter Wrap Attribute [0-1]: 1
Enter Unwrap Attribute [0-1]: 1
Enter Derive Attribute [0-1]: 1
Enter Extractable Attribute [0-1]: 1

Generated DES3 Key handler: 14

After that I checked its attributes:

G:\LunaG5> Cmu.exe getattribute -password 1234567

Select object to query

Handler Label
14      Generated DES3 Key

Enter handler (or 0 for exit) : 14
class=secretKey
token=true
private=true
label=Generated DES3 Key
value=86016e6572617465642044455333204b6579000000000000
keytype=3DES
id=
sensitive=true
encrypt=true
decrypt=true
wrap=true
unwrap=true
sign=true
verify=true
derive=true
startdate=
enddate=
extractable=true
local=true
neverextractable=false
alwayssensitive=true
modifiable=true

As you see above, the value of my generated 3DES key is:

86016e6572617465642044455333204b6579000000000000

Well, in the next step, I encrypt my text file using 1-my HSM, 2-OpenSSL, 3-this online tool. The weird thing is that the output of all are different with each other!

1-My HSM:

Enter your choice : 40
[ 1] DES-CBC       [ 2] DES3-CBC      [ 3] DES3-CTR      [ 4] CAST3-CBC
[ 5] DES-ECB       [ 6] DES3-ECB      [ 7] AES-CTR       [ 8] CAST3-ECB
[ 9] RC2-ECB       [10] RC2-CBC       [11] CAST5-ECB     [12] CAST5-CBC
[13] RC4           [14] RC5-ECB       [15] RC5-CBC       [16] RAW-RSA
[17] DES-CBC-PAD   [18] DES3-CBC-PAD  [19] DES3-CBC-PAD-IPSEC
[20] RC2-CBC-PAD   [21] RC5-CBC-PAD   [22] CAST3-CBC-PAD [23] CAST5-CBC-PAD
[24] SEED-ECB      [25] SEED-CBC      [26] SEED-CBC-PAD
[27] AES-ECB       [28] AES-CBC       [29] AES-CBC-PAD   [30] AES-CBC-PAD-IPSEC
[31] ARIA-ECB      [32] ARIA-CBC      [33] ARIA-CBC-PAD
[34] RSA-PKCS      [35] DES3-CFB8     [36] DES3-CFB64    [37] DES3-OFB
[38] AES-CFB8      [39] AES-CFB128    [40] AES-OFB       [41] ARIA-CFB8
[42] ARIA-CFB128   [43] ARIA-OFB      [44] AES-GCM       [45] XOR-BASE-DATA-KDF
[50] RSA-OAEP      [51] ECIES         [52] ARIA-CTR      [53] SEED-CTR
Select mechanism for encryption: 6
Enter name of file to encrypt: plain.txt

Enter key to use (-1 to list available objects) : -1

Handle 14 -- label: Generated DES3 Key

Enter key to use (-1 to list available objects) : 14

Encrypted data stored in file ENCRYPT.BIN
Status: Doing great, no errors (CKR_OK)

HSM output file content:

enter image description here

2-OpenSSL:

D:\GnuWin32\bin>openssl.exe enc -des-ede3 -e -in in.txt -out out.bin -K 86016e6572617465642044455333204b6579000000000000 -iv 0

OpenSSL output file content: enter image description here

3-Online tool&Output:

enter image description here

Why I have different outputs?

$\endgroup$
  • 1
    $\begingroup$ It seems strange that an HSM could leak its key, which is unusual. Moreover, your keyvalue is, after the first two bytes 86 01 the ASCII "nerated DES3 Key", followed by null bytes. So I don't think it's the actual key, but something else. The first two bytes "ought' to be 47 65 for "Ge", to make even more sense $\endgroup$ – Henno Brandsma Dec 8 '15 at 9:06
  • $\begingroup$ @HennoBrandsma You are completely right.Thank you. I'm just generated a new 3DES key on my HSM and checked its value. The new generated key value is the same too. Now the question is, why OpenSSL and the online tool have different values? $\endgroup$ – Abraham Dec 8 '15 at 9:17
  • $\begingroup$ @HennoBrandsma Do you have any idea how I can check the HSM to see if the 3DES algorithm is implemented correctly? (Yea, it's funny to check HSM, but I need to!) $\endgroup$ – Abraham Dec 8 '15 at 9:18
  • 1
    $\begingroup$ The online tool seems to use ASCII values as the key (so it's crap, basically), if the test vectors below on the page are to be believed. So your hex input is interpreted as ASCII, not as bytes encoded as hex-ASCII. $\endgroup$ – Henno Brandsma Dec 8 '15 at 10:15
  • 1
    $\begingroup$ Can you load your own key into the HSM? Then it would be testable $\endgroup$ – Henno Brandsma Dec 8 '15 at 10:32
2
$\begingroup$

The HSM is not supposed to expose its actual key material; that's the whole point of them, often: they're not as easy to compromise as a PC where key material is in memory that can leak etc.

The value 86016e6572617465642044455333204b6579000000000000 is just, after the first two bytes, the ASCII representation of "enerated DES3 Key", which makes it very likely that this is a different beast than the actual key bytes... It would have been even "better" had the first two bytes been 47 65 (so it would have said Generated...)

It's not strange that the RSA private key shows its modulus and publicexponent, these are supposed to be known in public key crypto, to encrypt and to verify signatures. Again, the actual private key (the private exponent, and maybe other so-called CRT parameters, like both primes etc.) are never supposed to be extractable.

To verify the implementation, import your own key for a symmetric cipher and let it encrypt with that; that should be verifiable. Or just single DES and brute force the key :) Otherwise, you must trust the implementation to be correct, as you cannot know the key material otherwise.

The difference between the online implementation and OpenSSL, is that in the latter you give your key as hex (which is then translated to the byte values), while the online tool you linked to uses the ASCII values of the key as its key bytes. So if you enter 8103 there, you have entered the four bytes 38 31 30 33, not the two bytes 0x81 and 0x03. I checked this with the openssl command line tool and the test vectors on the site.

$\endgroup$
2
$\begingroup$

Let me try to provide an answer for your question (despite the answers in the comment section). Some research showed that a recently discovered vulnerability allowed to extract the keys from SafeNet HSM (which the Luna G5 is). Therefore it should under normal circumstances NOT be possible to extract any private keys from the HSM.

To your question in the comments:

I checked getattribute command for RSA Keypairs on the the HSM. It seems that the device show the Modulus and public Exponent. Is it unusual and strange too?

Compared to 3DES, RSA is an asymmetric encryption scheme, meaning that you have a public and a private key. While data is ENcrypted with your private key, it can be DEcrypted with your public key. The modulus and public exponent are the public key of the private key which is stored in your HSM.

To sum it up: The purpose of a HSM is that no one should be able to extract any keys from it. In this case you may have to trust the implementation of the vendor.

$\endgroup$
  • $\begingroup$ Thank you. Is there any exploit or step by step manual for this vulnerability? $\endgroup$ – Abraham Dec 8 '15 at 11:37
  • $\begingroup$ The link I posted in my answer contains detailed information on how to extract partial keys from the HSM. Considering the announcements from SafeNet the vulnerability seems to be patched. $\endgroup$ – Kevin__ Dec 8 '15 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.