We get a lot of companies who ask us to review the security of their product after they’ve designed it and are making plans to put it on to the market, but one of the things that scares us the most is when they ask, “I’ve got an IoT product based on a Rasperry Pi - how do I secure it?”
The Raspberry Pi
Don’t get us wrong, we love the Raspberry Pi. It’s an amazingly low cost, capable, single board computer with decent processing power, good software support and good connectivitiy.
We even use them ourselves, for example in our 3D printer server, as an evil WiFi access point, and as part of our internal research project to develop a low cost, high quality advanced IoT device attack platform (but more about that in a future blog post…).
They’ve also kick-started a whole new generation of engineers capable of interfacing between software and the real world and brought back a spirit of computer enthusiasm to the younger generation that was lost after the advent of the low cost home computer in the 1980’s.
And that’s just it: the Raspberry Pi was designed as an educational platform.
Yes, it is great for prototyping as it provides a familiar Linux interface and software support, good wired and wireless interface support and good support for external hardware devices (including some great Pi HATs).
Unfortunately there are also lots of reasons why in general it’s not great for commercial products, and specifically why it can’t practically be secured.
Securing a Raspberry Pi
Regulation and brand protection means that security has become an important part of responsible IoT product design. When Cerberus reviews IoT product security, we look for a number of things in an IoT device, including:
- Hardware security support
- Physical security
- Firmware / software security
- Compliance with regulations
Hardware security support
The Raspberry Pi System-on-Chip (SoC) has very limited hardware security support features. Although the SoC has its origins in Broadcom set-top-box chips (which have a very high security level), these features were omitted from the RPi, probably to save cost, as they are not so relevant to an educational platform and it also avoids export restriction problems to some countries.
The RPi does have a hardware random number generator but lacks any other hardware cryptographic accelerator. Although the ARMv8 architecture has instruction-level support for things like AES operations, these are optional and have not been included.
There is no support for a secure / authenticated boot and so there is no way to prevent software tampering. There is also no support for securely storing cryptographic keys or certificates, so there is no way to safely include an RPi product into a commercial network and ensure that the connection is not being spoofed.
Physical security
IoT devices, especially consumer devices, can often be easily physically accessed. Having a removable SD Card is not a good start, especially as the software is unprotected and not authenticated.
Firmware / software security
Linux distributions such as Ubuntu do have good software security practices, but without a hardware “root of trust” or independent authentication, the software is still open for tampering and persistent malware could be added.
Compliance with regulations
There is not enough of a foundational hardware security level to provide enough confidence that data could be adequately protected. This would not allow compliance with data privacy regulations such as GDPR and would most likely fall short of even the basic protections required by most consumer IoT product requirements such as the US Federal Trade Commission Act (FTC Act), never mind more rigorous requirements in some markets such as the EU and UK Medical Device Regulation.
Even if personal data is not involved, an RPi does not allow a safe, authenticated connection into a commercial network so the network would be at risk of attack through it as well as corruption of data and loss of intellectual property.
Our advice
First of all, if you’re approaching us with, “I’ve got an IoT product. How do I secure it?…”, then we can automatically tell that it’s going to be more work than you expect. You need to be considering the security requirements of your product from a very early stage. Even if you don’t include security in early prototypes to speed up development time, you should be aware of what needs to be added and by the time you get to production prototypes then security should be there.
There are lots of good web articles and frameworks (such as the IoTSF best practice guidelines) to help get you started and raise your security awareness.
Use a hardware platform that has adequate security features for the security level you need (and make sure you understand what level that is from the start!). For consumer products, the NXP i.MX7 and i.MX8 series are suitable if you need RPi-like processing and video capabilities. Often a much lower-power device can be used and there are some recent wireless connectivity chips with good security such as the Cypress PSoc 6 BLE series, Silicon Labs Blue Gecko 2 BLE, Nordic nRF5340 BLE or Espressif ESP32 for WiFi (NOTE: make sure the ESP32 is the latest hardware version).
You should also understand the security features of the hardware platform that you are using and make sure that you implement security correctly. This can be more difficult if you’re not familiar with security or cryptography, but there are ways to help:
- Use manufacturer-supplied tools to implement features such as secure boot and make sure to follow their guidelines for things such as key generation
- Use manufacturer-supplied security libraries that support the hardware (but be beware that these can sometimes use out-of-date versions of software that need patching)
- Ensure that you enable the security features in a platform (these are often configured by one-time-programmable fuses)
- Use reputable cryptographic libraries such as OpenSSL or Sodium and make sure you understand what they do
If you end up designing your own PCB (and there are often very good reasons to do this) then there are things you can do to improve the overall security such as burying PCB tracks on multi-layer boards. You can also consider adding a Hardware Security Module chip.
If your application requires high levels of security (e.g. for banking, critical national infrastructure or protected video content) then you also need to be aware of advanced security concepts such as side-channel and fault injection attack protection.
You need to also consider the manufacturing implications of security: how are you going to get cryptographic keys or certificates into a product safely, especially if you are manufacturing them in an environment that you don’t control.
All of these take time, effort and cost - so make sure that you factor them into your product development.
How can we help?
Cerberus can help with IoT product design review, IoT security audit, hardware and software security implementation and security testing (including advanced side-channel and fault injection attacks).
Please use the web contact form or email us for more information.