OpenSSH Now Encrypts Secret Keys in Memory Against Side-Channel Attacks
In recent years, several groups of cybersecurity researchers have disclosed dozens of memory side-channel vulnerabilities in modern processors and DRAMs, like Rowhammer, RAMBleed, Spectre, and Meltdown.
Have you ever noticed they all had at least one thing in common?
That's OpenSSH.
As a proof-of-concept, many researchers demonstrated their side-channel attacks against OpenSSH application installed on a targeted computer, where an unprivileged attacker-owned process exploits memory read vulnerabilities to steal secret SSH private keys from the restricted memory regions of the system.
That's possible because OpenSSH has an agent that keeps a copy of your SSH key in the memory so that you don't have to type your passphrase every time you want to connect to the same remote server.
However, modern operating systems by default store sensitive data, including encryption keys and passwords, in the kernel memory which can not be accessed by user-level privileged processes.
But since these SSH keys live on the RAM or CPU memory in plaintext format, the feature is susceptible to hacking attempts when the attacks involve memory read vulnerabilities.
Here's good news — it's not the case anymore.
The latest update from the OpenSSH developers resolves this issue by introducing a new security feature that encrypts private keys before storing them into the system memory, protecting it against almost all types of side-channel attacks.
According to OpenSSH developer Damien Miller, a new patch to OpenSSH now "encrypts private keys when they are not in use with a symmetric key that is derived from a relatively large "prekey" consisting of random data (currently 16KB)."
It should be noted that this patch just mitigates the threat and is not a permanent solution. Miller says OpenSSH will remove this protection against side-channel attacks in a few years when computer architecture becomes less unsafe.
Have you ever noticed they all had at least one thing in common?
That's OpenSSH.
As a proof-of-concept, many researchers demonstrated their side-channel attacks against OpenSSH application installed on a targeted computer, where an unprivileged attacker-owned process exploits memory read vulnerabilities to steal secret SSH private keys from the restricted memory regions of the system.
That's possible because OpenSSH has an agent that keeps a copy of your SSH key in the memory so that you don't have to type your passphrase every time you want to connect to the same remote server.
However, modern operating systems by default store sensitive data, including encryption keys and passwords, in the kernel memory which can not be accessed by user-level privileged processes.
But since these SSH keys live on the RAM or CPU memory in plaintext format, the feature is susceptible to hacking attempts when the attacks involve memory read vulnerabilities.
OpenSSH Now Stores Only Encrypted Keys in the Memory
Here's good news — it's not the case anymore.
The latest update from the OpenSSH developers resolves this issue by introducing a new security feature that encrypts private keys before storing them into the system memory, protecting it against almost all types of side-channel attacks.
According to OpenSSH developer Damien Miller, a new patch to OpenSSH now "encrypts private keys when they are not in use with a symmetric 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," Miller explains.
"Implementation-wise, keys are encrypted 'shielded' when loaded and then automatically and transparently unshielded when used for signatures or when being saved/serialized."
It should be noted that this patch just mitigates the threat and is not a permanent solution. Miller says OpenSSH will remove this protection against side-channel attacks in a few years when computer architecture becomes less unsafe.
Have something to say about this article? Comment below or share it with us on Facebook, Twitter or our LinkedIn Group.