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

101–110 of 166 posts

Re: SSH gets protection against side-channel attacks

#101

Post by nickpsecurity »

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?

Yes. Most research makes CPU modifications since that makes the most sense. Sometimes they try to use OS-level techniques. Here's a survey showing some of each:

https://thayer.dartmouth.edu/tr/reports/tr13-001.pdf

Re: SSH gets protection against side-channel attacks

#102

Post by chasil »

foobar_ wrote: post #75
gnomewascool wrote: post #45

Earlier quoted context omitted.

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.

For your donation, you also received preliminary code for quantum-resistant key exchange.

    $ sed -n '/NTRU/,/enabled/p' ChangeLog
    sntrup4591761x25519-sha512@tinyssh.org using the Streamlined NTRU Prime
    4591^761 implementation from SUPERCOP coupled with X25519 as a stop-loss. Not
    enabled by default.

Re: SSH gets protection against side-channel attacks

#103

Post by nickpsecurity »

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…

You might find this paper interesting in regard to memsets optimized away:

https://www.usenix.org/system/files/conference/usenixsecurit...

I agree with you on a standard platform. Id get a company like Galois to build it. They already have and open-sourced the necessary tooling from thrir prior contracts.

Re: SSH gets protection against side-channel attacks

#104

Post by guan »

ktpsns wrote: post #88
mulander wrote: post #6

Earlier quoted context omitted.

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.

They use CVS, not git. The repository that’s on GitHub is a mirror of the CVS repository; I don’t know what tool is used to do the mirroring.

Here is the original change in authfd.c in cvsweb:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/au...

Re: SSH gets protection against side-channel attacks

#105

Post by kardos »

ktpsns wrote: post #88
mulander wrote: post #6

Earlier quoted context omitted.

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.

They use CVS; the github repo description says it is a mirror:

> Public git conversion mirror of OpenBSD's official cvs src repository.

Re: SSH gets protection against side-channel attacks

#106

Post by nickpsecurity »

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.

Clive Robinson on Schneier's blog predicted lots of these problems after arguing they were a law of nature. He said any form of matter or energy connecting two machines might create a side channel. He said we'd have to clock all the inputs and outputs, make them predictable, and then "energy gap" the systems. We both already knew about CPU leaks since that was described as risky in 1990's. Sure enough, air-gap-jumping malware and processor leaks showed up.

Later, getting a high-level view of hardware reinforced it was a law of nature. First, there's all kinds of RF leaks that attackers might pick up from normal operation. Second, most systems aren't fault/leak-proof if attackers actively hit the system with different physical effects or RF. Finally, each process shrink increases how easily chips, including mitigations on them, break. It looked like the stuff at 28nm was kind of broken by design with fixes and stuff built in to delay failures user would notice.

This all sounds like the laws of physics are a huge obstacle to computers (a) working at all and (b) keeping secrets. Achieving (a) takes hundreds of millions to billions in R&D each year. I can only imaging what (b) might take.

Re: SSH gets protection against side-channel attacks

#107

Post by chasil »

simias wrote: post #55
tremon wrote: post #26

Earlier quoted context omitted.

What part of the existing purpose is performance-critical?

I certainly wouldn't want scp to suddenly slow down compared to what I'm used to. I use scp and sftp rather heavily to transfer very large files and do backups, that might not be performance-critical but it's definitely performance-sensitive. I haven't had to mess with that in a while but there was a time where you'd get a significant boost with scp on underpowered hosts if you used the arcfour cipher for instance (I…

If you were willing to sacrifice best practices for performance, one obvious option is to accept only hmac-md5, which is very fast and still somewhat secure.

If the systems involved lack "AES-NI" native CPU opcodes, then you might revert to chacha20-poly1305, which is supposedly faster on CPUs that lack acceleration. This also overrides the hmac-md5 above, as it is an AEAD.

If you needed to go faster still, then you could instead choose ARCFOUR (RC4) as you say, but this has been removed from the latest versions of OpenSSH because it is not safe.

The worst of the above configurations are still not as bad as classic FTP.

Re: SSH gets protection against side-channel attacks

#108

Post by vinay_ys »

Zarathustra_ wrote: post #16
spacephysics wrote: post #14

Earlier quoted context omitted.

If I were writing a cryptographic algorithm in C++, how would I ensure the CPU cache was used for private keys? Would it have to be written in a lower level language, or does there exist a library for C/C++?

Previous thread with lots of relevant information: https://news.ycombinator.com/item?id=8542405 Short answer is yes usually, and if not, you can always do inline asm. Of course, you're really, really, really not supposed to write your own crypto.

If everyone follows this advice, who will write the crypto code? If anything we need lot more people who are formally trained to write proper crypto code and find bugs in such code etc.

Re: SSH gets protection against side-channel attacks

#109

Post by notacoward »

ryanlol wrote: post #96
notacoward wrote: post #59

Earlier quoted context omitted.

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.

If the "better" tools are unavailable, then it's the right tool. Your needs and priorities are not the only ones that exist anywhere in the universe.
Post reply on HN