Hi, I my opinion the only way to securely handle your keys is the usage of some kind of Hardware Security Module, e.g. www.smartcard-hsm.com www.yubico.com These lightweight HSMs provide a PKCS#11 interface which can be integrated using the PKCS#11 engine of OpenSSL. In addition the SmartCard-HSM supports key replication to build some kind of load-balancing cluster where all HSMs share the same key. Depending on the load of the server these "small" HSMs might be suitable. Otherwise you should spent some money for a complete and full HSM solution. Regards, Frank Am 21.07.2015 um 09:53 schrieb Mike Mohr: > Securing a system against this kind of attack can be done in several > ways, depending on the level of assurance you desire. You might start > out with Tripwire: > > https://en.wikipedia.org/wiki/Open_Source_Tripwire > http://www.tripwire.org/ > > You could also implement mandatory access control and ACLs using either > grsecurity or SELinux: > > http://grsecurity.net/ > http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf > https://en.wikipedia.org/wiki/Security-Enhanced_Linux > > Personally I prefer grsecurity, but it is not supported in mainline by > any major distribution that I am aware of. You'll have to patch, build, > and and support your own kernel image in order to use it. SELinux is > supported out of the box on CentOS 6 and 7, so it would probably be a > good place to start. > > If your concern is solely in the realm of protecting your RSA keys, you > might consider some HSM product from e.g. Yubico: > > https://www.yubico.com/ > https://en.wikipedia.org/wiki/Hardware_security_module > > These tiny USB keys store the RSA keys on a secure element which is > physically tamper-resistant. The key material never leaves the hardware > token. However, you'd probably have to write a custom provider for > OpenSSL, and the throughput would probably only be sufficient for a very > small amount of traffic. If you need something that can handle a higher > load, you might consider purchasing one of Cavium's cards: > > http://www.cavium.com/overview.html > > However, they are 10 gigabit passthrough devices and will unwrap / > re-wrap the SSL session in hardware. They are not cheap. > > Good luck! > > > On Mon, Jul 20, 2015 at 11:46 PM, James <james.arivazhagan at gmail.com > <mailto:james.arivazhagan at gmail.com>> wrote: > > Hi there, > I have a concern regarding the private keys we use in the https (say > apache) server. > The https server links with openssl.so file, and uses the APIs > provided by it. > If some one build their own openssl and add few lines to print the > keys during encrypt and decrypt and put in the library in the > LD_LIBRARY_PATH, may result in compromising the security of the keys. > > Does any of you faced this problem and if you could share the > solution it would be helpful. > > regards, > James Arivazhagan Ponnusamy > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Thater & Schwier Consulting GbR Frank Thater M.Sc. in Applied IT Security, Dipl.-Wirt.-Inf. Sch?lerweg 38 32429 Minden, Germany Phone +49 160 6316655 http://www.tscons.de Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
