Re: Unattended reboots (was Re: The clouds are not random enough)
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)
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
On Aug 2, 2009, at 4:00 PM, Arshad Noor wrote: 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. 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. I penned a recent blog about this fact at http://www.cryptoclarity.com/CryptoClarityLLC/Welcome/Entries/2009/7/23_Encrypted_Storage_and_Key_Management_for_the_cloud.html or http://tinyurl.com/klkrvu It discusses this fact and how it can be mitigated. Specifically, how wrapped keys can be escrowed, and used to boot a machine in, what I consider, a significantly more secure manner. Given that you can never guarantee a cloud provider can not tamper with you machine while running, this post describes the problem, a set of goals and one possible solution. Encrypted Kernels are requirement. Geoff Arnold http://speakingofclouds.com/ suggested that an AMI that can boot an encrypted AMI may solve the issue. A harder, but possible solution would be to change the AMI's Grub loader without changing AWS's infrastructure. Anyone interested on working on a prototype :-) Jim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Unattended reboots (was Re: The clouds are not random enough)
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)
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
Attacks against GOST? Was: Protocol Construction
On Sun, 2 Aug 2009, Joseph Ashwood wrote: So far, evidence supports the idea that the stereotypical Soviet tendency to overdesign might have been a better plan after all, because the paranoia about future discoveries and breaks that motivated that overdesign is being regularly proven out. And that is why Kelsey found an attack on GOST Do you want to say that the GOST (28147-89) block cipher is broken? I have never heard of an attack against it that is faster than the exhaustive search. By the way, it was not overdesign (IMO it is simpler even than DES), nor it was an example of the stereotypical Soviet... According to an informed source [1], it was specifically made to be not like military ciphers: its only purpose was to make something for non-military cryptography that would not betray any Soviet cryptographic know-how (this is why they chose to do something very similar to DES). [1] Mikhail Maslennikov, Cryptography and freedom (in Russian) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Unattended reboots (was Re: The clouds are not random enough)
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 reboot (was: clouds ...)
On 08/01/2009 02:06 PM, Jerry Leichter wrote: 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? This problem is routinely solved in practice. 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. 1a) Don't put the keys on the routine backups, and/or 1b) secure the backed-up keys as carefully as you secure the machine itself. 2) If the machine itself is not secure, you have already lost the game and there's no hope of securing any keys or certificates on that machine. 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 I see no advantage in that. The only halfway-useful property that such data has is that it is not backed up by ordinary off-the-shelf backup routines. That's not an important advantage because it is easy to arrange for *any* data of your choosing to be not backed up. -- If you routinely back up files, put keys in a special file. -- If you routinely back up entire partition, put keys in a special partition (or outside any partition). -- If you routinely mirror entire drives, put keys on a special drive. This is all stock technology. Let's be clear: If the attackers have penetrated the machine to the point where they can read the keys from a special file/partition/drive, they can read the hardware serial numbers etc. as well. . 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. That makes life harder for the good guys, and makes life easier for the bad guys. Just putting the keys on disk is far more reliable and practical, especially during hardware maintenance (scheduled or otherwise). On top of all that, there is the very serious risk of a dictionary attack against the hardware serial numbers. There's nowhere near enough entropy in the hardware serial numbers. There is incomparably more entropy in a special file/partition/drive. Virtualization changes all of this. That's yet another reason for not taking the hardware serial number approach. In contrast, a special file/partition/drive can be virtualized in a direct and natural way. Bottom line: Relying on hardware serial numbers etc. to defend keys is not recommended. Vastly more practical approaches are available. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Unattended reboots (was Re: The clouds are not random enough)
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)
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
New Attacks against AES-256
Paper and details are not yet public, but Schneier provides a summary: http://www.schneier.com/blog/archives/2009/07/another_new_aes.html Basically, if AES-256 is implemented with fewer rounds than the standard specifies (essentially the number of rounds recommended for AES-128), it is susceptible to a number of related-key attacks. -- I)ruid, C²ISSP dr...@caughq.org http://druid.caughq.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Unattended reboots (was Re: The clouds are not random enough)
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
