The Grumpy Troll

Ramblings of a grumpy troll.

ECDSA SSH redux: server key compromise attack may exist

[edit: per my comment, OpenSSH is apparently not vulnerable]

Aris Adamantiadis posted something worrying to the OpenSSH developers' mailing-list today [MARC archive, Google Groups archive] referencing this paper, http://eprint.iacr.org/2011/232 by Billy Bob Brumley and Nicola Tuveri.

In short, the authors manage to recover a TLS server's private ECDSA key because of a timing flaw in OpenSSL. Timing flaws are when an implementation takes different amounts of time to do different work, so by measuring how long certain operations take, you can glean information that you're not supposed to have about the private key. In the worst case, you get to recover the private key.

The question posed is whether or not OpenSSH with ECDSA keys is vulnerable to this. (I'm certainly not qualified to answer that.)

If we assume that the answer is "Yes" then this doesn't directly mean that intruders can break into your system; it will, however, give them the needed data to perform an attack whereby they have their server pretend to be yours.

If they can compromise your routing path with an active attack, they can trick you into logging into their server; if you use passwords, they then have the password and can attack at will. If you use public-key authentication and forward your SSH agent to your presumed-trusted server then they can use that to log into the real server, since most agents do not prompt for access. My cryptanalysis is near non-existent, so I don't know if there's a shorter version whereby the attacker could pose a man-in-the-middle whereby they get a connection to the server directly authenticated from the handshake at the start and still get access to the cleartext to manipulate: I suspect not, since they won't have direct access to the session key and the authentication handshake should be signing the session key.

So my suspicion is: if you do not use passwords and do not use SSH agent forwarding, the attackers can trick you into logging into their server but can't compromise your server. That's quite a few "ifs".

There's no indication from this if the user's private key can also be compromised in a similar way; nor, if it can, what would be involved and how visible it would be to the user that this had happened.

So what to do?


The whole point of having multiple key algorithms in use is so that one can be disabled, leaving the others active, in the event of compromise or even suspected compromise.

Since we're dealing here with the trust underlying the ability to connect safely to hosts and because the tools will automatically fall back to other public-key cryptosystems, the most paranoid course of action is also, in my opinion, the most prudent:

  • comment out the ssh_host_ecdsa_key HostKey entry in your sshd_config file and restart sshd
  • verify that connecting to the server used ECDSA before and does not afterwards
  • Remove the ECDSA key from a running agent if applicable (ssh-add -d ~/.ssh/id_ecdsa).
  • Move aside ~/.ssh/id_ecdsa (and the .pub file) to keep it from being loaded in future
  • Await news of the impact of the paper's attack and whether or not OpenSSH actually is affected.
  • If not affected: re-enable keys and continue. If affected: delete keys, wait for patch/fix, upgrade clients and servers, generate new ECDSA keys.

The most important take-away here is that it doesn't matter if OpenSSH actually is affected, we have safe options to mitigate even the risk that it might be!

If you're not using ECDSA yet, this is a good opportunity to double-check that you're set up to use both RSA and DSA keys, so that in the event of an issue with an implementation in one of those, you can safely make the same call to disable one until it's safe to re-enable it.

If you have automated systems which only use one key, for simplicity, then you're vulnerable to a single point of failure where the security depends upon what we don't yet know how to accomplish something. Now's a good time to stop and think about how you can move to supporting multiple keys.

Note that OpenSSH's ssh(1) client supports multiple -i <keyfile> options, so even automated clients which load passphraseless keys for restricted operations can support using multiple keys.

-The Paranoid Grumpy Troll

Comments

Phil P
And Damien Miller posted a reply,

This result concerns binary/GF(2m) fields only and not the prime fields that OpenSSH uses in recent versions.

Unless a similar timing oracle is found for GF(p) fields then no OpenSSH-side workaround is required.
Categories: ECDSA cryptography timing attack ssl security OpenSSL OpenSSH