Author Topic: Code protection on Raspberry Pi  (Read 1265 times)

0 Members and 1 Guest are viewing this topic.

Offline Puffie40Topic starter

  • Regular Contributor
  • *
  • Posts: 53
  • Country: ca
  • Irregular Logic
Code protection on Raspberry Pi
« on: October 19, 2022, 04:10:33 pm »
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?
 

Offline DC1MC

  • Super Contributor
  • ***
  • Posts: 1880
  • Country: de
Re: Code protection on Raspberry Pi
« Reply #1 on: October 19, 2022, 06:57:55 pm »
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.

 

Offline Whales

  • Super Contributor
  • ***
  • Posts: 1898
  • Country: au
    • Halestrom
Re: Code protection on Raspberry Pi
« Reply #2 on: October 19, 2022, 09:01:59 pm »
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.
« Last Edit: October 19, 2022, 09:16:01 pm by Whales »
 

Offline bitwelder

  • Frequent Contributor
  • **
  • Posts: 962
  • Country: fi
Re: Code protection on Raspberry Pi
« Reply #3 on: October 21, 2022, 11:15:40 am »
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?

 

Offline Puffie40Topic starter

  • Regular Contributor
  • *
  • Posts: 53
  • Country: ca
  • Irregular Logic
Re: Code protection on Raspberry Pi
« Reply #4 on: October 31, 2022, 04:55:18 pm »
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?

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.
 

Offline capt bullshot

  • Super Contributor
  • ***
  • Posts: 3033
  • Country: de
    • Mostly useless stuff, but nice to have: wunderkis.de
Re: Code protection on Raspberry Pi
« Reply #5 on: October 31, 2022, 05:54:56 pm »
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?

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.

A hard-coded password is a security issue that has been seen quite often within the past few years. Aka manufacturers backdoor - quite fun for everyone who gets to know the password.
Otherwise, there's little protection if the bad guys gain physical access. Any encryption or whatever scheme that doesn't rely on some non-copyable feature within the raspi and securely measured booting with a gapless chain of trust is easily defeated by accessing the SD card.
Oh, and for rendering a CCTV controller inoperable when physical access is gained, I'd use a hammer or similar non-software tools.
Safety devices hinder evolution
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf