Surespot looks like an open source alternative: https://www.surespot.me/ https://www.surespot.me/documents/how_surespot_works.html
technical overview 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. -- Moritz Bartl https://www.torservers.net/ -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
