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

121–130 of 166 posts

Re: SSH gets protection against side-channel attacks

#121

Post by java-man »

kjeetgill wrote: post #112
java-man wrote: post #54

Earlier quoted context omitted.

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

You can't treat memory, even arrays, as singular memory locations in Java. Stuff moves around because collectors are cimpacting.. If you want to "write in place" in Java you need to either use a non-moving garbage collector, use sun.misc.Unsafe to read write memory directly, or mayyyyyybe take advantage of humongous allocations (arrays big enough that the JVM won't move them).

Direct ByteBuffer?

Re: SSH gets protection against side-channel attacks

#122

Post by ris »

reza_n wrote: post #21
Koffiepoeder wrote: post #19

Earlier quoted context omitted.

Could you point me to the relevant source code? Am highly interested to take a look at it during the weekend.

Closed source, write up would be here: https://info.varnish-software.com/blog/introducing-varnish-t...

> Closed source

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

Re: SSH gets protection against side-channel attacks

#123

Post by dang »

ris wrote: post #122
reza_n wrote: post #21

Earlier quoted context omitted.

Closed source, write up would be here: https://info.varnish-software.com/blog/introducing-varnish-t...

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

"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

Re: SSH gets protection against side-channel attacks

#124

Post by viraptor »

rocqua wrote: post #99
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 'def…

I feel like the should be a different name for that class of mitigations. Probabilistic security maybe? Security through obscurity for me is "we won't publish our algorithm". But that's not the same as ASLR or memory encryption which targets specific type of attack by adding probably-too-high randomness to the attack path.

Re: SSH gets protection against side-channel attacks

#125

Post by carapace »

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.

I think folks are missing your point, which (I think) is something like:

I don't care if that car is faster if it is already on fire.

Re: SSH gets protection against side-channel attacks

#126

Post by wahern »

jasonh3 wrote: post #120

When I first saw this post, I got excited that someone had finally addressed the side channel from 17 years ago, which gathered inter-packet timing from ssh packets (and the fact that passwords are not echo'd) to a) detect when passwords were being typed, and b) use Hidden Markov Models to extract keystroke timing to try to extract the likely passwords. There have been defenses proposed over the years, but none were…

The proper defense is to not use passwords. It's 2019, nobody should be using passwords on SSH-enabled shell accounts.

Heck, I use secure tokens for authentication so this memory encryption hack is useless to me--even I don't know what my private key(s) are, nor does OpenSSH or any other software on my computers. But I appreciate that we're a long way from ubiquitous hardware-based authentication.

Re: SSH gets protection against side-channel attacks

#127

Post by the8472 »

mehrdadn wrote: post #119
the8472 wrote: post #116

Earlier quoted context omitted.

The prekey is hashed into the symmetric key. Both the hash function and the symmetric cipher have avalanche effects that mean that N bit errors require the attacker to bruteforce 2^N combinations. unprotected RSA keys on the other hand have structure and are dense in memory. That means fewer bit-errors and and the ability to guess the missing bits faster than O(2^N).

Yeah but my concern was about direct leakage not brute force. That's what Spectre is about.

Oh yeah, but the temporal sparseness doesn't just apply to the symmetric memory encryption key. The most important part is that it also applies to the asymmetric host keys, which are the actual thing one wants to have protected.

prekey -(hash)-> memory key -(decrypt)-> host private key

Re: SSH gets protection against side-channel attacks

#129

Post by the8472 »

java-man wrote: post #121
kjeetgill wrote: post #112

Earlier quoted context omitted.

You can't treat memory, even arrays, as singular memory locations in Java. Stuff moves around because collectors are cimpacting.. If you want to "write in place" in Java you need to either use a non-moving garbage collector, use sun.misc.Unsafe to read write memory directly, or mayyyyyybe take advantage of humongous allocations (arrays big enough that the JVM won't move them).

Direct ByteBuffer?

Yes, a direct byte buffer wrapped in class that ensures you can never copy the data somewhere else. That would also require cryptographic routines that can operate on bytebuffers or varhandles, which is quite an obstacle since many crypto libraries consume keys as byte[].

Re: SSH gets protection against side-channel attacks

#130

Post by gnur »

wahern wrote: post #126
jasonh3 wrote: post #120

When I first saw this post, I got excited that someone had finally addressed the side channel from 17 years ago, which gathered inter-packet timing from ssh packets (and the fact that passwords are not echo'd) to a) detect when passwords were being typed, and b) use Hidden Markov Models to extract keystroke timing to try to extract the likely passwords. There have been defenses proposed over the years, but none were…

The proper defense is to not use passwords. It's 2019, nobody should be using passwords on SSH-enabled shell accounts. Heck, I use secure tokens for authentication so this memory encryption hack is useless to me--even I don't know what my private key(s) are, nor does OpenSSH or any other software on my computers. But I appreciate that we're a long way from ubiquitous hardware-based authentication.

After you are connected you might still want to enter a password (for sudo perhaps).
Post reply on HN