[Freedombox-discuss] Novel design philosophy for end-to-end cryptographic protocols and software

[Boaz]

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