BTW, I migrated this thread over to randombit since Perry's overloaded. On Tue, Nov 09, 2010 at 02:34:37PM -0800, [email protected] wrote: > Cryptonerd version: > > Have the system PXE boot by default, and have it pull down an image > from a corporate server that grabs the key from a keyserver, and then > pivot into the full system boot, with decryption key in memory. > > A bit of a usability problem though; if you're off-network, the user > has to know how to disable PXE boot and go to regular boot process and > PBA prompting for passphrase. > > Can also replace PXE boot with a USB key.
A related problem is how to have a server located in a remote datacenter have encrypted disks, but be capable of being booted without help from the datacenter employees. This came up when a friend who is employed by a US corporation was asked to host some servers with customer data in a country that is cheap but "we" don't completely trust. The details aren't important; let's call it Spookistan. Before allowing them to host there, Spookistan asked for root passwords to the server; you know, just in case. How does he do this? The common answer, when I pose this problem, is "well, don't do that". But that's a cop-out. He can't change the decision. He has to secure the systems as best he can. But it's also missing the interesting problem. When the server isn't physically secure, how many attack vectors can we mitigate? First, let's toss out the ones we can't mitigate. We'll never be able to defend against physical attacks without tamper-resistant or tamper-evident hardware. Actually designing a tamper-evident server you could ship overseas and have co-located somewhere is an interesting engineering problem. If anyone has links on this, please do send them to me or the list. And the non-invasive passive physical attacks, such as power line analysis, are simply beyond our reach probably. Does anyone have hardware countermeasures for these? There's physical disclosure holes, like Firewire. We don't want firewire ports. Are there ways to disable them in software, prior to the system handling sensitive data? Can we monitor them for device attachment? So now we get to the fun, practical stuff; software. I'll assume we're talking Unix here. One suggestion is to have a simple boot environment, just enough to have a TCP/IP stack and run sshd. Once it gets into this state, the company logs in, optionally peeks at the machine state, and then provides the keys necessary to decrypt the rest of the system and continue booting. There's the issue of taking the system offline and trojaning the software to capture that key. Presumably this would take a long time, and one could simply stop using systems that went offline for long enough. Normal system monitoring tools are okay, but as Eric mentioned, there's an obvious problem with just pinging the system to monitor it; a secure heartbeat would be necessary. If anyone has done anything like this, I've never seen it. But it's a real problem in today's global economy. It seems like TCPA might mitigate some of this; one could use the same mechanisms that DRM uses to verify the machine is in a secure state prior to providing it the storage keys, and/or one could lock the storage keys away in a TPM. But I haven't looked into this too much. -- Good code works on most inputs; correct code works on all inputs. My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email [email protected] to get blacklisted.
pgpW78fupQUgO.pgp
Description: PGP signature
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
