For a while now, I’ve been noodling around with a cryptographically-secure "invitation protocol" of sorts. I want something that can start with Alice sending an Invitation Message to Bob, and end with fully secure bidirectional communication.
The use cases I have so far are:
- secure file-transfer tools, as a browser plugin or standalone application. The program would have an address-book, each entry would have an "Inbox" for that person, you would send them a file by drag-and-dropping it onto the Inbox. This invitation protocol would be used to populate the address book.
- secure communication tools, like Petmail or an encrypted email/IM client, in which you want to add address-book entries so you can later exchange messages with the right correspondent.
- Tahoe grid membership tools: you would use an Invitation to securely add another person’s client/server node to your grid, maintaining enough information to perform Accounting and server-selection properly.
but there are lots of others. Most applications with any sort of social component need a way to add "buddies" or correspondents. There are plenty of centralized systems (like IM networks, where the namespace is controlled by a single company), and a handful of insecure decentralized systems (like email addresses). I want this protocol for secure decentralized systems, in which the primary identifier for each participant is a public key of some sort.
Read on if you’re interested in cryptographic protocols..
A big usability-barrier for such systems is the bootstrapping problem: getting from a casual (insecure) everyday channel to the persistent secure long-term channel. A lot of tools punt on this and assume the keys are distributed ahead of time, or managed by some administrator. I’m interested in systems for which the only mode is "secure" mode, and which are as easy to use as traditional insecure systems. The usability standard is that the humans do not need to do anything more than they’re already doing: the system would look no simpler if you ripped out the security, so we might as well leave it in.
Imagine you’re chatting with someone at a conference, or at lunch, or in an IRC channel, and you want to send them a file, or pick up the conversation later, or whatever. You want your user agent to learn about their user agent, so that you can use it to send them a message later on. I’d like this to be properly secure, so every message is signed and encrypted, which means the agents need to learn each other’s keys. What can the two humans exchange that will let their agents establish that cryptographic connection?
The usual (worst case) pattern, with something like PGP, is that both people must pre-arrange for some common server to hold copies of their public keys, indexed by an email address, and to have secure hashes of those keys on something transferrable in their pocket (frequently printed on business cards). They can exchange business cards and type in their contents later (downloading the keys, computing the hashes, and comparing against the cards). Or, if they have an online connection already, they can paste large key files to each other, and perhaps paste+compare fingerprints. But we have plenty of experience showing that these schemes aren’t sufficiently usable, and needing to type in all that material discourages casual real-time use.
In the protocol I have in mind, one of these people sends an "Invitation" to the other, and the second person accepts it. Alice, the inviter, asks her computer for the invitation object (a file or a short string), and she somehow hands it to Bob: maybe she emails it to him, or pastes it to him over an IM channel, or recites it to him in person or over the phone. Bob drags or pastes or types this invitation into his computer. Then the two computers talk to each other, exchange keys, and at the end of the process, each computer has an address-book entry for the other. Later, their applications can use these keys to perform secure message exchanges with each other.
The ground rules for this protocol (including some assumptions and basic engineering tradeoffs) are:
- Alice has a "secure-enough" channel to Bob already. "secure-enough" means we’re comfortable pretending that whatever she emails or pastes or speaks to him will remain secret and intact (not modified by an attacker) long enough for Bob to use it. Alice and Bob can take extra steps to make it more secure, if they want.
- The channel isn’t long-term secure: we assume that the contents will become public eventually, so we aren’t allowed to put any long-term secrets in it
- The channel is one-way and one-shot: if Alice sends her invitation via email, the protocol isn’t allowed to use email to get the response back. (this would impose burdens on the users, and require more complex interaction between the protocol implementation and existing tools)
- The Invitation is thus single-use and only valid for a limited time, maybe 24 hours. We’re comfortable with a "Trust On First Use" policy: an attacker who both learns and acts upon the invitation early can impersonate Bob. But there will be a way to do an out-of-band comparison later, to completely rule out a man-in-the-middle.
- Since the Internet is no longer a network of computers that can all talk to each other, we assume that either agent may be behind a NAT box. We allow applications to bake-in the address a publically-reachable "Relay Service", which helps them exchange messages for the duration of the protocol. We don’t allow this service to affect the security of the system: it could mount a DoS attack, but otherwise is no more powerful than any other MitM.
- The goal of the protocol is to securely get Alice’s address-book entry into Bob’s address-book, under a petname for "Alice" that Bob picks when he accepts the invitation: we call this entry Ealice. We also need symmetry: to get Bob’s entry into Alice’s address-book under a petname that Alice picks when she sends the invitation, which we call Ebob. Part of these entries is the address of a relay-service or other helper to exchange subsequent application-specific messages.
- All these address-book entries are public knowledge: no need to keep them confidential during the protocol (this turns out to affect the protocol in significant ways)
- We have a secure/fast/short public-key signature scheme: Ed25519. We want a 128-bit security level.
I’ll post more later about the protocol I’m building to satisfy these constraints. Let me know what you think!