<div dir="ltr">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:<div><br></div><div><a href="https://en.wikipedia.org/wiki/Open_Source_Tripwire">https://en.wikipedia.org/wiki/Open_Source_Tripwire</a><br></div><div><a href="http://www.tripwire.org/">http://www.tripwire.org/</a><br></div><div><br></div><div>You could also implement mandatory access control and ACLs using either grsecurity or SELinux:</div><div><br></div><div><a href="http://grsecurity.net/">http://grsecurity.net/</a><br></div><div><a href="http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf">http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf</a><br></div><div><a href="https://en.wikipedia.org/wiki/Security-Enhanced_Linux">https://en.wikipedia.org/wiki/Security-Enhanced_Linux</a><br></div><div><br></div><div>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.</div><div><br></div><div>If your concern is solely in the realm of protecting your RSA keys, you might consider some HSM product from e.g. Yubico:</div><div><br></div><div><a href="https://www.yubico.com/">https://www.yubico.com/</a><br></div><div><a href="https://en.wikipedia.org/wiki/Hardware_security_module">https://en.wikipedia.org/wiki/Hardware_security_module</a><br></div><div><br></div><div>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:</div><div><br></div><div><a href="http://www.cavium.com/overview.html">http://www.cavium.com/overview.html</a><br></div><div><br></div><div>However, they are 10 gigabit passthrough devices and will unwrap / re-wrap the SSL session in hardware.  They are not cheap.</div><div><br></div><div>Good luck!</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 20, 2015 at 11:46 PM, James <span dir="ltr"><<a href="mailto:james.arivazhagan@gmail.com" target="_blank">james.arivazhagan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi there, <div>I have a concern regarding the private keys we use in the https (say apache) server. </div><div>The https server links with openssl.so file, and uses the APIs provided by it. </div><div>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.</div><div><br></div><div>Does any of you faced this problem and if you could share the solution it would be helpful. </div><div><br></div><div>regards,</div><div>James Arivazhagan Ponnusamy  </div></div>
<br>_______________________________________________<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
<br></blockquote></div><br></div>