Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH gets protection against side-channel attacks

undeadly.org

Post reply on HN
Print view View original

71–80 of 166 posts

Re: SSH gets protection against side-channel attacks

#71

Post by AlgorithmicTime »

thijsvandien wrote: post #56
reza_n wrote: post #15

Earlier quoted context omitted.

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 the…

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?

Wouldn't this be functionally similar to AMD's SEV and SME?

https://developer.amd.com/sev/

Re: SSH gets protection against side-channel attacks

#72

Post by reza_n »

thijsvandien wrote: post #56
reza_n wrote: post #15

Earlier quoted context omitted.

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 the…

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?

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.

Re: SSH gets protection against side-channel attacks

#73

Post by ncmncm »

dangerface wrote: post #39
yjftsjthsd-h wrote: post #5

Unfortunate that there's no commentary on performance impact. It's symmetric encryption on a few kB, so probably fast, but I'd like to have numbers.

It's not mentioned because it's irrelevant. There is no security / performance trade off for a secure program. It's secure or its not.

Degree of security is routinely measured by expense to overcome it.

Re: SSH gets protection against side-channel attacks

#74

Post by cesarb »

simias wrote: post #67
Koffiepoeder wrote: post #10

RAM encryption for sensitive data is overlooked in so many applications, even "highly secure" applications like veracrypt [0] only recently started adding it. In my opinion server-applications of all sorts should encrypt their private keys by default; this makes cold-boot attacks and other memory-escape attacks so much harder, since now two totally unrelated memory chunks have to be combined in order to retrieve the…

I've tried implementing a couple of (toy) password managers over the years and dealing with private keys is genuinely complicated. Even something as trivial as making sure that the memory gets zeroed correctly when you discard the key is trickier than it seems. Compilers these days are very good at detecting "dummy" memsets to memory that's never read afterwards and optimize them away. You have to use some dirty tric…

> Compilers these days are very good at detecting "dummy" memsets to memory that's never read afterwards and optimize them away. You have to use some dirty tricks to get the compiler to do what you want (copious amounts of volatile helps).

Or you can use explicit_bzero(), which is designed for that use case.

Re: SSH gets protection against side-channel attacks

#75

Post by foobar_ »

gnomewascool wrote: post #45
foobar_ wrote: post #34

Take my money!

Great! You can donate to OpenSSH[0], whose "funding is generally done via the same donation framework" as the rest of OpenBSD, to which you can donate either directly[1] or via the OpenBSD Foundation[2]. If you're serious about donating obviously please check that these links are legitimate and I'm not a scammer. (I'm not affiliated with OpenBSD in any way.) [0] https://www.openssh.com/donations.html [1] https://www.…

50$ donated! I hope that's good for some beers :)

On a sidenote paypal donation took way too long. If anyone is interested in making open source donations simpler feel free to ping me.

Re: SSH gets protection against side-channel attacks

#76

Post by sjwright »

java-man wrote: post #54
Koffiepoeder wrote: post #10

RAM encryption for sensitive data is overlooked in so many applications, even "highly secure" applications like veracrypt [0] only recently started adding it. In my opinion server-applications of all sorts should encrypt their private keys by default; this makes cold-boot attacks and other memory-escape attacks so much harder, since now two totally unrelated memory chunks have to be combined in order to retrieve the…

RAM encryption is a feature in my password manager (java): https://github.com/andy-goryachev/PasswordSafe/blob/master/s... Curiously, RAM encryption, and its relative - clearing secrets from memory when not in use - cannot be added to the Bouncycastle library because they use java BigInteger (unless reflection is used of course).

How do you guarantee actual clearing of physical memory in a garbage collected VM?

Re: SSH gets protection against side-channel attacks

#77

Post by mehrdadn »

simias wrote: post #7
yjftsjthsd-h wrote: post #5

Unfortunate that there's no commentary on performance impact. It's symmetric encryption on a few kB, so probably fast, but I'd like to have numbers.

If I understand correctly it's effectively a one-time constant cost when setting up an encrypted connection, so it should be negligible unless you have a use case for setting up many extremely short-lived connections.

SSH has multiplexing [1] specifically to speed up multiple connections... would be interesting to know whether it incurs the overheads once vs. on every connection.

[1] https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

Re: SSH gets protection against side-channel attacks

#78

Post by mehrdadn »

> 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.

It seems the real mitigation isn't the prekey size, but the temporal sparseness of the symmetric key -- since I would've imagined attackers would just try to obtain the symmetric key rather than the prekey. Weird to see they they didn't even mention this... I imagine attackers would try to find a way to get the symmetric key to stay in memory for a while.

Re: SSH gets protection against side-channel attacks

#79

Post by whatshisface »

bigato wrote: post #30
hvidgaard wrote: post #28

Earlier quoted context omitted.

Given the nature of this software, it's natural to have mitigations against side channel attacks. They happen multiple times, and will happen in the future, no matter how secure we believe the hardware is. With that in mind, it's probably the better strategy to use slower and more complicated algorithms to protect the user. This would mean that when a side channel attack becomes known, if the algorithm already protec…

Side channel attacks are only possible because the hardware is currently vulnerable. They are not a law of nature. Once you solve the vulnerability at its root and it becomes physically inexistent, and there's no more running hardware in the market that has such vulnerability, it would make no sense to keep such software mitigation.

Businesses still run mainframes from the 1970s - so, get ready to wait a century.

Re: SSH gets protection against side-channel attacks

#80

Post by Dylan16807 »

blattimwind wrote: post #69
yjftsjthsd-h wrote: post #5

Unfortunate that there's no commentary on performance impact. It's symmetric encryption on a few kB, so probably fast, but I'd like to have numbers.

> Unfortunate that there's no commentary on performance impact. It's symmetric encryption on a few kB, so probably fast, but I'd like to have numbers. TFA comments on the performance impact. It's only about the handshake, i.e. irrelevant.

Saying it's about the handshake is not a comment on performance impact, and doesn't need a patronizing "TFA". Especially when the article just talks about 'signatures', in a way that doesn't make it obvious exactly when this key is being used.

This code is probably not adding more than a millisecond, but it's not at all true that handshake speed is irrelevant. If you rewrote the RSA code in a slow secure way, going from 100ms to 5s on a slow chip, that would have very real effects.

Post reply on HN