Some things some times turn out to be just way too easy.
I’ve put off doing an ‘all system’ encrypted SD card. It’s usually painful to do encryption. Various things make it that way. From the frequent sloth of getting things done to the need to create keys and select encryption methods and more. I’d seen the “check box” but left it unchecked. Until now.
Today I decided it was time. I would make an encrypted Berryboot SD card.
The basics stay the same. Go to the main Berryboot site. Click the download link. Put the .zip file in a directory and unpack it. (It unpacks individual files into your current directory, so if you unzip it on, say, the desktop, all those files get mixed with all the other files you left laying around on the desktop the last 6 months and you get to sort them out…)
For people short on SD cards: Berryboot is a simple boot selection screen, allowing you to put multiple Linux distribution on a single SD card.
In addition it allows you to put the operating system files on an external USB hard drive instead of on the SD card itself.
Download link Berryboot for the original Raspberry Pi: berryboot-20140814.zip
Download link Berryboot for the quad-core Raspberry Pi 2: berryboot-20150916-pi2-only.zip
To install: extract the contents of the .zip file to a normal (FAT formatted) SD card, and put it in your Raspberry Pi. This can be simply done under Windows without any special image writer software.
Once you start your Pi it will start an installer that reformats the SD card and downloads the operating systems files from the Internet.
At their site, the two .zip names are live links you click on to start the download. Then, just like it says, extract and put on an SD card ( micro-SD for the PiM2 ).
Stick it in the Pi, boot.
You are greeted with a selection panel of what media to use (so you can choose an external USB stick if desired) and you pick your SD card. At one point it basically says “Are you sure? This will erase all data” and the thing that’s easy to ignore is a nice little check box that says “Encrypt disk”. All you need to do is check the box with a mouse click.
During the format it asks you to enter the password. You need to do this three times. I think the first two set the password and then the third lets you continue using the disk.
On an 8 GB card, I installed the newer Debian, Arch Linux, Puppy Linux, and the PXE Boot Server and had about 1/2 the card left empty for private data and added program installs.
Berryboot stores things more densely that the native install. IIRC, it is using a compressed squashfs file system for the base system, then overlays active rw space (but I’ve not verified that).
Once the downloads are done, reboot. I’m now making this posting from that install. I did have to do an “apt-get install Iceweasel” to get the browser I wanted. But that let me assess the impact of the encryption on things like installing new software. I didn’t notice a thing…
Near as I can tell, all downloads are limited by the wire. The quad core CPU chip usually has a core idle, so any added decryption load is invisible to the core I’m using, and read / write is speed limited by the SD card anyway and it works in big blocks, so that’s no different. Watching the “top” command, you can occasionally see an encryption related process, but it is way down on the list of CPU usage.
Not Perfectly Hidden
Unlike a full chip encryption, there is evidence visible that you have an encrypted part. Since the boot loader and all are on a FAT32 partition, and not encrypted, it is easy to see this is a Raspberry Pi OS chip, and even mess around with things like the boot loader and kernel.
That would help someone to bugger the chip to send them the password, or to store it off somewhere, but it does not let someone get into the encrypted part without the password. So if someone in customs takes your chip to the back room for 1/2 hour… I’d re-flash it from an encrypted backup before I’d reuse it for anything really important.
At boot, just after the initial kernel load, the Pi puts up one line of text asking for your passphrase. Enter it, and the rest of the boot and OS load is exactly as usual.
BUT, if you instead run ‘gparted’ against the chip to look at it and see what’s there, you can see the Raspberry Pi boot partition and the LUKs encrypted partition.
On the one hand, it is nice that it warns you there is really something there. It is way too easy to have some tool that doesn’t know what luks is, declare it an empty partition, and let you blindly format it. Like Windowz for instance. OTOH, it does ‘tattle’ that there’s something there and you need to beat the key out of someone.
That is where the “boot to USB” is handy You can have an SD card set up to boot to the external media, then the encrypted file system lives on it. Now someone needs to get both pieces of media and know that they go together, before they can figure out what is going on. I’d likely use a full sized SD card in a USB adapter. That way the “boot to USB” is just that much more confusing and someone needs to figure that out, then dig through your photo gear checking all the chips (and using Linux to do it so it doesn’t just show up as ‘unformatted’ as it does on Windows). If you need more security than that, you “have staff”… IMHO at least.
So while this is an incredibly easy set-up for an encrypted system, it is not for use with “needs” that might involve pressure from Agencies or Mobs or Cartels who know where your spouse is at…
But at the same time, I’d be quite happy to have one of these cards (say, a 32 GB one) with a large FAT partition up front, perhaps even with a half dozen pictures in ‘the usual place’ so my camera would show it as a working card with images, and with most of it holding a traveling system quasi hidden and encrypted. Turn on the camera, it looks like photos. Stick it in a PC, it looks like photos plus strange files (that one hopes they don’t recognize, most of the world being PC guys). Stick it in a Linux box and you see the encrypted space exists, but can’t open it. Stick it in a R.Pi it boots and asks for the passphrase… Good enough for a lot of things. Most all of anything I’d need.
“Sometime later” I’m gong to try putting it in a camera and see if it survives; or if I have to do the camera folder and photo or two first, then make the system around that. It ought not to matter, but one needs to test these things.
I’ve used the ‘dd’ command described in other postings to make a copy of the “pristine” build. Also later I’ll be testing the restore of it. As dd is a bit for bit copy there ought to be no problems.
It looks like there is a ‘restore’ choice on the boot to let you wipe anything added from initial install. I’ve not tested that, but it would be a convenient way to avoid needing to restore the entire 8GB chip just to erase cookies, command histories, and such from one OS on the chip.
Assuming that IS what it does, between those two options you have a system that can be booted clean, run for ‘whatever’ you want, and store things you download or save in a safe encrypted way. Then, later, if desired, can be ‘reset’ to the original pristine form. Any “odd bits” left laying around from the erased parts out to be bags of encrypted stuff so hard to extract anything meaningful. Run this through an Onion Router and you have 90%+ of Tails without all the work. Probably more than enough for the typical person doing ordinary things.
Personally, I’d rather “customize” it from the base install. All those things from the build script. Some of my personal scripts and tools. Maybe a cookie or two from a couple of “safe” sites (like Bigcharts where they store my chart preferences in a cookie) and THEN make a dd based “standard starting point” copy. Now I can “do my business” and even browse a few questionable web sites, and if one of them inserts some malware onto the image, not to worry. I just dd on the standard starting image prior to next use and I’m clean.
If there is a “knock on the door” by the gendarmes, I reach out and hit the power switch on my power strip and all goes back to being encrypted. Even the saved image is encrypted as it was dd’d from an idle chip as raw bits, not from the opened unencrypted file system.
Only hard bit looks to be making sure you don’t forget the passphrase…
Like I said, this is way too easy.
Sidebar On Speed
I don’t know if it is the Jessie release that is faster, or the Berryboot version that looks like it includes a bit of ramdisk overlay:
root@raspberrypi:/home/pi# df Filesystem 1K-blocks Used Available Use% Mounted on dev 431696 0 431696 0% /dev none 7377768 1990356 4989588 29% / tmpfs 441376 0 441376 0% /dev/shm tmpfs 441376 11644 429732 3% /run tmpfs 5120 4 5116 1% /run/lock tmpfs 441376 0 441376 0% /sys/fs/cgroup /dev/mmcblk0p1 129774 35286 94488 28% /boot tmpfs 88276 4 88272 1% /run/user/1000
Those “tmpfs” devices…
Or maybe the IceWeasel browser adds something…
But in any case, the posting experience is now “quite acceptable”. A tiny bit of typeahead sometimes, but I have that on the non-Pi boxes as well and I think it is the network latency of the spell checker. When I turn off spell checking there is not as much and maybe almost none at all. “Hard to say” is also “plenty fast”…
So with this being so “tasty” to use, and nicely private: I’m going to apply my ‘build script’ to this Debian image, save it in a ‘base state’, and use it as the Daily Driver for Browsing and Posting. I’ve often been just a tiny bit bothered by some of the random places I browse when working on a posting.
Type in a search term, click the first 5 links… You can only do that so long before you eventually hit some malware. And while almost all of it is aimed at Microsoft and can’t touch me, there is some that gets into Linux machines. I’ll be happier with the “reset scrub”. I’ll also be setting that one up with the Squashfs file systems and read only mounts we saw earlier, so those things that DO try to write things into /etc or /bin or /usr get a rather high hurdle to deal with. Yeah, overkill when it’s just going to be re-written in 2 hours anyway… but I like overkill for security.
If I want to save something? I’ll have an NFS mounted spot of disk I can “mount as needed”. Only mounted for the time used, then unmounted. That way any “hack” that does happen, as unlikely as it is, can’t get to the disk. (Other than during the few minutes it is mounted… but as I have a “top” system monitor running all the time, any unexpected activity would mean a shutdown and scrub and I’d not do the mount / save.) Not quite perfect security, but way more than I’m likely to really need.
And yes, if really worried, I can stick in a USB stick and copy files to that instead so they never touch my network drive… but if I’m that worried, I’m unlikely to save the file anyway. But that’s just me.
So there you have it. A Darned Easy and Darned Simple way to get a system on encrypted media, with mostly read only partitions for system binaries, and with easy backup / scrub and reset options. Not quite Tails level of amnesiac and incognito, but much more comfortable for most low risk uses.
As that’s a day or two of work ahead while I re-do all those things done on other chips, but in this encrypted space, it will be a couple of days before I’m running on it full time. After the end of all that, I think I’m pretty near as far along as one can get without doing the Full Monty Tails build.
At that point I’ll likely do a ‘summary posting’ pulling all the bits into one place so you don’t need to backtrack through the different postings to pick it all out.
I do have to say, in closing, that it does feel a bit nicer to know that I’ve got this reasonably good performance platform, that is easily reset to a base state that is customized to my needs, and that is very easy to ‘lock out’ via power switch. That it is also “fast enough” is nice added seasoning.
I’ll post a comment after I put the chip in the camera and see what happens ;-)
Subscribe to feed