Foreword

This was my Final Year Dissertation / Thesis for my BSc Computer Science degree at King's College London and it was awarded a First-Class Honours. You can find the thesis here.

The Problem

In an increasingly technologically-interconnected world, messaging apps are more ubiquitous than ever. A number of them now support End-to-End Encryption (E2EE) using the Signal Protocol, enabling billions of people to communicate privately and securely. However, the protocol has serious security vulnerabilities. While it attempts to provide some protection against those vulnerabilities like in-person verification, they come at such an expense to usability that this protection is practically rendered as futile.

The most used E2EE messaging apps are WhatsApp (by Facebook) with 1.6+ billion monthly active users and Facebook Messenger with 1.3+ billion monthly active users, and embody the widely used design of E2EE - the Signal Protocol. These E2EE messaging solutions are centralised which means all data is stored and transmitted via a central server. Due to that, to use the messaging service, the users are necessitated to give all their personal data, agree to their terms of its use and trust them to act ethically with it. As history has shown, however, their trust is inevitably abused for profit in such a system as evidenced by the Facebook–Cambridge Analytica data scandal where Facebook sold the personal data and private messages of millions of its users to Cambridge Analytica without their consent (who then leveraged it to influence major elections internationally) and by the numerous data-sharing deals which Facebook has profited from.

Existing E2EE messaging solutions require a phone number and other personal information to be used that is all stored on a central server. Even if the messages are E2EE, there's still a great deal of data that can be collected about them (timestamps, recipient, etc.) since all messages are relayed via the central server. Additionally, since both apps are owned by Facebook, the phone number can be used to link their WhatsApp profile with their Facebook profile and collect more data. This profoundly undermines the user's privacy.

In the Signal Protocol, all the messages are cryptographically signed and authenticated using an ephemeral identity key pair whose public key is uploaded to a central server. If a user Alice wants to send an E2EE message to another user Bob, then she requests Bob's public keys from the central server. This is a centralised Public Key Infrastructure (PKI) approach where the trust is centralised to a central entity, the central server here, which manages and distributes the public keys. The trust is centralised here in the sense that a user requesting the public key of another user from the central server trusts the central server to return the true public key of the user requested. However, this design presents a major security vulnerability as it is susceptible to a Man-in-the-Middle Attack (MITM) wherein the communication between two parties is monitored and may be modified by an unauthorised third party.

The unauthorised third party in this case of a MITM is the central server that acts as a relay between Alice and Bob. When Alice asks for the public keys of Bob to send an E2EE message, the central server can simply generate a new set of key pairs which it controls and give its own public keys back to Alice telling her that they are Bob's public keys. When Alice sends an encrypted message to Bob via the central server, the central server can decrypt it using its own keys, modify and re-encrypt it using Bob's actual public keys before relaying the message to Bob. The central server has then compromised the E2EE between Alice and Bob, it can covertly eavesdrop on all their conversations and even modify their messages. This is can be done for all conversations on the messaging service, compromising them all. Moreover, should the central server get compromised by an adversary, the adversary can compromise all conversations the same way. No implementation guards against this as they are all centralised.

The ephemeral identity key pair presents another security vulnerability as it allows a MITM to be performed by an external adversary, Mallory. When Alice uninstalls the app or her device becomes inaccessible for some reason (e.g. is damaged, lost...), Alice has to generate a new identity key pair and upload its public key to the central server upon logging into the app again. The central server then uses the user's phone number to universally identify the user and universally verify the identity of the user upon login through SMS verification, an ephemeral secret code is sent via an SMS text message to the number and verified. However, this process has been shown to be compromisable by an adversary. Even with a perfect implementation of SMS verification, SMS text messages have been shown to be vulnerable to hijacking due to known flaws in the cell networks. Since there is no conclusive way for any users in conversation with Alice and even the central server to know whether the new identity key truly belongs to Alice, Mallory can generate her own identity key and exploit this reset mechanism to pretend to be Alice to every other user (like Bob) that Alice was already in conversation with and the other parties to Alice. Mallory has thus compromised the E2EE encryption between Alice and any parties Alice was in conversation with and can eavesdrop or even modify their messages.

