surespot stores the following data on its servers:

• Usernames.
• Friend relationships (who is friends with who, blocked who, ignored who, deleted who).
• Conversation relationships (how many friends currently you have a “conversation” with – meaning have a sent or received a message with).
• Messages in the amount of MAX_MESSAGES_PER_USER (currently 1000) which each have a server timestamp, to username, from username, and encrypted content, or link to encrypted content (image or file).
• Encrypted message file data (image or other – anything but encrypted message content) is stored (encrypted in the same way text messages are) on rackspace cloud files.
• Total messages sent per user.
• Total images sent per user.
• Current message count per user. (How many messages they have stored in the database currently, will always be <= MAX_MESSAGES_PER_USER (currently 1000)).
• Signing (DSA) public keys and versions.
• Encryption (DH) public keys and versions.
• Encrypted “friend images” or avatars and friend aliases that are assigned to certain usernames. These are encrypted with a key generated from ECDH key derivation of assigning identity’s private/public keypair.
• Google GCM id (used for push messaging) which is related to the username in the surespot database.
• Apple APN token (used for push messaging) which is related to the username in the surespot database.
• If voice messaging is purchased, a purchase token given to us by Google or Apple which is related to the username in the surespot database.
• Server logs may contain any of the above information and are in a 20 log – 5MB per log rotation.

Database Exposure

If an attacker were to obtain access to the surespot database they would have access to the above information.

An attacker that gained access to the surespot database server could delete or otherwise corrupt user data, potentially disrupting the surespot service.

Server exposure

If an attacker were to gain access to a surespot server machine they would have the ability to prevent surespot from working by changing the server private keys forcing all public key validation to fail on the client. (As public keys are cached when they are verified this would only affect messages generated with keys that have not been cached already).

An attacker would have access to the database and could delete all of the data.

Man in the Middle prevention

On top of SSL surespot prevents MITM attacks in the following ways:

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.

Identity (private key) backup

Practically, identity (username + private key) backup mechanisms are needed to facilitate the features people expect from a social network like application. In the event of a lost or stolen phone one can not expect a user to simply create a new identity and lose all of the relationships and conversations contained within the application. Hence surespot provides two identity backup mechanisms which have different threat implications.

1. Backing up one’s identity to local storage using the “backup identity” feature in surespot is the safest mechanism. It reduces the key exposure to devices that have physically had the key copied to them. As long is one as careful to not give the private key to anyone there is minimal threat introduced here. If an attacker were to gain access to the private key it is stored encrypted with 256 bit AES-GCM with a key derived from the user’s password using a PBKDF, so they would have to know the user’s password also.
2. Backing up one’s identity to Google Drive opens up the following threats. The identity is stored (as above encrypted with 256 bit AES-GCM with a PKBDF key derived from password) on Google Drive’s cloud servers. This means that we cannot control who gets access to this encrypted backup, we are trusting Google to ensure that no-one can access our private keys. Again as the keys are encrypted, the obtainer of the keys would have to know or brute force the password to do anything with them. This threat grows if the Google account password and surespot password are the same. For all we know Google could be storing passwords in plain text!

Stored client data

No decrypted message contents are stored on the device filesystem. The user’s identity (username plus private keys) is stored encrypted on the device with 256 bit AES-GCM using a salted key derived from a PBKDF upon the user’s password. An attacker with access to the device would have to know the user’s password to be able to decrypt the private key to generate the shared secret to decrypt the messages.

Caching

Shared secrets are cached in the device memory by a background service that starts when the application is launched for the first time after the phone is booted. After a successful login has occurred shared secrets are cached in the device memory and used as needed. An attacker with physical access to the device that has shared secrets cached could potentially scan or dump the memory for the secrets and decrypt messages. There is not a lot that can be done to prevent an attacker getting access to the data they want should this threat scenario occur. Various protections could be put in place to make this harder but a determined hacker with device access in this scenario will probably be able to gain access to the information they seek no matter what precautions are put in place.

Login validation, sessions, and web method access

Sessions are created by checking the user’s password plus a signature validation of the username, password, and a random token generated by the client, against the data stored by the server upon creation of the identity. Replay attacks / session hijacking are prevented by SSL. If this is deemed to be too insecure, additional security could be implemented with a challenge/response mechanism as used by the majorly destructive operations described below.

Because sending and receiving messages that can actually be read requires a private key and validated public key, a session hijacker without the associated private key would not be able to read any of the associated encrypted message data, nor send a readable message to a user.

A session hijacker would be able to delete messages and images, invite and remove friends (from the list of friends, not actually delete the associated identities), and change image unlock state.

Majorly destructive operations such as deleting an identity, generating new key pairs, and changing passwords require re-authentication which includes checking a client signature against a token issued by the server so could not occur with a hijacked session.

A majorly destructive operation can only be initiated by a client with a valid username and matching private key set so again an attacker would have to gain access to the device and know the password to be able to accomplish execution of any of the majorly destructive operations.

Encryption strength

All messages and data (images and other files) are encrypted using 256 bit AES-GCM with the shared key derived using ECDH with 521 bit keys. The shared key is never uploaded to any server or stored physically on the device. It is only ever generated and stored in device memory. Assuming the private key remains private it would be extremely hard to decrypt any message sent with surespot today.

Lost/Stolen device

In the case of a lost or stolen device there exist the following threats. As a surespot session lasts 72 hours (we plan on making this user configurable), the attacker holding a device where surespot has a valid session will be able to open surespot and view any messages.

Rogue clients

There is no way for any software to guarantee the behavior of a client, or that the client is “authentic” and has not been tampered with in some way. Features such as deleting a message from a remote device, or deleting a revoked identity depend upon the client obeying the instructions the server sends it. There always exists the potential for an unsavory user to create or use a hacked or modified client and not perform the expected actions when asked to by the server. The good news is that there is no way for a rogue client to compromise the security of a message. In order for a rogue client to engage in a conversation with a legitimate client, the rogue client would have to abide by the same rules – that is use the same encryption methods, follow the same key generation procedures, etc., therefore the actual act of encrypted message exchange would have to be preserved, otherwise no encrypted message exchange could occur.

In short put your trust in the users you are exchanging data with, not in any technology that claims it can control what a client (rogue or legitimate) does with that data once it has received it.