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.

  • 1
    Does your threat model wears uniforms with three letters on it? :)
    – Sven
    Commented Jul 2, 2009 at 2: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
    Commented Jul 2, 2009 at 2: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
    Commented Jul 2, 2009 at 3: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
    Commented Jul 2, 2009 at 6:10
  • +1 for actually thinking through the threat model, something many people with a similar question forget to do.
    – sleske
    Commented May 9, 2010 at 21:52

2 Answers 2


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


  • 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. Commented Jul 2, 2009 at 4:46
  • 2
    Evan, you want to read the FAQ in the Mandos README, I think....
    – cjs
    Commented Jul 2, 2009 at 6: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
    Commented Jul 2, 2009 at 6: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. en.wikipedia.org/wiki/…
    – Haakon
    Commented Jul 2, 2009 at 8: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: mail.fukt.bsnet.se/pipermail/mandos-dev/2009-February/… 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
    Commented Nov 2, 2009 at 15:53

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.


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.

  • 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
    Commented Jul 2, 2009 at 2: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
    Commented Jul 2, 2009 at 2: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
    Commented Apr 20, 2017 at 7: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. Commented Apr 20, 2017 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
    Commented Sep 10, 2017 at 16:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .