Is it possible to secure the boot partition when the root partition is encrypted?

[tal]

When trying to secure the files on a Raspberry Pi that’s being sent out into the field with sensitive data on it, it’s obviously nice to make sure no attacker can steal the box, and access those files. That’s where encrypting the root partition comes in. Encryption of a root partition on a system that’s supposed to be able to decrypt it on boot, while not letting an attacker access the decryption key is where the Zymkey comes in.

Unfortunately, even though the root partition is encrypted, the /boot partition is not. Using the boot partition, you can easily tell the kernel to open an interactive shell at boot by modifying the cmdline.txt file. This entirely bypasses the security provided by an encrypted root partition, and by Zymkey.

This has been asked before here: PI - Reset admin password, bypass Zymkey?

At the time, Scott looked into it, and was not able to prove this exploit was usable with whatever version of Raspbian he was using at the time. This exploit definitely works, even with the latest version of Raspbian. Here’s proof:

Hacking Into Encrypted Root Partition

Is there any way to secure the boot partition to prevent this exploit?
Will the physical tamper detection prevent this somehow? (I haven’t looked into it)

Even if physical tamper detection CAN prevent this, is that the main thing we’re relying on? Or is there another (better?) way to secure the boot partition?

I was thinking of perhaps compiling a custom kernel that won’t use the cmdline.txt file, but the problem is that the kernel itself is on the boot partition. The attacker can easily replace the kernel with his own, or with just the default one that does read the cmdline.txt file.

Edit: Quickly looking into the Zymkey’s tamper detection features, it looks like the main one is the perimeter detection. We can’t use the accelerometer detection because that sounds like that only works if your device isn’t meant to be moved when deployed in the field, which ours can be.

With the perimeter detection, I imagine it would be difficult to actually tie it to the SD card to know if it’s been removed. I think that’s meant to secure the box the Pi is in from being opened. If that’s true, then someone could potentially steal one of these boxes from the field, open them (tripping perimeter detect), and figure out exactly how it’s wired. Then they could steal a second box, and knowing how it’s wired inside, open it without tripping the perimeter detect. Or am I confused about how it works?

[Scott_of_Zymbit]

Hi @tal,

Thanks for documenting the init=/bin/sh exploit that has been known for some time. We agree it is a real exploit, and that is why we designed ZYMKEY4 with tamper resistance features to help mitigate this exploit. The post you have referred to was from 2017 and I was originally surprised to discover that the exploit seemed not to work for reasons we were not able to comprehend. I can confirm that we discovered at a later time that it had crept back in in a later update to the kernel.

However, as I also had mentioned in that post, tamper detection is still important in general.

Tamper Detect Has a Purpose

If you choose not to use the tamper-detect features of ZYMKEY4, then obviously you are choosing to expose yourself to this exploit.

Most professional users of ZYMKEY do choose to implement tamper-detect. They integrate it into their specific enclosure and system configuration. Here are some great examples of how customers have implemented tamper detect.

Perimeter Detect Circuit Examples

See Zymbit’s Documentation Site for the latest documentation on Perimeter Detect Circuit Examples.

Your post suggests that perhaps Zymbit should offer some standard “tamperware” accessory products too. Every customer has a different use case – enclosure, HATs, heatsinks, etc - which makes it difficult to come up with a “one-size fits all” approach to designing Tamperware. That said, we will take your feedback on board and come up with a couple of concepts that we will share for review by the community.

Secure Boot for Raspberry Pi

We agree that secure boot will reduce the vulnerability of any system, but it is not a replacement for tamper-detect, it is in addition to.

As we both know, secure boot is not available on the standard RPI products. Given this reality, Zymbit has been working on integrating a secure boot chain feature into our next generation security module. We should be able to share implementation details toward the end of the summer, but in the mean time I can tell you it will be derived from our new HSM6 product, and it will address the specific known exploit in your video.

Summary

Security is not an exact science. Everything is exploitable, it is just a matter of time and money. The logical response is a strategy of defense-in-depth: this requires multiple layers of hardware, software, firmware and silicon protections.

All Zymbit products follow this layered approach, starting with an outer layer of physical security, ending with a silicon based secure element.

Answers to Questions

Q: Can the Zymkey detect if the SD card has been removed?
A: No, but perimeter detect can be configured to prevent access to the SD card. When a tamper event is detected, the Zymkey will, when properly configured via the API, destroy all critical key material and the root fs will fail to be decrypted upon boot.

Q: Can you tell the kernel not to run a shell?
A: As you mentioned in your video, someone could easily replace the kernel and, while it is possible to configure initramfs to not permit the busybox shell to , that can be sidestepped as well. Even if you hack your own changes to the kernel (the last time I checked, this was not a kernel option in the kernel make) which would ignore the init option, someone could replace your kernel. Also, kernel updates would have to be done manually and the updates from the apt repo would have to be blacklisted.

Q: Or ignore cmdline.txt?
A: There are many reasons why this is infeasible, but the main one is that, since the GPU initially functions as a bootloader processor during boot and since Broadcom has not made the GPU compiler publicly available as well as the source code for the bootloader, one cannot simply compile their own code that would ignore cmdline.txt.

Q: Is it possible to encrypt the boot partition?
A: No because the GPU bootloader does not have encryption features implemented and, even in lieu of that, it does not know how to communicate with zymkey. The best solution, then, would be to implement an independent secure boot procedure. As mentioned above, we are currently working on adding this feature in a future product.

Q: Can you boot a custom kernel?
A: Of course, but as you mentioned, it would be trivial to replace the kernel image if one could gain access to the SD card.

[tal]

Thanks for your quick, and detailed reply Scott. That clears things up a lot. I’m glad you guys are working on an official solution to this, and we will be looking forward to its release.

I also now have a better understanding of the Perimeter Detect functionality, and its role in the overall security of the device.

Just to make sure there’s nothing else that can be done in the meantime beyond Perimeter Detect, maybe you can clear up one last thing for me. I mentioned this briefly, but the SD card on our Pi has some data that we are trying to protect when the Pi gets sent into the field. Unfortunately, the data can’t be stored remotely, and streamed to the Pi when it needs it, or anything like that. It must be stored on the Pi.

This data we’re trying to protect is stored in a single directory. We don’t necessarily need to encrypt the entire root partition, the majority of which is just Raspbian, which is obviously publicly available, and doesn’t need to be secured. We only care about securing that one directory where the sensitive data is.

Instead of encrypting the entire root partition, would it be possible to simply create an encrypted partition (either a real partition, or a single file that acts as a partition when you mount it), and use the Zymkey as the key that unlocks this partition at boot? Would it be any more secure than encrypting the entire root partition?

Note that the Pi NEEDS to use this sensitive data as it runs, so it does need to mount it at boot. I’m aware that if it was encrypted data that the system didn’t need to automatically mount at boot, it would be super trivial to just not have the key on the Pi at all, and require admins to provide the key when they interact with the system. Unfortunately, that’s not the case here.

I’m pretty sure I know the answer (just want to confirm it with an expert): no matter how you secure this encrypted partition, if the system mounts it at boot, and the attacker can login to the system (which they can with the exploit above no matter if the root partition is encrypted or not), the partition with this sensitive data will already be mounted when they login. Does that sound right? Or is there a secure way to do this?

Thanks

[piotr]

@tal sorry for digging out this almost 2 years old topic, but you’ve touched the subject I’m also trying to solve. I can see you didn’t have any reply to your last question - did you ever figured it out?