Sidechannel attack in-memory-protection the way OpenSSH does

[rugk]

Summary

There are many in-memory (hardware) vulnerabilities appearing that can be used to slowly "recover" data from other user's processes via side-channel attacks. E.g. Spectre, Meltdown, Rowhammer and Rambleed…

Now OpenSSH has decided to try to mitigate/protect against these. As per their commit https://marc.info/?l=openbsd-cvs&m=156109087822676&w=2.

Desired Behavior

As their commit message reads:

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.

Possible Solution

see above

As far as I understand it, it encrypts data with such a large key that cannot easily be recovered via a side-channel attack, because these attacks still have bit-errors that make it improbable that the whole key is recovered.

Context

Here is a German news article about that topic: https://www.golem.de/news/rambleed-openssh-entwickelt-schutz-gegen-sidechannel-angriffe-1906-142075.html

---

I am in no way able to judge whether this is effective/a good idea, but I wanted to make you aware of it, because I think (hope) the OpenSSH devs know what they do.

[phoerious]

We've had a branch in preparation for a while now where we do something similar.

[rugk]

Oh, that's great to hear. Would be interesting to know how that compares to OpenSSH's approach. I mean, I don't want to discredit your thoughts you put into this, but I guess OpenSSH devs evaluated their approach in a good way.

[droidmonkey]

To me it feels like "we are doing something!" kind of approach. It is saying we will use a large enough key that the probability of a low probability attack goes below the noise threshold. Eventually 16KB won't be enough or another method will be found that can defeat it. To me it is not worth chasing this issue. OpenSSH already has a very tight control of their memory and they do not run a GUI. When you add a GUI, Qt, and everything else we have going on you get into a much bigger situation.

[rugk]

Mhh, yay, possibly. But a mitigation is better than no mitigation. (if it does not introduce [big] risks/side effects)

And as @phoerious said, apparently you are also "doing something!", so I'll stay curious here…

[phoerious]

I wonder what they do with their "16kB" key. XOR it onto another 16kB string that contains the private key somewhere? Use some other stream cipher with variable-length keys? Hash it into a shorter key for a block cipher?

[rugk]

(obligatory reminder: you can read the source code, then you'll see 😜)
As far as I understood it though, they just keep it in RAM. The security comes from the fact that the key is sooo large that recovering it via side-channel memory attacks takes a very long time or is even impossible, because the attacks are not (yet?) good enough to not introduce bit-errors (bit-flip-like), so that the key cannot be recovered in total.

[phoerious]

Yes, but if they hash it into a shorter key, you could try to use the recovered information to find a collision and in the best case wouldn't need the full 16kB.

[conz27]

@rugk , wouldn't you just use a privilege escalation attack to become root and the just dump whatever memory you want? Why go through the trouble of side-channel, speculation attacks? Path of least resistance.

If the target code was running in VM in the cloud you are also susceptible to malicious admin attacks, where the Cloud Provider Admins can access the VM with super-user privileges and dump whatever memory they want. As @droidmonkey alluded to above, this is "security by obscurity".

The OpenSSH solution is better than nothing, but pales in comparison to the security offered by hardware like SGX.

[rugk]

wouldn't you just use a privilege escalation attack to become root […]? Why go through the trouble of side-channel, speculation attacks?

Because that is how Spectre, Meltdown, Rowhammer and Rambleed work. They are not privilege escalation vulnerabilities, they are side-channel vulnerabilities, where attackers can recover data due to the mentioned vulnerabilities in your CPU's or RAM's hardware etc.

[conz27]

My point is simply that no one is going to spend time breaking into a barred, reinforced window if the front door can be kicked down. Attackers use these more sophisticated speculative / cache-priming attacks against targets where easier attacks like key-logging or escalation to root are not possible or take a lot more time to exploit. Therefore, the proposed defence is only effective if the target is protected against the easier-to-exploit attacks.

[rugk]

Well… that was never a point I wanted to discuss and I also think it is not very helpful to now discuss it here.

[conz27]

I only made this point because if you look at this from the perspective of the Product Manager where you have limited resources and you have to get the maximum Return on Investment (ROI), what would make you pick this solution over others? Is the ROI high enough to justify addressing say 3%-5% of attempted attacks against KeePassXC? Wouldn't you look for another solution that does this and more?

With that said, there is technical merit to your proposal in that it's better than nothing at all - especially if target machines don't have other security features like SGX that can be leveraged. But 80% of desktop computers sold in the last 3-5 years by default already come with SGX and are based on Intel CPUs, so if I was in a Product Manager's shoes ... SGX seems to offer a much higher ROI given all the other security benefits that come with it, and it also offers protection from Meltdown and RAMBleed (Spectre has been shown to work, but much more difficult to pull-off in with SGX-encrypted RAM than with unencrypted RAM, RowHammer can be made worse by hiding the attack through the SGX-Bomb method).

[rugk]

Wtf… KeePassXC is not a company and does not want any ROI…

This gets off-topic…

[conz27]

Wtf… KeePassXC is not a company and does not want any ROI…

This gets off-topic…

If you had 1 person who specialized in security, is this the feature you'd have them work on? Company or not, it's called prioritizing your feature/issue backlog. I've said all I've had to say.

[rugk]

I guess the KeePassXC devs can prioritize themselves what is more important (and actually, what is easier to implement, what works on all platforms etc.).

[droidmonkey]

ROI is a very important concept, especially for volunteer-based projects. It's not about money, but time and attention. If I spend an hour of my time, will it benefit the majority of the users or just a handful? That is always how I look at developing features for KeePassXC.

[jeroenev]

But 80% of desktop computers sold in the last 3-5 years by default already come with SGX and are based on Intel CPUs.

So what about people with AMD cpu's then?

[conz27]

@jeroen7s , AMD has a similar feature known as SEV which comes with Secure Memory Encryption much like SGX - but not as isolated, from what I understand. The ideal solution will feature a plugin architecture which will choose the correct implementation following detection of the underlying hardware. If KeePassXC runs on an ARM device, it should also be implemented to leverage TrustZone.

I think that covers a majority of the existing landscape. When RISC-V matures, it can be addressed as well as it also contains SGX-like isolation.

[droidmonkey]

This will not be implemented