[Discuss] key server

[tmetro+blu at gmail.com (Tom Metro)]

Rich Braun wrote:
> (a) the keys are convenient, readily accessible at every reboot
> (b) the keys can't readily fall into the wrong hands

Is it a requirement that reboots happen unattended? If not, what level
of interaction is acceptable? You said in a previous message you didn't
want to have to carry around a USB thumb drive to each computer when
rebooting multiple machines (presumably after a power outage).

Would you apply this same setup to a laptop? If so, how do you boot it
when it is off your LAN?


> Commercial companies have products that address all of these and more...

Can you describe how the commercial solutions achieve both of those
simultaneously?

Have you looked into any open source key servers? Do they exist?


> An open-source thing that wouldn't be all that hard to write could set up a
> little Raspberry Pi device to act as a key server, where once you set it up
> you can then run around to each of the systems on your home (or small-office)
> LAN to initialize a token stored locally. 

By token you mean some moderate-strength (easy to remember) pass phrase
that you enter into each PC, which then uses it to authenticate against
the key server to retrieve the real key?


> ...the handshake would involve the token plus a pass-phrase challenge to
> be entered on a web-page console interface on the keyserver device.

Oh, then I'm not following what the token is.

So you are unlocking the key server as well.

This sounds like a fairly interactive and manual process.


> ...after which each machine...can then fetch its keys to mount
> filesystems...or reboot

Requiring network communication with a key server before the boot device
can be unencrypted does complicate matters. You'll need to have a
mini-OS that boots first, sets in place the keys, then chain loads the
real OS.

There may be existing open source encryption products that already have
this part figured out.

Of course it also simplifies matters if you only encrypt home/data drives.

Interfacing to the machine as a USB keyboard might be one way to avoid
this complication. Then a network-unaware bootloader can prompt for the
pass phrase.

Something like a USB Rubber Ducky could help implement this:
https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-ducky-deluxe

A pass phrase can be stored on them, and it'll replay it with the press
of a button. (A Yubikey would work as well, for this use case. With the
discovery that you can hack the firmware in some USB Flash drives, I
wouldn't be surprised to eventually see instructions online for how to
turn a $5 USB drive into a emulated keyboard replay device.)

But the more interesting approach would be to use this same keyboard
interface, but control it with a micro that has some network
connectivity, be it Bluetooth, WiFi, Zigbee, or Ethernet. Then it could
communicate back to a key server. This could be a private network
separate from your LAN.

You'd drive the process from a web UI on the key server. Enter your
master pass phrase to unlock it, and then select the target machine you
want to send a key to, and click a button at the appropriate point in
the machine's boot cycle.

A Rubber Ducky could be used as a portable alternative when off-LAN.

A more practical solution that you could cobble together with
off-the-shelf devices and a bit of scripting might be to put Bluetooth
receivers on each computer, encrypt only data drives, so you an insert
some custom scripting to retrieve keys from the Bluetooth, and repurpose
an old smartphone as your key server, which might require a custom app.

 -Tom

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/