News for hackers. Stuff that matters.

A comment on SSH gets protection against side-channel attacks. Parent comment

Re:SSH gets protection against side-channel attacks by reza_n on Friday June 21, 2019 @08:30AM (#20241895)
Yup, we added this feature to Varnish Cache a few years ago, random key encryption. It generates a random key at startup and encrypts all memory with it. Since this kind of memory is only resident for the lifetime of the process, it works. We stored the random key in the Linux kernel using the crypto API [0] just because its not safe storing any kind of keys in a memory space used for caching (Cloudbleed [1]). We then use the key to generate a per object HMAC, so each piece of data ends up with its own key, which further prevents something like Cloudbleed. Since we used kernel crypto, overhead was about 50%. If you stay completely in user space, its probably much lower.

[0] https://www.kernel.org/doc/html/v4.17/crypto/userspace-if.ht...

[1] https://en.wikipedia.org/wiki/Cloudbleed

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by thijsvandien on Friday June 21, 2019 @09:47AM (#20242426)
Could this be implemented at the OS level, i.e. whenever a proces launches, the OS generates a key that it will keep to itself and use to transparently encrypt all memory allocated by that process?
[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by mjevans on Friday June 21, 2019 @04:42PM (#20246164)
My first thought was to try to use 'containers' (cgroups) combined with the AMD secure memory extensions to achieve this type of isolation using as much off the shelf hardware as possible.

https://en.wikichip.org/wiki/x86/sme

https://www.kernel.org/doc/Documentation/x86/amd-memory-encr...

From the quick description it sounds like this provides a way of encrypting, per memory page, based on a symmetric key that is backed by some level of hardware encryption. It was not clear (in a quick read) how or where to specify the key by which an individual page is encrypted. That would be a critical component of comprehension with respect to identifying if this could be used to encipher individual processes and further isolate memory. It sounds like it might be possible to establish per-process memory isolation, which is probably the best level of security possible without resorting to entirely isolated hardware.

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by the8472 on Friday June 21, 2019 @04:43PM (#20246171)
Per-process keys aren't really possible because memory can change process ownership (vmsplice) or be shared across processes (fork, page cache, memfd). It might be possible for pages marked MADV_DONTFORK

Additionally a per-process key does not help against spectre style attacks where you would trick the process into speculating on protected memory.

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by simias on Friday June 21, 2019 @10:04AM (#20242573)
You'd probably want a hardware module to do that lest performance plummets. Memory controllers can already deal with ECC efficiently, adding a simple cypher on top of it should definitely be feasible.
[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by reza_n on Friday June 21, 2019 @10:04AM (#20242579)
Possibly, but memory is accessed using plain CPU instructions, so it would be hard to transparently encrypt all memory for an application at the kernel level. You do have virtual memory, but I dont think that could be leveraged for this. But who knows whats possible there, maybe if you align and address each memory value at the page boundaries and always force a page fault you could have a really poor implementation :)

Transparent disk encryption, not a problem since devices have filesystems which can implement encryption at that layer.

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by repolfx on Saturday June 22, 2019 @06:09AM (#20248867)
Modern Intel chips can encrypt memory on the fly without performance loss (SGX does this). However I think it's not exposed for non-enclave use. Perhaps it should be.

Note: inside the enclave there is a performance loss but that's due to MAC checks. If you just want encryption without integrity against tampering you don't need that.

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by zzzcpan on Friday June 21, 2019 @10:52AM (#20242984)
But that wouldn't prevent (mitigate) cloudbleed anymore as the problem is about isolating contexts within process boundaries.
[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by blattimwind on Friday June 21, 2019 @10:00AM (#20242531)
Technically yes, but practically no, because mediating all memory reads through the kernel would be very slow.

SME/MKTME add hardware support for this.

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by nickpsecurity on Friday June 21, 2019 @11:56AM (#20243638)
Yes. Most research makes CPU modifications since that makes the most sense. Sometimes they try to use OS-level techniques. Here's a survey showing some of each:

https://thayer.dartmouth.edu/tr/reports/tr13-001.pdf

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by peteretep on Friday June 21, 2019 @09:35AM (#20242342)
Just to clarify my understanding, the reason for doing this is so that random sampling / leakage of the contents of the RAM stops being useful, you need to specifically get the key (and then presumably a whole chunk of encrypted RAM to decrypt?)?
[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by reza_n on Friday June 21, 2019 @09:51AM (#20242457)
Yup. When something goes wrong in these kinds of applications, you sometimes tend to just randomly dump memory, which is a huge data leak. Or even worse, if someone figures out a way to force a data leak, then your are completely compromised. Having each piece of data with its own key and that key is a combination of data outside of the process address space drastically lowers the chances of data leakage and total compromise.
[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by Koffiepoeder on Friday June 21, 2019 @08:35AM (#20241923)
Could you point me to the relevant source code? Am highly interested to take a look at it during the weekend.
[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by reza_n on Friday June 21, 2019 @08:37AM (#20241942)
Closed source, write up would be here:

https://info.varnish-software.com/blog/introducing-varnish-t...

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by AnaniasAnanas on Saturday June 22, 2019 @09:07AM (#20249401)
No offense, I am genuinely curious, why would anyone use any closed source software for anything related to security after the Snowden revelations?
[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by ris on Friday June 21, 2019 @02:32PM (#20245161)
> Closed source

Ah, so we'll just have to trust you that it's doing anything at all, then.

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by dang on Friday June 21, 2019 @02:34PM (#20245182)
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

https://news.ycombinator.com/newsguidelines.html

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by vageli on Friday June 21, 2019 @04:58PM (#20246262)
> "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

> https://news.ycombinator.com/newsguidelines.html

Forgive me but can we not be skeptical of claims made about a commercial product?

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by dang on Saturday June 22, 2019 @12:09AM (#20247976)
Of course you can, and there are plenty of ways to do so that don't break the site guidelines. Cheap, snarky one-liners are not the way. If someone's posting about their own work, there's no need to be disrespectful.

It's also not helpful to post such a clichéd dismissal of what someone else says or their work. That's in the site guidelines too.

https://news.ycombinator.com/newsguidelines.html

[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by isatty on Friday June 21, 2019 @09:57PM (#20247565)
Isn’t his reply valid and an exception to the rule given the context?
[ Parent | on HN ]
Re:SSH gets protection against side-channel attacks by reza_n on Saturday June 22, 2019 @10:12AM (#20249642)
We have no problem sharing our codebase with customers, especially if there are concerns like this. Shoot me a msg if you are genuinely interested in anything you have read.
[ Parent | on HN ]