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

161–166 of 166 posts

Re: SSH gets protection against side-channel attacks

#161

Post by pstrateman »

java-man wrote: post #160
pstrateman wrote: post #157

Earlier quoted context omitted.

The compiler will see that your operation does nothing and simply not do it.

What I mean was: do you know this to be the case for JVM 8 later? This is an interesting subject. Was there a study or a paper you can refer me to?

JVM 8 isn't an implementation, it's a specification.

Assuming you mean oracles implementation, it's likely that it is.

https://www.sjoerdlangkemper.nl/2016/05/22/should-passwords-... http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buf... https://man.openbsd.org/explicit_bzero.3

Re: SSH gets protection against side-channel attacks

#162

Post by java-man »

pstrateman wrote: post #161
java-man wrote: post #160

Earlier quoted context omitted.

What I mean was: do you know this to be the case for JVM 8 later? This is an interesting subject. Was there a study or a paper you can refer me to?

JVM 8 isn't an implementation, it's a specification. Assuming you mean oracles implementation, it's likely that it is. https://www.sjoerdlangkemper.nl/2016/05/22/should-passwords-... http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buf... https://man.openbsd.org/explicit_bzero.3

Thank you. I was hoping for a more definitive answer, may be a reference to an explicit test involving memory dump analysis.

Re: SSH gets protection against side-channel attacks

#163

Post by Liquid_Fire »

Klasiaster wrote: post #148

It could use the x87 floating point register stack to store the encryption secret. These registers are not used unless there would be some assembly in the SSH libs that accesses them.

Wouldn't they be saved to memory anyway on a context switch?

Re: SSH gets protection against side-channel attacks

#164

Post by Klasiaster »

Liquid_Fire wrote: post #163
Klasiaster wrote: post #148

It could use the x87 floating point register stack to store the encryption secret. These registers are not used unless there would be some assembly in the SSH libs that accesses them.

Wouldn't they be saved to memory anyway on a context switch?

Yes, but I thought this is done in kernel space and a userspace attack has no access to that while the syscall is served.

Re: SSH gets protection against side-channel attacks

#165

Post by Liquid_Fire »

Klasiaster wrote: post #164
Liquid_Fire wrote: post #163

Earlier quoted context omitted.

Wouldn't they be saved to memory anyway on a context switch?

Yes, but I thought this is done in kernel space and a userspace attack has no access to that while the syscall is served.

That is true - it's probably more secure than storing them in the process, but several of these side-channel attacks can apply to kernel space (depending on hardware and security patches applied).

It's also not portable - OpenSSH runs on non-x86 architectures, and they might not have spare basically unused registers lying around.

Finally, I'm not sure the x87 registers have enough space to fit these keys. You have 8 80-bit registers, for a total of 640 bits. Your typical SSH private key might be 2048 bits or more.

So it's a fun and creative line of thinking, but probably not practical in this case.

Re: SSH gets protection against side-channel attacks

#166

Post by java-man »

rurban wrote: post #155
saurik wrote: post #90

Earlier quoted context omitted.

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…

Java also has no mfence or clflush support, so crypto.zero would never be secure. It might overwrite the key in the store buffer only, but not on the heap immediately, so prone to sidechannel attacks.

This is interesting. Could you explain this please?
Post reply on HN