...
On the platforms, where there is no TPM support, we need to store the key on the hard disk. TBD: Should we even support disk encryption on platforms without TPM?
Suggestion: If we encrypt, we always encrypt, tpm or not.
- TPM device: as above, depends on PCR registers (given the constraints in the earlier comments)
- Non-TPM: Encryption key stored in Controller.
At initial startup, a device registers, cloud generates an encryption key and sends it. The device does not persist this key, but stores it in memory. At next boot, device retrieves the key from the cloud via an API call. At first blush, this doesn't do much, since the device's auth-to-the-cloud-identity is still based on something on the local disk/flash. It does, however have the following advantages:
- Stealing the disk/device is useless since it is useful only against the controller
- We can strengthen the device-to-controller auth by adding the serial (we already do that at registration), which won't be known unless someone steals the entire device, or add something hardware specific that is read from the firmware on every boot and auth, not just first-boot/registration.
- Most importantly, we have a "kill switch". It doesn't prevent the disk from being stolen, but it adds an extra step, one that connects to a controller space (the Controller), providing a place to deactivate a device (or even a whole class).
Master Key Rotation
Fscrypt supports changing the protectors password without re-encrypting all the files in the encrypted directory. If required, we can change the protector password, if we think that protector keys might have been compromised. In future we can consider rotating these protectors periodically (say every week) as a precautionary measure to enhance the security.
...