Products > Security

Code protection on Raspberry Pi

(1/2) > >>

Puffie40:
How would one protect the file system on a Raspberry Pi from unauthorized access?

I'm thinking LUKS encryption, but the RPi system needs to be autonomous with self-executing code.  Is there a way to configure the encryption so you don't need a password every time it boots up?

DC1MC:
There are exactly zero ways to properly protect the firmware of RPi of all kinds, none, as one can establish a chain of trust without hardware support.
Maybe the future versions will have something, as the EU directive mandates secure firmware on IoT devices.
Or maybe not, because in the end is mostly an educational platform.

Whales:
How much are you prepared to pay to protect your code?  What is the value you are expecting to lose if protection is broken (in terms of dollars)?  What is the likelihood of this happening?  How much money are your attackers likely to spend on getting your code?  Will a single breach by one attacker result in a small amount of damage to you (eg one user's files lost) or a systemic one (eg all of your proprietary secrets lost that are the same on all devices)?


All self-decrypting systems are flawed and limited.  Some hardware devices try and make it harder to extract the keys, but the keys still have to eventually end up in plaintext in the device for decryption routines to use them.

Providing the key remotely is an option, but it's also flawed because the target device can be modified to log the key.


In the end all you can aim for is making it slower and more expensive for an attacker to work out how to decrypt your code.  Combinations of hardware-level obfuscation and complex bootloaders will achieve this until they don't.  Implementing these is expensive, implementing them well and testing them well (ie attacking them yourself) is expensive, probably more so than a single attacker's costs.

Broadcom may already have some hardware obfuscation features in the SoCs on the Raspberry Pis, but I suspect you would need to engage them at a business level to get solid information.

A cheaper option is software-only obfuscation, of which there are many write ups on the internet with millions of different methods & justifications.  This will definately be the easiest method on a Raspi as you don't need any extra hardware.

Some companies provide pre-made obfuscation methods as a service.  These have different flaws, but they might meet your requirements in other ways (you get to shift blame to a 3rd party).

The best method is avoidance: don't have secrets on hardware that you don't physically secure and control.  Sadly this is often not feasible, but minimisation is still worthwhile.

bitwelder:
As already commented, it's probably a difficult if not impossible task.

But, generally what is your threat model? For instance:
Is the RPi physically going to be in a 'unsafe' place, at reach of somebody who could potentially tamper with it?
Or would it run in a safe place, but their users may find/cause a software bug and take over the control of the system?

Puffie40:

--- Quote from: bitwelder on October 21, 2022, 11:15:40 am ---But, generally what is your threat model? For instance:
Is the RPi physically going to be in a 'unsafe' place, at reach of somebody who could potentially tamper with it?
Or would it run in a safe place, but their users may find/cause a software bug and take over the control of the system?

--- End quote ---

The RPi is used as a centralized controller for a CCTV system. I cant think of any benefit of tampering with the system other then rendering it inoperable, but our main concern right now would be users attempting to reverse-engineer the code.  The system SSH is protected by a developer password that we do not share, but that does not protect from someone simply accessing the code through the SD card.

Navigation

[0] Message Index

[#] Next page