Implementations attempt to guard against the ephemeral identity key pair MITM through optional in-person verifications of the identity key. Parties can optionally verify their E2EE session after one has been established by each user scanning the other user's QR code of their encoded identity key and vice versa. However, this must be done in-person between any given pair of parties for every device they own since there is an identity key per device. This exacerbated by the fact that this process must be repeated again every time the identity key for a user changes when, for example, they log in from a new device. As result, numerous manual in-person verifications may be continuously required for the E2EE to be effective. Considering the continues physical effort this demands, the E2EE can practically be rendered futile.

Ciphora

The root cause of the vulnerabilities highlighted with the existing solutions (see above) is their centralised architecture as it necessitates all users to trust a central server unconditionally in order to use the messaging service. Quite apparently, this compromises the user's privacy and security.

Ciphora addressed this by using a decentralised architecture instead, where no central server needs to be trusted. With Ciphora, users are able to message each other directly, peer-to-peer, instead of relying on a central server to relay and store their messages. This does not only provide strong privacy to users but also makes the system more efficient and faster. Moreover, it almost eliminates the cost of operating the messaging service with the massive overhead of storing and relaying messages being eliminated.

Ciphora fixes the ephemeral identity key MITM vulnerability by using a Decentralised Public Key Infrastructure (DPKI), involving long-lived established identities instead of the centralised ephemeral ones. Ciphora uses Pretty Good Privacy (PGP) as its DPKI since it is the most widely used email encryption system in the world, allowing users who already use it to simply use their existing established identity. PGP is based on public-key cryptography using a portable long-lived key pair called a PGP key to represent the identity of a user universally. These PGP keys are shared without a central server directly between users decentrally. Replacing the ephemeral identity key with a PGP key that is long-lived and portable eliminates the reset mechanism of existing solutions that makes the system susceptible to the MITM. Moreover, no in-person verification is required as the user identity is already established and long-lived.

PGP employs a decentralised trust model known as the Web of Trust, an identity vetting scheme in which any user can act as a Certificate Authority (CA) and issue trust tokens known as digital certificates for other users. The idea of a Web of Trust is that if you already know and trust user_A then you will also trust any user_i that user_A vouchers for. This is done by user_A issuing a digital certificate for a user_i, a digital document that attests that user_A has verified the identity of user_i and trusts user_i, digitally signed by user_A. So if Alice knows and trusts Bob then if Bob vouches for Charlie by issuing a digital certificate digitally signed by him, Alice would also trust Charlie. Due to this, no exhaustive in-person verifications are required like with the Signal Protocol.

While PGP can be and is usually used to encrypt data as in the case of email, Ciphora only uses it to sign and authenticate all communication between parties. This is because PGP encryption is not as secure as the Signal Protocol's encryption and always produces a long output for even small inputs making its encryption much less secure and efficient. So Ciphora leverages the best of the Signal Protocol and PGP. Ciphora uses OpenPGP, the open standard of PGP encryption software.

The user's PGP key is universally unique so it is used to universally identify and verify the user instead of a phone number or other personal info. This allows users to guard their privacy and even stay anonymous. The PGP key fingerprint, a 40 char long hex string derived from the PGP key, is the User ID which is easy to use and share. Since it is derived from the PGP key, the PGP key of the user you want to message is sufficient to find and message that user.

As security and privacy are Ciphora's primary concerns, the security and privacy of the system were considered at every stage of development with them informing every decision made. The application implements end-to-end encryption for all messaging to securely exchange messages between parties. Since the application implements the Signal Protocol to accomplish this, all its security features (resilience, forward security and post-compromise security) are provided for all the messages. Using PGP keys, the application also offers identity verification, data authentication and data integrity for all messages. The application securely stores the private key of the user PGP key in the database by encrypting it with the PGP key passphrase. This passphrase is securely stored in the operating system’s keychain. Furthermore, the server implements authentication securely verifying every user’s identity (PGP key) and verifying every message against it so no impersonation can occur.

Learn more about Ciphora in my thesis :)