Would it be possible to perform rekeying entirely inside the Yubikey?

[plaidfinch]

I ask this without knowing exactly what APIs are exposed by the PIV mode used by age-plugin-yubikey, and whether this is possible even in principle:

In many threat models, the developer workstation is the weak link for compromise. If this were to occur, malicious code could in principle read the secrets out of memory while they are being rekeyed, because presently as I understand it rekeying works by decrypting (to a pipe) and re-encrypting. If it were possible to decrypt-and-encrypt in a single step entirely on the Yubikey without secrets ever being even instantaneously exposed in the clear, then this kind of compromise would not be possible. Do you have thoughts on (1) whether this is even an option in principle, given the API exposed by the Yubikey and by age, and (2) how difficult it would be to support, if so?

Thanks for this excellent project!

[oddlama]

Most likely this isn't possible due to the way the yubikey works generally. For rekeying you would require that the hardware key support an entirely new type of operation that does the full decrypt and reencrypt on the yubikey (operating on a transient pubkey that is transferred to the key). Broadly speaking, I don't think any hardware key will ever support such an operation, because it is not something that an average user would need at all.

But I have some thoughts regarding your threat model: Ususally you only need to rekey secrets one time, which is after creating the secret. So by definition you will have to make the secret material available on your machine in the beginning to encrypt it in the first place. I don't think the rekeying operation following this isn't going to make a big difference then. If an attacker had compromised your system at that time, they could already steal the secret when you first create it. Or am I missing something?

If you are really paranoid about it, you could always create, edit and rekey your secrets on an air-gapped machine.

[plaidfinch]

Thank you for the explanation, this makes total sense. I'm not (yet!) deeply familiar with the cryptographic operations already supported by the yubikey, so this is quite helpful.

Broadly speaking, I don't think any hardware key will ever support such an operation, because it is not something that an average user would need at all.

I agree in general, though I think the use case of performing key rotation of encrypted material inside a trusted enclave is one that has somewhat wide applicability.

Ususally you only need to rekey secrets one time, which is after creating the secret. So by definition you will have to make the secret material available on your machine in the beginning to encrypt it in the first place. I don't think the rekeying operation following this isn't going to make a big difference then. If an attacker had compromised your system at that time, they could already steal the secret when you first create it. Or am I missing something?

Suppose that secrets are to be deployed to machines which may from time to time be destroyed or created. Each time a new machine is created in place of its predecessor, a re-keying is required, because it will have a new identity keypair, freshly generated at instantiation. The creation and first encryption of the secret material ought to happen in all cases on an air-gapped machine, but if inside-the-yubikey rekeying were possible, the airgap would not necessarily be required to rekey a secret to deploy it to a new machine, as it would remain encrypted at all times from the perspective of the possibly-compromised developer workstation. With full hardware rekeying, if the workstation is compromised, then the adversary further needs to use that compromise not only to get access to the remote machine which will decrypt the secret (hardware SSH keys can help mitigate this), but also to exploit that machine in some way to exfiltrate the decrypted secret material. The thought is that if hardware rekeying were possible, it would raise the bar identically to the state of affairs where rekeying is done in an airgap, but with much better usability. Alas!

Feel free to close this issue out; maybe someday someone will make a device that supports this. (It occurs to me that it should be possible to do something like this with a Ledger hardware wallet...)

[oddlama]

The thought is that if hardware rekeying were possible, it would raise the bar identically to the state of affairs where rekeying is done in an airgap, but with much better usability.

Definitely!

Feel free to close this issue out; maybe someday someone will make a device that supports this.

I mean it's really just a firmware thing, so you could try to ask this in a related firmware repository for your favorite hardware key :)