LUKS Encrypt Your Root File System on Raspberry Pi


@mark Sorry for the late response and thanks for describing your use case. It’s an interesting and logical one, to be sure.

I think it would be completely possible to have Zymkey manage LUKS keys for two separate volumes. The basic flow would go something like this:

  1. Kernel boots with initramfs
  2. initramfs mounts and hands over to encrypted rootfs
  3. /etc/fstab and /etc/crypttab describe other encrypted volumes. The rootfs key could be used or unique keys could be generated for each separate volume.

I would start with encrypting the rootfs with either the SD card conversion or the external USB migration script. Once you have that set up and booting, then you could encrypt your secondary external drive referring the external USB script as a guideline, then soft links could be set up on the encrypted rootfs environment to point to the important files or directories that live on the secondary drive.


It may well be that my understanding is flawed, but this thing bugs me still. Given the 4i Lite without tamper detection, how would you mitigate a scenario where the bad actor modifies the initramfs to get a login tty and then just stays in the initramfs indefinitely without mounting the encrypted rootfs as root?

Essentially they’d have all the required software in the inherently unprotected initramfs to use Zymbit’s API to decrypt the LUKS key and then they could just mount and browse the rootfs as a simple mount, if I’m not mistaken.

Does the Zymkey somehow verify the initramfs image the script creates to prevent this? Or does the Zymkey present the decrypted key to LUKS or other subsystem in a way that the decrypted key cannot be intercepted (e.g. from a memory dump)?


