Messaging Leapfrogged Email
Email drew everyday users to the internet, because it was simple and fast … ask a question and get a quick answer. While email remains popular (281 billion emails sent in 2018 growing by 5% per year[1]), messaging is winning … for the same reason. Domo reported[2] that mobile users send 15,220,700 text messages every minute, which is nearly 8 trillion messages annually! Why did users switch? Email often feels too formal (e.g., to, from, subject, body, etc.) while messages are short to send and quick to read. This trend is also attracting businesses who connect with customers through messages to send appointment reminders, fill prescriptions, send fraud alerts, etc.
Are SMS Messages Secure?
Nope. When SMS messaging (text messaging) was invented, the transmission method piggybacked on GSM signaling channels when they were not in use. By integrating with the signaling channels, the new SMS messages had to appear like signaling messages. This was perfect, because it leveraged existing infrastructure (i.e., it kept costs lower), however, it didn’t include user-level message encryption.
Securing Messages … With End-to-End Encryption
Thanks to the myriad of data breaches plaguing society[3], today’s users are painfully aware of the need to protect their private data and are increasingly moving from insecure SMS communication to over-the-top secure messaging applications. Strong encryption keeps data secure, so that unauthorized parties can’t read it, while End-to-End Encryption (E2EE) ensures that only the intended receiver can read it. Coupling E2EE with detailed message authentication processes are vital in keeping the message exchange processes secure from other attack vectors, such as forgery attacks that let attackers maliciously misattribute message posts (e.g., WhatsApp[4]) and Media File Jacking that replaces message attachments with fake files before they are viewed (e.g., WhatsApp and Telegram[5]). Making E2EE work (and simple for users to use) requires strong encryption plus some behind the scenes encryption key management that is simplified by emerging Self-Sovereign Identity technologies.
Situational Personas: the Sudo
Internet users connect to online websites and services while performing a wide variety of activities that include: work tasks, family activities, social group interactions, traveling, personal medical research, volunteering, etc. Personal contact points (e.g., email address, phone number, credit card number, etc.) have become the de facto identifiers that websites use to track and correlate user activity across numerous websites with the intent of delivering targeted advertising. However, these correlations are not always limited to advertising and this presents numerous privacy risks for unsuspecting users. While many services work to block ads and tracking objects, Anonyome Labs extends those methods by encapsulating a full set of personal contact points into a new type of identity called a Sudo. Anonyome users can create a separate Sudo to use with each of their various digital activities. Using Sudos helps users segment their digital exhaust, which helps block tracking entities from collecting, buying, and selling a user’s identity and personal data.
What is Self-Sovereign Identity?
As the internet and web were created, great emphasis was placed on networking technologies (e.g., TCP/IP, http) and other concerns such as user identity was not a big consideration. The concept of Self-Sovereign Identity (SSI) has emerged to help users identify themselves to remote sites and services, securely exchange information, and digitally prove facts about themselves that are currently difficult to verify. In a nutshell, today’s users need to create a new identity (e.g., login name and password) with every online service where they interact, and SSI will make that more secure and simpler for users. For an in-depth overview of SSI, the Sovrin Foundation has created an excellent whitepaper[6].
SSI Building Blocks
SMS Messaging has enabled subscribers of one SMS Provider (e.g., telco) to communicate with subscribers of another SMS Provider and this cross-service communication has been a boon for SMS messaging overall. As new over-the-top application providers (e.g., iMessage, WhatsApp, Telegram, Signal, etc.) migrated towards encrypted messaging services, they ended up creating walled gardens that require message senders and recipients to both use the same messaging app and provider. While this provider-centric communication method simplifies encryption key management, it also limits message recipients to those already belonging to the same messaging service.
The Anonyome Labs Sudo Platform[7] is a set of SDK/APIs and associated services that allows application developers to easily add privacy features to their applications. Sudo Platform’s upcoming Advanced Messaging system overcomes this provider-centric encrypted messaging limitation by using several core SSI elements to send end-to-end encrypted messages to receivers on separate, but compatible messaging systems. Sudo Platform provides a set of interoperable APIs that can be used by a variety of vendors to connect their messaging apps with apps that have integrated with the Sudo Platform. Providing E2EE interoperability enables users to communicate with their friends and associates even if they use a different, but compatible, messaging app.
One of the core SSI maxims is that control of user identities (including encryption keys) resides with the individual users and not with a specific provider. New SSI user experience paradigms make exchanging identity information very simple for users. In one scenario, a user can display a QR code for another user to scan with their phone’s camera. In another scenario, a user can send their SSI information to another user who can verify it on the blockchain. Both of these methods provide very simple user experiences that invoke several strong cryptographic processes that the user doesn’t have to understand or mess with.
On the web, the main identifier is a URL, which is used to navigate to webpages. With SSI, the main identifier is known as a Decentralized Identifier or DID[8]. DIDs are conceptually similar to URLs in that while URLs point to webpages, DIDs reference cryptographically verifiable identifiers on a decentralized ledger or blockchain. Figure 1 shows the similarity between DIDs and URLs:
What makes DIDs useful is that they are self-certifying identifiers (users can verify that the link is real) and they can return a companion DID Document (also called a DID Doc) that contains additional information, such as: encryption keys, digital signatures, pointers to additional information, etc. When a decentralized ledger is used to store and retrieve DIDs, it keeps the authentication mechanisms out of band from the host messaging service and helps avoid compromises from Man-In-The-Middle (MiTM) attacks.
DIDs written to a public ledger are called Public DIDs and are often used to help users identify each other. Once two users verify each other’s identity, they will often create a private or Pairwise DID. Pairwise DIDs are created between two users who keep them private and never write them to an external location or blockchain. While Public DIDs help users connect, Pairwise DIDs enable users to create a private encrypted communication pathway. This may seem like an unnecessary extra step; however, it has valuable security benefits. Using different Pairwise DIDs with each communication partner ensures that if the encryption (i.e., Pairwise DID, encryption keys) between one set of users is ever compromised, that the Pairwise DIDs created with other communication partners remain secure. This is a key benefit over standard public key encryption wherein if a public/private keypair is compromised, it affects all or most of a user’s communication partners.
Encrypted Messaging: Putting It All Together
When users install the Sudo Platform-enabled encrypted messaging app and create a Sudo identity, it performs an SSI initialization process. During the initialization, the app creates a secure SSI storage wallet specific to an individual Sudo identity. The wallet is used to securely store Public DIDs (including the private keys) and exchanged Pairwise DIDs. While not discussed here, the wallet may also contain other SSI elements, such as Verifiable Credentials, Verifiable Claims, and other secure tokens. After the wallet is created, the Sudo optionally creates an initial Public DID, and registers it with the Sudo Platform Server, which writes it to the Sovrin decentralized ledger. The results of writing the Public DID to the ledger are returned to the requesting Sudo and stored in the wallet. This process is shown in Figure 2:
As mentioned above, writing a DID to the ledger is optional. Whether or not a user chooses to make a DID publicly verifiable by writing it to the ledger depends on why they are creating a DID. For example, if a user wishes to create a Sudo (and the corresponding DID) in order to interact with public organizations (e.g., government, university, etc.) or financial entities (e.g., banks, crypto currency exchanges, etc.), then creating a public DID on the ledger will likely be mandatory for interacting with those types of entities. However, if a user creates a Sudo mainly for private communications, interacting in online chat forums, or using social media, then the user may not necessarily need or want their DID to be public and a non-public DID (i.e., not written to the ledger) may be a more appropriate choice. Anonyome Labs enables the user to choose the type of DID they wish to create and enables them to use it accordingly.
In order to establish a private end-to-end encrypted messaging channel, two users need to negotiate a Pairwise DID. The Sudo Platform server provides the messaging transport service that relays encrypted messages between the two Sudo users. At the user level, Sudo Platform provides functionality to enable two Sudo users to perform the Pairwise DID negotiation process (e.g., using the Hyperledger Aries DID Exchange Protocol[9]), as shown in Figure 3:
The preceding Pairwise DID negotiation steps are also depicted below in Figure 4. In this scenario, one user displays a QR Code, which is scanned by the other user. This step, usually performed in person, asserts one user’s identity. After that, both users begin the Pairwise DID negotiation process described above and exchange those messages using the Sudo Platform server to relay the messages. Once this process is complete and both users have the Pairwise DID, they can use it to send E2EE messages, which contains encryption keys that are unknown to any external party.
Another method for remotely negotiating Pairwise DIDs leverages a decentralized ledger or blockchain for the initial user identification step. In this process, a user can send their DID to another user who confirms with the sender that it is their DID. The receiver can resolve the sender’s DID on the blockchain where it is hosted and retrieve the DID Doc. With the sender’s DID and DID Doc information, the receiver can perform the same Pairwise DID negotiation steps as outlined above in Figures 3 and 4. The remote Pairwise DID negotiation process is shown in Figure 5:
A third method for exchanging DIDs exists with users that share the same message hosting provider (i.e., they reside in the same walled garden). The DID exchange steps are the same as shown in Figure 3, although the initial retrieval of the DID and DID Doc may be obtained locally from the message hosting provider. This greatly simplifies the DID exchange process by nearly eliminating all manual user steps, which are performed automatically by the messaging provider. When this method is used, an out-of-band key verification step is available to users wishing to verify the authenticity of the remote DID. One method, for example, is to have each party verbally convey a set of random values to the other party and ensures that the retrieved DIDs are the same DIDs used in the pairwise DID generation process.
Once the sender and receiver have negotiated their unique Pairwise DIDs, then they can exchange E2E encrypted messages. In this process, Sudo A will use the Pairwise DID negotiated with Sudo B to encrypt the message and send it to Sudo B via the Sudo Platform’s Message Server. When Sudo B receives the encrypted message, it will retrieve the corresponding Pairwise DID, load their private key, and decrypt the message. Using this process, while the messaging transport layer (e.g., messaging hosting provider’s server) controls the transmission of the messages, it does not have access to the decrypted message, nor the key used to encrypt it. This process is shown in Figure 6:
Sudo Platform: End-to-End Encrypted Messaging Between Walled Gardens
The current generation of over-the-top encrypted messaging apps is operated by many separate messaging providers who each offer E2EE messaging services to users operating within the protective environment of their respective walled gardens. Such apps include Apple’s iMessage, Facebook’s WhatsApp, and Whisper Systems’ Signal. Under this paradigm, users can send E2EE messages to recipients, but only if the recipients operate on the same E2EE system.
While contemporary over-the-top E2EE systems have helped increase user privacy over traditional SMS messages, Sudo Platform is implementing new messaging standards that will enable E2EE message exchange between users of separate messaging providers. The message exchange components are based on the Hyperledger Aries messaging protocols. Messaging providers implementing Hyperledger’s open standards will enable their users to exchange DIDs[10], encrypt messages[11], and exchange messages[12] in a standard compatible format regardless of whether the senders and recipients are hosted within the same walled garden. A high-level view of this new process of exchanging messages between message hosting providers is shown in Figure 7:
Exchanging messages between separate messaging providers is a process inherent in email and SMS messaging, however, it is notably absent in the current generation of over-the-top E2EE messaging providers. This is due, in part, to the lack of methods for discovering remote messaging servers, but also in large measure due to the logistical complexity involved in distributed key management. The Hyperledger Aries protocols, Sovrin ledger, and W3C DID specifications enable the Sudo Platform to provide an open E2EE messaging service and to facilitate interoperability with compatible messaging providers.
Specific routing protocols use exchange messages between different messaging providers and is described in the Hyperledger Aries protocols as described above. However, they key identifiers that make this possible are contained within the DID Document, itself. Figure 8 shows the key DID Document elements that enable a sender to identify a receiver’s messaging endpoint:
Sudo Platform: Interoperable End-to-End Encrypted Messaging
As evolving threats to user privacy emerge, it is vital that messaging providers deliver new ways of increasing the security level for user messages and their host messaging platforms. The Sudo Platform provides secure E2EE messaging capabilities by incorporating Self-Sovereign Identity functionality, End-to-End Encryption, authenticatable messages, and strong encryption algorithms. Incorporating these industry standard elements enables the Sudo Platform’s E2EE messaging service to create the widest level of interoperability between different messaging providers, to help make E2EE communications the default online communication method, and to break down the communication barriers inherent in contemporary walled garden messaging models.
[1] “The Shocking Truth about How Many Emails Are Sent”, Campaign Monitor, May 2019, https://www.campaignmonitor.com/blog/email-marketing/2019/05/shocking-truth-about-how-many-emails-sent/
[2] “Data Never Sleeps 5.0”, Domo, https://www.domo.com/learn/data-never-sleeps-5
[3] “The 21 scariest data breaches of 2018”, Paige Leskin, Business Insider, 30 Dec 2018, https://www.businessinsider.com/data-hacks-breaches-biggest-of-2018-2018-12#2-marriott-starwood-hotels-500-million-20
[4] “FakesApp: A Vulnerability in WhatsApp”, Check Point Research, 7 Aug 2018, https://research.checkpoint.com/fakesapp-a-vulnerability-in-whatsapp/
[5] “Symantec Mobile Threat: Attackers Can Manipulate Your WhatsApp and Telegram Media Files”, Symantec, 15 Jul 2019,
https://www.symantec.com/blogs/expert-perspectives/symantec-mobile-threat-defense-attackers-can-manipulate-your-whatsapp-and-telegram-media
[6] “The Inevitable Rise of Self-Sovereign Identity”, Tobin et. al, Sovrin Foundation, 28 March 2017, https://sovrin.org/wp-content/uploads/2018/03/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf
[7] Anonyome Labs Sudo Platform, https://anonyome.com/sudo-platform/
[8] “Decentralized Identifiers (DIDs) v0.13”, W3C, 13 Aug 2019, https://w3c-ccg.github.io/did-spec/
[9] Aries RFC 0023: DID Exchange Protocol 1.0, Hyperledger Foundation, 27 May 2019, https://github.com/hyperledger/aries-rfcs/blob/master/features/0023-did-exchange/README.md
[10] Aries RFC 0023: DID Exchange Protocol 1.0, Hyperledger Foundation, 27 May 2019, https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange
[11] Aries RFC 0019: Encryption Envelope, Hyperledger Foundation, 4 May 2019, https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope
[12] Aries RFC 0095: Basic Message Protocol 1.0, Hyperledger Foundation, 6 Aug 2019, https://github.com/hyperledger/aries-rfcs/tree/master/features/0095-basic-message
