Re: [openssl-users] Regarding the security of the keys

[Frank Thater]

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  > 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.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Regarding the security of the keys

[Mike Mohr]

On Tue, Jul 21, 2015 at 9:46 PM, Salz, Rich  wrote:

>
> > Actually that isn't quite right.  A properly configured and
> tuned RBAC policy, when combined with PaX, can very effectively limit all
> userspace activity (including root access!).
>
> How do you know that the module is installed and actually doing things?
> How do you know what kernel is actually booted?
>

Of course you're right.  One might also consider attack vectors from an
unsecured BMC or the IME - they probably have undetectable DMA access to
the host, after all.  But that isn't the point ... steps can and should be
taken to lock down the host operating system.


>
> > It helps if you can also use a hardware security module to protect your
> key material.
>
> How do you know that the operations that YOU request are actually the ones
> being performed?  How do you know that the operating system isn't making
> additional requests of its own?
>
> You have to trust root.  No two ways about it.
>

The first question has no bearing on the second statement.  With or without
grsecurity/selinux, you have no way to guarantee that the kernel is
operating the way you expect it to at any given time.  I suppose it boils
down to the threat model.  However, limiting root's power is a good idea,
and grsecurity provides an excellent framework in which to do so.  Caveat
emptor.


>
> ___
> 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

Re: [openssl-users] Regarding the security of the keys

[Jeffrey Walton]

> 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.

Also see 
http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Regarding the security of the keys

[Salz, Rich]

> Actually that isn't quite right.  A properly configured and tuned RBAC 
> policy, when combined with PaX, can very effectively limit all userspace 
> activity (including root access!). 

How do you know that the module is installed and actually doing things? How do 
you know what kernel is actually booted?

> It helps if you can also use a hardware security module to protect your key 
> material.

How do you know that the operations that YOU request are actually the ones 
being performed?  How do you know that the operating system isn't making 
additional requests of its own?

You have to trust root.  No two ways about it.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Regarding the security of the keys

[Mike Mohr]

Actually that isn't quite right.  A properly configured and tuned RBAC
 policy,
when combined with PaX , can
very effectively limit all userspace activity (including root access!).  It
helps if you can also use a hardware security module
 to protect your
key material.

On Tue, Jul 21, 2015 at 1:48 AM, Salz, Rich  wrote:

> > 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.
>
> Can anyone other than root do this?  You have to trust root.  They could
> just cat your keyfile anyway.
>
> ___
> 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

Re: [openssl-users] Regarding the security of the keys

[Salz, Rich]

> 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.

Can anyone other than root do this?  You have to trust root.  They could just 
cat your keyfile anyway.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Regarding the security of the keys

[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  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

[openssl-users] Regarding the security of the keys

[James]

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