Search Mailing List Archives
[liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
moritz at torservers.net
Mon Jul 15 03:41:45 PDT 2013
Surespot looks like an open source alternative:
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
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.
More information about the liberationtech