| > What would you say is the threat model that leads one to auto-encrypt sdcards? Jumping off of daemonologist's point, the most convincing model I could think of is one where you are consistently removing the SD Card, likely because you are swapping multiple SD cards back and forth. But this still seems bad! In that case your multiple SD cards all share the same decryption key (or I guess less egregiously all at least share the same physical vulnerability of that device's nonvolatile memory). > For a machine that needs to boot unattended, what would you do with disk decryption keys? This depends entirely on what you mean by unattended. Here's some candidates: 1. The machine has a network connection and you would like to boot it over the network. In that case you have a small unencrypted bit that handles the boot sequence and then pass the decryption key over the wire, store in volatile memory, and wipe on shutdown or logout. 2. The machine is regularly serviced/booted by an in-person operator. You give the decryption key or passphrase to the operator to decrypt and boot the machine. 3. The machine is meant to autonomously reboot itself due to e.g. error conditions. In extreme cases when the machine detects that there is a large probability of physical compromise, it shuts down. In this case for the former I would imagine some power supply, e.g. a backup battery, that keeps the volatile memory up when rebooting and in case of large probability of physical compromise there is a forced shutdown and/or wipe of the volatile memory. 4. An operator needs to periodically boot up the machine, but the operator should not be able to access any previous data the machine has recorded (data from the moment operator arrives forward is assumed leaked to the operator because e.g. the operator can just position their own sensor in front of the machine and collect data). In that case asymmetric encryption should be used and the encryption keys should be stored on the machine, but the decryption keys should not, effectively turning the machine into a write-only device from the operator's perspective. The only case I could imagine where you want the machine to boot unattended and you'd keep the decryption keys in nonvolatile memory on the device is if you want an operator to be able to boot the device without knowledge of the decryption key and also to be able to view historical data previously recorded by the device. But in that case there is no functional difference between that and a device that is unencrypted! In both cases you boot up the device without a password and voila all the data is in front of you ready to be read! And indeed that's basically what happened here (modulo the difficulties associated with the device being damaged). And in that case encryption seems like pure overhead for no real security benefit. |