How does WBB Chat work?
User creation
Users are created with two ECC (secp521) key pairs one for key derivation, and one for signing.
The username plus key pairs create a ‘WBB Chat 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.
As the exchange occurs over SSL, session cookies are thought to be a secure enough mechanism to facilitate authentication. 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 key to unlocking all of the data. In the case of a lost or stolen device, if the key is lost along with it, so is all of the data. 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.
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
- user lost his phone, luckily he has his identities backed up on Google drive
- user buys a new phone and installs WBB Chat & WBB Dashboard
- user restores his identities from the backup
- user 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:
- user1 wants to send user2 a message
- user1 asks the server for the latest version of user2 public key
- user1 verifies user2 public key against the hard coded server public key in the app and proceeds if valid
- user1 derives the shared secret
- user1 encrypts the message using AES 256bit GCM using the derived shared secret as the key and sends it to user2, the to and from key version used to generate the message are included as part of the message
- user2 receives the encrypted message
- user2 downloads and verifies the version of user1 public key needed to derive the shared secret for the message
- user2 derives the (same) shared secret
- user2 decrypts the message using the shared secret
Data stored on device
WBB Chat 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.