Live data from Hacker News

SSH gets protection against side-channel attacks

undeadly.org

81–90 of 166 posts

Re: SSH gets protection against side-channel attacks

#81
post #74
post #67

Earlier quoted context omitted.

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.

Sure, although this is a non-standard and potentially non-portable extension. memset_s in Annex K is standard, but all of Annex K is optional, and like the rest of Annex K, it has an awful interface.

Re: SSH gets protection against side-channel attacks

#82

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

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

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 underlying arrays are not easily accessible (save for reflection).

Re: SSH gets protection against side-channel attacks

#83
post #72

Earlier quoted context omitted.

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…

But that wouldn't prevent (mitigate) cloudbleed anymore as the problem is about isolating contexts within process boundaries.

Re: SSH gets protection against side-channel attacks

#84
post #30

Earlier quoted context omitted.

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.

Well yes, but that's a pretty special case. Those running such ancient hardware keep their own software and patches, and you don't see many software vendors supporting them unless their are being very well paid. OpenBSD itself does not support even VAX anymore, and developers felt pretty happy when they finally deleted large portions of specific code. Ubuntu is talking about dropping i386. Given enough time, the burden of supporting old hardware outweight the benefits for pretty much everybody, so it makes sense that it should fall on the shoulders of those who decided keeping the old hardware was a good idea.

Re: SSH gets protection against side-channel attacks

#85

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.

> It's secure or its not.

Well, it's not. Now that we've debunked performance and security, I guess we can just write everything in PHP.

Re: SSH gets protection against side-channel attacks

#87
post #43
post #37

Earlier quoted context omitted.

"I’m really not convinced". Ok great thanks, neither is anyone else, which is why we'd like numbers.

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

Re: SSH gets protection against side-channel attacks

#88
post #6

Anyone with the actual link to the specific commit?

Sure: https://github.com/openbsd/src/commit/707316f931b35ef67f1390...

   -  /* $OpenBSD: authfd.c,v 1.113 2018/12/27 23:02:11 djm Exp $ */ 
   +  /* $OpenBSD: authfd.c,v 1.114 2019/06/21 04:21:04 djm Exp $ */ 
what weird tool/infrastructure do these guys use, that they maintain CVS/SVN string identifiers in the files but nevertheless use git?

I actually liked these identifiers. There were tools like ident (http://manpages.org/ident/1) to deal with them.

Re: SSH gets protection against side-channel attacks

#89

Earlier quoted context omitted.

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

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.

Re: SSH gets protection against side-channel attacks

#90

Earlier quoted context omitted.

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

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 it but before generating the key.
Post reply on HN