Protecting Your Messages with End to End Encryption

Since the beginning of development, data security, especially as it pertains to messages sent between users, has been paramount. The initial encryption that was added during development was always meant to be reworked before launch since what was in place was inadequate and was vulnerable in the event of a server breach.

So what does this mean? As simple as I can explain it, it means that when you send a message to another user, only that user can read the message. No one else, not even Tower, can read that message.

In more technical terms:

Private & Public Keys

When you log in to Tower on any device, we create a P-256 ECDH key used for encrypting and decrypting data. This key has two main parts: the Private Key portion and the Public Key portion. The Private Key is then stored in the keychain. Access control for this key is set so that the key can only be read after the first time the device has been unlocked after a reboot, and is only meant for that device (no storage in iCloud.) With the Private Key created we can now access the Public Key of the Private Key. Unlike the Private Key, which must be kept as private and secure as possible, the Public Key can be shared freely. With that in mind, the Public Key is sent over to the Tower API service and persisted.

This happens for every user, on each device they log in on.

Okay, so we’ve Private Keys securely stored on device and we’ve got Public Keys persisted somewhere in the service layer, what’s next?

Key Exchange

When you enter a conversation with another user on the platform, regardless of whether you’re the author or a participant, you exchange Public Keys with the other user. This means that you have a copy of their Public Key and they have a copy of your Public Key.

Encryption & Decryption

Now that we have our own Private Key and our chat partner’s Public Key, we’re ready to encrypt and decrypt messages. For sake of clarity on terminology, when we send a message, we encrypt it. When we receive a message, we decrypt it. To encrypt a message we create what’s known as a Symmetric Key. This is a special key that is derived from combining your Private Key with your partners Public Key, as well as a “shared salt”. The salt can be anything, but it must be stable and identical for both users. We use the Symmetric Key to “seal” the message, which encrypts it. The message is then sent to the Tower API service, persisted, and broadcast to the recipient.

When the recipient receives the encrypted message, they decrypt it by doing, essentially, the reverse of the encryption process; convert the encrypted message a “sealed box”, create a Symmetric Key from their Private Key, the authors Public Key, and a mutual salt, and finally using that Symmetric Key to “unseal” the box.

🎉

We’ve bolstered up our data privacy capabilities. It’s not a silver-bullet, though. Security best practices are constantly evolving and staying on top of industry trends will be important to ensuring that Tower keeps your private and sensitive data safe.