LUKS Encrypt Your Root File System on Raspberry Pi


#41

@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.


#42

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 mk_encr_sd_rfs.sh 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)?


#43

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 (https://github.com/BertoldVdb/sdtool). 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.


#44

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.

Regards,


#45

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.


#46

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?


#47

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.