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