Hardening a Raspberry Pi

Recently I was asked for advice on securing Raspberry Pis, which somebody intended to use as the basis of a simple embedded device.

This is a frequent question, but unfortunately strong solutions don’t exist.

Securing the hardware

The fundamental issue is that there’s no way to stop a reasonably determined attacker from extracting or modifying the operating system and application, both of which are stored pretty much in the open on an SD card.

The only option you have is to make it difficult, but there’s no way to actually prevent it. Some microcontrollers can be configured to only load signed code and similar things, but unfortunately not the Raspberry Pi.

You can have physical security an un-openable (or rather, hard to open) enclosure, glue the SD card in place with epoxy resin, or similar shenanigans, but clearly that will only deter amateurs, not stop an actual determined attacker.

Hermetically closed cases may also present a problem to transfer heat away from the CPU.

Securing software or communications

If you have code that will phone home, you have another problem to consider: can your infrastructure trust the data coming from the devices in the field?

Generally speaking, once a device is in the customer’s hands, you’re out of luck. Much like with client-side Javascript, the best approach is to treat all communication from the device as hostile. Sanitise and validate everything, don’t trust the data, expect attacks. Your edge devices are the enemy.

By all means take steps to discourage tampering:

• use Tripwire or similar systems to discover somebody fiddling with the OS image
• perhaps de-authorise devices once they inform you of a tampering attempt
• obviously, use encryption (ideally with certificate pinning to thwart man-in-the-middle attacks)
• sign the communication with your central server, and include aspects of the SD card contents (e.g. your actual program binary) in the hash (so that modified SD card content won’t be able to create valid signatures)
• you might even consider including aspects of the hardware (e.g. MAC address) in data signatures, so you can detect other forms of tampering – while remaining mindful that MAC Addresses can be spoofed
• while considering all of the above, be mindful that the stricter your security becomes, the easier it will be for someone to create a DoS for your clients by somehow disturbing the validation mechanisms; also the management effort, as well as the risk for mistakes on your end increase

But be aware that none of these measures will prevent tampering at all – they just make it more cumbersome to attack you successfully, but won’t stand up to a competent person.