Again, if I’m looking into the future, the first thing I wanna do is deal with the choices that aren’t really choices. The second thing I wanna do is worry a little bit less about information freedom. And the third thing is I wanna worry a lot more about forward security and this key disclosure problem. What happens when you show up at customs? You know what happens when you’re living in the open and someone comes knocking on your door.
Nikita Borisov, Ian Goldberg and Eric Brewer wrote a pretty nice paper – I think in 2004 or 2006 – called “Off-the-record communication, or, why not to use PGP”. And in this paper, they make a pretty simple observation. They say – okay, everyone’s familiar with the PGP1 model, you have an email you want to send to Bob, you encrypt it with Bob’s public key and you send it to Bob. The next time you wanna send an email to Bob, you encrypt it with Bob’s public key and you send it to Bob. You could do this for twenty years.And the problem is that if at any point in the future, Bob’s public key is compromised, all previous traffic is compromised as well; that someone could easily just record all the traffic, and that’s totally not unrealistic today, and then at any point try and compromise Bob’s public key and go back and decrypt all of the previous traffic. So the first thing they notice is that one key compromise affects all previous correspondence. The second thing that seems weird is that the secrecy of what I write is a function of your security practices. I mean, I feel like I’m somewhat paranoid and I have reasonable security practices, but I don’t know about the people that I am communicating with. I would like for what I write to somehow be a function of my security practices. And the third thing that they note is that the PGP model gives you authenticity, but not deniability. If I sign my email “Hey Bob, today I was thinking that Eve is a real jerk” and at some point this email is compromised and discovered, there’s no way for me to deny that I wrote this. So the nice thing is that Bob knows that I wrote it, but there’s no way for me to deny to everyone else that I wrote it – you have this ‘undeniable’ problem. And so the OTR2 model works a little bit differently. What happens is every time you wish to communicate you do an ephemeral key exchange, and you have public private key paired just like normal, except it is only used for signing ephemeral key exchanges, it is never used to actually encrypt data. Then, every time you’re exchanging messages your message also includes one-half of a new key exchange. So each time you complete a message exchange you are also doing a new key exchange. So the key material that you have is constantly rolling forward and the old key material is discarded. If at some point in the future, somebody comes and tries to get something off of your computer, there’s nothing for them to get – the old key material is gone, there’s nothing that they can use to decrypt previous traffic, so it gives you forward security. Additionally, you have messages that are encrypted with a session key, and then they are authenticated with Message Authentication Codes (MAC3). The key for the Message Authentication Code is derived from the session key, and two parties have that session key: me and Bob, right? So signatures are undeniable because there is only one possible author, but MACs are deniable because they have two possible authors. Both me and Bob know the key that could be used to authenticate this message. If Bob receives an email with a MAC on it, he knows that he didn’t write it so it must have come from me. But now, he can’t take that and show it to the world and say “Moxie wrote this”, because it’s just as likely that he wrote it.
Additionally, since this session key is constantly rolling forward, the old MAC keys are constantly rolling forward as well, and every time they roll forward you can just broadcast them in the clear, and now anybody could just as likely have created an old message. So you get authenticity, but you also get deniability.
These are two principles that I think are going to become more and more important in the future as we roll forward.
Some projects that I’ve been working on in that line – one is called ‘Whisper Systems’. And the idea is to try and bring forward secure protocols into mobile devices. So these are these two spaces: mobile devices are this place of choice that isn’t really a choice, and forward secure protocols is this thing that’s becoming increasingly important with this new strategy of key disclosure.
So one of the apps we have is called ‘RedPhone’, and basically it’s an encrypted voice application for mobile devices. The way it works is through VoIP4. And there’s this problem – doesn’t VoIP suck? It tends to; it tends to really suck in the mobile environment. And so, looking at this we wondered – okay, what is so bad about VoIP in the mobile environment? And we realized that the problems often (almost always) come down to the signalling layer. So the way it usually works is there’s some Asterisk server out on the Internet and you do signalling through this thing, you have to maintain a TCP connection and then do ‘SIP’ (Session Initiation Protocol) to notify the other client that you want to try and call them and other stuff. It’s a big problem because in the mobile environment your connection status is usually pretty flicky and you are moving in between networks. Maybe you still have a connection, maybe you don’t. Maybe you think you do but you don’t. And also, it doesn’t allow your device to go to sleep ‘cause you have to maintain this either UDP or TCP connection and so your device can’t ever really power down, so it’s bad for your battery.
Well, what we realized is that the mobile environment actually has an entire signalling infrastructure already built in – the telecoms made it for us, and they use it to signal mobile devices. And so potentially we could just leverage that. Now, instead of like some Asterisk server allowing you to communicate with other devices using SIP, we just use SMS which is a signalling piece that’s already build into the mobile environment. The nice things about this are that you don’t need to maintain some constant network to some server, so your phone can go to sleep; you don’t the equivalent of like a Skype ID or a SIP account or something like that – you can do addressing based on your normal phone number because we are using SMS for the signalling; and the third thing is that you don’t need to run a VoIP server or set up an account or anything like that – you just install this small piece of software and now you’re ready to call anybody whose number you know. So then the question is – okay, how do we provide mobile security? Normally, VoIP has just a simple RTP string of voice data between two devices, and we have what’s known as ZRTP5 string – that’s a protocol that was developed by Philip Zimmermann, and it’s actually a pretty nice protocol. The way it works is that you do some ephemeral key exchange, and then from that key material you derive what’s known as a ‘Short Authentication String’. And once the call is set up, at the bottom of the in-call screen you display the ‘Short Authentication String’ – in this case, the two words ‘flatfoot Eskimo’. Now, if there’s a man in the man-in-the-middle attack, the key material between the two devices would be different: you have one key on one side of the main-in-the-middle, and one key on the other side of the man-in-the-middle. And so these two words would be different on the two phones that are trying to talk to each other. So what happens is now you set up a call and you just read these two words to each other (‘flatfoot Eskimo’), and if they are the same on both sides, you know that the call is authentic, and so you don’t need certificates, certificate authorities, you don’t need fingerprints, digital signatures, Web of Trust – none of that stuff. You just read the two words to each other and you know you have an authentic call. It’s also kind of fun – it’s like refrigerator magnet poetry or something like that – the two words are always like a profound haiku, you know: “Flatfoot Eskimo – yeah, that’s how I’m feeling today”. So it’s actually kinda fun to read those things to each other.
The other app we have right now is called ‘TextSecure’, it’s an encrypted text messaging application using a protocol that’s derivative of OTR – this thing that gives you nice forward security and deniability properties. And it works just like the normal ‘Stock SMS App’ for Android, we’ve cloned it feature for feature. So the idea is you can install this and fully replace the default messaging app and use it to message any way you like and at the same time if someone else is running this, you get an encrypted session. The way the session works is as follows: every message you exchange includes one-half of a new key exchange, and so the key material that you’re using is constantly rolling forward. If someone were to record all of your SMS traffic and later try and compromise your phone and get something to decrypt all of that – they can’t because those keys are gone.
So anyway, these projects are a small hope of mine that we can come up with technical solutions to reduce the scope of the choices that we need to make. You can download all of this stuff for free – all the Internet apps and ‘GoogleSharing’ – online. Feel free to contact me, and thank you for listening to me talk.
1 – PGP (Pretty Good Privacy) is a data encryption and decryption computer program that provides cryptographic privacy and authentication for data communication. PGP is often used for signing, encrypting and decrypting texts, e-mails, files, directories and whole disk partitions to increase the security of e-mail communications.
2 – OTR (Off-the-Record Messaging) is a cryptographic protocol that provides strong encryption for instant messaging conversations. OTR uses a combination of the AES symmetric-key algorithm, the Diffie–Hellman key exchange, and the SHA-1 hash function. In addition to authentication and encryption, OTR provides perfect forward secrecy and malleable encryption.
3 – MAC (Message Authentication Code) is a short piece of information used to authenticate a message. The MAC value protects both a message’s data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content.
4 – VoIP (Voice over IP) commonly refers to the communication protocols, technologies, methodologies, and transmission techniques involved in the delivery of voice communications and multimedia sessions over Internet Protocol (IP) networks, such as the Internet.
5 – ZRTP is a cryptographic key-agreement protocol to negotiate the keys for encryption between two end points in a Voice over Internet Protocol (VoIP) phone telephony call based on the Real-time Transport Protocol (RTP).