[cryptography] How to Not Trust Spookistan, was Re: Disk encryption advice...

travis+ml-rbcryptography at subspacefield.org travis+ml-rbcryptography at subspacefield.org
Tue Nov 9 18:26:29 EST 2010


BTW, I migrated this thread over to randombit since Perry's
overloaded.

On Tue, Nov 09, 2010 at 02:34:37PM -0800, travis+ml-rbcryptography at subspacefield.org 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 john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20101109/ad8be65c/attachment.asc>


More information about the cryptography mailing list