You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I understand (from reading the source, as well as having worked with TPM 2.0 itself) the plugin generates identities as TPM-bound NIST P-256 keys, used with ECDH to wrap the age session key.
Assuming this is the case, encrypting to a TPM recipient should only require knowledge of that P-256 point/pubkey, yet age-plugin-tpm attempts to access /dev/tpmrm0 and fails if permission is denied. This is an issue in my usecase in two different ways:
I'm managing secrets in a distributed environment, so encryption might be done on a system which does not have access to the recipient's TPM, or any TPM at all ;
unprivileged users should be able to introduce new secrets (i.e. encrypt) without being granted decryption privileges, let alone full access to the TPM device.
The text was updated successfully, but these errors were encountered:
nbraud
changed the title
age-plugin-tpm requires access to the TPM when encrypting a secret
age-plugin-tpm requires access to the TPM when encrypting
Dec 27, 2024
I didn't know about the proposed p256tag keytype, but I agree waiting for upstream to adopt it might be the best solution long-term. There doesn't seem to be much activity on that PR, but hopefully it can happen soon.
As far as I understand (from reading the source, as well as having worked with TPM 2.0 itself) the plugin generates identities as TPM-bound NIST P-256 keys, used with ECDH to wrap the age session key.
Assuming this is the case, encrypting to a TPM recipient should only require knowledge of that P-256 point/pubkey, yet
age-plugin-tpm
attempts to access/dev/tpmrm0
and fails if permission is denied. This is an issue in my usecase in two different ways:The text was updated successfully, but these errors were encountered: