Re: Unattended reboots (was Re: The clouds are not random enough)

2009-08-03 Thread Richard Salz
 in order for the application to have access to the keys in
 the crypto hardware upon an unattended reboot, the PINs to the hardware
 must be accessible to the application.

The cards that I know about work differently -- you configure them to 
allow unattended reboot, and then no PIN is involved.  This is a little 
more secure, in that it requires a conscious decision to do this, as 
opposed to sticking the PIN somewhere on the filesystem.

/r$

--
STSM, DataPower CTO
WebSphere Appliance Architect
http://www.ibm.com/software/integration/datapower/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Unattended reboots (was Re: The clouds are not random enough)

2009-08-03 Thread Arshad Noor

Richard Salz wrote:


The cards that I know about work differently -- you configure them to 
allow unattended reboot, and then no PIN is involved.  This is a little 
more secure, in that it requires a conscious decision to do this, as 
opposed to sticking the PIN somewhere on the filesystem.




I'm not sure I'm following, Richard.

All the HSMs I've worked with start their system daemons automatically;
but the applications using them must still authenticate themselves to
the HSM before keys can be used.  How do the cards you've worked with
authenticate the application if no PINs are involved?

Arshad Noor
StrongAuth, Inc.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Unattended reboots (was Re: The clouds are not random enough)

2009-08-03 Thread lists
Arshad Noor arshad.noor strongauth.com wrote:

 to the keys, in order for the application to have access to the keys in
 the crypto hardware upon an unattended reboot, the PINs to the hardware
 must be accessible to the application.  If the application has automatic
 access to the PINs, then so does an attacker who manages to gain entry
 to the machine.

 If you (or anyone on this forum) know of technology that allows the
 application to gain access to the crypto-hardware after an unattended
 reboot - but can prevent an attacker from gaining access to those keys
 after compromising a legitimate ID on the machine - I'd welcome hearing
 about it.  TIA.

You could have a device that uses the keys only once for each time
it is powered on, and see that the intended process uses it early
in the boot process to answer the challenge of whatever it's
authenticating to.  This could be simulated in s/w using something
such as BSD securelevel or having a different sudoers file for
one part of the boot process.

Then you're going to want only cold reboots, and if your device doesn't
work when expected you'd wonder whether someone beat you to it.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Unattended reboots (was Re: The clouds are not random enough)

2009-08-03 Thread Darren J Moffat

Arshad Noor wrote:

Almost every e-commerce site (that needs to be PCI-DSS compliant) I've
worked with in the last few years, insists on having unattended reboots.


Not only that but many will be multi-node High Availability cluster 
systems as well or will be horizontally scaled.  This means that there 
are multiple machines needing access to the same key material.  Or it 
means putting a crypto protocol terminator on the front - the down 
side of that is loosing end to end security.



Even when the server is configured with a FIPS-certified HSM and the
cryptographic keys are in secure storage with M of N controls for access
to the keys, in order for the application to have access to the keys in
the crypto hardware upon an unattended reboot,


This is because availability of the service is actually more important 
to the business than real security.


 the PINs to the hardware

must be accessible to the application.  If the application has automatic


Or at least a broker for the application.


access to the PINs, then so does an attacker who manages to gain entry
to the machine.


The way we have traditionally done that in Solaris for IKE is to write 
the passphrase/PIN in the clear to disk but rely on UNIX permissions to 
protect ie readable only to root or the user account the service runs as.



P.S. As an aside, the solution we have settled on is to have the key-
custodians enter their PINs to the crypto-hardware (even from remote
locations, if needed, through secure channels).  While it does not
provide for unattended reboots, it does minimize the latency between
reboots while ensuring that there is nothing persistent on the machine
with PINs to the crypto-hardware.


We recently added this ability for the IKE daemon on Solaris/OpenSolaris 
for the case when the private keys IKE uses are stored in a PKCS#11 
keystore (HSM or TPM).  However we don't expect this to be used in the 
case where unattended reboots or cluster failover be used.


