Traditional IM (OTT), SMS, etc. communications send messages in “plain text”. This means that the information is sent without anything done to protect the information from being read by anyone else. It is akin to sending a postcard.

Imagine you are on vacation in Italy, Florence to be precise, and you send a postcard to your sister in London. As the postcard travels anyone that touches it can read it. Typically you do not send information like a credit card number or your pin number or an intimate thought using the postcard format. Today this is what sending an email or a text message or an instant message or a picture is like. The message is the postcard which travels along many hops until it reaches its destination. At every one of these “hops” the message could potentially be read.

For example you, are reading an email at Starbucks. To read this email the information travels from the server (gmail) through their (Google’s) ISP, to Starbuck’s ISP, to the Starbucks location you are at. At any one of these points the email can be read. To illustrate this we can run the traceroute command which shows the hops your data is taking to reach its destination.

for example the traceroute from alice’s house to mail.google.com looks like this:

• [alice@monkey ~]$ traceroute mail.google.com
• traceroute to mail.google.com (74.125.225.213), 30 hops max, 60 byte packets
• 1 DD-WRT.mugello (192.168.10.1) 0.506 ms 0.598 ms 0.794 ms
• 2 24.9.100.1 (24.9.100.1) 16.723 ms 17.837 ms 32.677 ms
• 3 ge-1-39-sr01.summit.co.denver.comcast.net (68.85.220.81) 17.710 ms 17.711 ms 17.828 ms
• 4 te-0-3-0-5-ar02.denver.co.denver.comcast.net (68.86.179.13) 21.140 ms 22.087 ms 22.145 ms
• 5 pos-0-7-0-0-ar02.aurora.co.denver.comcast.net (68.86.128.246) 25.333 ms 25.334 ms 25.448 ms
• 6 he-3-4-0-0-cr01.denver.co.ibone.comcast.net (68.86.90.149) 24.116 ms 20.657 ms 20.689 ms
• 7 * * *
• 8 173.167.57.206 (173.167.57.206) 17.512 ms 18.328 ms 18.402 ms
• 9 72.14.234.57 (72.14.234.57) 16.190 ms 16.218 ms 16.160 ms
• 10 209.85.251.111 (209.85.251.111) 16.674 ms 20.817 ms 21.715 ms
• 11 den03s06-in-f21.1e100.net (74.125.225.213) 17.238 ms 18.200 ms 18.152 ms

We can see that to get to Google’s server at mail.google.com, the data is being routed through at least 11 hops, anyone of which could have a chance to intercept the information. Now if you controlled the routing and could make the data on your network always pass through a certain one of these hops, you could monitor all of the “plain text” data being sent on your network. Not exactly “secure”.

so how do we get around this?

You may have seen at times when you used your web browser that the URL was pointing to https:// instead of http:// and there was an associated padlock icon or similar. This indicates that the connection is being made using SSL or Secure Sockets Layer. This means that the connection from your web browser to the server is encrypting the information. “In cryptography, encryption is the process of encoding messages (or information) in such a way that eavesdroppers or hackers cannot read it, but that authorized parties can.” (Wikipedia). So applying this to our mail.google.com traceroute above, this means that only hop 1 (alice’s computer) and hop 11 (Google’s server) can see the information, all that hops 2-10 can see is encrypted HTTPS traffic. This is great! There is however still a problem. We have logged onto https://mail.google.com presumably to send an email, which in this case contains a credit card number. So we send the email to someone at Hotmail, bob. Now the email which is in plain text is sent from Google’s server to the Hotmail server and eventually to the recipient’s device, taking a multi-hopped path much like the traceroute above. At this point we no longer have control over how the message is secured. Is Google using SSL to transmit the message to Hotmail? Probably. Is the message downloaded from Hotmail to the recipient’s device in a secure manner? Maybe, but how can we be sure? Now extrapolate this example to any information you send on the internet. What is happening to your data when it is on the server or in transit in plain text? How could anyone possibly know? How secure is the server at protecting your plain text data from hackers? What are the guardians of your data doing with your data?

enter surespot…

Surespot solves these problems by using end to end encryption. Whereas SSL can be thought of as client to server encryption where the hops cannot access the plain text but the server can, end to end encryption encrypts the data so that only the end users can decipher it. No one along the network route the message takes from one client to another, not any of the hops, not even the surespot server, can view the contents of the data. Only alice and bob.

how does this work?

Encryption is an electronic lock and key system. You take a plain text message and encrypt it using a key (secret). You can then decrypt the message using the same key. Pretty simple. You encrypt data at one end using the key, send it over all the network’s hops and servers, and at the other end it can be read because the key is known. None of the hops and servers in-between can read it because they don’t know the key.

So alice encrypts a message for bob with a key, then bob decrypts it using the same key. Simple right, except for the fact that bob needs to know the key! Somehow we need to get the key to bob but how can we send it over the network? We can’t encrypt it because we need a key to encrypt so we have a catch 22. Or a chicken and egg situation. The answer is we don’t send the key over the network. Well not the key we’re using to encrypt the messages at least.

public key encryption

When a user is created in surespot an associated key pair is generated. A key pair consists of a public key and a private key. These keys allow us to do magical things. So now alice has a key pair and bob has a key pair. The private key is stored on the device, the surespot server does not need and never will have access to it. The public key is given to the user that you wish to exchange messages with. So surespot ensures that alice gives bob er public key and bob gives alice his public key. Now the brilliance of shared key derivation can shine. The key pair algorithm that surespot is using allows the following mathematics to happen: alice can now take bob’s public key and with her private key can derive a secret. Bob takes alice’s public key and with his private key derives the same secret! Re-read that part a few times. This shared secret is unique to alice and bob, only they know, and assuming their private keys remain private, only they will ever know. This shared secret has never been and never will be exposed to the surespot server or any other hops along the network route that the message takes. This shared secret can now be used to exchange information securely. This is the crux of what makes surespot work.

