0

On my embedded Linux product, I have done the following:

  • Disable root
  • Remove SSH from the final product

Normally, a non-root user (used for development) can do lots of damaging stuff, such as editing bootup scripts and overriding files. The assumption is that if SSH is disabled, nobody can access the file system, and we are safe (I am disputing this claim, because if it is true, why do we have to remove root access in the first place? Just remove SSH and we are done)

  1. Are there any other ways to access the file system that I am not aware of? Perhaps by soldering directly to the NAND flash, or a different protocol.
  2. Are my security measures sound, or naive? If not, any better suggestions from the community?
  • I assume your threat is local access to the device? – schroeder Jul 12 '18 at 8:27
  • Correct. Owners of the embedded device trying to hack for licensed functionality. – Ryuu Jul 12 '18 at 8:55
  • 2
    @Ryuu when you sell a product to a customer, that customer then owns that hardware and subsequently has the inherent right to modify it or any code on it. Not you or your company. They have the right to hack it if they want to. Also, they'll find a way. There's always going to be a way in. – Anthony Russell Jul 12 '18 at 13:06
3

You have to check for all ways to access the device. For example:

  • Is there some sort of serial interface that already has a console on it
  • is there some serial interface that can be used to access the boot loader
  • is there some serial interface that can be changed to have a console on it
  • can the flash chip be accessed and changed directly (usually yes, you can only make it harder)
  • are there any services listening on the network interface that can be used to change the filesystem
  • are there any services listening on the network interface that have bugs which can be used to change the filesystem

apart from all that, it is always possible to directly change the (flash)memory contents, if they are not encrypted. You can make this harder e.g. by drowning the flash chips in lots of resin (make sure they don't overheat) but that just makes it harder.

The most secure way is to use hardware that has support for encryption in the CPU/MCU and secure storage for the encryption key. This way, the flash storage is always encrypted and can't be changed. For even more security, the RAM contents also have to be encrypted.

This probably discourages most attackers. Still, modern game consoles use quite similar security measures and all of them got hacked eventually (due to bugs in the implementation/hardware).

The only thing you can do is decreasing the attack surface until it is not economically feasible to break the security. If redeveloping the device from scratch is cheaper than attacking yours, there is not much point in securing your device more.

  • +1 for mentioning game consoles and the fact that all "you can do is decreasing the attack surface until it is not economically feasible to break the security". In fact, OP tries to implement some sort of DRM, as he/she want's to protect code/functions which are delivered to the customer, but should not be accessed without buying/licensing them. The device cannot be trusted, as the customer could tamper with it. So it's indeed a matter of when, not a matter of if. – GxTruth Jul 12 '18 at 10:46
  • Are there examples of tools that help change the contents of the flash? Encryption is taxing in a low powered device, so it sounds like this is the weakest link. – Ryuu Jul 12 '18 at 12:12
  • @Ryuu what do you mean tools? You can write to the flash memory, so nothing stops others from doing the same. How exactly that works depends on the specific hardware you are using. – Josef Jul 12 '18 at 12:38
  • "This way, the flash storage is always encrypted and can't be changed." - Not quite true. At best, the entire chip can be reverted to previously dumped contents, at worst each bit can be flipped individually. – AndrolGenhald Jul 12 '18 at 13:41
  • @AndrolGenhald I assumed proper authenticated encryption. – Josef Jul 13 '18 at 6:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.