This is really no different to storing a root/host/service keytab on 
disk for Kerberos - yet that seems to be accepted practice even in 
organisations that by policy don't want passphrase/PIN on disk.


--
Darren J Moffat

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Unattended reboots (was Re: The clouds are not random enough)

2009-08-03 Thread Richard Salz
 All the HSMs I've worked with start their system daemons automatically;
 but the applications using them must still authenticate themselves to
 the HSM before keys can be used.  How do the cards you've worked with
 authenticate the application if no PINs are involved?

Sorry, I wasn't clear enough.  When I think PIN I think of a keypad and 
secure channel to the HSM.  Not the name/password used by the application. 
 For that, of course, you're right -- the application needs it.

/r$

--
STSM, DataPower CTO
WebSphere Appliance Architect
http://www.ibm.com/software/integration/datapower/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Unattended reboots (was Re: The clouds are not random enough)

2009-08-03 Thread Ali, Saqib
 If you (or anyone on this forum) know of technology that allows the
 application to gain access to the crypto-hardware after an unattended
 reboot - but can prevent an attacker from gaining access to those keys
 after compromising a legitimate ID on the machine

This is the conundrum of the of the the decade. The TPMs etc, tie a
HDD to a server. This helps in cases where the HDDs are discarded w/o
proper destruction of data or are stolen. If you have a problem of
entire servers being stolen, than you have to worry about physical
security.

saqib
http://kawphi.blogspot.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Unattended reboots (was Re: The clouds are not random enough)

2009-08-03 Thread Philipp Gühring
Hi,

 If you (or anyone on this forum) know of technology that allows the
 application to gain access to the crypto-hardware after an unattended
 reboot - but can prevent an attacker from gaining access to those keys
 after compromising a legitimate ID on the machine - I'd welcome hearing
 about it.  TIA.

I (re?)invented a concept for that application, which can be applied in
certain situations.
I have started from the assumption that we are talking about something
like an E-Business system that is hosted in a normal commercial
environment with wired, routed networks.
The attack-vector I wanted to secure against was stealing the machines.
So in the scenario, an attacker would break into the building, steal the
server, get out again, and would try to get access to the data afterwards.
As long as the machine stays in place, it should be able to reboot
unattendedly, as soon as it's somewhere else, it shouldn't be able to
reboot unattendedly anymore.

The concept is to have a secondary server (or several secondary servers)
somewhere else, which has the necessary key available. It should be
situated in a place where it is highly unlikely that it also gets stolen
when the primary server gets stolen, and it has to be connected through
a somewhat trusted routed network.

Now the secondary server has configured the IP address of the primary
server, and regularly tries to contact the primary server, every minute
or something. (Or it uses a different method to detect when the primary
server needs the key).
The contact-tries are done over the routed network, and the routers must
be somewhat secured, and the links in between also have to be trusted.
When the secondary server succeeds the connection to the primary server,
 it authenticates the connection to the primary server (with a key that
is stored in plaintext on the primary server, or perhaps generated from
the hardware configuration). If the authentication succeeds, the
secondary server sends the private key to the primary server, and the
primary server can continue to boot normally.
If an attacker steals the server, and connects it at a different place
in the network, or somewhere else, then the secondary server will not be
able to reach the IP address due to the routing, and won't be able to
provide the key. So the attacker could only try to break in again, and
trace back where the server is, where it comes from, ...

Due to the connection originating from the secondary server and not from
the primary server, you have to have both the server, and you have to be
on the right place of the network.

It's not perfect security, but I think it's a reasonable tradeoff for
the given threats and the need for high-availability in those certain
situations.

Please let me know if you hear about any other interesting solutions too.

Best regards,
Philipp Gühring

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Unattended reboots (was Re: The clouds are not random enough)