Hi @hlev80,
You are correct in your understanding as it pertains to an encrypted root file system on SD card with the 4i Lite. As I mentioned in a previous post, we currently don’t do anything to protect/validate the /boot partition, so a bad actor could exercise Zymkey to get at the LUKS key. I should mention a couple of things here:

  1. We are currently working on strategies that validate the critical boot components. These are in the design and development stages.
  2. If one was to use the external migration script instead of the SD card conversion script to migrate the root file system to an external USB mass storage device, an extra level of security could be achieved by permanently write protecting the SD card ( Since the Zymkey binds itself to the host computer and the SD card ids and the SD card would be locked, the system would be a little more secure because the bad actor could not simply rebuild the initrd with his own malware onto a new SD card. The only real drawback to this approach is that the kernel could not be upgraded. However, in a production environment, I think most people would agree that major components like the kernel should be locked down for the life of deployment for the sake of stability.

Having said the above, if one has physical access to a device, a lot more attack vectors become exposed no matter how good the cryptographic design is. That’s why we strongly recommend tamper detection as part of a robust IoT deployment strategy. With the tamper detection feature configured for “self destruct” mode, the Zymkey will turn itself into a brick after the detection of a tamper event.


Hi Guys,
Im interested with Zymkey to protect my Raspberry pi.
But I got questions:
Actually my project will be temperature and pressure monitoring.
I will be using 4 pcs ADS1115 ADC that uses the I2C
with the following address:
0x48 (1001000)
0x49 (1001001)
0x4A (1001010)
0x4B (1001011)

This will not interrupt or zymkey and my devices will work?

  1. If I LUKS encrypt and apply zymkey to /home/pi folder with my application is also located that will run the programs for my temp and press monitoring, will the program will still work even the system hung and reboot itself with an external watchdog timer?
    The program is run on startup using the crontab as a task.

looking forward for your reply soon for me to decide to buy Zymkey.



Hi @azkikr,

Thanks for your interest in Zymkey. The Zymkey 4i default i2c address is located at 0x30, so there should be no conflict with the devices you listed.

Regarding your second question, please keep in mind that this community post details how to encrypt the entire root file system. If your system hangs or is reset by a watchdog timer, there is always a small possibility that some files on the root file system may become corrupt. This is true with or without encryption. In order to avoid these kinds of issues, it is always a good idea to shut down gracefully whenever possible. Having said that, the ext4 file system is probably the most robust file system in existence today with regards to recovery. This is due in part to good journaling design.


Hi @Scott_of_Zymbit,

  1. Thanks for the reply and noted about the I2C address.s

  2. Understand about this.
    My application I am running is a simple python script that gets the monitoring data every 5 minutes. The program is not looping instead it is run by a task every 5 minutes using crontab. Hence corrupted file maybe not an issue.
    The raspberry pi is on remote location which not easily accessible by people to reset in case the raspberry pi hangs. So I put a watchdog timer to reset it automatically.
    My question is if the raspberry pi was reset is the raspberry will boot automatically and run with its scheduled task to run my python program?
    Or does it need a human intervention to reset the zymkey in order for the Pi to boot itself?

If it can boot automatically is there a chance that zymkey will prevent it on booting up the Pi?


If the RPi reboots as a result of the watchdog timer, the Zymkey will reboot itself as well because it will no longer be receiving heartbeats from the Zymkey interface daemon.


Is this the solution for colocation of a raspberrypi in a data center?

I tried encrypting the root with Luks on a Odroid C2 that was in a data center. Worked great until a firmware update borked it. The way I had it working was to secure shell into initramfs and enter password. Than ssh again after system comes up.

So what happens if someone physically steals my raspi or connects to serial port? Is my data safe using your zymbit module? Can I set it up to still be asked for a passphrase after reboot via remote ssh session? Your system sounds like what I am looking for.


Our root file system conversion/migration scripts don’t currently configure a backup password. However, this can certainly be accomplished with a little work. Or, as you suggested, you could certainly set up something like dropbear in the initramfs.

Another idea that you might be interested in that we are working on is the concept of one or more backup Zymkeys. In one use case, you could safely store a backup key in a safe place and, when the Zymkey was compromised via tamper detection, the backup key could be installed so that the data could be recovered.

To answer your larger question, we believe that if you configure a secure enclave with Zymkey tamper detection, Zymkey could certainly work for you.


Hey @Scott_of_Zymbit

So I just got the 4i and I want to secure my RPi using the luks encryption and allow for remote access using SSH and I got some questions for you.

  1. after installing the i4 (to the point where it blinks every 3 seconds), all I need to do to encrypt the entire sd card and save the master key to the i4 is run the command written in option 1 (with the relevent parameters)?
  2. after the sd is encrypted, how do I unlock it? will it open up just when the i4 will be connected upon reboot? is there a password I need to set and use upon login?
  3. using option 1 I need an external drive to be connected to the RPi, should it be empty? or with a raspi installed? and do I need to change configurations with the RPi so it will boot with the usb drive instead of the SD?
  4. after having the encrypted system, is it possible in any way to remotly connect to it? transfer files (from/to)?
  5. which distributions works best with the i4?

Sorry for all the questions I’m kinda new to linux/RPi.

Thanks, Ido.

  1. Run the SD card conversion script. BTW, this only encrypts the root file system, not the boot partition.
  2. The SD card conversion script is meant to boot an encrypted root file system in unattended mode, which is a use common use case for an IoT device. So, no password is necessary. You can prove this by popping the SD card with an encrypted rfs into a Linux PC and trying to mount the rfs. You will see that it will ask for a passphrase and if you try to read the sectors on the disk, they will be indecipherable.
  3. It would be better if the external drive was empty, but the entire device will be wiped out and reconfigured anyway.
  4. The encrypted root file system will behave just like it did before the encryption phase. As described in 2., it won’t be able to be read outside of the parent Pi.
  5. We support Raspbian Jessie and Stretch today. They both work well, but Stretch is more recent with a lot of improvements, so I’d concentrate on that distro.

No problems about the questions. That’s what we’re here for :slight_smile:


Thanks scott,

I got the encryption and zymkey working.
To test the encryption I tried to load the same SD on a different pi and after that failed I inserted the Zymkey to the new pi which resulted in a working pi. I just wanted to make sure that the reason it worked is becuase the Zymkey cut-2-lock tab was still intact so the module just paired with the new pi, which means that if I’ll cut it the system will be unlocked only if I’ll use the paired pi + the zymkey, right?


That’s correct. Once you cut the lock tab, the Zymkey cannot be moved to a different Pi + SD card.