Hi Peter:
On October 26, 2009 10:37:54 pm Peter Lin wrote:
> Thanks all guys for your opinion.
>
> There is a HSM used which vendor provides hardware RSA encryption and
> decryption. However, the key of to the hardware is one way-- I can only
> pass in the key to the hardware, but cant pass out. Due to the low
> performance of the hardware decryption, I decide to use the software
> decryption
> alternatively. (The software decryption is executed in a embedded linux sys
> which is still within the secure scope). Therefore, I need to take a
> procedure to ensure the storage safety of my private key.
>
So, what you are really saying is that you want to keep the key safe, and
instead of swapping the HSM for one with decent performance, you want to take
a shortcut that keeps the decrypted private key in memory of the device for
the lifetime that it is booted, thereby making the use of an HSM irrelevant at
best, and, if the marketing folks get at it, deceptive at worst ("Our product
protects the keys using an HSM" - which, if you implement what you are talking
about, is a bald faced lie - the key is protected by RSA whatever encryption
and the skill of the programmers to ensure that no attacks can lead to anyone
dumping memory). The entire point of using an HSM is to avoid having the
Private key in memory.
> Sorry I made a mistake. My proposed design should be "RSA key XYZ's public
> key ->encrypte AES key -> encrypt RSA key XYZ's private key". Meanwhile, I
> will pass the RSA XYZ's private key to the hardware RSA decryptor. Upon
> startup, the HSM decrypts the AES key with the desired but "not touchable"
> private key, and consequently decrypt the encrypted private key. Will this
> procedure be safe in the case someone obtained my encrypted AES key and
> encrypted RSA private key?
>
Your problem is not "obtain my encrypted AES key and encrypted RSA private
key" - it is "can someone cause anything on the system to fail in a way that
allows for an attacker to read from the portion of memory that has the
decrypted RSA Private key, or the decrypted AES key". Unless you are doing
formal validation of your code, you can never assure this, thus, you will
fail, and someone at some point will get the RSA Private Key - so, the best
thing to do here is to solve the actual problem (RSA performance too slow on
the HSM), and not hack around it.
Have fun.
--
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
