surespot stores the following data on its servers:
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.
Any discovery of a user's real identity can be mitigated by using an anonymous email account to register with Google as well as a pre-paid or no contract phone that has no ties to the user.
As another mitigation strategy, an advanced user could compile their own surespot client from source and prevent a gcm id from ever uploading to the surespot server and completely remove this threat. This functionality could easily (and probably will) become a user setting in the client.
Even if an attacker were to gain access to all of the data stored in the surespot database there is not a way they could read the encrypted message data without the user's private key which resides on their device and is never sent to surespot servers. Because usernames are completely arbitrary and chosen by the user the surespot database in an attacker's hands represents an anonymous and practically useless dataset.
Passwords are stored salted and hashed in the surespot database rendering them useless to an attacker. Even if a user were to expose their password, without the private key which resides on the device the attacker can do nothing to decrypt a user's messages.
Regular backups of the database are encrypted using AES-256 and stored offsite and kept for 1 week.
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.
Regular backups of the database are encrypted using AES-256 and stored offsite.
In the event of a server compromise the server could be rebuilt from the database backup in minutes. New server private keys would be created which would require an upgrade to the client.
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.
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.
Ensure google and surespot passwords are completely different, and strong, and use local device identity backup only if possible.
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.
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.
Be careful with your device; don't allow root access to unknown apps; don't install malicious software, and don't let your device fall into the wrong hands.
If possible, powering down the phone before a unwanted party gains physical access will clear this information from the device memory and require login to surespot again to view messages.
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.
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.
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.
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.