2009-08-03 Thread Peter Gutmann
Arshad Noor arshad.n...@strongauth.com writes:

If you (or anyone on this forum) know of technology that allows the
application to gain access to the crypto-hardware after an unattended reboot
- but can prevent an attacker from gaining access to those keys after
compromising a legitimate ID on the machine - I'd welcome hearing about it.

I talked to an auditor about this a while back, here's my summary of this:

  For auditing purposes the only thing that.s required for unattended restart
  is a mechanism to prevent an attacker from copying unprotected keying
  material from the machine.  For example storing the key in a token plugged
  into the machine is generally considered sufficient because it gives you the
  ability to point to a physical security procedure that.s used to prevent the
  key (meaning the token that it.s held in) from being removed.  This
  functions as an audit mechanism because it.ll be noticed if someone removes
  the token, which isn.t the case if someone copies a file containing the
  unprotected key from the machine.  Hardware security modules (HSMs, a
  special-purpose crypto computing device capable of storing thousands of
  keys and performing encryption, signing, certificate management, and many
  other operations) are often used for this purpose, storing a single
  symmetric key in the HSM to meet audit requirements.  If the HSM vendor has
  particularly good salespeople then they.ll sell the client at least two
  $20,000 HSMs (each storing a single key) for disaster recovery purposes.

In other word's the target isn't necessarily what's good enough for security
people, but what's good enough for the auditors, and the above was deemed good
enough for the auditors.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: The clouds are not random enough

2009-08-02 Thread Jerry Leichter

Why Cloud Computing Needs More Chaos:
http://www.forbes.com/2009/07/30/cloud-computing-security-technology-cio-network-cloud-computing.html

[Moderator's note: ... the article is about a growing problem -- the
lack of good quality random numbers in VMs provided by services like  
EC2

and the effect this has on security. --Perry]
The problem is broader than this.  A while back, I evaluated a  
technology that did it best to solve a basically insoluble problem:   
How does a server, built on stock technology, keep secrets that it can  
use to authenticate with other servers after an unattended reboot?   
Without tamper-resistant hardware that controls access to keys,  
anything the software can get at at boot, an attacker who steals a  
copy of a backup, say - can also get at.  So, the trick is to use a  
variety of measurements of the hardware - amount of memory, disk  
sizes, disk serial numbers, whatever you can think of that varies from  
machine to machine and is not stored in a backup - and combines them  
to produce a key that encrypts the important secrets.  Since hardware  
does need to be fixed or upgraded at times, a good implementation will  
use some kind of m unchanged out of n measurements algorithm.   
Basically, this is the kind of thing Microsoft uses to lock license  
keys to particular instances of hardware.  Yes, it can be broken - but  
you can make breaking it a great deal of work.


