Introduction
Raspberry Pi is probably the most known and used SBC. In 2019, zdnet said 30 millions Raspberry Pi were sold. Indeed, there are countless open source projects based on it. Even companies use it to build PoCs or even commercial products. However this board is also known to be one of the weakest SBC in the world and the current Raspberry Pi shortage may not be that bad.
A straw house
Well, to be honest, there is probably a huge number of SBCs that could claim this honorary title. However Raspberry Pi is probably the most used SBC so, I’m going to focus on it.
There are four main models of Raspberry Pi, all these boards are powered by Broadcom’ SoCs based on ARM cores. Raspberry Pi 3, exhibits a BCM2837 which embeds a Quad-Core ARM Cortex A53 (ARMv8) at 1.4GHz. What is interesting is that ARMv8 cores implement the TrustZone security extension. This technology provides a low cost and flexible alternative to a third party secure element or secure coprocessor by providing two virtual processors in a single hardware processor. This particular design allows to isolate security critical tasks (the Secure World) from other tasks (the Normal World). So one could wonder what could be the problem with that?
In fact, having two (virtual) processors does not help if the non secure one can access the memory and peripherals of the secure one. In the case of the BCM2837, Broadcom implemented the Quad-Core Cortex A53 as is without taking into account the particularity of the ARM TrustZone security extension. Indeed this extension requires putting security controllers on the memory and peripheral buses. OP-TEE (an open source secure OS for ARM TrustZone) documentation page dedicated to Raspberry Pi 3 clearly states that OP-TEE implementation is not secure on this platform and that it should be used only for educational purposes.
Root of what ?
Ok, most people don’t care about the TrustZone. This technology only provides a convenient way to isolate security critical tasks from the others. It does not guarantee that the software executed by the board is genuine nor does it prevent copying the sdcard content.
To do that, you have to use a secure piece of hardware called a Hardware Root of Trust. This hardware root of trust might be a small NVM memory embedded into a SoC which securely stores the bootloader of your device. Because nobody can tamper with the content of this memory, you can implement an algorithm which checks the integrity and the authenticity of a second stage bootloader. This second stage bootloader will do the same on the linux kernel, etc. This process is called a Chain of Trust.
If you want to decrypt an encrypted sdcard at boot using LUKS, you will have to store the encryption key somewhere. Because BCM2837 SoC does not embed such a little NVM memory and relies on an external unsecure EEPROM to boot then Raspberry Pi does not have root of trust. In consequence, you cannot hide an encryption key and cannot be sure that this key would be handled by trusted software. In short, if your boot process is automated (i.e. user does not have to enter a password), you cannot decrypt your sdcard without compromising the encryption key.
A glimmer of hope
Ok, Raspberry Pi does not have a Root of Trust but I could append a TPM to secure the whole thing, right?
a developer looking for reassurance
Well, yes and no. Actually, using a TPM on a Raspberry Pi may prevent cloning attacks. For example, you can use this TPM to store a certificate which allows you to authenticate your device when it is connecting to a remote service (e.g. video on demand). In this case, the sdcard content would be cloneable but the TPM not and therefore you will be able to exactly control how many devices can access your service.
With a TPM, sdcard content still cannot be protected against attackers given that the TPM is under the control of an untrusted software (as there is no Root of Trust on Raspberry PI). However there are some security products (e.g. Zimbyt ) sold on the market which are advertised to prevent sdcard cloning. Actually, the security of these devices relies on the fact that you cannot remove the sdcard without erasing an encryption key stored into a volatile memory. But, a determined attacker will probably manage to circumvent the countermeasure while tampering with a software stored into a SoC NVM is a real challenge.
Conclusion
Unfortunately, Raspberry Pi 4 is likely to be as weak as its predecessor so if you want to protect a software stored on a Raspberry Pi, put the board into a secure box that cannot be opened.
A simpler solution would be to use one of the numerous SoC built with security in mind. Feel free to contact us if you have any questions about how to choose a secure SoC for your upcoming embedded device.
TrustnGo markets products and services which can help you to secure your products.