When we left off last article, we examined the two most common security models used today and found them both lacking. But fear not, brave readers - there are yet more key distribution solutions out there. Surely one of them isn't total shit!

TOFU, or "eh, it's probably alright"

There is one other method of key distribution that is commonly used. Made popular by OpenSSH, TOFU, or "trust on first use", has a slightly different attitude to the problem of key distribution than other solutions. The hardest problem in key distribution is bootstrapping your trust from nothing. At the end of the day, you need to choose something to build your trust on top of: the certificate authority model chooses a list of preselected authorities that are burned into the operating system, and the web of trust model bootstraps based on a network of people you trust in person. TOFU looks at this problem and tosses up it's hands. "Fuck it," TOFU says. "It's probably alright."

Trust on first use provides its security guarantees by protecting all of your connections /after/ the first one. The first time you connect, you are prompted with a key fingerprint of the server and asked if it's the right server.

The authenticity of host 'xmenrevolution.com (97.107.134.16)' can't be established.
RSA key fingerprint is b9:2b:30:7c:a8:89:39:86:9b:13:19:fe:1b:c4:ec:a0.
Are you sure you want to continue connecting (yes/no)?

It is the users responsibility to verify this fingerprint through some out-of-band method. Checking with the server operator, looking at SSHFP records in DNS, or sacrificing virgins to those beyond the veil for the answer. Whatever works. After this first connection, the certificate is saved with a mapping to the host that you connected to. On every subsequent connection, it verifies that the server you think you are connecting to has the same fingerprint as the one you first connected to. If the key changes, it blocks the connection with a warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
b9:2b:30:7c:a8:89:39:86:9b:13:19:fe:1b:c4:ec:a0.
Please contact your system administrator.
Add correct host key in /tmp/asht to get rid of this message.
Offending RSA key in /tmp/asht:3
  remove with: ssh-keygen -f "/tmp/asht" -R xmenrevolution.com
RSA host key for xmenrevolution.com has changed and you have requested strict checking.
Host key verification failed.

Sarcasm aside, this is not necessarily an unreasonable approach. In order to subvert it, an attacker must be constantly in a position to sit between the user and the server, always ready to intercept the connection. If the attacker misses the window of opportunity, they won't be able to use a man-in-the-middle attack in the future without being noticed. Even for an adversary with extensive control, this is a difficult - though certainly not impossible - proposition. TOFU strikes a utilitarian balance between security and usability, but it's far from a silver bullet. It can't be easily used for asynchronous communications, like e-mail, because the window for an attacker is lengthened significantly. It doesn't help at all in the face of a global adversary, or one that is able to attack the network at the point of connection between the server and the internet. It is difficult to imagine it being used for a replacement for the CA model used in SSL/TLS without sacrificing security in a substantial way.

Keybase

One company out there aims to solve some of the problems with the complexity of the web of trust by creating a publicly audited directory of people's PGP keys. It does so not only through a social mechanism, but also by letting people post claims to their identity through attestations on accounts that they control. The Keybase software then lets you verify that these attestations are still in place when you retrieve the copy of their public key. Even if an attacker compromises the person's Keybase account, it is probably difficult for them to compromise all the associated accounts and post new attestations with a key controlled by the attacker. For example, my own Keybase profile has links to Twitter, Github, Hacker News, and this website. An attacker would have to either compromise all of those accounts to post new attestations, or provide attestations to other profiles that could be confused with mine, as well as my Keybase account. (Or Keybase itself.)

Keybase also lets you "track" someone's identity by signing an attestation yourself that you have verified someone's information. This attestation can be used by yourself in the future, if you change computers and no longer have access to the cached information. It can also be used by others to validate that other people have been watching the profile for changes for a period of time. The idea being, even if an attacker manages to compromise all the accounts, the more people that are watching, the more likely the compromise would be noticed and reported. Keybase also uses the Bitcoin blockchain to make attacking Keybase servers more difficult[1]; in the end, it is likely an attacker would choose to target an individual user rather than the Keybase servers itself.

On the surface, it seems that it would be very difficult for an attacker to simultaneously compromise all of the associated accounts on Keybase. Many of the websites that can be linked support two-factor authentication and have strong password requirements. If it's difficult to break into one, surely it's difficult to break into all of them, right?

Well. Sort of. Let's take my profile as an example. I have four accounts linked on Keybase - Github, Hacker News, Twitter, and this website. My email accounts that are supported in my key are a Gmail account and an account hosted on the same server as this website. That would mean, you would need to compromise at least four different accounts, two of which have two-factor authentication, and all of which have strong passwords that are not shared between any accounts. (Password reuse rates have been seen as high as 50%, making the average user's case likely much easier than attacking mine. [2])

There is another link between all of these accounts, though. Password reset mechanisms. Many, many websites - including most of the above mentioned - use email as the out-of-band authentication mechanism. An attacker that was able to compromise an email account could reset the passwords on the other accounts and gain access to them that way and "bootstrap" their access up to other websites. This is a very common tactic and has been used to great effect, including in the Twitter hack in 2009 [3]. "Separate" accounts may not be so separate after all, weakening the fundamental security that Keybase is built on top of. Whether such a compromise could go unnoticed is a more nebulous question.

DNS, DANE, and SSHFS - oh my!

One option that has seen some popularity recently is validating the certificate of a server through the DNS infrastructure. While a little bit of a strange choice at first glance, after mulling it over for a sufficient amount of time, it can make some sense. DNS is the "directory-book" of the internet; why not extend it to give clients a picture not only of what server they want to contact, but also how to verify that server?

Lots of reasons, it turns out. DNS, by default, isn't authenticated at all. This means even trivial attackers can pass you whatever records they feel like. So much for security. Relatively recently, the DNS infrastructure has begun to be signed through a process called DNSSEC. DANE, the standard for putting TLS certificates into DNS, requires that DNSSEC be used in order to trust the results. Unfortunately, the roll-out of DNSSEC has been slow, with many top level ccTLDs not yet signed, and with most DNS resolvers still not verifying the chain.

Even if DNSSEC was fully deployed, it's really just a microcosm of the CA model. Instead of trusting a whole laundry list of domains, though, you must trust a different set of people: the root keyholders, the TLD keyholders, and the nameserver keyholders. If you mistrust anyone in the chain - and the US government is (substantially) in control of the root - then you can't trust results coming from DNS. DANE just ends up being another form of the certificate authority model.

What's next?

We've looked at a handful of different problems with widely-deployed crypto out in the wild - from user experience to key distribution. At this point, you might be feeling somewhat depressed about the state of security on the internet; I can't particularly blame you. A truly secure system isn't something that you can really ever reach, though. A recurring joke in ##crypto is a statement of the form "Best security practices recommend you X", where X is something of the form "encase your system in cement", or "cool your system with sulfuric acid". Security and usability are opposite ends of the spectrum; a well-secured system has struck the right balance between them for its particular threat model. Security needs to exist in the world, not a vacuum. So don't fear, and don't reach for the impossible. Find the right balance of compromises for you.

This is the last article in the "GPG is awesome; GPG is terrible" series. If you have comments or questions, please feel free to reach out to me, over IRC, email, or IM. I will continue covering security related topics in the future; if you have suggestions of things you'd like to read, please feel free to recommend them.