Trust on first use

Trust on first use (TOFU), or trust upon first use (TUFU), is an authentication scheme^[1] used by client software which needs to establish a trust relationship with an unknown or not-yet-trusted endpoint. In a TOFU model, the client will try to look up the endpoint's identifier, usually either the public identity key of the endpoint, or the fingerprint of said identity key, in its local trust database. If no identifier exists yet for the endpoint, the client software will either prompt the user to confirm they have verified the purported identifier is authentic, or if manual verification is not assumed to be possible in the protocol, the client will simply trust the identifier which was given and record the trust relationship into its trust database. If in a subsequent connection a different identifier is received from the opposing endpoint, the client software will consider it to be untrusted.

TOFU implementations[edit]

In the SSH protocol, most client software (though not all^[2]) will, upon connecting to a not-yet-trusted server, display the server's public key fingerprint, and prompt the user to verify they have indeed authenticated it using an authenticated channel. The client will then record the trust relationship into its trust database. New identifier will cause a blocking warning that requires manual removal of the currently stored identifier.

The XMPP client Conversations uses Blind Trust Before Verification,^[3] where all identifiers are blindly trusted until the user demonstrates will and ability to authenticate endpoints by scanning the QR-code representation of the identifier. After the first identifier has been scanned, the client will display a shield symbol for messages from authenticated endpoints, and red background for others.

In Signal the endpoints initially blindly trust the identifier and display non-blocking warnings when it changes. The identifier can be verified either by scanning a QR-code, or by exchanging the decimal representation of the identifier (called Safety Number) over an authenticated channel. The identifier can then be marked as verified. This changes the nature of identifier change warnings from non-blocking to blocking.^[4]

In e.g. Jami and Ricochet the identifier is the user's call-sign itself. The ID can be exchanged over any channel, but until the identifier is verified over an authenticated channel, it is effectively blindly trusted. The identifier change also requires an account change, thus a MITM attack for same account requires access to endpoint's private key.

In WhatsApp the endpoint initially blindly trusts the identifier, and by default no warning is displayed when the identifier changes. If the user demonstrates will and ability to authenticate endpoints by accessing the key fingerprint (called Security Code), the client will prompt the user to enable non-blocking warnings when the identifier changes. The WhatsApp client does not allow the user to mark the identifier as verified.

In Telegram's optional secret chats the endpoints blindly trust the identifier. Changed identifier spawns a new secret chat window instead of displaying any warning. The identifiers can be verified by comparing the visual or hexadecimal representation of the identifier. The Telegram client does not allow the user to mark the identifier as verified.

In Keybase the clients can cross-sign each other's keys, which means trusting a single identifier allows verification of multiple identifiers. Keybase acts as a trusted third party that verifies a link between a Keybase account and the account's signature chain that contains the identifier history. The identifier used in Keybase is either the hash of the root of the user's signature chain, or the Keybase account name tied to it. Until the user verifies the authenticity of the signature chain's root hash (or the keybase account) over an authenticated channel, the account and its associated identifiers are essentially blindly trusted, and the user is susceptible to a MITM attack.^{[citation needed]}

Model strengths and weaknesses[edit]

The single largest strength of any TOFU-style model is that a human being must initially validate every interaction. A common application of this model is the use of ssh-rpc 'bot' users between computers, whereby public keys are distributed to a set of computers for automated access from centralized hosts. The TOFU aspect of this application forces a sysadmin (or other trusted user) to validate the remote server's identity upon first connection.

For end-to-end encrypted communication the TOFU model allows authenticated encryption without the complex procedure of obtaining a personal certificate which are vulnerable to CA Compromise. Compared to Web of Trust, TOFU has less maintenance overhead.

The largest weakness of TOFU that requires manual verification is its inability to scale for large groups or computer networks. The maintenance overhead of keeping track of identifiers for every endpoint can quickly scale beyond the capabilities of the users.

In environments where the authenticity of the identifier can not be verified easily enough (for example, the IT staff of workplace or educational facility might be hard to reach), the users tend to blindly trust the identifier of the opposing endpoint. Accidentally approved identifiers of attackers may also be hard to detect if the man-in-the-middle attack persists.

As a new endpoint always involves a new identifier, no warning about potential attack is displayed. This has caused misconception among users that it's safe to proceed without verifying the authenticity of the initial identifier, regardless of whether the identifier is presented to the user or not.

Warning fatigue has pushed many messaging applications to remove blocking warnings to prevent users from reverting to less secure applications that do not feature end-to-end encryption in the first place.

Out-of-sight identifier verification mechanisms reduce the likelihood that secure authentication practices are discovered and adopted by the users.

First known use of the term[edit]

The first known formal use of the term TOFU or TUFU was by CMU researchers Dan Wendlandt, David Andersen, and Adrian Perrig in their research paper "Perspectives: Improving SSH-Style Host Authentication With Multi-Path Probing" published in 2008 at the Usenix Annual Technical Conference.^[5]

Moxie Marlinspike mentioned Perspectives and the term TOFU the DEF CON 18 proceedings, with reference to comments made by Dan Kaminsky, during the panel discussion "An Open Letter, A Call to Action". An audience suggestion was raised implying the superiority of the SSH Public key infrastructure (PKI) model, over the SSL/TLS PKI model - whereby Moxie replied:

Anonymous: "...so, if we dislike the certificate model in the (tls) PKI, but we like, say, the SSH PKI, which seems to work fairly well, basically the fundamental thing is: if I give my data to someone, I trust them with the data. So I should be remembering their certificate. If someone else comes in with a different certificate, signed by a different authority, I still don't trust them. And if we did it that way, then that would solve a lot of the problems- it would solve the problems of rogue CAs, to some extent, it wouldn't help you with the initial bootstrapping but the initial bootstrapping would use the initial model, and then for continued interaction with the site you would use the ssh model which would allow you continued strength beyond what we have now. So the model we have now can be continued to be re-used, for only the initial acceptance. So why don't we do this?"

Dan: "So, I'm a former SSH developer, and let me walk very quickly, every time there's an error in the ssh key generation, the user is asked, 'please type yes to trusting this new key', or, 'please go into your known hosts file and delete that value', and every last time they do it, because it's always the fault of a server misconfiguration. The SSH model is cool, it don't scale".

Moxie: "And I would just add, what you're talking about is called 'Trust on First Use', or 'tofu', and there's a project that I'm involved in called perspectives, that tries to leverage that to be less confusing than the pure SSH model, and I think it's a really great project and you should check it out if you're interested in alternatives to the CA system."

Related work on the subject[edit]

• Work toward creating visual representations of server certificate 'fingerprint' hashes has been implemented into OpenSSH in the form of ASCII Art. The intention is for users to visually recognize a 'graphical' image, instead of a long string of letters and numbers. The original research paper was written by Adrian Perrig and Dawn Song, at the Carnegie Mellon University Computer Science Department.
• The originator of the 'TUFU' acronym was describing the inspiration for the 'Perspectives Firefox Plug In', which was designed to strengthen the SSL/TLS PKI model by contacting network notaries whenever your browser connects an HTTPS website

Prior work[edit]

The topics of trust, validation, non-repudiation are fundamental to all work in the field of cryptography and digital security.

See also[edit]

• List of information technology acronyms
• Man-in-the-middle attack

References[edit]

External links[edit]

Look up TOFU in Wiktionary, the free dictionary.

• "DEF CON 18 Schedule, Open Letter - Call to Action"
• Firefox extension that contacts network notaries whenever your browser connects an HTTPS website
• Hash Visualization in OpenSSH