16

I'm setting up some new Ubuntu servers, and I'd like to secure the data on them against theft. The threat model is attackers desiring the hardware or rather naïve attackers desiring the data.

Please take note of this section.

The threat model does not include smart attackers desiring the data; I presume they will do one or more of the following:

  1. Splice a UPS into power cable in order to keep the machine running continuously.

  2. Insert a pair of Ethernet bridges between the computer and the network termination point that will bridge the traffic over a wireless network of sufficient range that the host will maintain network connectivity.

  3. Open the box and use a probe on the memory bus to grab interesting stuff.

  4. Use TEMPEST devices to probe what the host is doing.

  5. Use legal means (such as a court order) to force me to disclose the data

  6. Etc. Etc.

So what I want is to have some, or ideally all, of the data on the disk on an encrypted partition, with the key material necessary to access it on external media of some sort. Two methods I can think of for storing the key material are:

  1. Store it on a remote host accessible via the network, and configure enough of the network to retrieve it during the boot process. Retrieval would be allowed only to the IP address assigned to the secured host (thus not allowing access to the encrypted data if it were booted on another network connection) and could be disabled by administrators if the machine were discovered to be stolen.

  2. Store it on a USB storage device that is made in some way significantly more difficult to steal than the host itself. Locating it remote from the host, such as at the end of a five meter USB cable leading off into another corner of the room, or even another room, would probably significantly decrease the chances of attackers taking it. Securing it in some way, such as by chaining it to something immobile, or even putting it into a safe, would work even better.

So what are my options for setting this up? As I said before, I'd prefer to have everything (aside from perhaps a small boot partition that does not contain /etc) encrypted, so that I don't have to worry about where I'm putting files, or where they're accidentally landing.

We're running Ubuntu 9.04, if it makes any difference.

cjs
  • 1,355
  • 1
  • 12
  • 23
  • 1
    Does your threat model wears uniforms with three letters on it? :) – Sven Jul 02 '09 at 02:42
  • They don't wear uniforms. :-) But seriously, no; any governmental agency, covert or not, is likely to be smart enough to take all of the hardware, not just what they can grab quickly. – cjs Jul 02 '09 at 02:55
  • 1
    Your question seems to contradict itself. First you say "I'd like to secure the data on them against theft", then you say "does not include smart attackers desiring the data". Do you care about the data or not? – Zoredache Jul 02 '09 at 03:31
  • 1
    I care about it yes. If you can, for a similar cost, secure it against smart attackers as well as dumb ones, great, I'll do that. If not, at least I avoid the situation where someone buys a used drive at a recycle shop and discovers all my clients' data on it. – cjs Jul 02 '09 at 06:10
  • +1 for actually thinking through the threat model, something many people with a similar question forget to do. – sleske May 09 '10 at 21:52
  • I think the smart attackers would far more simply use an advanced toolkit designed to break into running systems using zero-days or whatever. Just tossing compromised USB sticks around outside your building is a pretty good way to get in. I know you're specifically saying you don't care about those people (or like me you just don't think you'll be able to stop them)... just saying. – darron Sep 10 '17 at 16:56

2 Answers2

8

I know of a clever variant of Option 1 called Mandos.

It uses a combination of a GPG key pair, Avahi, SSL and IPv6 all added to your initial RAM disk to securely retrieve its root partition's key password. If the Mandos server isn't present on the LAN your server is an encrypted brick or the Mandos server hasn't seen a heartbeat from the Mandos client software for a given period of time it will ignore future requests for that key pair and the server is an encrypted brick next time it boots.

Mandos Homepage

Mandos README

Teddy
  • 5,134
  • 1
  • 22
  • 27
Haakon
  • 1,305
  • 7
  • 11
  • 1
    Interesting idea. I'm assuming you'd be PXE booting the clients so that the public/private keypair wasn't on the hard disk drive. Still, you could snoop the keypair off the wire and then use that, in combination with a sniff of the transmission of the bulk encryption key by the server computer, to decrypt the drive. The whole "server won't hand out a key if it hasn't heard a heartbeat in xxx time window" sounds like a neat way to get a human into the loop, too. Neat project. Not too hard to defeat if you have physical access, but neat. – Evan Anderson Jul 02 '09 at 04:46
  • 2
    Evan, you want to read the FAQ in the Mandos README, I think.... – cjs Jul 02 '09 at 06:17
  • Hm. I'm not clear on why Mandos runs only across a LAN. Is it because it can't set up an IP address and routes to use an internet? – cjs Jul 02 '09 at 06:26
  • 1
    Curt, Mandos uses ipv6 link local addresses to communicate which is limited to the local lan. It does however mean that it doesn't need any external configuration (dhcp) or conflict with other servers on the same LAN. http://en.wikipedia.org/wiki/IPv6#Link-local_addresses_and_zone_indices – Haakon Jul 02 '09 at 08:17
  • 1
    As the co-author of Mandos, I can only agree with Haakon. There is actually a way for Mandos to use global IPv4 addresses using the kernel `ip=` and `mandos=connect` parameters, see this mail: http://mail.fukt.bsnet.se/pipermail/mandos-dev/2009-February/000058.html but note that this is somewhat fragile as the clients will only attempt to connect to the specified server *once* and irrevocably fail otherwise. The recommended configuration is via the LAN. I can also mention that Mandos is available in Ubuntu since 9.04 (and also in Debian testing) – Teddy Nov 02 '09 at 15:53
  • @Teddy: Mandos, since version 1.3.1 (2011-07-27), retries the server indefinitely until a password is received. – Teddy Sep 24 '11 at 21:44
