Category Archives: protocol

Keeping it private – part 2


So in the last post we described the setup of the app and how it starts off on its journey to build a private channel.  To quickly recap, the phone now has a public/private keypair, a secret key that you’ve exchanged with the system and the system has got your public key and knows it’s from you, which gets stored in our directory ready to give it to anybody else who asks.

The next step is to build a private, encrypted channel between you and your friend.  The first step is to get their public key, so the app asks us, what the registered public key is for your friend[1].  We give that to you using the private channel between you and the system and we sign that response, so you know the public key comes from us not to mention coming back over our shared secret channel[2].

You then generate a channel name (a friendly name, usually the persons name), channel id and a new secret key, the app bundles this up in much the same way as it did when it started to talk to the server.  The bundle of data, including your public key is encrypted using your newly generated secret key and then your secret key gets encrypted with your friends public key.  You also sign this entire packet.  The phone then sends that to us.  We do a few things to just double check that this message is from you.  Firstly it has to come over our shared secret channel which we know is from you and secondly the digital signature on the channel message (which we’ll forward on) has to be signed by you[3]. If that’s ok, we send it on to your friend.

When your friend gets your message, the first thing they do, is get your public key from the server.  They then check the signature on the negotiation message to make sure that it really has come from you.  If it isn’t, the throw it away.  They then decrypt the first part of the message using their private key.  In this part is the secret key that you are going to use to chat with each other.  They then send an acknowledgement message to you, encrypting that message with their secret key, signing it with their private key[4] accepting the channel.

So what have you got now?  You have now exchanged a secret key with your friend that we the system haven’t seen, in a way that makes your sure that you’ve exchanged that key with who we say it is.  You can now chat away, with us forwarding your messages knowing that nobody in the middle can read your messages or impersonate your friend.

We’ll start to explore how the app detects if we’re messing with the public keys that we’re publishing, in the next post, when Mars attacks.

[1] This is to ensure that you don’t get sent a different public key in the message at face value asserting to be from a specific phone.

[2] Some might wonder what the point of signing the message is if it’s coming from the server over our shared secret channel which we’ve already authenticated.  This is a practical measure for security.  Secret keys must be available to the server processes to wrap and bundle our messages and anything we forward to you from others.  That means if a front line server is compromised somebody could start to impersonate us on that server fairly easily.  Our private key on the other hand is kept well away from the front line machines in a processes not on the same network directly connected to the servers terminating chat connections.  If we can afford it, we’ll use a hardware security module.

[3] This proves that someone hasn’t just managed to obtain your secret key (say from us) and that you have access to your private key still, the other half that we’ve authenticated and hold.

[4] Lastly, to close the loop on the protocol, the far end signs the acknowledgement.  Now notionally this isn’t actually necessary as you’ve encrypted your secret key with their public key so if they’ve decrypted it (and sent you a message back) you can assert they’ve got their private key.  That’s all well and good for single user channels but that isn’t so easy when you want to have multi-person chats with a group of friends.

Additionally: Private key operations are expensive, they take lots of processing power and that in turn eats battery life.  We use them for critical parts of the protocol but not everything all the time.


Keeping it private – part 1


In the first of the series about explaining how Talaria keeps your chat private I wanted to give a very  quick overview about how it works.  It’s fairly technical in detail but if you want to understand any of the building blocks in more detail, leave questions in the comments.  We’ll start with the overview and post the actual messages from the system once we’ve done the high level stuff.

Talaria keeps your messages private by first creating a public/private key pair.  The public half of this, you’re going to give to us, so we can give it to your friends when they want to start a private channel with you.  After you’ve created the key pair you’ll create another key, a secret key, you’re going to share this key with us.  This is used to protect messages sent between you and us the chat server.

You give us a bundle of information, your phone number, your public key and the secret key you generate.  Using our public key (which comes with the app when you download it) you bundle all of this up, number, public key, secret key, id and send it to us.  We now have your public key, a secret key to talk to you with and your phone number.  The next step is important.  We don’t just publish to the world that your public key corrosponds to that phone number.  Next we generate two numbers, encrypt them using your secret key and then send them back to you via text message.  The application then decrypts this text message, takes out the two numbers, adds them together and sends them back to us over the internet.  We verify that response and if we’re happy we record your public key as being linked to that phone number (a phone number that your friends already have in their address book on their phones).

So what’ve we got now? Well, you’ve got a public/private key pair, we’ve got a shared secret key and we have a strongly authenticated binding of your phone number with your public key.  Which is all well and good, now we can exchange messages that nobody can read or impersonate.

A quick note about using SMS.  Some of you will be thinking that SMS is the sort of thing that can be manipulated by unscrupulous actors and that someone who has access to the telecoms infrastructure could impersonate you and receive the verifier and do this whole process pretending to be you.  This is true, the first time, but we’ve got some faith in human nature here and critically we have a number of ways to enable this to be detected, in that people quickly work out that they’re in fact not talking to the person they think they are. We’ll discuss is some detail the possible scenarios how we enable people to detect compromises in the system. Once you’re set up on the system of course any change to the public key that’s been published is detected by both parties.  As part of the startup process the app asks the system, what public key is it publishing for itself and checks to see if those are the same.  It’s also double checked during the login phase which we’ll describe later.  We do also support ‘usernames’ but what happens if you lose your key?  If you don’t back it up somehow or otherwise protect it?  We’ve come up with a way to back up keys on paper or use Mifare cards for those with NFC readers on their phones but that starts to get a bit user un-friendly and we expect the majority of people won’t make good use of that.

Still no private chat channel though?  We’ll cover that in the next post.