
How to handle Linux system integrity and secrets on physical product? - weeeee
I&#x27;m working on a IOT physical product that runs Linux and will be sold to customers. This product has a server with a SSD and contains source code in addition to secrets used to communicate with a backend.<p>The product is early on in the development stages and we currently use LUKS. Our technicians enter in the decryption password to unlock these servers at the beginning of the day.<p>When this product makes it to production, providing our customers with the decryption key is definitely a no-go. We need to guarantee that our source code and secrets are protected in addition to ensuring that the system hasn&#x27;t been tampered with.<p>What are some common ways to handle this in physical products? Any links or tips on this topic would be massively appreciated!
======
noodlesUK
This is a very hard problem to solve. It isn’t possible to prevent a well-
resourced determined adversary from getting into such a device (iPhones are
some of the most well locked-down devices in the world, and there are still
jailbreaks). For ordinary hardware you’re probably looking at using something
like a TPM, which can be used to decrypt drives based on the state of the bios
and hardware. Your best bet is to have trustworthy customers and strong legal
protections. If that’s not good enough, a TPM will be the next best thing.
Have a look at the red hat documentation on how to set up a TPM for LUKS. Also
be sure to set up secure boot correctly with a custom key and lock the BIOS.

[https://access.redhat.com/documentation/en-
us/red_hat_enterp...](https://access.redhat.com/documentation/en-
us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-
unlocking-of-encrypted-volumes-using-policy-based-decryption_security-
hardening)

Edit: I’m reading through your question again. In terms of secrets used to
communicate with a back end, it’s very very very important that the secrets
used for each device/customer are different, and can be revoked. If you’ve got
something like AWS access keys in there, don’t. Use per-user secrets that
aren’t the keys to the kingdom.

~~~
weeeee
Awesome, thank you for the detailed response! This all looks promising. It
appears that our mobo has a TPM connector and they sell a TPM module. I'll
look into this further!

------
alltakendamned
There's multiple steps involved in this, but some of the important ones are:

\- encrypt all the contents of your flash (e.g. with LUKS)

\- store the key in a crypto hardware module

\- Typically you'd then have a System on Chip which supports a secure boot
with a fused certificate key as hardware root of trust. Each subsequent phase
of the boot process needs to be attested by the previous phase to maintain
this chain of trust. Have the boot process pull the key for your Flash
partition and unlock the flash

\- Ensure your board is fully locked down, so no debug access, no boot
overrides, no sideloading, ....

\- make sure the key can't be accessed with the same process privileges as the
server running on the unit, for when someone inevitably pops it

\- select a SoC with protections against side channel attacks and fault
injection (glitching), not some 0.3 USD microcontroller

------
MasterIdiot
While there are some good recommendations here, I would defintely hire an
expert (either in-house or some external contractor) to design and test the
final solution.

