From what I understand, this measure targets the ssh-agent program which holds the key in memory until some random ssh client ask for it.
With key shielding, the private key is encrypted using a prekey, and both are kept in the same struct in memory.
Which means that if an attacker dumps the whole struct, he should be able to decrypt the key using the prekey.
Are my assumptions correct ? If so, against which attack vector does it effectively protect the key ?
I think the commit linked in the post gives the details you’re looking for. It sounds like this is a mitigation against sidechannel attacks, and works by increasing the amount of work someone using one of those attacks would have to do. As you noted it doesn’t appear to protect at all against an attacker who can just dump any random memory easily.
The commit makes it much more explicit indeed, thanks for the pointer !
So to sum it up, the security model here is based on the fact that the prekey changes on each shield/unshield operation, thus resulting in an encrypted key in RAM that is changed on each call.
In order to retrieve the key, an attacker would have to dump the whole encrypted key + prekey in one go, which is currently impossible with the existing side-channel attacks.
This assumes that an attacker must also know the exact location in-memory of the prekey, all of which is higly improbable.
Ah, in-memory encryption with keys in memory.. Microsoft has been doing that since Windows 2000 but of course the reasoning back then did not have anything to do with speculative execution.
I just noticed that the Microsoft thing (according to Wikipedia) “relies on the Windows operating system’s ability to protect […] keys from compromise”. Which gives me an idea: maybe OpenBSD should make an interface for storing secrets in kernel memory (and retrieving for use and then zeroing again)? Then the secrets would be protected with KPTI (or whatever swear word OpenBSD called it) most of the time…