• caglararli@hotmail.com
  • 05386281520

How to safely use dm-crypt as overlayfs uper partition?

Çağlar Arlı      -    19 Views

How to safely use dm-crypt as overlayfs uper partition?

Context

I'm working to make an embedded devices safe against physical access. (publicly accessible device and can be easily stolen)

I already made the following action :

  • secure boot is enabled on cpu, bootloaded is signed
  • Image is also signed and verified at boot
  • the base rootfs is protected against modification by dm-verity. Hash and salt are provided by u-boot with dm-mod.create= option, and stored in a signed file.

With that, i have a safe read-only system (I hope), and I now want to make it writeable only by the device itself. For that, I want to use a second partition, with dm-crypt on it. Key will be stored in the CPU OTP (fuse) and given by u-boot. This encrypted partition will then be used as the uper layer of an overlayfs, mounted as rootfs.

My concern

The dm-crypt volume will so contains all device specific information that include sensitive information (access key to remote servers) and /etc directory, including the shadow file. I consider dm-crypt safe enough to protect against flash extraction to read or edit this information.

But, as this is an overlayfs, clearing the whole uper partition will result in a factory reset.

Not a big issue at first, but this cause in fact a sort of big issue : the root password is then restored to the factory value (revert to original shadow file) and so the attacker can ssh to the device and read the encryption key. Then it could use it to decrypt the remaining data on the disk.
I could fill the disk with zero in case the encrypted volume is no more formatted at boot, but the attacker can still copy the encryption key and use it to decrypt a dump of my encrypted volume.

Actual question(s)

How could I prevent that ?
Is storing the key in the OTP bad ? Being able to change the key could solve part of issues, but where ?
Could LUKS help me for that ? If so, how ?

Bonus question

Also, could we imagine that an attacker could delete/zero a region of the encrypted partition (without knowing the key), so that in my overlayfs, only /etc/shadow is back to its original version ? Or does any modification will trigger an error ?