public key authentication

[Patrick]

Hello,

Wondering if you could take a look at the scheme I'm working on to store PANs in a DB. The system is going to use an HSM to generate a symmetric key and do the cryptograhpy as required. The PAN cannot be left unreadable so the symmetric key will be encrypted with a public key (also using the HSM) and backed up on another 'key server'. To ensure decrypability the private key will also need to be backed up for which the 'key server' would provide a public key for safe transportation and storage.

This system seems vunerable to the man in the middle attack when transfering the 'key servers' public key. I have looked at the use of certificates but if the man in the middle has an approved certificate the system is still vunerable and I don't want to use SSL anyway (which, I think, is the only way to go through the certificate chain) as this is not a browser or https based system.

I cannot think of an automated way to safely pass the public key to the server and am considering using a manual process to check a hash of the public key over the phone before installing the public key in the HSM. This would have to happen periodically to meet 3.6.4 and is not desirable.

Is there a standard way of handling this that I have missed in my research? Or is it acceptable to see such an attack as unstoppable but unlikely? Any advise will be gratefully recevied.

If you have time please let me know if any of my assumptions are incorrect or if there are any other weaknesses in the design as well.

Thanks in advance,
Patrick

[jbhall56]

What you describe is not public key infrastructure (PKI) encryption if my assumption that you are using a hardware security module (HSM) is correct. HSM is a technology used in the financial institution industry for automated teller machine (ATM) processing.

To properly implement HSM, you need to generate two (2) random key pairs of sufficient length to create a strong key. I recommend to clients that their key custodians use something like http://www.winguides.com/security/password.php to generate a random, 32 character key. Then each custodian enters their 32 character key half into the system, destroying the key half once it is used. This will create a 64 character random value that the HSM will convert into its key.

There is much more to this process and I won't take up the bandwidth to document it all here.

I have a diagram on the whole process that I'm willing to share. Just send me an email at jeff.hall@rsmi.com and I will forward it to you.

[mdahn]

... that being said, I can guarantee you that your risk of compromise does not originate from your encrypted data being lifted. Remember that hackers attack the low hanging fruit. If you are encrypting the data with a symmetric key and that key with an asymmetric key, you are really well off. Don't forget key management and storage.

[andrewj]

Unless there is a pressing business need, you don't really need RSA for this system. Try this:

1) Have the HSM generate a strong symmetric key (eg 256 bit AES) - lets call it 'Km'. Deliver this securely to the 'key server', using mulitple smartcards or printed components to maintain dual control and split knowledge. The 'key server' should also use some sort of hardware system to secure this key - such as a HSM, token, or smartcard.
2) When you need to deliver a new key - lets call this Kd - from the HSM to the key server, have the HSM generate another key - lets call this one Ks - and use this to encrypt the key that you want to deliver to the 'key server'.
Eg: Result1 = encrypt using Ks (Kd)
3) Finally, encrypt Ks using Km.
Eg: Result2 = encrypt using Km (Ks)
and then deliver Result1 and Result2 to the 'key server'.

This gives you a secure method to deliver new key encryption keys (Ks) without using RSA. Km doesn't change, but then almost all key management systems end up with a static master key at the top of the heirarchy. It's very hard to avoid, and trying to 'fix' this can often lead to a less secure system.

[andrewj]

Unless there is a pressing business need, you don't really need RSA for this system. Try this:

1) Have the HSM generate a strong symmetric key (eg 256 bit AES) - lets call it 'Km'. Deliver this securely to the 'key server', using mulitple smartcards or printed components to maintain dual control and split knowledge. The 'key server' should also use some sort of hardware system to secure this key - such as a HSM, token, or smartcard.
2) When you need to deliver a new key - lets call this Kd - from the HSM to the key server, have the HSM generate another key - lets call this one Ks - and use this to encrypt the key that you want to deliver to the 'key server'.
Eg: Result1 = encrypt using Ks (Kd)
3) Finally, encrypt Ks using Km.
Eg: Result2 = encrypt using Km (Ks)
and then deliver Result1 and Result2 to the 'key server'.

This gives you a secure method to deliver new key encryption keys (Ks) without using RSA. Km doesn't change, but then almost all key management systems end up with a static master key at the top of the heirarchy. It's very hard to avoid, and trying to 'fix' this can often lead to a less secure system.

[andrewj]

Unless there is a pressing business need, you don't really need RSA for this system. Try this:

1) Have the HSM generate a strong symmetric key (eg 256 bit AES) - lets call it 'Km'. Deliver this securely to the 'key server', using mulitple smartcards or printed components to maintain dual control and split knowledge. The 'key server' should also use some sort of hardware system to secure this key - such as a HSM, token, or smartcard.
2) When you need to deliver a new key - lets call this Kd - from the HSM to the key server, have the HSM generate another key - lets call this one Ks - and use this to encrypt the key that you want to deliver to the 'key server'.
Eg: Result1 = encrypt using Ks (Kd)
3) Finally, encrypt Ks using Km.
Eg: Result2 = encrypt using Km (Ks)
and then deliver Result1 and Result2 to the 'key server'.

This gives you a secure method to deliver new key encryption keys (Ks) without using RSA. Km doesn't change, but then almost all key management systems end up with a static master key at the top of the heirarchy. It's very hard to avoid, and trying to 'fix' this can often lead to a less secure system.