Friday, November 22, 2013

BKMs #0: Setting Up air gapped machine


Here's how I've setup and maintain Linux-based (Debian) air gapped computer.

Getting Debian

1) From trusted environment (I used computer and network at my work) I've downloaded debian.iso:

 $ wget http://cdimage.debian.org/debian-cd/7.2.0/i386/iso-dvd/debian\ 
-7.2.0-i386-DVD-1.iso

2) I've downloaded SHA1 sum and it's signature:

 $ wget http://cdimage.debian.org/debian-cd/7.2.0/i386/iso-dvd/SHA1SUMS.sign

3) To verify signature I needed Debian's cd/dvd signing key:

I googled exactly what I needed: "debian cd signing key", first match looked very promising: http://www.debian.org/CD/verify

I found (there was also second key with uid "Debian CD signing key" but with older date) what I was looking for:

pub   4096R/6294BE9B 2011-01-05
Key fingerprint = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B
uid Debian CD signing key
sub 4096R/11CD9819 2011-01-05

To be sure that http://www.debian.org/CD/verify site wasn't compromised at a time I was viewing it - I visited Google Cache of this site and compared key of interest:

pub   4096R/6294BE9B 2011-01-05
Key fingerprint = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B
uid Debian CD signing key
sub 4096R/11CD9819 2011-01-05

Good - exactly the same. One have to bear in mind that best practice is to check keyid/fingerprint of given cryptographic key from at least two sources (it's more difficult to compromise two sources at once). I used official Debian website as a first source and Google Cache of this site as second source. It's somewhat simpler approach (I don't need to look for second source which is sometimes tedious) but it's crucial to check date of generating cache by the Google. In this situtation older cache is better, for example if cache was generated ten days ago (and keys are identical on both current and cached versions) it means that site wasn't compromised OR it was compromised but nobody spotted it for 10 days (which is highly unlikely because many Debian developers see and use this site and would notice that keys listed there are forged).

4) Now that I identified valid key and verified that the source of it wasn't compromised, I could fetch key from public keyserver (using key id from above listings) and verify it's fingerpint:

 $ gpg --keyserver pgp.mit.edu --recv-keys 0x6294BE9B
$ gpg --fingerprint 0x6294BE9B

Key fingerprint = DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B

Good - it's the same as advertised by key owner.

5) Now I can validate (by validating the key I confirm that I trust the owner of the key):

 $ gpg --edit-key 0x6294BE9B (in prompt choose: trust,3,quit)

6) Finally with valid key I can verify signature of downloaded iso image:

 $ gpg --verify SHA1SUMS.sign

7) I burned downloaded iso to DVD disc.

Installation

1) I used my legacy PC machine that I haven't used anymore (even better is to use completely new computer). I used magnetic (as opposed to SSD) disk (it much more difficult to securely erase SSD disks).

2) First I wiped out all the data from the disk (to do that I had to download Debian's liveCD and burn it to CD disc - I've made it from my trusted computer. I followed steps above when downloading livecd), then I boot it on my computer and I run:

 # shred /dev/sda

3) I've double checked that computer isn't connected to network and that it doesn't have wifi card installed (from this point on it will never be connected to network again). Now I could start installing OS.

4) I used following guide to do whole-disk encryption (I skipped part with setting up recovery system). I used Blowfish as an encryption algorithm (I do not trust AES anymore). I used this advice for choosing strong password that I could remember.

Usage

1) I bought new pendirve for moving files on and off my air-gapped machine (by the way I called it vault :) and I shredded it and created FAT16 partition:

 # shred /dev/sdb
# fdisk /dev/sdb (n,t,w)
# mkdosfs -F 16 /dev/sdb1

2) I generated gpg key pair on the vault and copied public key to pendrive:

 $ gpg --gen-key
$ gpg --armor --output vault-key.asc --export

Assumption is that private key will never leave vault machine. I copied public part (vault-key.asc) to my pendirve and I will share it with persons I need to communicate securely (of course I will also need their public keys for secure 2-way communication).

3) Also pendrive's whole-disk encryption is worth considering but I wanted to be able to use this pendrive both on Linux and Windows machines so I skipped this step for now (when I will transfer something sensitive I can always encrypt it with vault's public key).

4) I have now reasonably secure, air gapped computer. It's by no mean perfect: the way how files are transfered back and forth vault is obviously it's weakest point. Trusted "converters" or "verifiers" as mentioned here would help, but someone would have to write it first which isn't trivial.

5) Some typical maintenance issues and the way I deal with it:
- In case I will need more software I can always repeat steps "Getting Debian" to download second (or third) Debian's DVD.
- Keeping software up to date can be achieved by downloading Debian's update iso images.
- One more thing that I leave for now is maintaining secure backups of vault's disk - but it's doable.