Hi Scott, thanks for your quick answer. I’ve understood the dev and production mode, but whats with the explanation above how the encryption key is released. Zymkey operational status is “secure” or “dev_secure” Do I have to do something to get into one of these states?
Encrypting Your Root File System on Raspberry Pi - using LUKS & dm-crypt
It looks like we have a bit of mis-documentation here. There is no “dev_secure” state. The state “secure” means that if the tamper detect inputs have been configured for “self-destruct” while in production mode, the tamper loop must be closed to be considered “secure” otherwise, the Zymkey will no longer work.
This script has bricked my Pi… the scrypt finished after around an hour with a final “done”. I rebooted and now I’m welcomed with a kernel panic.
@josenovera
which script - URL
which PI
which SDCard
which power supply (it matters because if the Pi is under-powered it slows the CPU and can take much longer to encrypt your sd card - an hour is excessive, it should take 5-10 minutes).
Thanks for the quick response Phil.
This the raspberry pi hardware that I’m running: https://www.amazon.ca/gp/product/B07BD4R3WY/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1
The script that I ran was:
curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_sd_rfs.sh | sudo bash -s -- -x /dev/sda -m 7
/dev/sda being my usb key and assuming that /dev/mmcblk0p7 is the linux partition. Decided on 7 because fdisk -l looked very similar to user ‘wiill’'s output:
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 2476562 2468371 1,2G e W95 FAT16 (LBA)
/dev/mmcblk0p2 2476563 31116287 28639725 13,7G 5 Extended
/dev/mmcblk0p5 2482176 2547709 65534 32M 83 Linux
/dev/mmcblk0p6 2547712 2682879 135168 66M c W95 FAT32 (LBA)
/dev/mmcblk0p7 2686976 31116287 28429312 13,6G 83 Linux
the instructions say that it should take around 40 minutes so I thought it was working properly…additionally no errors occurred during the process. Also, the zymbit was not permanently paired if that matters.
When you say the “zymbit was not permanently paired” do you mean the lock tab was not cut ?
Yeah that’s right, it was still in development mode.
Any idea on what could have gone wrong? Is there another step when the script finishes? Does it matter what distro is installed on the PI?
Yes it matters which distro you are using.
We recommend i) Stretch ii) Buster
Which software distribution are you using ?
I’m using Stretch (raspbian v9)
After several restores I’m able to run the script without bricking it, but phase 2 never starts. It keeps rebooting back into the SD card with the zymbit flashing quickly as if it was not paired, which makes sense since the script stops zkifc from running.
Any way to get this working??
It sounds like you are running NOOBS. If that’s true, we’ve had issues with other customers that have tried to get the encrypted volumes running on NOOBS configured SD cards. Since we have only tested this script on the non-NOOBS images (e.g. Raspbian Buster Lite or Desktop), we have recommended that our customers use those images. This step has always solved their problems.
That was it - it worked when running the scripts with only 2 partitions and not the 7 that NOOBS uses.
Cheers
hi all,
my zymbit seems to be unstable. i dont know why. sometime the blink is like before binding sometime the blink is ok and in bind condition. (blink every 3 second).
its because of the power voltage goes under 4.75V? because the red led on my rpi stop blinking.
i try the sd encryption but fail. zymbit not found.
i hope can get some help
saufy
Yes it sounds like power could be the cause of your problems. Let me explain:
-
If the red LED on the Pi is blinking, or not illuminated, then your Pi is likely not getting enough power and you will need a better power supply. (“better” meaning more power capacity). Learn About Power Quality on Pi>
-
During encryption, the Pi generally consumes a lot of power (its compute intensive to initially encrypt the file system). If the power quality is poor, then the Pi can behave in ways that will slow or completely stall the encryption process:
a) when power quality is marginal, the Pi can reduce its clock speed to reduce power consumption - this slows the encryption process, dramatically
b) when power quality is poor, then Pi can reset, breaking the encryption process entirely.
Try a better power supply, it will likely fix your issues.
hi phil,
yes. i bought new adaptor and the process progressing. around 40 minutes i take the second option to convert external drive to LUKS drive.
i reboot but hang at initramfs.
cryptsetup: WARNING: cryptfs: ignoring unknown option ‘timeout’
UUID:xxxxxxxxxx
i remove the usb and the same happening.
help me. thnks
saufy
Hi,
I’ve been testing disk encryption using a Zymkey 4i with a Raspberry Pi 4B and Ubuntu 18.04.4 64-bit. There are a couple differences in the boot process for Ubuntu that prevented the current scripts from working as is.
-
Ubuntu doesn’t store the kernel command line string in cmdline.txt. Instead the script needs to check the cmdline option in config.txt to get the correct file. Affects both mk_encr_sd_rfs.sh and mk_encr_ext_rfs.sh.
-
Ubuntu hangs during boot up when using root=PARTUUID in the kernel command line, however will boot ok when using UUID. Affects mk_encr_sd_rfs.sh.
Below are modified versions of the scripts that implement changes for these issues:
Where(path) are the encrypted keys located in the boot partition ? If I load the boot section of SD card on a computer, where would I find them ?
If I understand correctly, the encrypted keys should be present somewhere in the boot partition, since the bootloader needs to present it to zymkey module to get the plaintext keys.
The encryption script makes an initrd for booting into the encrypted root file system. The encrypted LUKS key is stored in the initrd as well as the target root file system at /var/lib/zymbit.
@iesplin
Thanks for chasing that down!
I think that things may have changed internally with Bionic because the PARTUUID method was known to work in the early days. Just goes to show you how quickly the landscape of Linux development development changes…
Anyway, we have tested your scripts on Ubuntu as well as Raspbian and have verified that things work. Your modifications are now available publicly.