Hi, apologies if this is a really silly question but if you used your product to encrypt the system partition of a raspberry Pi and then the unit was stolen could you bypass the encryption/protection by doing the following
Remove the SD card and put in another computer
Edit the cmdline.txt and add init=/bin/sh to the end of the line.
add a new blank file called “ssh” in the boot partition, this enables SSH if you want
Put back into the Pi leaving the Zymbit connected, add keyboard/monitor and boot.
At the prompt type “mount -rw -o remount /”
type passwd pi
Enter new password
Thats it, you’ve in and the data is accessible because the Zymbit board is still connected.
Im guessing that is why you have the tamper protection which will disable the Zymbit but I can’t find the documentation to this and it doesnt look like its available on the standard product, only OEM. I did read that you will have a reset function for this but concerned this could be used by the person who stole the device.
I presume the Zymbit will rely on the onboard coin battery to detect tampering in order to disable the product else someone could simply remove the power and break into it.
Could you please provide advice and ETA when it’ll be in your standard product plus documentation.
That’s a great question. I’m not aware of such an exploit, but we’ll look into it and repost within the next 48 hours.
The tamper detection is currently an OEM feature, but we plan on doing a general release when the customer demand requires it. It’s mainly there for customers that need compliance with the more advanced levels of FIPS 140-2. The zymkey could be configured to respond to a tamper detection event in the following ways:
Only log and notify regarding tamper detection events.
Temporarily suspend execution until the unit can be serviced (TBD in future products).
The zymkey will destroy itself for FIPS 140-2 level 4 compliance. If the root file system is encrypted using zymkey, this will result in the pi being rendered useless as well.
On a related note, we’d be more than happy to discuss your application privately with you and address any concerns you might have if you’d like: https://zymbit.activehosted.com/f/5
I’ve run a few tests and am happy to report that I can’t get things to break in the way that you outlined. Even though tacking init=/bin/sh does produce a # prompt and does freeze the boot cycle, the user is unable to interact with initramfs with keyboard. Adding the file ssh does nothing as well.
Keep in mind that an encrypted root file system requires the pi to use an initramfs as an intermediary and the only way to interact with that is through the rescue shell.
Then, according to documentation, the only options for breaking into initramfs via rescue shell are to add something like break=mount to the kernel command line. However, I think that this might be an option that has to be added during the build of the initramfs. When I add break=mount (or any other option, like top, for that matter) to the kernel command line, I’m still unable to break into the rescue shell.
@Scott_of_Zymbit Hi Scott. I’m not sure what OS you were using back then to test this on, but this can easily be done on the latest Raspberry Pi OS from May 7, 2021.
Hopefully there’s some sort of fix for this, because this appears to largely make the fact that the root partition is encrypted irrelevant , as breaking in only takes a few minutes, and requires very little skill. Anyone who’s ever reset a Linux password understands the general process.