3

My company works with Raspberry Pis, where all data (OS, our software, etc) is stored on an SD card. We configure these devices (load our software on them), and send them out into the field (an environment we don't control). These Pis have sensitive data on them, and the fear is that someone in the field will take the Pi, and get access to this sensitive data.

The obvious solution of not storing sensitive data on the SD card, but rather streaming it over a secure network won't work for us - the Pi won't always have access to internet, or any other kind of network.

The other obvious solution is to encrypt the partition where the data is stored, but that is proving to be a challenge. The Pi needs to be able to access this sensitive data as it runs, which means no matter what type of encryption we use, the Pi needs to be able to decrypt the encrypted partition at boot. This implies that it needs to have some sort of decryption key that is stored on a non-encrypted partition, which is inherently flawed. An attacker can easily gain access to the key, and use it to decrypt the encrypted partition.

There are hardware solutions, like the Zymkey, that promise to address this. We tried that, and it took me just over 5 minutes to break into an encrypted root partition that used the Zymkey as its key. The problem is that even though you can encrypt the root partition, you can't encrypt the boot partition, which stores the kernel, and the files that pass args to the kernel at boot. This lets an attacker modify these bootloader files, asking the kernel to start a shell at boot for example, giving the attacker full access to the encrypted root partition.

Even if we were to compile our own custom kernel that didn't accept any args, preventing boot args that give an attacker shell, this custom kernel would be stored on the /boot partition that the attacker has access to. Nothing would stop them from just replacing our custom kernel with a generic one.

I know you can hack together some hardware solutions, where you glue the SD card, and/or put the Pi in a box that's rigged with booby traps, where if someone tries to open the box, it will delete the encryption key, and unmount the encrypted partition (or reboot). Those are all relatively easy to bypass, and are hacky at best.

So my question is this: Is it conceptually even possible to encrypt either the entire root partition, or just some data partition where sensitive files can be stored, so that if an attacker gets their hands on the SD card, they won't be able to get their hands on the files themselves? Linux still needs to be able to decrypt and use these files as it runs.

11
  • 1
    It sounds like you might need to rethink the choice of platform... I’m not sure Pis are really appropriate if you want to secure the payload. Commented Jul 20, 2021 at 18:24
  • @StephenKitt For better or worse, a Pi is what we have to work with. It has plenty of horsepower for what we need, and the price per unit is great. We just need to secure it somehow
    – John
    Commented Jul 20, 2021 at 20:36
  • it's possible to solve the kernel args part of the problem. Some bootloaders can be configured to require a password to override the configured args. e.g. if your RPis use grub as the boot-loader, you can do this (should be easily doable on an rpi 3 or 4, harder on older versions). However, as with the encryption key, that's just another password that can be read by anyone who has root or physical access to the machine (or just reconfigure it so that it doesn't require a password).
    – cas
    Commented Jul 21, 2021 at 4:49
  • If you can't restrict physical access to the hardware and can't require the keys/passwords to be manually entered at boot time, then any security measure is going to be a time and convenience hassle to an attacker, rather than a complete blocker. The questions you need to ask yourself are: What kind of attackers are you envisioning/expecting? How determined do you expect them to be? How much effort and expense will it take to make it not worth their while (you really can't expect to stop a determined attacker with lots of time and money.....but you can expect to block casual curiosity)
    – cas
    Commented Jul 21, 2021 at 4:55
  • @John I understand the attractiveness of the Pi here; but “We just need to secure it somehow” is a requirement which affects the choice of platform IMO. Other platforms have security equipment which the Pi lacks (or can’t use because of its boot sequence). Commented Jul 21, 2021 at 7:17

3 Answers 3

3

You cannot secure sensitive data without a minimum amount of physical security. A Raspberry Pi has no physical security. Either you need to put it inside a tamper-resistant box, or you need to use different hardware that has tamper resistance built in.

Yes, it will cost more. Security is a feature that often comes with a cost.

Notice from the forum post you cited that a Zymkey that functions only as a companion device to a Raspberry Pi cannot protect anything. You also need some physical protection of the Pi itself.

A single-board computer with secure boot should work. I don't have any particular model to recommend. It's also apparently possible to bolt a TPM on a Raspberry Pi; this doesn't give you secure boot (no verification of the code before executing it) but it gives you verified boot (if the code isn't what is expected, it won't be able to retrieve the key from the TPM). Note that either way, this only prevents small-scale physical attacks such as swapping an SD card, not more invasive attacks such as inserting a logic probe on the RAM bus.

0

You can use LUKS for this, using an encrypted file as a vault for your application to store files on.

To use the encrypted volume you will have to,

  1. Open the encrypted LUKS volume.
  2. Mount the encrypted volume to a mount point for your app to use.

When you are done,

  1. Unmount the volume mount point.
  2. Close the encrypted LUKS volume.

The post linked below covers the steps required.

Create an encrypted file vault on Linux

2
  • 2
    Wouldn't this mean that an admin with the luks password should be present at each reboot? (Not my downvote btw)
    – user000001
    Commented Jul 20, 2021 at 18:00
  • Crap missed that. You're right. @user000001
    – d4n3sh
    Commented Jul 20, 2021 at 18:34
0

I had a similar problem in the past. I anticipate there is no perfect solution. It very much depends on how much time the intruder wants to dedicate to break into the system and how much time you dedicate to creating difficulties. There is for sure no 100% secure solution. The Zymkey solution is really neat, but it can be costly depending on the project also not effective in some cases.

This is the way I did it and it was enough for the client requesting it:

  1. Create a hidden volume with all the encrypted data (try to make it read only and if possible read once for speed: encrypted volumes are very slow. Forget about using it for frequently access/modified data). In my case I was storing code that was read only once.
  2. Create a command that makes some verifications and afterwards mounts the volume. Use a low level language like C. (yes I know, a bit tough, but some how it forces the intruder to use a disassembler or a kernel debugger if you do it right).
  3. Compile with all your symbols hidden
  4. Obfuscate all strings with a very complex algorithm. (strings include passwords, file names, external commands, etc. Basically do it with everything)
  5. Encrypt obfuscated strings (I was using libtomcrypt)
  6. Make sure all strings are not visible (use strings command)
  7. Insert random and complex math calculation functions between valid functions to complicate disassembly
  8. This command will run an external command to mount the encrypted filesystem that will need several authentication variables:
  • Use the unique serial number of the PI for one (/proc/cpuinfo)
  • Use the serial number of the SD card for another (or together with the PIs)
  • Use some additional files that are generated on the fly by the command
  • Use the checksum of the files in the dos partition (start.elf, kernel.img)
  • Verify that root password has not been changed
  • Verify timezones, os versions and other aspects of the OS that might be more specific to your environment
  • If you have some type of network access (even if only local) or specific devices connected to it check if they exist
  1. Files shall be created in memory, used for mount and deleted
  2. password should be passed as environment variables so they are not seen with a ps/top/htop
  3. Basically make sure that the command will not run if all these conditions are not met.

When all these checks are correct then the command mounts the volume. (add the execution of the command as a systemd service). Install a well known service that you won't use and replace the executable with your new command. You can even hide the command it some script that runs for another service.

It took some time, but it was fun remembering C from the old times. Of course there are ways to break into the code of the C command, but I guarantee the intruder will spend several sleepless nights trying it. In my case, the clients only wanted to avoid that the others were copying the SD card to it worked well for us.

2
  • This is the approach I am familiar with - making it hard (but not impossible) for an attacker to break in. I was hoping there was some sort of simple solution involving encryption that wouldn't require so much effort, and was more secure
    – John
    Commented Jul 22, 2021 at 22:41
  • This is the sort of mumbo-jumbo that clients who don't know better will buy, but I guarantee you that people who know what they're doing will not lose any sleep over it. There is a state-of-the-art for code obfuscation; this isn't it, and even the state of the art won't hold up for long if someone really cares (and if no one cares you don't need any of this). It's also the kind of thing that adds a lot to support costs (my SD card went flaky and the backup doesn't work! Nothing is working after the disk was temporarily full! …) Commented Jul 28, 2021 at 22:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .