Encrypted Berryboot way too easy

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
sha1sum: f6a5f4fa59ae62c1e64288ec0cc69908c69f9b81

Download link Berryboot for the quad-core Raspberry Pi 2: berryboot-20150916-pi2-only.zip
sha1sum: aaf63e2d7f09f4c010515de5a2a80db6f1a236ef

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.

gparted view of encrypted Berryboot SD card

gparted view of encrypted Berryboot SD card

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.

In Conclusion

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

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits. Bookmark the permalink.

8 Responses to Encrypted Berryboot way too easy

  1. E.M.Smith says:

    Stuck it in the camera. It said I had 15 photos of space left. Took two pictures. Now I’m posting from it!

    Gotta love it when a plan comes together…

    I doubt if it is worth the trouble to make the FAT partition bigger than the default. If the guy looking over the camera is going into enough depth to notice only 15 photos of space on a card, and takes the micro-SD out of the full size SD carrier to read what size it is, you are getting a full search of absolutely everything already anyway and I doubt it would make a difference.

    But now you know. Anything that takes a FAT32 SD card can be your ‘carrier’ for the ‘system disk and user space’ for your Pi. It will just look like an unformatted chunk to anything but Linux (and related) systems, and it can’t be examined inside that partition without the password. I’m good with that. I suppose you could also put it in some phones, and my tablet takes a micro-SD card too. But those are more likely to be subjected to ‘computer guy searches’ than a camera. Maybe…. I think I’m back at “good enough” for most anything I’d need at this point. Still going to work on a RaTails, but I’ll be doing it from an already pretty secure platform…

  2. E.M.Smith says:

    Looks like you can copy a github git source archive here:


    and that page has a ‘dowload a zip archive’ button with this link in it:


    that downloads an 8 MB zip file (that I’ve not unpacked yet).

    For those folks wanting to “look over the sources” and make sure it is doing only what it claims to do… or desiring to modify it for “special purposes”. Or just have a copy of it in the archive for that day when someone makes a stupid change in it or decides to retire and go fishing instead of doing free computer development… That happens some times in Free and Open Source projects.

  3. pyromancer76 says:

    All your efforts might pay off for those who want truly “private” computer systems. More info about your skills for those who could “crowd-source” funding for your continuing these efforts more than the full time you put into informing us on your blog. I hope this happens; your insights, knowledge, and research abilities are essential to free minds/free society.

  4. E.M.Smith says:


    Well, other than “hard core Unix / Linux computer geek with security background and over 25 years experience” not sure there’s much worth adding that doesn’t end up in Technobabble ;-)

    FWIW, I’ve thought maybe when I get this all ‘sorted out’ I’d try offering a batch of ‘pre-built’ SD cards for a modest price and see if folks want them. I generally lean toward the FOSS (free and open source software) POV, but there are still ways to make money out of that by selling convenience.

    Frankly, my major motivation in this particular R&D thread (secure system) is simply that The Constable made the mistake of Pissing Me Off with the raid on Tallbloke. Big Mistake. I don’t do nearly as much when I’m the one whacked as I do when I see an innocent get whacked. Sets a ‘bit in the brain’ that I can not unset. So if I make money from it, or not, makes no difference. I will provide enough public information and methods for anyone anywhere to have such a thing happen to them and not have it hurt them.

    I’m pretty close to “done” on that front, IMHO.

    We’ve got non-buggered hardware and boot code (Raspberry Pi Model 2), and we’ve got an encrypted OS / user file space. The OS is FOSS and source is available to ‘many eyes’. It all fits on a chip that is easily “cloned” (in a safe and also secure way) for rapid restoration and of such a small size that a ‘copy’ can be saved just about anywhere; including as spare chip slipped into the cardboard of a frozen TV dinner in the freezer… are they REALLY going to open every single package and space in the house where a micro-SD card could be hidden? Even lift the cap off the shaving cream and remove a color matched plastic insert covering the chip (trim from old cap to fit)? AND if they do, they still get nothing and your recovery time increases by how long it takes to get to the local drug store at midnight and buy a new chip, then do the download of the encrypted image from the “cloud of your choice”. IFF 100% of hardware is taken, you are “next day shipping” away from recovery with a buy of a new R.Pi from Amazon for $60.

    Oh, and it is all portable so you can use it from Starbucks and not mark your home IP address as the source, and the WiFi dongle is a $9 part that you can fry and toss as needed to completely nuke any MAC ID information. (Changing the MAC ID can be done, but for those not interested in that tech hurdle, or just wanting a 20 second “fix”, a short stint at the end of a spark plug wire and a toss off a bridge works wonders… ;-)

    “I’m good with that”.

    So I’m fairly sure we’re in the final “putty and spackle” phase of the basic system. I’ll keep working this problem space until we have a full on full up RaTails system (first step being to run THIS system through a TOR router), but as of right now I’m pretty sure this is all “good enough for daily use” as it stands. I still need to pick some cloud provider and test that process (though it ought to be seamless. It’s just upload a file, download a file.) I also still need to sign up for some kind of VPN provider and test performance “popping out” of the system on the far side of the world (so my traffic looks like it originates in, say, Slovenia…) Then there is the ‘lock down the applications’ part. Less important when you ‘flash’ them new each use, but it would still be nice to not have them leak so much information (i.e. cookies and such).

    So the work isn’t done. But as of now I think it is good enough to be used.

    BTW, anyone who already has a cloud provider or a VPN service, feel free to do those steps and report in… It’s not like I have to do it all to feel fulfilled ;-)

  5. Larry Ledwick says:

    I think a pre-loaded SD card and a small booklet would be a nice value add and convenience item. Something reliable for “that day”, and would get you going while you learned how to do it yourself.
    Something you could sell via Amazon Ebay or any other online source with no hassle.
    Include a short tutorial on Unix for new guys and I suspect you could sell it for enough to make a bit of profit to cover your expenses.

    Remember the old Forest Mims electronics books sold at Radio Shack, how many thousands of those do you think got sold?

    He’s still at it.


  6. E.M.Smith says:


    Interesting idea. Maybe a “soup to nuts” how to make a secure portable disposable system for the not so technical person. With chip pre-bulit. Maybe even set up with ‘everything the typical reporter and leaker would need’ ;-) I like it …

    @Encryption longhand:

    Just a quick note about the “less easy” way to do LUKS file encryption…

    I was working on doing a “shrink the 64 GB card” backup with non-dd tools and decided to work on the encrypted card too. Well, that lead to me wanting to mount the encrypted file system on a different system…

    First, you need to install some tools for it to work:

    apt-get install cryptsetup

    that’s the basic LUKS tool. I also did an install of lvm2 just so I’d have logical volume manager available should I want it (some folks put swap on a file inside an ecrypted lvm set so it’s encrypted too). And turns out there’s an enhanced dd for forensic use named dcfldd that I also installed, though I’ve not found out yet what makes it ‘special’ (likely more emphasis on maintaining metadata intact).

    Now the interesting indirection comes. It’s not enough to just have the crypt stuff installed and mount the file system… no… It’s a Kentucky Two Step process.

    I don’t know if one needs to do this part. I did it part way through but had another hurdle to cross first. But if all else fails, try:

    modprobe dm-crypt

    to make sure the kernel modules are loaded and running. Then you mount the file system in that 2 step kind of way.

    First you do a:

    cryptsetup luksOpen /dev/sdc2 RPi

    This takes the partition (in this case it was at /dev/sdc2) that’s encrypted and decrypts it (after asking you for the passphrase if you didn’t put it on the command line). But it doesn’t put it where you can use it as a file system. No… That RPi name is just a handle for the actual mounting. It makes a decrypted blob that’s still a LUKS container and puts it in /dev/mapper like this:

    root@RaPiM2:/mnt# ls /dev/mapper
    control  RPi

    I don’t know what ‘control’ is, and don’t really care right now ;-) but the other name is what you feed to the mount command:

    mount /dev/mapper/RPi /mnt/Testing/

    Then you are able to see it as a mounted file system:

    root@RaPiM2:/mnt# df
    Filesystem      1K-blocks      Used Available Use% Mounted on
    rootfs           59805812   5463924  51280848  10% /
    /dev/mmcblk0p5     499656       680    462280   1% /media/data
    /dev/mmcblk0p3      27633       444     24896   2% /media/SETTINGS
    /dev/sdc1          129774     47884     81890  37% /media/03F0-04DE
    /dev/mapper/RPi   7377768   2116268   4863676  31% /mnt/Testing

    That /dev/sdc1 mounted automatically at /media/03F0-04DE is the /boot partition of the SD card where all the stuff that boots the rest of it is found. It isn’t encrypted.

    So there you have it. How to get into that encrypted file system without just booting and running. Useful in many ways, not the least of which is if you wanted to suck out the contents without booting up. (Say with the card in some other box like a Debian backup server…)

    cryptsetup has a bunch of options. Including one to nuke the keys to the container quickly. Seems that they thought about the need to rapidly nuke the contents, and it is designed in. There is also an option to ‘backup the header’ where the encryption key(s) live (you can have something like 8 different keys for different folks if you like, and can revoke the keys individually.

    Revoking the last key leaves the data blob inaccessible…) just in case you nuke too many keys you can restore the header without moving the whole bucket of bits in the container.

    An interesting idea / question is can you ship the blob separately from the header to assure no decryption can be done. I’m sure it can be done that way, just don’t know the risks. Back up header to USB stick (that might, itself, be encrypted in some way). Nuke all keys in LUKS container. Ship it. “whenever” you get reunited again, restore the header from your USB. Neither part is usable alone… I can see that being VERY useful for putting a ‘blob’ in the ‘cloud’ somewhere. You store the keys / header where they are very hard to find, and if found, still kind of useless. You put the data in ‘the cloud’ with empty header. Very very useless as no key can decrypt it. Someone can steal it, attack it, do ‘whatever’ and still get nothing unless they can find where you hid the header. Nice.

    So read the ‘man cryptsetup’ pages and make sure you are comfortable with it before doing anything exotic… But there is clearly a lot of potential here.

  7. Larry Ledwick says:

    Aside from the Forest Mimms series, one of my all time favorite technical books is:

    “How to build and use electronic devices without frustration, panic, mountains of money, or an engineering degree” By Stuart A. Hoenig PhD and F. Leland Payne, MSEE

    Your postings are very much in the same style as that book. You might pickup a used copy as a type example — and it is just fun to read and realize that lots of apparently complex gadgets are at their heart really pretty simple and with a bit of applied hacking can get you a long way with the help of reading a few spec sheets.

    He gave really simple straight forward “recipes” for lots of useful toys and devices and gave you enough info (tweak this resistor to change xyz) to allow folks to get the thing working and then massage it to do what they needed with a little bench time.

  8. E.M.Smith says:


    I must have checked these particular books out of the library a few dozen times, for weeks at a time…

    I can still see the wooden plank I talked my Dad it cutting from a board and that I labored varnish over… and the CK722 transistor I’d pestered the local ‘radio repair shop’ into ordering for me… along with the 360 mf? variable capacitor taken from old broken radios and / or TV sets… Made several radios, amplifiers, what have you…

    With The Boys’ Second Book of Radio and Electronics, in 1957, Morgan broke new ground in several areas. First, he introduced transistors, those “versatile midgets which can do the work of vacuum tubes.” There followed a handful of transistor projects using such devices as the now legendary Raytheon CK722 and General Electric 2N107. After the chapters on transistors, Morgan returned to vacuum tube projects including a design that was perhaps inevitable for the late 1950s in a country newly under the threat of nuclear annihilation: a home-made Geiger counter or, as he called it, a “Gamma Sniffer.”

    Wanted to make the “Gamma Sniffer” but Dad wouldn’t buy the needed tube… ;-)

    Maybe it’s time for something similar based on the R.Pi as ‘the kid’s book of computers’…

    I lived in “The First Book” for months, then moved on to the Second Book… I can still see the drawings in the books… forever written in bits in the brain… Clips, screws, wires, and all..

Comments are closed.