Security and privacy in messaging systems have recently gained prominence. There are some very well-crafted messaging protocols for end-to-end encryption (E2EE). The goal of any End-to-End encryption protocol in messaging systems is to reduce the number of parties who can interfere and break the encryption.
The wiki page for E2EE has a nice definition:
“End-to-end encryption is intended to prevent data being read or secretly modified, other than by the true sender and recipient(s)”
Most protocols work in ways such that even the server is not trusted within that chain of trust between two or more participants.
While lots of attention has been put on securing messaging protocol design to achieve strong end to end encryption, little attention has been put on the identity and authentication aspects of the participants in a conversation. The question is about Claim, if I claim I am Bob, I need to have a mathematical way to assert that claim which can be independently verified by Alice who I want to talk to. Further, only Bob can make such a claim and there doesn’t exist another entity who can make such claims, i.e. there can only be 1 Bob. In any messaging system we call this step the identity assertion step on an individual user. The relationship between the user and their device needs to be first established securely which can be independently verified by Alice. Also, the trust may change over time. For example, Alice trusts Bob today and will continue to trust until a time when they need to revalidate their relationship.
In a secure messaging system if the identity can be swapped or not strongly tied to the user, it introduces some challenges and raises some questions about end-to-end privacy.
Let’s expand common practices of user enrollment using SMS
The typical process is Bob enters the phone number to sign up, this loosely becomes Bob’s identity to the system. The system then generates a code to validate Bob is in possession of the phone. This is typically done through a one-time pass code (OTP) or a challenge factor to validate proof of possession of that SIM. Typically, systems would then generate some strong identity keys and signature keys to identity Bob in the future. This relationship is created and established between Bob and the system providing the service. At the end of this process, Bob’s identity was created and validated that Bob is in possession of the SIM.
Some other applications use additional device hardware (HW) properties to tie the HW of the phone with the SMS OTP for better association of SIM to the Phone. However, it’s not difficult to see it’s the physical SIM that’s replaceable. It is what identifies Bob regardless of the strong keys that are generated in the background. For most apps that reply on phone number-based identity, once the account is created, you can remove the SIM and the app will continue to work, since it’s just used to create the identity step. There are numerous examples that explain SMS fraud, recycled numbers and other vulnerabilities that are outside the control of the service infrastructure.
Most secure messaging apps notify when the account has changed phone number to all their contacts, however consider the following. What about if Bob was on vacation and switched off his SIM. In the meantime, Lucy swapped Bob’s SIM and performed a device switch. All of Bob’s contacts are notified of an account change. However, Lucy says she is Bob and starts conversations with Bob’s contacts. Now of course Bob’s friends could call Bob using a regular phone call just to check on him.
This model also relies on trusting the server to associate phone numbers and identity keys. When another user of the messaging system requests a user’s key from the server, a malicious server could substitute it for their own key, enabling a man-in-the-middle attack.
Some apps have this issue and by default a sender will re-encrypt and re-send any messages pending delivery when a recipient key change is detected. It also doesn’t warn users by default if one of their contact’s keys changes.
The complexity of using phone numbers goes way beyond just app signup. It’s a simple low-effort way of onboarding users to create their identity, leaving open long-term identity assertion problems that are integral to the lifecycle of the communication relationship.
The question is are there other ways and if so how?
Let me take you down memory lane. Those of you who have been BBM users many years ago on BlackBerry devices, you may recall when switching devices, the user had to have possession of both devices or a manual export of contacts by password etc. This process was called a device switch. It’s the act of transferring identity and trust from one physical device bound to that user to another one.
It was relatively easy since we could rely on HW root of trust, secure boot rom and HW etched PIN along with HW etched PIN authentication keypair that came out of the box after the manufacturing process. So, it leveraged identity from the HW root of trust along with the PIN which can’t be replaced or swapped or tampered with. It’s important to observe that end-to-end security is difficult to achieve if a strong identity cannot be asserted which exposes various side-channel attacks. Most vulnerability breaches are not related to breaking the crypto rather various side channel strategies devised to break the trust circle between entities in communication.
In the post BlackBerry device era let’s examine how a strong identity can be established for a secure messaging service.
Vanilla account creation username/password approach – This is the simplest form of allowing users to create a username and password for the service. Isolation of concern is worth pointing out here. The service that is trying to enroll the user here is not the same service that is in the path of the account creation and password exchanges of the user. The mechanics of federated identity, OuAth2, OpenID Connect, SAML etc., have specifications that define this process quite well and are standards. The entity that assigns the identity is foreign to the service that offers functionality of the service such that each user of that service can trust the external entity.
To read more on isolation of concern approach you can read here:
Simple Certificate based Enrolment (SCEP) – It allows you to securely issue certificates to a large number of network devices or users for automatic enrolment. The idea is the same from a user’s perspective, they get an activation code against which their chosen identity can be used to bootstrap or signup to the service. In-depth review of SCEP is outside of this discussion, but you can find SCEP and improvement to the original IETF in literature published elsewhere.
Elliptic curve simple password exponential key exchange (EC-SPEKE) – This is a cryptographic method for a password authenticated key agreement. In a secure messaging context after the user is enrolled, they now need to chain their identity from SCEP or the username/password step or a mix of both, to generating their identity key pair. The identity key pair is typically a Diffie-Hellman (DH) key pair with a public key meant to be shared publicly and a private key meant to be guarded safely. The identity DH public key would require a form of integrity protection to prevent modification if it were being intercepted. EC-SPEKE does provide this, by making the point on the curve a shared secret. This allows a secure exchange of keys over a wiretap channel. Read more of DH keys in literature elsewhere. https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
The public part of the DH key can leverage EC-SEPKE to exchange with each party Bob intends to create a relationship. This way even the public part of DH which is meant to be public, is protected in relationship creation with Alice.
Finally, Bob is enrolled and chained with strong identity and leveraged EC-SPEKE to setup a trusted relationship with Alice who has also done the same. This just allows Bob and Alice to independently validate and verify each other’s identity claims. Now they are ready to proceed with various key exchanges to start a conversation.
Password-Based Key Derivation (PBKD) and hash-based message authentication code (HMAC) methods – PBKD and HMAC also allow authenticated key agreement. Two or more users could establish identity via signing their identity keys using HMAC with a key derived from a shared password that both agree through an out-of-band channel. The main challenge in this approach is both parties need to be available in an interactive mode to complete the session of establishing trust. In principle this approach is slightly simpler than EC-SPEKE. However, it requires this process to be carried on with each participant and can be cumbersome.
Zero Knowledge Proofs and Blockchain (ZKP) – ZKP have been around for a while and recently gained popularity with blockchain use in protecting and validating private data. A similar approach can be taken in verifying the identity between peers. The basic idea is Bob and Alice each creates their identity claims and publishes in a blockchain. The result is a blockchain record of the Public part of Diffie-Hellman (DH). Instead of sharing the Public Key it’s the cryptographic hash of it that’s published. When Alice and Bob need to validate each other’s identity keys, they can now rely on Zero knowledge proof between themselves and the Blockchain record to validate their identity.
I hope this article has taken you through some of the challenges secure messaging systems face and possible alternative and solutions. For more information on some of these approaches please see