Key Verification in Secure Messaging
Or how can I know you are who you say you are?
By Joël Alwen
*** Updated on Aug 18, 2017 to reflect the change in Wickr Me’s key video verification process. It is now similar to that on Wickr Pro.
There are many things cryptography solves when it comes to ensuring the integrity and privacy of user connection — from protecting the content of communications so only intended recipients can decrypt them to authenticating the parties to multi-actor transactions. One of the coolest things crypto enables is ensuring that a person I think I am talking to is exactly who I think it is, even if they are thousands of miles away and I’ve never met them. I want to share our thinking about key verification design and ways we implement it to help our users across Wickr apps to authenticate their contacts.
WHAT IS KEY VERIFICATION?
On Wickr networks — either Messenger or Wickr Pro — each user’s account is ultimately bound to their signature key pair: Identity Keys. Such Identity Keys consist of a matching public and private key. The latter is used to produce digital signatures and the former can then be used to verify those signatures. When you add someone to your contact list, your Wickr client immediately obtains the public part of the contact’s identity keys from the server and stores it locally. All subsequent communication to come from that contact can now be authenticated by checking that the received message was digitally signed using the contact’s identity keys. Put differently, a Wickr account is controlled by whoever controls the identity keys belonging to the account.
However, in practice we all are usually interested in communicating with a particular person, not just anybody who controls a particular set of identity keys. In other words, although Wickr guarantees that all communication from a contact was really produced by the holder of that contact’s keys, it is equally important to ensure that the person using those keys is really who we think they are. Making that connection between identity keys and the actual person behind them is what is sometimes called key verification.
Key verification is a crucial step for securely (i.e. privately and authentically) communicating with your contact using Wickr (and really any tool making use of end-to-end encryption). It is only by performing this step that we can protect ourselves from man-in-the-middle attacks where an adversary substitutes their own identity keys for those of the contacts during the initial setup phase.
KEY VERIFICATION IN PRACTICE // Wickr Pro
Given the importance of key verification, a variety of practical solutions exist to help users perform key verification.
Take as an example probably the most widely deployed solution — the certificates used in conjunction with TLS protocol. Essentially, a certificate is a digital voucher that a trusted third party, namely the Certification Authority which issued the certificate, has verified that the holder of a particular key pair has the real world identity specified in the certificate. In other words, a certificate encodes statements of the form “Certification Authority Verisign guarantees that the holder of public key XYZ is the company Wickr Inc.”
Another example of a tool to assist with key verification are the 2D barcodes used by some apps to encode the public part of a key. The idea here is to make it easier for users to communicate their key to each other using some out-of-band channel. A 2D barcode makes this easier by providing users with a simple image they can exchange and scan, potentially a much less arduous task than communicating say, a long strings of digits.
KEY VERIFICATION IN WICKR
Wickr is no exception in that key verification is a crucial part of using the app securely. However, as we do not want to solely rely on third party services for key verification, the certificate solution of TLS is not a realistic option for Wickr.[1] What’s more, when designing the key verification procedure we wanted to build a system which did not require contacts to already have a pre-existing authenticated out-of-band channel with which to communicate their key verification information as this could prove to be an onerous prerequisite in many practical use cases.
These constraints motivate the video-based key verification solution used by Wickr applications. The solution consists of two simple steps:
STEP 1
Let’s take Wickr Pro as an example: when I create a new account and accompanying identity keys, Wickr Pro app asks me to create a matching key verification video. To make this video, the app first hashes the public part of my identity keys (using the collision resistant hash function SHA256) and encodes the (first half of the) resulting digest. The result is a short list of English language words unique to my particular public identity key. Next, I am prompted by the app to read out those words while recording myself to produce my key verification video.
Finally, the resulting video is encrypted (using AES256 under freshly chosen random key that only I have access to) and bundled along with the rest of the new account’s public information and stored on the Wickr server to be distributed to other users who wish to communicate with me. The Wickr server is not able to watch my key verification video. I can always re-record my video, which will be encrypted with a new key. In order for anyone to actually watch the video they must first ask for my permission through the Wickr app as described in the next step.[2]
STEP 2
Suppose Alice wants to add me to her contact list. To do this, first her Wickr app obtains my public information from the Wickr server. This includes the encrypted video and my (supposed) public identity key. Next, her app informs me that Alice would like to perform key verification. If I accept the request, then my app sends her the decryption key for the video together with a SHA256 digest of the video I produced in Step 1 to help her verify that she was given the correct video by the Wickr server.
Upon receipt of the decryption key (and verification that her copy of my video has the correct SHA256 digest), Alice’s app decrypts it. Then it runs the same procedure as in Step 1 to obtain the unique word list for my supposed public key obtained from the server. The app plays back my key verification video to Alice while simultaneously displaying the word list it just computed. Now Alice should verify two things:
• The person in the video is who she thinks it is.
• The person is reading out the same list of words that her app is showing her.
If both checks pass, Alice can now be sure that she is really communicating with me and that she has the correct keys on file for me.
WICKR MESSENGER // Wickr Me
As of August 12, 2017, key video verification process in Wickr Me is similar to that on Wickr Pro.
[1] The careful reader may notice that we do use TLS to communicate between the client and server. However, in that case we only ever need to verify a single key, namely that of the server. Thus the verification happens once when the app is created and the server’s public key is then bundled together with the app (a practice known as “certificate pinning”). Also, the messages inside the TLS tunnel are also encrypted and authenticated separately by the client and server.
[2] Still, it is worth noting that if I want to create a completely anonymous account (that is one which is not tied in anyway to my real world identity) I can, of course, always just cover the camera when recording the key verification video.
