SoylentNews is people
SoylentNews
posted by
Fnord666
on Sunday June 23 2019, @04:26AM
from the next-up-is-bottom-channel-attacks dept.
from the next-up-is-bottom-channel-attacks dept.
Submitted via IRC for Bytram
SSH gets protection against side channel attacks
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).
[...] Many thanks to Damien and all the others involved for working on this improvement!
This discussion has been archived.
No new comments can be posted.
SSH Gets Protection Against Side Channel Attacks
|
Log In/Create an Account
| Top
| 6 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
BEWARE! People acting under the influence of human nature.
(Score: 2) by Rosco P. Coltrane on Sunday June 23 2019, @06:03AM (4 children)
At some point or other, the key must be decrypted and stored in RAM in plaintext for use. I suppose if an attacker manages to halt the ssh process at the right moment, they could be able to recover the key in clear.
(Score: 5, Insightful) by maxwell demon on Sunday June 23 2019, @06:37AM (2 children)
I suppose an attacker that is able to stop your process at will has already gained enough access to your system that side channel attacks are no longer needed to get at the key.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Sunday June 23 2019, @12:11PM
More like "sample it enough" - the RAM leaks aren't crashes and you can keep leaking, so if you detect one signal commonly and one un-, the un-common one is the real key.
That would be like scroll/wand ID'ing in nethack, for the geek analogy.
GP was right that a commonly used key will be in RAM enough during use that one of the RAM leaks could, in theory, still exploit it.
The rowhammer-type attacks will almost entirely be avoided by this. Silent caches higher up of course are their own buckets of bits.
(Score: 1, Interesting) by Anonymous Coward on Sunday June 23 2019, @12:14PM
PS - being able to hang a process one way or another, or more easily, to keep the need for the key in RAM, doesn't require full access either. Eg. maybe I send you a million cert decrypt requests, so that the value is in RAM more than it's not, because the CPU is starved while using the value for decryptions and it can't yet flush the operators.
(Score: 0) by Anonymous Coward on Monday June 24 2019, @05:24AM
Side channel countermeasures are all about increasing difficulty of attacks, because in most cases side-channel leakage is impossible to completely eliminate and therefore an attacker willing to spend unlimited time and resources on a particular side channel will get at the secrets. However, as with all security schemes, when it costs more for the attacker to break it than the stuff being protected is worth to anyone, then that is mission accomplished for the security scheme.
Nevertheless, effective side channel countermeasures are notoriously hard to get right as it is very easy to miss minor details which end up cancelling the effectiveness of the entire scheme.