Trust on first use

Trust on first use (TOFU), or trust upon first use (TUFU), is an authentication scheme 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

In the SSH protocol, most client software (though not all) 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.

In HTTP Public Key Pinning browsers will always accept the first public key returned by the server and with HTTP Strict Transport Security in which browsers will obey the redirection rule for the duration of 'age' directive.

The XMPP client Conversations uses Blind Trust Before Verification, 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.

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.

Model strengths and weaknesses

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

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.

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:

Related work on the subject

* 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

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

See also

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

References

External links

{{Wiktionary, TOFU

"DEF CON 18 Schedule, Open Letter - Call to Action"


* ttps://users.ece.cmu.edu/~adrian/projects/validation/validation.pdf Hash Visualizationin OpenSSH

Computer security