Hi Mimi, Thanks for taking a look at this question. > > The problem is if the TPM dies, I need to recover my data (e.g. computer dies, > > and need to restore from encrypted backups). What I'm wanting to do is use a > > passphrase to decrypt data if the TPM is not available, to be used only in > > special circumstances. > > Encrypted keys can be updated so that they're encrypted with a different > user or trusted key, but the key type (user | trusted) can not be > changed. Allowing the key type to change would kind of defeat the > purpose of using a trusted key in the first place. Agree 100% that changing the master key type from trusted to user would defeat the whole point. But that's not really the request here. What is the harm about initially populating the encrypted key type with a known mounting passphrase instead of random data? For example, if the user has an existing ecryptfs file system they now wish to protect with the TPM? I don't think it's the kernel's place to judge whether I think my payload has been compromised or not, or if it is sufficiently random. I cannot think of any problem with this, so it seems to me, if it's not currently possible, this would be an area of needed improvement in the kernel to enable the proposed real-world use? I mean, as I currently understand it, the only way to use trusted & encrypted keys together involves randomly-generated encrypted keys, whose plaintext contents cannot be easily backed up since we cannot (and should not) be able to change the master key type. But now the potential for data loss if the TPM fails seems certain, thus making this feature an interesting academic exercise but useless in the real world where backups are needed when real-world hardware stops working. Am I missing something? To contrast, with LUKS or BitLocker for example, the decryption key for the block device can be recovered using multiple methods. For example, a passphrase can be used to decrypt the main key for the drive. Alternatively, one could conceivably use a different LUKS slot for use by the TPM, such as done by the tpm-luks project. So I can use TPM for day-to-day use, and then put the passphrase in a safe offline place in case I have to recover when the TPM stops working. I thought about the problem some more yesterday. I guess one could use tpm_unsealdata and then ecryptfs-add-passphrase by hand from the command line. But then the authentication token is stored in a regular user key, not within the protection of an "encrypted" key type. So the security is not as good because userspace can read the authentication token in plaintext at any time. Best regards, James Johnston -- To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