User creation

When a user is created in surespot two ECC (secp521) key pairs are generated, one for key derivation, and one for signing.

The username plus keypairs create a ‘surespot identity’. This identity is stored on the device symmetrically encrypted using 256 bit AES-GCM with a PKCS5S2 key derived from the user’s password (plus salt and other data). The public keys are uploaded to the server where they are signed by the server using the server’s private key. A user may create multiple identities and switch between them at will.

User authentication

To login the client generates a signature using the identity’s private signing key against the username, password, and randomly generated data. The server validates the client provided username, password, and aforementioned signature against its stored public signing key for the identity in question. If successfully verified the client is issued a session cookie which authenticates them for future requests until the session expires or they logout.

As the exchange occurs over SSL, session cookies are thought to be a secure enough mechanism to facilitate authentication, but in the future every request could be validated against the signature. The fact that messages could not be decrypted by a session hijacker given the end to end encryption nature of the system also factors into this decision.

Identity backup/restore

As the private key stored on the device is the, uh key, to unlocking all of the data, it is of utmost importance. In the case of a lost or stolen device, if the key is lost along with it, so is all of the data. Identity backup/restore and key versioning help to mitigate this problem. A user may backup their (encrypted) identities (username and key pair history) to device storage, or the cloud and restore them upon demand. Obviously the security is only as strong as the password used to store the identity in whatever cloud service and the surespot password, so make them strong! Never shall a private key be stored on a surespot server.

Man in the middle

MITM is currently thwarted by the following:

• standard SSL implementation.
• The user creation mechanism in the client generates two ECC 521 bit public/private key pairs, one for encryption and one for signing. The two public keys are uploaded to the surespot server along with the desired username and PBKDF derived password. The server then signs the user public keys, the username, and the key version with its private key. The client is compiled with the server’s public key. When a message is received the client downloads the sending user’s public keys and server signatures. The key signatures are then validated against the compiled public key and if the validation fails the message cannot be decrypted and the user is told.
• Starting with version 62 on Android and 10 on iOS the client side key generation mechanism signs the new public keys, username, and version with the previous private key. This creates a chain of trust going back to the initial key pairs. Any new public key presented to a client is validated against the signatures that were created by the user’s previous private key. Thus an attacker in control of the server would not be able to inject a rogue public key and perform a man in the middle attack.

Key versioning/revoking

A user may generate a new pair of key pairs at any time. This process is as follows:

• the user requests a “key token” from the server
• the user generates a new pair of key pairs and uploads them to the server along with an authentication signature (username, password, random) and a token signature (the received key token, password) generated by the identity’s existing signing private key.
• the server validates the password and both signatures and if valid increments the “key version” and signs and stores the public keys in the database.
• the server notifies other users involved in conversations with the revoker that the key has been revoked.
• clients will receive this revoke notification and act accordingly.
• the old keys are now considered revoked and any message sent using them will be rejected by the server.

Use case: lost/stolen phone

• alice lost her phone, luckily she has her identities backed up on Google drive
• alice buys a new phone and installs surespot
• alice restores her identities from the backup
• alice generates a new pair of key pairs successfully
• attacker with old phone receives revoke message
• old phone knows revoke message is from the same user and promptly logs out and deletes any related data
• any subsequent authentication attempts on old phone will be rejected

Sending a message

After two users invite then accept each other the users are now friends, the two friends can access each other’s public keys, which allows key derivation and message exchange. The scenario plays out as follows at a high level glance:

• alice wants to send bob a message
• alice asks the server for the latest version of bob’s public key
• alice verifies bob’s public key (which is signed by the bob and the server) against the hard coded server public key in the app, and also verifies the client signature using bob’s previous key, then proceeds if valid
• alice derives the shared secret
• alice encrypts the message using AES 256bit GCM using the derived shared secret as the key and sends it to bob, the to and from key version used to generate the message are included as part of the message
• bob receives the encrypted message
• bob downloads and verifies the version of alice’s public key needed to derive the shared secret for the message
• bob derives the (same) shared secret
• bob decrypts the message using the shared secret

Data stored on device

surespot ensures that no message data or keys are stored on the device an unencrypted fashion. This means that even if someone has your device they will not be able to get the information without knowing your password. Users will be prompted to create a secure password upon creating an identity.

Server

• Web application server is running on node.js, written in CoffeeScript
• RESTful JSON API
• Chat implementation utilizes Socket IO (websocket + chat rooms)
• Linux servers
• Databases- Redis and Cassandra.
• Files- Encrypted data files are stored on rackspace cloudfiles and delivered via the Akamai CDN.

Clients

• Android v2.3+ supported
• iOS 7.1+ supported
• Socket IO for real-time updates while app is open
• GCM notifications, for invites, invite accepts and new messages (sound, LED and vibrate notification configurable)
• HTTP caching implementation to reduce bandwidth usage and increase responsiveness
• All cached message contents and users private keys reside on the device in an encrypted state and can only be decrypted with a password

surespot clients are open source this means that anyone on the planet can review the source code and find flaws. When you have an entire planet looking at the source code you can be assured that the implementation is highly scrutinized and proven. This means that surespot does exactly what it says it does, there can be no back doors or pilfering of any information.