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!
Related Stories
SSH key forwarding is to be avoided when possible. When it is not possibile to avoid, it is a good idea to limit what gets forwarded. Software developer Vincent Bernat describes one way by putting a simple shell script wrapper around the SSH client to provide a session with a unique, ephemeral key agent.
ssh-agent is a program to hold in memory the private keys used by SSH for public-key authentication. When the agent is running, ssh forwards to it the signature requests from the server. The agent performs the private key operations and returns the results to ssh. It is useful if you keep your private keys encrypted on disk and you don't want to type the password at each connection. Keeping the agent secure is critical: someone able to communicate with the agent can authenticate on your behalf on remote servers.
ssh also provides the ability to forward the agent to a remote server. From this remote server, you can authenticate to another server using your local agent, without copying your private key on the intermediate server. As stated in the manual page, this is dangerous!
Perhaps another approach would be to embed the wrapper in the ProxyCommand configuration directive, thus obviating the need for either a shell alias or shell function.
How and why have soylentils had to deal with SSH agent forwarding?
Previously:
(2019) How SSH Key Shielding Works
(2019) SSH Gets Protection Against Side Channel Attacks
(2018) Default OpenSSH-Portable RSA Private Key Encryption is Poor
(2017) SSH vs OpenVPN for Tunneling
(2016) Upgrade Your SSH Keys
(2015) Why Aren't We Using SSH for Everything?
(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.
(Score: 0) by Anonymous Coward on Sunday June 23 2019, @02:39PM
now we know what caused those holes in the oil tankers: it was a time-bubble materializing with a human inside bringing back the latest future ssh-hack-code from john connor, keeping the future sky net from starting WW3!