...
And finally, contents of vault directory will be enabled for encryption (fscrypt encrypt /persist/vault), and pass a randomly generated hex key as the passphrase to protect the protector used for /persist/vault. You can treat this passphrase as the key which will unwrap the protector key, which will in turn unwrap policy key. Policy key is the key used for the actual encryption.
Unlocking on Genuine Boot-up
On every boot, /persist/vault should be unlocked for accessing its files and subdirectories. For this we need to feed the passphrase to fscrypt to unlock the policy keys and adding the policy keys to the kernel keyring. On platforms with TPM, TPM can be used to protect this passphrase, and TPM can unseal the passphrase against the validity of a set of PCRs - Providing a way to unlock the directory only if this is a legal, untampered bootup.
Protecting the Master Passphrase
For disk encryption to serve its purpose, the keys used for encrypting the data should be secure. For end-user devices, usually user input is sought to unlock the keys during bootup. (e.g. bitlocker password, PIN/fingerprint/pattern for smartphones). For Edge devices, this is not an option. On the other hand, we can’t store the keys on the hard drive, as anyone who steals the hard drive has the keys on the drive itself, which defeats the purpose.
One option is that TPM is used for sealing the master passphrase against a set of PCR values. But unless EVE supports complete measured boot(that measures all the components in the boot chain), we can't use PCRs reliably. Also, if we store passphrase in TPM, if the hard disk alone is physically compromised, the keys are still not available on the hard disk, so there will not be a way to decrypt the data on the disk, but if the entire device is physically compromised, TPM will automatically unseal the encryption key. Therefore a better option is preferred, possibly the one which renders the device data unrecoverable if the EVE node is not enrolled and visible to the Controller.
...
Protecting the Master Passphrase
The goals of protecting the master passphrase are:
a) Access to hard drive or the EVE node should not lead to access to the master passphrase. (Physical Isolation)
b) The encryption keys are made available once the Identity of the EVE node is established and possibly when the node meets a certain software integrity criteria (Node Authentication and Attestation).
c) A capability to revoke passphrase from Controller, in case the EVE node is found to be compromised, which will render the contents of the drive permanently unrecoverable (Key Revocation)
Controller-Managed Key with TPM
On EVE nodes with TPM devices, TPM can be used for sealing the master passphrase against a set of PCR values, so the master passphrase will be unsealed only when the PCRs values indicate that there is no change in the software state. Once EVE supports measured boot(that measures all the components in the boot chain, and storing its measurements in the TPM PCRs), we can start using those PCRs to seal the master passphrase. Also, if we store passphrase in TPM, if the hard disk alone is physically compromised, the keys are still not available on the hard disk, so there will not be a way to decrypt the data on the disk, but if the entire device is physically compromised(which is more likely than just the drive being physically compromised), TPM will automatically unseal the encryption key.
Therefore, we can enhance this and arrive at a better model for EVE nodes with a TPM: Use a key from TPM and a key from Controller to arrive at the master encryption key. It is the best of both of the above approaches put together. With this, even if the entire EVE node is physically compromised, one can not access the complete encryption key unless the EVE node is authenticated and attested by the Controller, which can be advised to flag a given EVE node as black-listed, and hence revoke it's authentication and hence, the encryption key as well.
Physical Isolation: Yes
Node Authentication & Attestation: Yes
Key Revocation: Yes
Controller-Managed Key without TPM
On devices without TPM, we do not have a way to measure the software state or seal the encryption key outside the hard drive. The only other place for creating and storing the keys is the Controller. Therefore for EVE nodes without TPM, it is proposed that encryption keys will be stored in the Controller. After device registers and gets UUID from the Controller, it would fetch either new encryption key(if booting up for the first time) or unlock the encrypted directory with the key fetched get the stored encryption key from the 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:
...
After this EVE will either setup the directory for encryption (if booting up for the first time) or unlock the encrypted directory with the key fetched from the Controller.
Physical Isolation: Yes
Node Authentication & Attestation: No
Key Revocation: Yes
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. The frequency can be either on-demand, or a configured time-interval which can be configured for each EVE node from the Controller. However care needs to be taken to not miss any rotation from Controller, as this will render the whole data locked forever.(i.e. Controller moved from key 2 to key 3, but EVE is yet to process the last config change from key 1 to key 2)
...