Virtualization changes all of this.  Every copy of a virtual machine  
is will be identical as far as most of these measurements are  
concerned.  Conversely, if you try to let the physical level show  
through - e.g., use the disk serial number of the real disk on which a  
virtual disk lives - you disrupt some of the things VM's are trying to  
provide, lie easy transportability of instances from one hardware  
home to another.  The last I heard about the technology I looked at,  
they didn't have any good solution for VM's (though I haven't kept up  
and don't know the current status).


Ultimately, the only solution is for hypervisors to take on some  
security roles - passing along unforgeable ID's and random numbers  
from hardware and other resources that they have access to but do not  
export to the guest OS's. That doesn't *solve* the problem.  It puts  
us back where we were before the virtualization craze:  Needing to  
write a secure OS and various secure
services.  However, since hypervisors are much smaller and *much* more  
limited in operation than full OS's, so the problems may be  
correspondingly easier to solve.

-- Jerry


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: The clouds are not random enough

2009-08-02 Thread Ben Laurie
On Sat, Aug 1, 2009 at 10:06 PM, Jerry Leichterleich...@lrw.com wrote:
 Why Cloud Computing Needs More Chaos:

 http://www.forbes.com/2009/07/30/cloud-computing-security-technology-cio-network-cloud-computing.html

 [Moderator's note: ... the article is about a growing problem -- the
 lack of good quality random numbers in VMs provided by services like EC2
 and the effect this has on security. --Perry]

 The problem is broader than this.  A while back, I evaluated a technology
 that did it best to solve a basically insoluble problem:  How does a server,
 built on stock technology, keep secrets that it can use to authenticate with
 other servers after an unattended reboot?  Without tamper-resistant hardware
 that controls access to keys, anything the software can get at at boot, an
 attacker who steals a copy of a backup, say - can also get at.  So, the
 trick is to use a variety of measurements of the hardware - amount of
 memory, disk sizes, disk serial numbers, whatever you can think of that
 varies from machine to machine and is not stored in a backup - and combines
 them to produce a key that encrypts the important secrets.  Since hardware
 does need to be fixed or upgraded at times, a good implementation will use
 some kind of m unchanged out of n measurements algorithm.  Basically, this
 is the kind of thing Microsoft uses to lock license keys to particular
 instances of hardware.  Yes, it can be broken - but you can make breaking it
 a great deal of work.

 Virtualization changes all of this.  Every copy of a virtual machine is will
 be identical as far as most of these measurements are concerned.

I'd imagine (I'm not particularly interested in licence enforcement,
so I really am imagining), that the opposite was the problem: i.e.
that the host could run you on any VM which might have wildly varying
characteristics, depending on what the real machine underneath was,
and what else you were sharing with. So, every time you see the
measurements, they'll be different.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Unattended reboots (was Re: The clouds are not random enough)

2009-08-02 Thread Arshad Noor

Jerry Leichter wrote:
  How
does a server, built on stock technology, keep secrets that it can use 
to authenticate with other servers after an unattended reboot?  Without 
tamper-resistant hardware that controls access to keys, anything the 
software can get at at boot, an attacker who steals a copy of a backup, 
say - can also get at.  


I would be very interested in learning what conclusions you came to,
Jerry.  It is my experience that even *with* tamper-resistant hardware
(TPM, HSM, smartcard), the threat of breach is very high if the server
is configured for unattended reboots.

Almost every e-commerce site (that needs to be PCI-DSS compliant) I've
worked with in the last few years, insists on having unattended reboots.
Even when the server is configured with a FIPS-certified HSM and the
cryptographic keys are in secure storage with M of N controls for access
to the keys, in order for the application to have access to the keys in
the crypto hardware upon an unattended reboot, the PINs to the hardware
must be accessible to the application.  If the application has automatic
access to the PINs, then so does an attacker who manages to gain entry
to the machine.

If you (or anyone on this forum) know of technology that allows the
application to gain access to the crypto-hardware after an unattended
reboot - but can prevent an attacker from gaining access to those keys
after compromising a legitimate ID on the machine - I'd welcome hearing
about it.  TIA.

Arshad Noor
StrongAuth, Inc.

P.S. As an aside, the solution we have settled on is to have the key-
custodians enter their PINs to the crypto-hardware (even from remote
locations, if needed, through secure channels).  While it does not
provide for unattended reboots, it does minimize the latency between
reboots while ensuring that there is nothing persistent on the machine
with PINs to the crypto-hardware.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


The clouds are not random enough

2009-08-01 Thread Ali, Saqib
Why Cloud Computing Needs More Chaos:
http://www.forbes.com/2009/07/30/cloud-computing-security-technology-cio-network-cloud-computing.html

[Moderator's note: It is not supposed to be the moderator's job to read
a link and then summarize for the readers it is interesting to click
on. In the future, posters should provide at least a few sentences
explaining why a link is of interest or I'm going to simply stop
forwarding them.

In the current instance, the article is about a growing problem -- the
lack of good quality random numbers in VMs provided by services like EC2
and the effect this has on security. --Perry]
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com