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 my house to mail.google.com looks like this:

  • [adam@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 (my 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, cherie. 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 adam and cherie.

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 adam encrypts a message for cherie with a key, then cherie decrypts it using the same key. Simple right, except for the fact that cherie needs to know the key! Somehow we need to get the key to cherie 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 adam has a key pair and cherie 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 adam gives cherie his public key and cherie gives adam her 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: adam can now take cherie's public key and with his private key can derive a secret. Cherie takes adam's public key and with her private key derives the same secret! Re-read that part a few times. This shared secret is unique to adam and cherie, 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.
  • When a user is created and its public keys uploaded to the server, the server signs the public keys. Clients that download the public key then validate the signature of the key against the hardcoded server public key in the client. This ensures a MITM attack trying to use a rogue key pair to impersonate a user will be prevented.

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

  • adam lost his phone, luckily he has his identities backed up on Google drive
  • adam buys a new phone and installs surespot
  • adam restores his identities from the backup
  • adam 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:

  • adam wants to send cherie a message
  • adam asks the server for the latest version of cherie's public key
  • adam verifies cherie's public key (which is signed by the server) against the hard coded server public key in the app and proceeds if valid
  • adam derives the shared secret
  • adam encrypts the message using AES 256bit GCM using the derived shared secret as the key and sends it to cherie, the to and from key version used to generate the message are included as part of the message
  • cherie receives the encrypted message
  • cherie downloads and verifies the version of adam's public key needed to derive the shared secret for the message
  • cherie derives the (same) shared secret
  • cherie 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 V. 2.3 thru 4.4 supported
  • iOS 6+ 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 is 100% 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.

surespot is available on:

Get it on Google Play Available on the App Store

donate to surespot