Why the Raspberry Pi isn’t suitable for IoT

Let’s start by praising the Raspberry Pi: it has brought cheap computing to many, has inspired and enabled education and undoubtedly been a huge benefit. I use my own Pi daily, and we have often used its flexibility to perform hardware testing, from accessing UART to reading flash memory. So why do we not recommend developers use it from a security perspective?

It offers a flexible platform – you can develop a solution on a Pi 4, then just move that image straight to a compute module. But this rapid prototyping and development has led some vendors of smart devices to simply embed the Pi in their smart ‘thing’. Again, that’s a good thing as it has reduced hurdles to market entry, right?

Here’s the problem from a security perspective: the Pi doesn’t have a secure bootloader.

A secure boot is for two primary purposes: to prevent the device from running code that it shouldn’t, and by making it easy to encrypt storage and therefore to protect any secrets (whether intellectual property or customer’s data) from being extracted and reviewed.

For storage, the Pi uses either an SD card or flash memory. If you were to place your cryptographic keys on there, they are open to simple extraction. Pop the cover and pull the SD card, or pull out the Compute Module. Put either in a reader and you have everything you need to decrypt data and recover credentials.

When we looked at an early smart car charger, we found a normal Raspberry Pi 3. We simply pulled the SD card and read the entire filesystem, which contained far more than we expected.

Looking at a later car charger that used the Pi Compute Module, again it was trivial to pull the module and read the filesystem using a development board.

Also, because there is no integrity testing it would have been feasible for us to alter the filesystem, insert some malicious code, and then let the device run whilst our code allowed us full remote control over the device.

What should you be doing?

Use hardware intended for the purpose.There are plenty of great microprocessors on the market that offer a trusted execution environment, a secure enclave and good source of entropy to seed crypto operations. Don’t forget to configure them correctly, particularly around changing root passwords and setting logical fuses to prevent code readout.

There’s plenty more on this subject in our blog here and here.

Counter arguments

We’re often told that secure boot is pointless, as one can simply replace the hardware if one has physical access to the device.

This is true, but it fails to note that if the hardware is replaced, all the users secrets are still safe. If the victim’s Wi-Fi PSK is stored on it, in the case of an IoT device, it’s lost, as are credentials to services the device uses.

So yes, of course one can replace hardware, but that’s a different attack with different risks that are harder to mitigate.

Silly arguments

One charger vendor announced that they would continue to use the Pi as… paraphrasing a little, ‘other manufacturers also use it’.

This is a ridiculous argument. Everyone can learn and improve.

It’s also not a great commercial argument – the Pi CM isn’t cheap when compared to an MCU intended for the purpose, such as an STM32. Whilst it might be cheap to start with, as one doesn’t need a dedicated embedded systems engineer / developer, as one scales production the cost overhead of using the Pi becomes very significant.

Finally, regulation is likely to emerge that is based on good standards such as ETSI EN 303 645, which specifies the requirement for a secure bootloader in Provision 5.7-1. It would be very painful and costly to be forced to re-architect your product as a result of being unable to sell it in your target markets.