-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GitHub here: https://github.com/surespot, includes client and server software. Would be interested in hearing folks' thoughts on it.
Dev is @adam2fours, we ought to invite him to the conversation if he isn't on libtech. On 07/15/2013 06:41 AM, Moritz Bartl wrote: > 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 faciligroup chattate 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. > > - -- Michael Carbone Manager of Tech Policy & Programs Access | https://www.accessnow.org mich...@accessnow.org | PGP: 0x81B7A13E PGP Fingerprint: 25EC 1D0F 2D44 C4F4 5BEF EF83 C471 AD94 81B7 A13E -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJR5EdDAAoJEDH9usG3Jz33T0YP/i0DXUvRc/usUybFrQxxn0ZM h+yslfJbdK+JVTwOyp9Fpt2nXKFgcRd3LsHFr6fvPOei4ZjJy5xcyekVfeB1sULl B8wvb0Lg5dj0jM7LXB0D6oFEEj8H5ODpqcOd3+QIYzFcp1nfpj8+y51U5D7u+Moe Uv3NG9jRhTbnpwy27B2O/m1l1F3KInFuOIvSAe+4ylVZ3yrRqTN2fXGWZyvEY3F/ MEPrSqkBy25n1oI0k0sXsKZ9g0ol2dKwUkxhA8czrUZSN0ETQjVkGaUUWaiqlXAC eJais8k0t62DVRuzIqU4cpHoiuRFFWUD62BO0v+kj67I/45ZxW+f2Cv56jaUwIe8 ZIaeEYZnq1u5i/9bu4zcMMv+z7W0rhUbrq5TA05uW2Cc7/M7MlAPR10+GzcZmawX VPsMKaWplguwzwvDJDdiEGmYgJcnkwJpC+8kPyus9ucHPCV+84SuSEVeg1Qma0ro KXWwt8Q/rg+T8hO1YhEc8o7BjLgbY3551zbZklJqCwGeLByfhkQYS9LExXBodQJp h/f1uvN4SknmgpSczk922RbY9frWrQFn/IBUQ5+pzuQB+3s6+zKxoAAoxyY26zHI HpLr7ESP5uY9jaVJv3xArzWAnZBNG9Jdyzzdx5JqYyOEdSnv8zslyOLBXGzRNMme ZqI0eM5s5/Lf/ZjHCEVi =yBgf -----END PGP SIGNATURE----- -- 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
