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

91–100 of 166 posts

Re: SSH gets protection against side-channel attacks

#91

Post by [deleted] »

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?

[deleted]

Re: SSH gets protection against side-channel attacks

#92

Post by java-man »

saurik wrote: post #90
java-man wrote: post #82

Earlier quoted context omitted.

by explicitly clearing it when an operation is finished. example: https://github.com/andy-goryachev/PasswordSafe/blob/master/s... byte[] key = generateKey(); try { // sensitive operation } finally { Crypto.zero(key); } once the operation finishes, the memory is cleared (and possibly subject to gc) the problem is that some java classes, for instance BigInteger, are not designed for cryptographic operations - it's unde…

In that code, after generateKey, during the sensitive operation, the system might need to do a garbage collection, at which point this array might have been copied to a different location in memory before your call to zero. You have to also "pin" (afaik this is the usual terminology for this) that array to a fixed location (which would then have to be a feature of that runtime and garbage collector) after allocating…

So what you are saying is that JVM copying surviving object between generational pools might expose secrets in memory?

A very good point, thank you.

What could be done to mitigate this? Direct ByteBuffer per

https://stackoverflow.com/questions/5670862/bytebuffer-alloc...

?

Re: SSH gets protection against side-channel attacks

#93

Post by java-man »

pstrateman wrote: post #89
java-man wrote: post #82

Earlier quoted context omitted.

by explicitly clearing it when an operation is finished. example: https://github.com/andy-goryachev/PasswordSafe/blob/master/s... byte[] key = generateKey(); try { // sensitive operation } finally { Crypto.zero(key); } once the operation finishes, the memory is cleared (and possibly subject to gc) the problem is that some java classes, for instance BigInteger, are not designed for cryptographic operations - it's unde…

That operation is almost certainly optimized out.

Would you elaborate please?

Re: SSH gets protection against side-channel attacks

#94

Post by LinuxBender »

mehrdadn wrote: post #77
simias wrote: post #7

Earlier quoted context omitted.

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

Just keep in mind that multiplexing makes phishing risks significantly higher. ssh wont log multiplexed auth and phished connections are auth free, up to 9 more sessions by default.

Re: SSH gets protection against side-channel attacks

#95

Post by FDSGSG »

castis wrote: post #87
FDSGSG wrote: post #43

Earlier quoted context omitted.

Why do you think that this specific change would make ssh not "work at all" as opposed to the hundreds of other changes that happen? Do you even pay close attention to those changes? I for sure don't. Why are you concerned about this in the first place? Obviously there's always a general concern about any changes, but what makes this specific change a big deal to you?

edit: your annoyance is not worth anyones time

>reading way too far into it

Dunno, your earlier comments seem to imply otherwise:

>we'd like to know that its not heavily degrading to the existing purpose... which is why we'd like numbers

Re: SSH gets protection against side-channel attacks

#96

Post by ryanlol »

notacoward wrote: post #59
ryanlol wrote: post #11

Earlier quoted context omitted.

If you need high performance why are you using OpenSSH?

Ssh isn't just for interactive terminal sessions. It's not that uncommon for people to use ssh tunnels in situations where proper VPNs etc. are blocked. Others use sftp or tunnels plus a SOCKS proxy in one specific application. In those applications, performance regressions are a legitimate concern precisely because it's not expected to be all that great to begin with.

If you’re concerned about performance then sftp or SSH tunnels simply aren’t the right tools for you.

Re: SSH gets protection against side-channel attacks

#97

Post by chasil »

mtgx wrote: post #57
baq wrote: post #2

> Hopefully we can remove this in a few years time when computer architecture has become less unsafe. I think the author misspelled 'decades' here :)

I believe all consumer AMD Ryzen CPUs support Secure Encrypted Memory (SEM), but for some reason it's not enabled by default on most Ryzen devices/motherboards. It's a shame. I'd also love to see AMD bring an updated and patched version of Secure Encrypted Virtualization (there have been some attacks against it, although still fewer than against Intel's SGX) to consumer Ryzen in the near future. With so many cores av…

Isn't AMD's encrypted memory meant more for the case of someone with physical access aggressively cooling a running system, then cutting power and removing the chilled memory for analysis (which will preserve contents much longer when cold than at normal temperatures)?

The case of an attack on the SSH Agent would take place within the CPU, perhaps even in the same core on a separate HT/SMT thread, where the memory would be cleartext.

Re: SSH gets protection against side-channel attacks

#98

Post by chasil »

nabakin wrote: post #86

Is this only for OpenBSD's implementation of SSH?

If we wait long enough, it will go all the places that the portable release at openssh.com pushes it.

It will take a few service packs, but even Windows will get it.

    C:\>ssh -V
    OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4

Re: SSH gets protection against side-channel attacks

#99

Post by rocqua »

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…

> in fact one could argue that, the higher the quantity of memory chunks is, the harder it is to correctly decrypt the original private key; although to me this has the security through obscurity smell

I am not sure this is a bad place for security through obscurity. ASLR is similar. The thing is, here we are not using this is a primary mechanism. (that would be preventing RCE) Instead, this would be a secondary 'defense in depth' measure meant to make it harder to deploy an exploit after you have been compromised.

For such a second layer of defense in depth, obscurity is a decent option. Things go wrong if you start relying on your obscurity to do anything but slow down an attacker.

Re: SSH gets protection against side-channel attacks

#100

Post by marvin-83 »

java-man wrote: post #93
pstrateman wrote: post #89

Earlier quoted context omitted.

That operation is almost certainly optimized out.

Would you elaborate please?

I believe he is referring to compiler optimisation which removes wasteful or extraneous operations. I don't write in Java though, so can't comment more than that.
Post reply on HN