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