6

If you're just looking to protect against non-technical attackers I think your best bet is better physical security.

My thinking is thus:

If you're looking for a boot requiring no human interaction to enter key material then you're not going to come up with any solution that will be safe from even casual theft by an attacher with any technical skills (or, more appropriately, the ability to pay someone with technical skills).

Putting key material in something like a USB thumb-drive wouldn't offer any real security. The attacker could just read the key off of the thumb drive. The thumb drive can't know whether the computer it has been plugged into is the server computer or the attacker's laptop. All the attacker has to do is be sure they either take everything, or in the case of your USB key on the end of a 15 foot long USB extendo-cable stuck inside a safe, just plug the extendo-cable into their PC and read the key.

If you're going to transfer the key over the network you'll probably "encrypt" it. All the attacker has to do is eavesdrop on the keying process, steal the server, and then reverse-engineer any "encryption" you did when you sent the key across the network. By definition, the server computer receiving an "encrypted" key from across the network has to be able to "decrypt" that key in order to use it. So, really, you're not encrypting the key-- you're just encoding it.

Ultimately, you need an (artifical?) intelligence present to input the key into the server. One that can say "I know that I am not divulging the key to anyone but the server computer, and I know that it hasn't been stolen." A human can do this. A USB thumb drive cannot. If you find another intelligence that can do it then I think you'll have something marketable. >smile<

It's most likely, I think, that you'll lose the key and destroy your data while not gaining any security. In lieu of your strategy with encryption games, I think you're better off having stronger physical security.

Edit:

I think we're working from different definitions of the term "threat model", perhaps.

If your threat model is hardware theft, then your proposed solution re: disk encryption is, as I see it, doing nothing about counteracting the threat. Your proposed solution looks like a countermeasure against theft of the data, not theft of the hardware.

If you want to stop the hardware from being stolen, you need to bolt it down, lock it up, encase it in concrete, etc.

I've already said what I wanted to say re: theft of the data, so I won't harp on that again, except to say: If you're going to put the key into a physical device and you can't protect the server computer from being stolen then you can't protect the key device from being stolen either.

I guess your best "cheap" solution is to rig some kind of network-based key exchange. I'd put one or more humans in the loop to authenticate "release" of the key in the event of a reboot. It would cause downtime until the human "released" the key, but at least it would give you a chance to find out why a key "release" was being requested and decide whether or not to do so.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • This is an good addition to the security analysis, so I've given it an upvote, but it's not an answer to my question because you're using a different threat model. Note what I said in the question about against whom I am and am not defending. – cjs Jul 02 '09 at 02:47
  • 1
    As for better physical security, I'd like to look at less expensive options first. In our current environment, it would cost us many thousands of dollars to install something that couldn't be quickly defeated by someone with a pair of bolt cutters. – cjs Jul 02 '09 at 02:50
  • Re-reading this, I'm not sure you're clear that my threat model is not hardware theft _per se_, which is basically just an inconvenience, but the concomitant theft of data that goes along with it. That is precisely why my proposed solution is a countermeasure against data theft, rather than hardware theft. – cjs Apr 20 '17 at 07:17
  • It's interesting to see a comment on a nearly 8 year-old question. If your solution works for you I'm certainly glad of it. – Evan Anderson Apr 20 '17 at 17:23
  • I was just thinking "I shouldn't necropost", then I saw these last comments. I think Curt's threat model is the same as mine... to protect the data against someone stealing the hardware. Several comments on this and similar posts have said people could just "eavesdrop" on the key process and figure it out later. Only a really ridiculously bad process could be broken by any sort of replay. Also... "all the attacker has to do is" ... "reverse engineer any encryption you did"... Who are we talking about? What are the chances a common thief would have such ability... or even desire to do so? – darron Sep 10 '17 at 16:32
  • My threat model includes a common thief breaking in to steal computers... who would be foiled by any level of encryption. They wouldn't even care.. they just want hardware. My worst case to protect against is a non-inside person wanting to steal our IP. In the IT world, we tend to think of those as skilled, sneaky hackers... but in my world the guys I am worried about specifically are almost completely unskilled in IT who would simply break in and steal everything that looks like a computer or external storage. – darron Sep 10 '17 at 16:46