bzr branch
http://bzr.recompile.se/loggerhead/mandos/release
152
by Teddy Hogeborn
* README: New file. |
1 |
-*- org -*- |
2 |
||
3 |
* Mandos |
|
4 |
- Have your cake and eat it too! |
|
5 |
|
|
6 |
You know how it is. You've heard of it happening. The Man comes |
|
7 |
and takes away your servers, your friends' servers, the servers of |
|
8 |
everybody in the same hosting facility. The servers of their
|
|
9 |
neighbors, and their neighbors' friends. The servers of people who |
|
10 |
owe them money. And like *that*, they're gone. And you doubt |
|
11 |
you'll ever see them again. |
|
12 |
|
|
13 |
That is why your servers have encrypted root file systems. However,
|
|
14 |
there's a downside. There's no going around it: rebooting is a |
|
15 |
pain. Dragging out that rarely-used keyboard and screen and |
|
16 |
unraveling cables behind your servers to plug them in to type in |
|
17 |
that password is messy, especially if you have many servers. There |
|
18 |
are some people who do clever things like using serial line consoles |
|
19 |
and daisy-chain it to the next server, and keep all the servers |
|
20 |
connected in a ring with serial cables, which will work, if your |
|
21 |
servers are physically close enough. There are also other |
|
22 |
out-of-band management solutions, but with *all* these, you still |
|
23 |
have to be on hand and manually type in the password at boot time. |
|
24 |
Otherwise the server just sits there, waiting for a password. |
|
25 |
|
|
26 |
Wouldn't it be great if you could have the security of encrypted |
|
27 |
root file systems and still have servers that could boot up
|
|
28 |
automatically if there was a short power outage while you were
|
|
29 |
asleep? That you could reboot at will, without having someone run
|
|
30 |
over to the server to type in the password?
|
|
31 |
|
|
32 |
Well, with Mandos, you (almost) can! The gain in convenience will
|
|
33 |
only be offset by a small loss in security. The setup is as
|
|
34 |
follows:
|
|
35 |
|
|
36 |
The server will still have its encrypted root file system. The
|
|
37 |
password to this file system will be stored on another computer
|
|
38 |
(henceforth known as the Mandos server) on the same local network.
|
|
39 |
The password will *not* be stored in plaintext, but encrypted with
|
|
40 |
OpenPGP. To decrypt this password, a key is needed. This key (the
|
|
41 |
Mandos client key) will not be stored there, but back on the
|
|
42 |
original server (henceforth known as the Mandos client) in the
|
|
43 |
initial RAM disk image. Oh, and all network Mandos client/server
|
|
44 |
communications will be encrypted, using TLS (SSL).
|
|
45 |
|
|
46 |
So, at boot time, the Mandos client will ask for its encrypted data
|
|
47 |
over the network, decrypt it to get the password, use it to decrypt
|
|
48 |
the root file, and continue booting.
|
|
49 |
|
|
50 |
Now, of course the initial RAM disk image is not on the encrypted
|
|
51 |
root file system, so anyone who would come and take the the whole
|
|
52 |
computer would have the Mandos client key when they took the server
|
|
53 |
offline and read the disk with their own tools. *But*, by then the
|
|
54 |
Mandos server will have detected that the original server is no
|
|
55 |
longer online and will no longer give out the encrypted key. The
|
|
56 |
timing here is the only real weak point, and the method, frequency
|
|
57 |
and timeout of checking can be adjusted to any desired level of
|
|
58 |
paranoia.
|
|
59 |
|
|
60 |
(The encrypted keys on the Mandos server is on its normal file
|
|
61 |
system, so those are safe, provided the root file system of that
|
|
62 |
server is encrypted.)
|
|
63 |
||
64 |
* FAQ - couldn’t the security be defeated by...
|
|
65 |
||
66 |
** Grabbing the Mandos client key from the initrd *really quickly*?
|
|
67 |
This, as mentioned above, is the only real weak point. But if you
|
|
68 |
set the timing values tight enough, this will be really difficult
|
|
69 |
to do. An attacker would have to physically disassemble the client
|
|
70 |
computer, extract the key from the initial RAM disk image, and then
|
|
71 |
connect to a *still online* Mandos server to get the encrypted key,
|
|
72 |
all *before* the Mandos server timeout kicks in and the Mandos
|
|
73 |
server refuses to give out the key to anyone.
|
|
74 |
|
|
75 |
As the typical SOP seems to be to barge in and turn off and grab
|
|
76 |
*all* computers to maybe look at them months later, this is not
|
|
77 |
likely.
|
|
78 |
||
79 |
** Replay attacks?
|
|
80 |
Nope, the network stuff is all done over TLS, which provides
|
|
81 |
protection against that.
|
|
82 |
||
83 |
** Man-in-the-middle?
|
|
84 |
No. The server only gives out the passwords to clients which have
|
|
85 |
*in the TLS handshake* proven that they do indeed hold the OpenPGP
|
|
86 |
private key corresponding to that client.
|
|
87 |
||
88 |
** Physically grabbing the Mandos server computer?
|
|
89 |
You could protect *that* computer the old-fashioned way, with a
|
|
90 |
must-type-in-the-password-at-boot method. Or you could have two
|
|
91 |
computers be the Mandos server for each other. (Multiple Mandos
|
|
92 |
servers can coexist on a network without any trouble. They do not
|
|
93 |
clash, and clients will try all available servers.)
|
|
94 |
||
95 |
** Faking ping replies?
|
|
96 |
The default for the server is to use "fping", the replies to which
|
|
97 |
could be faked to eliminate the timeout. But this could easily be
|
|
98 |
changed to any shell command, with any security measures you like.
|
|
99 |
It could, for instance, be changed to an SSH command with strict
|
|
100 |
keychecking, which could not be faked. Or IPsec could be used for
|
|
101 |
the ping packets, making them secure.
|
|
102 |
||
103 |
* Security Summary
|
|
104 |
So, in summary: The only weakness in the Mandos system is from
|
|
105 |
people who have:
|
|
106 |
1. The power to come in and physically take your servers, and
|
|
107 |
2. The cunning and patience to do it carefully, one at a time, and
|
|
108 |
*quickly*, faking Mandos client/server responses for each one
|
|
109 |
before the timeout.
|
|
110 |
|
|
111 |
While there are some who may be threatened by people who have *both*
|
|
112 |
these attributes, they do not, probably, constitute the majority.
|
|
113 |
|
|
114 |
If you *do* face such opponents, you must figure that they could
|
|
115 |
just as well open your servers and read the keys right off the
|
|
116 |
memory by running wires to the memory bus.
|
|
117 |
|
|
118 |
What this system is designed to protect against is *not* such
|
|
119 |
determined, focused, and competent attacks, but against the early
|
|
120 |
morning knock on your door and the sudden absence of all servers in
|
|
121 |
your server room.
|