Moritz Bartl <mor...@torservers.net> writes: >Surespot looks like an open source alternative: > >https://www.surespot.me/ >https://www.surespot.me/documents/how_surespot_works.html
surespot's code may be excellent (I haven't looked at it), but their front page at https://surespot.me/ makes a promise it shouldn't make: | You can delete your message from the receivers phone. | | Be confident sending private information and pictures. You have | control over your messages, when you delete a sent message it will | be removed from the receivers phone and images are not sharable | unless you make them so. Software can't be simultaneously open source on the client side and make promises about how the client side will behave. Actually, one can't really make that commitment even when the client side is closed-source (for example, if a closed-source app runs on an open source OS, then when the app tries to delete the message, the OS can retain a copy). But anyway, the loophole is even easier to exploit when the application code itself is open source. Surespot is just one of several apps making such claims. I wrote a bit of a rant about this trend here: http://www.rants.org/2013/06/09/privacy-promises-and-client-side-betrayal/ Again, this is not about their code, which may be fantastic. It's just about their marketing language around the code. Best, -Karl >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. -- 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
