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

Reply via email to