Contributed by Paul 'WEiRD' de Weerd on from the Sshould be a sshecret dept.
Damien Miller (djm@
) has just committed a new feature for SSH that should help protect against all the various memory side channel attacks that have surfaced recently.
Add protection for private keys at rest in RAM against speculation and memory sidechannel attacks like Spectre, Meltdown, Rowhammer and Rambleed. This change encrypts private keys when they are not in use with a symmetic key that is derived from a relatively large "prekey" consisting of random data (currently 16KB).
Attackers must recover the entire prekey with high accuracy before they can attempt to decrypt the shielded private key, but the current generation of attacks have bit error rates that, when applied cumulatively to the entire prekey, make this unlikely.
Implementation-wise, keys are encrypted "shielded" when loaded and then automatically and transparently unshielded when used for signatures or when being saved/serialised.
Hopefully we can remove this in a few years time when computer architecture has become less unsafe.
been in snaps for a bit already; thanks deraadt@
ok dtucker@ deraadt@
Many thanks to Damien and all the others involved for working on this improvement!
(Comments are closed)
By Peter J. Philipp (pjp) nospam@centroid.eu on https://centroid.eu
Hey, this is great. Is there a chance we'll see something of the likes in libc functions (section 3 of manual) as I'm sure other daemons could be using such concept to protect against this malware. Putting it into libc would be beneficial right? What do you think?
I'm thinking I want this functioning workaround in my daemon too...
Greetz,
-peter
Comments
By Peter J. Philipp (pjp) nospam@centroid.eu on https://centroid.eu
Just so that I make sense of the code, so I can implement this myself, does it arc4random_buf() the "key" over 16K but then digests that with a SHA512 and then uses the digest as the key when encrypted?
I'm looking near lines 1841 of sshkey.c of todays -current code.
Again kudos! This is wonderful!
-peter
Comments
By Darren Tucker (dtucker) dtucker@openbsd.org on
> does it arc4random_buf() the "key" over 16K but then digests that with a SHA512
Yes (the code refers to this 16 kbyte buffer as the "prekey").
> and then uses the digest as the key when encrypted?
More or less. The first 256 bits are used as the key for AES256 counter mode and the next 128 bits are used as the initialisation vector.
The current attack is has a relatively low bit rate and is non-deterministic. The intent is that the asymmetric private keys and AES key do not stay in memory long enough to be recovered by this rambleed attack, while the prekey that does it is large enough that it will be slow to recover, is very likely that one or more recovered bits will be in error, and has no structure to help an attacker.
One or more bit errors in the prekey will flip about half of the bits in the key and IV. The paper quotes an accuracy of 90%, so at the moment that's roughly 13k wrong bits over 131k bits of prekey. That should be implausible to brute force so long as the error rate is significantly higher than zero.
Comments
By Peter J. Philipp (pjp) nospam@centroid.eu on https://centroid.eu
Thanks for the explanation Darren.