In recognition of the fact that the list is being swamped with enthusiastic but unspecific comments, and to help you decide not to read my post if it suits your fancy, I'm going to state right at the beginning of the post that I'm not a competent developer by any stretch.
On the other hand, I have been following the list for many months now, so I won't be completely oblivious to discussions that have already taken place. And as for my technical prowess and insight, well, judge me by my words. I humbly ask for your readership. >If the repressed source is known only publicly as "fubar127", the >non-repressed activist can use OpenPGP certifications to assert that >fubar127 does in fact hold key X. Here I must disagree. The anonymous blogger named fubar127 does not need anyone to attest to his identity as fubar127. He need only start posting comments under that name, signed with some key. Consider the person who reads some posts by fubar, and comes to think of fubar as a specific person whom a new post may or may not be written by. If he wants to know whether a new post is by the “real” fubar127, he (his software) need only check that it's signed with the same key as the prior posts. Indeed, an ad-hock identity with no prior meaning to the person who needs to verify it is the one and only type of identity for which key continuity alone is a sufficient authentication method. For any other “identity”, some authentication is required. The recent talk of public key authentication in the “Relationship driven privacy” and “Establishing Communication between Freedomboxes” threads and the fascinating discussion of the “bump” or “high-five” or whatever it should be called, a while back, as well as my finally having time to write, has inspired me to write this post. Perhaps before reading this post you should read two other posts, “Freedom Box as the server for other projects' protocols”, and “Freedom Box client device software” that I'll make within the next couple minutes, because in this post I reference ideas discussed in them. Also, if you're interested by what I say, I've already written about aspects of this post's topic in previous posts to this list, which you could find and read if you like. In this post, I advocate a design philosophy for end-to-end cryptographic protocols, which has been brewing in my head for over a year now. It's a philosophy which I'm sure I can't truthfully claim to be novel, indeed, I'm sure components of it have come to me from dozens of sources. I call it novel in the subject, only because it is not reflected in the design of any existing protocol, it desperately needs to be, and I've never seen it described explicitly in its entirety. It's a simple philosophy, which grows naturally out of a single remarkable insight, which I feel that the global community of developers in the field of cryptography is gradually coming to, but not nearly quickly enough. It's a simple philosophy, but I think it will be revolutionary in its effects. At the risk of being over dramatic, for thousands of years, cryptography has been a tool only for the powerful to oppress, never for the balance of humanity to live free. In the 1970s came advances which stand poised to change all that, but a few obstacles remain. I believe that this philosophy, properly implemented, will be the final ingredient in a recipe, (started in the 1970s) for human liberation on such a scale as the world has never seen. Its proper conclusion is a protocol and a software to implement it which I'm sure would become a cornerstone of Freedom Box, but which, like the myriad of components of the future Freedom Box which don't yet exist, probably should be developed apart from the Freedom Box project. That said, the reason I'm writing about it here is that I intend, over the next few weeks/months/years, to peddle this notion to anyone who will listen, and this list is too great a gathering of people with both the skills and the interests necessary for realizing this vision, to pass up the opportunity to peddle it here. Now that I've talked this notion up so high, without further ado I'll begin my sales pitch. If you want to skip ahead, so to speak, and cut to the chase, here are the tenants of the philosophy I'm advocating: 1. A persistent key, which defines an identity, is used for authenticating transient keys used for encryption of message content. I'll call these “identity keys”. 2. All the numerous and varied communication protocols serving different forms of communication and with different security properties derive their authentication from the single identity key. 3. When two people want to start communicating, their software exchanges their identity keys and starts using them, even if no method for authenticating the identity keys is available at the time of exchange. 4. Authentication of the identity keys could take place at the time of exchange, or at a later time. 5. There are many different ways to authenticate identity keys, each of which may be more practical than all the others in some set of circumstances. 6. To secure all forms of communication with one individual, it's necessary to authenticate one identity key, once, by the single most convenient from among all the possible methods. 7. Bottom line: communication protocol is independent of authentication method. Following is a more thorough discussion of the advantages of this framework. We know the goal; the goal is the privacy of strong end-to-end cryptography extended to every last human soul and to every last message. And we know the problem, the problem of public key authentication, the problem of “I'm sending and/or receiving messages to/from someone, but is that someone the someone I think it is?”. It's a difficult problem. A public key is an unwieldy thing. And while it does not need to be kept secret (it's best feature), it, which is an instrument of “signatures”, before it can be fully trusted, ironically must itself be “signed” so to speak in some way that proves that it belongs to whoever it is that you actually want to be talking secrets with. Excuse my pessimism, but no method which involves manually verifying, by voice or print, hexadecimal strings, will ever be used by very many people. He who has both the proper skills and either an intense need for secrecy, or a deep fascination with cryptography itself, might embrace this method, but the lion's share of humanity never ever will. I think it'll be valuable to discuss at this juncture some tremendous limitations in the utility of PKI, that system by which someone whose key you've already securely verified, and whom you personally trust, has verified the relationship between a key and the “identity” of the new person you want to talk to. Too many people seem to think that this method is a total solution to the problem. Even when, unlike X.509 as implemented by web browsers, and like OpenPGP, the trust model is in keeping with the actual human trust model of the user, I see three very burdensome limitations inherent to this method: 1.Okay, so you verify the key of the new person you want to talk with based on your trust in someone else. How did you verify that person's key? And how did that person verify the key of the new person? At some point, someone's got to be using some other method. 2.It's easy to lose sight of the fact when traveling among certain social circles unrepresentative of humanity as a whole, but among the vast majority of humanity, the WOT is a green field. You don't get much help from a “web” when that web so far has no strands. 3.“Identity” you say? What is this “identity” thing? One name almost surely belongs to many people, and one person surely belongs to many names. Just what value of “identity” were you interested in verifying. Any solution that has someone else do the verification for you involves you and that person having the same notion of what identity means. The most robust solution is one which enables you, through direct cooperation with the person whose identity you're trying to verify, to verify exactly the “identity” which is of concern to you. I'm not trying to say that the WOT model doesn't have its use. I'm trying to say that we shouldn't rely on it as being the perfect and only solution. Thankfully, several powerful and elegant solutions have been developed. The newer versions of OTR use a system by which an (even very short!) arbitrary shared secret can be used for authentication, using a very cool protocol called socialist millionaire's protocol. One word or even a single character scribbled on a napkin at a party, perhaps? Or, if you have shared past experiences with this person, you could surely agree, over a potentially insecure channel, on a secret which you both know, but which an attacker, even having access to the words you used to agree on it, would not be able to guess. The value of “identity” that this procedure verifies is “that person who knows the secret”, rather than a name. A protocol called ZRTP authenticates VoIP calls using verification, by voice, of two words generated from a list of words using a hash of the result of a Diffie-Helman exchange. “Clockwork Pegasus?” “Yup, Clockwork Pegasus.” “Okay good, we're secure.” The value of identity that this procedure verifies is “that person whose voice is that particular voice which I recognize”, not a name. The discussion on this list a few days ago, points out that a key fingerprint could be exchanged in a scanable, machine readable format (e.g. a QR code), either displayed on a smartphone screen for another smart phone to scan, or printed on a business card to be scanned on the spot or at a later time. The same QR code could also contain other information (e.g. contact info). The value of identity which this procedure verifies is “that person whom I met that one time”, not a name. There's three different, relatively easy to use ways to authenticate a person's public key. Each one might be easier than the others in a different set of circumstances. The ZRTP way is probably easiest for someone you already know (and recognize the voice of), especially if meeting in person is not convenient. Unless you don't have the ability to make a voice call (there might be many reasons for this), in which case a secret negotiated based on past shared experience might be best. If this is someone you're just now meeting, in person, then the “bump” system is probably easiest. Of course, unless not both parties brought smart phones and not both parties brought business cards, in which case the secret agreed on in person will do nicely. Okay, so far I've established that there's a problem, it's a difficult problem, but there are some good solutions for it. So what's the special insight? Think of, for a moment, all the cryptographic protocols which you use. You probably use SSL/TLS, and IPSEC, and SSH, and OpenPGP. Perhaps you use OTR, maybe even ZRTP, probably others which I didn't think of just now or haven't heard of. You're used to the authentication method of each of those protocols. You're browser has checked X.509 certificates, you have verified PGP fingerprints, and SSH fingerprints (or maybe just crossed your fingers), perhaps you've typed shared secrets into your chat client or voiced short authentication strings. It's a paradigm that we take for granted: each protocol has it's own method for solving the difficult problem of authentication, and if you're going to use that protocol, you'd better authenticate the other person using the authentication method used by that protocol. So I pose a hypothetical. Say you're trying to establish secure communication with someone you just met. You plan to securely communicate with this person using many different forms of communication: email, IM, VoIP, websites, file transfer, remote login sessions, everything you can think of. You're on the phone, and you have just finished reading each other your PGP fingerprints. Okay, now you should exchange SSH fingerprints, then OTR fingerprints, then X.509 certificate fingerprints, and so on. Get comfortable, you're going to be on the phone for a while. Or wait, why bother? Just end the call, and then send the other person an email, signed with your PGP key (which you've already exchanged), containing all that other information. Notice what just happened. You've already authenticated this other person, you've already accomplished that difficult task. Now you can use that authentication which you've already done as a basis to secure many different communication protocols. In fact, why do you need to do anything manually to take advantage of this? Shouldn't your computer do it automatically? That's the basic insight. Why do I need to use a specific method of authentication for a specific form of communication? Why not just use whichever method is most practical given the circumstances. Why should I need to authenticate with a single person more than once? Why not just once. This basic premise is what's so revolutionary about Monkeysphere. What actually is Monkeysphere? It's just a way to use the authentication mechanism of one protocol, OpenPGP, to authenticate two other protocols, SSL and SSH. In other words, it's the beginning of the process by which the unnecessary mapping between communication methods and authentication methods starts to breakdown. So here are the tenants of the design philosophy that I think so desperately needs to be used as the basis for cryptographic protocol design: 1. A persistent “identity key” is used for authenticating transient keys used for encryption of message content. 2. All encrypted communication protocols derive their authentication from the single identity key. 3. Identity keys are exchanged, and encryption starts, immediately. 4. Authentication could place at the beginning, or at a later time. 5. A whole list of authentication methods are supported. 6. All communication protocols are authenticated by one authentication event, which utilizes the single most convenient from among the supported methods. 7. Bottom line: communication protocol is independent of authentication method. What I imagine as a base reference implementation of this philosophy, is a combination mail client, IM client, and VoIP client, with a unified contacts interface. Each contact is defined by an identity key, and identified in the interface by a local pet name which the user chooses, though the contact may suggest one. For example, the user “bumps” with a person whose smart phone is configured to suggest the name “Robert Foo” (which is his actual full name). But this particular Robert Foo is the user's mother's brother, and so she ignores that suggestion and chooses the name “Uncle Bob” for this contact. When she's using the contact interface, to send emails or initiate chats or phone calls, she needn't even mess with the actual email addresses, SIP addresses, or XMPP addresses. She just, for example, starts a chat with “Uncle Bob”. The identity key isn't used for encryption of message content. Rather, it's used for verification of the keys that are used to encrypt message content. Each communication protocol can have the security properties desired. For example, perhaps by default phone calls come with perfect forward secrecy and deniability, and are not recorded, chats come with perfect forward secrecy and deniability, but are recorded, and same for email, except email with people in the “business contacts” section of the contacts, which are non-repudiable. Or whatever. The point is that each form of communication can get it's own desired security properties, but all are authenticated by a single identity key which isn't ever used for any other purpose and so doesn't interfere with the unique security properties of the respective protocols. Now say our user, call her Alice, has chatted with Uncle Bob a few times. Then, Bob sends her an email, using an email address that her client software has never seen before. But it identifies itself using the identity key that her client knows as “Uncle Bob”. And therefore, the email (from an address she's never seen before in her life), is automatically presented to her as being from “Uncle Bob”. So the problem of authentication is confirming that the identity key which defines a contact truly belongs to the person that the user had in mind. That the Uncle Bob key really does belong to Alice's uncle, Bob. This is up to the user to determine. The program provides several convenient ways to do this. Ever time the user makes a phone call, short authentication strings appear ready to be verified in case the parties to the conversation decide to do so. While chatting, the user can at any time click “enter secret” to offer to the other person's client to do a socialist millionaire's exchange against the other persons' secret. At any time, the user can scan a QR code, containing a key fingerprint (and which may also contain an email address, and XMPP address, a SIP address, and a suggested pet name, among other information), and confirm that it matches the key. But even if the user doesn't do any of these things, keys are agreed upon and used, preventing a passive listening attack from working. Whenever the user does do any of these things, from that moment on she can be assured that all future and past communications will not be/have not been MITMed. Perhaps the way two users got each other's contact info was using QR codes, in which case the keys were authenticated right from the beginning. Or maybe the users exchanged email addresses, exchanged a few emails over the course of a week, and then made a phone call and verified the short authentication string, and the keys were authenticated a week after they started to be used. Maybe the users communicate for years, and only then decide to talk about something super secret, and do a socialist millionaire exchange on some shared secret. Whatever. I envision that in the contact interface, you can click on a contact and select “authentication information” or “is this really the right person” or something like that, and see information about what method(s) have or have not been used to authenticate that contact. Provided with this tool, with a selection of easy to use authentication methods any one of which can be used just once to authenticate encryption for all forms of communication with a certain contact, the bulk of the internet connected world will finally be able to enjoy the benefit of strong and strongly authenticated end-to-end encryption, rather than just a few crypto geeks. This tool's effects on human freedom will be profound and long lasting. Ultimately, I envision that this combined mail/IM/VoIP client will be expanded to support other protocols (anyway this program is really just existing clients for the various protocols tacked together into a single interface). And as it grows to support other protocols, it will come to support every protocol that the Freedom Box will come to serve, and it will become the Freedom Box interface application. I hope that I have captured the imagination of even just one person with skills to help bring this vision about. Thank you for your time. Boaz _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
