sign in sign up
<<
Home , Autocrypt, Bitmessage, Brian Acton, ChatSecure, Cryptocat, Double Ratchet Algorithm

End-to-End Encrypted (E2EE) Messaging

2021 Rolf Oppliger Slide 1 Presenter

• eSECURITY Technologies Rolf Oppliger (founder and owner) • Swiss National Cyber Security Centre NCSC (scientific employee) • University of Zurich (adjunct professor) • Artech House (author and series editor for information security and )

→ rolf-oppliger.ch or rolf-oppliger.com

2021 Rolf Oppliger Slide 2 Reference Book

© Artech House (2020) ISBN 978-1-63081-732-9

→ Personal → Artech House (UK)

2021 Rolf Oppliger Slide 3 Disclaimers

• The slides are relatively simple, down-to-earth, and not visually stimulating • Mathematical fundamentals are not addressed • Alice, Bob, Carol, Dave, Eve, and the rest of the

gang are posted as missing (cf. Disillusioning http://xkcd.com/1323/ Alice and Bob, IEEE Security & Privacy, Vol. 15, No. 5, September/October 2017, pp. 82 - 84) • The world of is somehow restricted and does not properly take into account human aspects and the subtleties of machine-user interaction (cf. video)

http://xkcd.com/538/

2021 Rolf Oppliger Slide 4 Preliminary Remark

• Crypto Wars • I (1970s): Publication and standardization • II (1990s): Export controls • III (now): E2EE messaging («going dark»)

2021 Rolf Oppliger Slide 5 Outline

1. Introduction 2. Cryptographic Techniques 3. «Conventional» Approaches and Solutions 4. «Modern» Approaches and Solutions 5. Conclusions and Outlook

2021 Rolf Oppliger Slide 6 1. Introduction

• Text-based messaging (e-mail) has been one of the first (asynchronous) applications on the (message format is specified in RFC 5322) • The Internet mail architecture is spe- cified in informa- tional RFC 5598 • SMTP (RFC 5321), POP3 (RFC 1939), and IMAP4 (RFC 2060) are the core protocols

2021 Rolf Oppliger Slide 7 • The Extensible Messaging and Presence Protocol (XMPP) – formerly known as Jabber – is an open XML- based protocol for real-time communication () • It is specified in Internet Standards Track RFCs 6120 (core), 6121 (instant messaging and presence), and 7622 (address format) • It enables many synchronous applications, including instant messaging, presence and collaboration • There are a few alternatives to XMPP, such as MQTT or SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) • XMPP can be layered on top of TLS to provide

2021 Rolf Oppliger Slide 8 • RFC 3923 specifies how to invoke S/MIME for message signing and in an XMPP setting • There are only a few implementations (e.g., Sixscape) • In spite of the existence of XMPP, most messenger apps use proprietary protocols and are based on a simple (and centralized) architecture • WhatsApp • Yahoo Messenger • Messenger • … • This is fundamentally different from e-mail • The architecture is susceptible to man-in-the-middle (MITM) attacks

2021 Rolf Oppliger Slide 9 • During the past decade, instant messaging (in various forms) and pro- prietary have become very successful • The empire (of telcos) strikes back and tries to re- vitalize the success story of SMS (and MMS) with the Rich Communication Services (RCS) stan- dardized by the GSM Association in 2012 • On the technical side, RCS is based on HTTP(S), SIP(S), MSRP(S), and Session Initiation Protocol (S)RTP Message Session Relay Protocol • is also heading towards RCS with its Jibe platform and RCS (that replaces ) • Since November 2020, Google Messages imple- ments E2EE with the protocol (beta release) • The outcome of this power game is open

2021 Rolf Oppliger Slide 10 2. Cryptographic Techniques

• All approaches and solutions for secure Internet messaging are based on cryptography and cryptographic systems () • There are many systems to choose from

Unkeyed (keyless) Secret (symmetric) Public Key (asymmetric) • Random generators • Pseudorandom generators • Key establishment • Random functions • Pseudorandom functions • Asymmetric encryption • One-way functions • Symmetric encryption • Digital signatures • Hash functions • Message • Public key certification • • Protocols

2021 Rolf Oppliger Slide 11 • The «conventional» approaches and solutions employ hybrid message encryption (aka «digital envelopes») and digital signatures

E (k) E (m) D (m) pkB k skA

Message m sent from A to B • The «modern» approaches and solutions employ • Ephemeral Diffie-Hellman To provide (perfect) • Ratchet-based key derivation and post-compromise security (PCS) • codes (MACs) • Deniable authentication To provide • Malleable encryption (in contrast to nonrepudiation) • …

2021 Rolf Oppliger Slide 12 • Example (Diffie-Hellman key exchange) • Safe prime p = 23 → q = (23-1)/2 = 11 is a also prime (i.e., Sophie Germain prime) * • Z23 = {1,2,…,22} has subgroup G = {1,2,3,4, 6,8,9,12,13,16,18} with |G| = q = 11 elements • 3 is a generator of G (i.e., 30 = 1, 31 = 3, 32 = 9, 33 = 4, 34 = 12, 35 = 13, 36 = 16, 37 = 2, 38 = 6, 39 = 18, and 310 = 8) • G and g are input parameters 6 • A randomly selects xa= 6 and computes ya = 3 mod 23 = 16 9 • B randomly selects xb= 9 and computes yb = 3 mod 23 = 18

• A and B exchange their y-values, i.e., ya and yb • A computes 186 mod 23 = 8 • B computes 169 mod 23 = 8 • 8 is the

2021 Rolf Oppliger Slide 13 • The notion of (perfect) forward secrecy has a long tradition in crypto- graphic protocol design (e.g., IPsec/IKE) • The notion of post-compromise security (PCS) is relatively new, subtle, and maybe even illusive • In either case, the question is whether (past or future) communications can be protected in spite of a compromise of a long-term key

2021 Rolf Oppliger Slide 14 3. «Conventional» Approaches and Solutions

• The «conventional» approaches and solutions are based on hybrid message encryption and digital signatures • This is true for Privacy Enhanced Mail (PEM) and MIME Object Security Services (MOSS) • It is also true for PGP/OpenPGP and Secure MIME (S/MIME) • For more than 15 years (early 1990s to mid-2000) it was thought that secure Internet messaging was a solved problem • But something went wrong and people did not really use the respective solutions

2021 Rolf Oppliger Slide 15 • There are many usability concerns (related to PGP/OpenPGP) • Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0 (1999) • Johnny 2: A User Test of Key Continuity Management with S/MIME and Outlook Express (2005) • Why Johnny Still, Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client (2015) • … • S/MIME is better integrated into MUAs (e.g., Outlook), and hence the usability concerns are less obvious • But S/MIME still requires users to make informed decisions and public key certificates to be available in the field • There are recent discussions about the security of S/MIME and PGP/ OpenPGP (e.g., EFAIL, signature spoofing attacks, … )

2021 Rolf Oppliger Slide 16 PGP/OpenPGP

• (PGP) was originally developed by in 1991 ( 30 years ago) • It natively used IDEA, MD5, and RSA • Due to a patent litigation, PGP was modified to incorpo- rate the RSAREF library of RSA Security • PGP was the focal point of Cypto War II • In 1997, the IETF chartered an Open Specification for Pretty Good Privacy (openpgp) WG that remained active until 2017 • The result is OpenPGP that is currently specified in RFC 4880 (OpenPGP Message Format) and RFC 3156 (MIME Security with OpenPGP)

2021 Rolf Oppliger Slide 17 • Today, there are many implementations of OpenPGP – for many MUAs on multiple platforms • Either the MUAs natively support OpenPGP, or plug-ins provide the res- pective functionality • Most importantly, there is a implementation known as GNU Privacy Guard (GnuPG or GPG) • GPG was originally developed by Werner Koch on behalf of a German ministry • It was later taken over by the GnuPG Project and raised € 36,732 in crowdfunding in February 2014 • Today, GnuPG is further developed and is currently the most widely deployed implemention of Open- PGP (at least in Europe)

2021 Rolf Oppliger Slide 18 • An OpenPGP message can be sent in the message body part of an RFC 5322-compliant message • Enrypted (digitally enveloped) message

• Digitally signed message

2021 Rolf Oppliger Slide 19 • In many situations it is advantageous to combine PGP and OpenPGP with the Multi-purpose Internet Mail Extensions (MIME) system • RFC 1847 specifies 2 security multiparts • multipart/encrypted • multipart/signed • RFC 3156 specifies 3 content types (or «protocol» parameters) • application/pgp-encrypted • application/pgp-signature • application/pgp-keys

2021 Rolf Oppliger Slide 20 • Exemplary message (digitally signed and enveloped)

2 multiparts

decrypt

2021 Rolf Oppliger Slide 21 • Messages are always processed in the same order • • Compression • Encryption • Transfer encoding • PGP/OpenPGP uses a distinct for- mat for public key certificates and a • The cryptographic algorithms are currently being updated to meet the state of the art

2021 Rolf Oppliger Slide 22 S/MIME

• In the second half of the 1990s, Secure MIME (S/MIME) evolved from PEM and MOSS • Version 1 (1995) • Version 2 (1998, RFCs 2311, 2312) • Version 3 (1999, RFCs 2630, 2631, 2632, 2633, 2634) • Version 3 was updated twice • Version 3.1 (2004, RFCs 3850, 3851) • Version 3.2 (2010, RFCs 5750, 5751, 5752) • S/MIME version 4.0 (RFCs 8550, 8551) was officially released in 2019

2021 Rolf Oppliger Slide 23 • With regard to the functionality and the security services it provides, S/MIME is very similar to PGP/OpenPGP • Fundamental differences • Message format • Public key (and certificate) management → Trust model • Due to these differences, PGP/OpenPGP and S/MIME implementations do not interoperate • There are some implementations that provide support for both standards, but this need not be the case • From a standardization viewpoint, there are two solutions for effentially the same problem (this can be viewed as a failure in standardization)

2021 Rolf Oppliger Slide 24 • Compressed-only MIME entity (S/MIME headers)

• Enveloped MIME entity

2021 Rolf Oppliger Slide 25 • Signed MIME entity

Detached signature format («clear-signing format») → can be viewed by any MUA (with or without S/MIME support)

2021 Rolf Oppliger Slide 26 • All implementations of the «conventional» approaches and solutions are difficult to use and lack user deployment • There are implementations that try to improve the user experience (e.g., OpenKeychain, R2Mail2, Horde/IMP, … ) • Evolutionary improvements • Web Key Directory (WKD) and Web Key Service (WKS) • DNS-based distribution of public keys • (RFC 7435) based on (TOFU) • • (p≡p or pEp) • LEAP Encryption Access Project • Web-based solutions (e.g., Hushmail, ProtonMail, … )

2021 Rolf Oppliger Slide 27 4. «Modern» Approaches and Solutions

• Design goals • Session-oriented (still supporting asynchronous messaging) • Forward secrecy and PCS • Deniability (in contrast to nonrepudiation provided by digital signatures) • Multi-device support • Efficient group communication • …

2021 Rolf Oppliger Slide 28 OTR

• In contrast to «conventional» wisdom in , Nikita Borisov, Ian Goldberg, and Eric Brewer proposed off-the-record (OTR) messaging in 2004 • The goal was to «simulate» a personal (face-to-face) conver- sation held privately, e.g., in a private room • Such a conversation provides privacy (in terms of forward secrecy and PCS) and plausible deniability • Privacy → Diffie-Hellman ratchet to establish short-lived keys • Plausible deniability → MACs instead of digital signatures, revelation of MAC keys after use, malleable encryption, …

2021 Rolf Oppliger Slide 29 • More specifically, OTR comprises • an authenticated key exchange (AKE) protocol to initialize a session and establish a session key k • DSA signatures and public key fingerprints for authentication (alternatively, a protocol to solve the Socialist Millionaires' Protocol (SMP) can be used for password-based authentication) • a Diffie-Hellman ratchet to constantly generate new keys (→ forward secrey and PCS) • a symmetric encryption system for message

encryption (kenc = SHA-1(k)|128)

• MACs to authenticate messages (kauth = SHA-1(kenc))

Whoever knows kenc also knows kauth → Anybody who can encrypt and decrypt a message can also generate and verify a MAC (→ improves deniability)

2021 Rolf Oppliger Slide 30 • When A wants to send a message m to B, it

• determines A and B’s latest Diffie-Hellman parameters keyidA and keyidB (and respective keys x and y ) ai bj xa xb xa • uses x and y to compute the Diffie-Hellman key k = y i = g j ii ai bj bj • derives kenc and kauth from k

• AES-128 in CTR mode is used for encryption, i.e., = AES-128kenc(m) • This construction is malleable and requires an 8-byte counter ctr • A compiles a record T = (c,keyid ,keyid ,ctr,y ), where y is A’s next A B ai+1 ai+1 to be used Diffie-Hellman parameter

• A uses kauth to compute a MAC t = HMAC-SHA256-160kauth(T) • Finally, T and t are transmitted to B, together with the old authentication keys that are no longer needed (→ improves deniability)

2021 Rolf Oppliger Slide 31 • After having received T and t, B

• extracts keyidA and keyidB from T • determines y and x and computes the respective Diffie-Hellman key k ai bj • derives kenc and kauth from k

• uses kauth to verify the MAC t (for T) • extracts c from T

• decrypts c with kenc and ctr • updates A’s Diffie-Hellman ratchet key with y ai+1 • All of these steps need to be repeated for each message exchanged between A and B

2021 Rolf Oppliger Slide 32 • In 2009, OTR was complemented with a multi-party OTR (mpOTR) protocol • The basic idea of mpOTR is to replace MACs with deniable digital signatures (generated with ephemeral signing keys) • This deviates from the original design goals of OTR • Furthermore, OTR (and mpOTR) has been designed to be used only in a synchronous setting • This limitation is overcome by the • The most current version of OTR (i.e., OTR v4) adapts techniques from the Signal protocol and can also be used in an asychronous setting (among other changes) • OTR remains important mainly for historical reasons

2021 Rolf Oppliger Slide 33 Signal • Based on the work on OTR, Trevor Perrin and (then with Open ) developed an E2EE messaging proto- col that also works in an asynchronous setting • The protocol was released in 2013 as Axolotl • It was used in TextSecure and RedPhone (renamed to Signal in November 2015) • The Signal protocol (as it is called today) is not patented and the spe- cification is publicly and freely available • It stands for the state of the art in E2EE messaging (and is promoted and further developed by the Signal Technology Foundation)

2021 Rolf Oppliger Slide 34 • Core technologies • eXtended Triple Diffie-Hellman OTR AKE X3DH (X3DH) Key Agreement Protocol using elliptic curves specified in RFC 7748 (i.e., and Curve448) © ://signal.org/blog/simplifying-otr-deniability/ • XEdDSA and VXEdDSA signature schemes • SHA-2 (SHA-256 or SHA-512) and HMAC-based Extract-and-Expand (HKDF) specified in RFC 5869 • AEAD encryption/decryption with AES • Double ratcheting mechanism • Diffie-Hellman (DH) ratchet from OTR • Symmetric key / hash ratchet from the Instant Messaging Protocol (SCIMP)

2021 Rolf Oppliger Slide 35 • When A installs the software, the following elliptic curve public key pairs are generated

ID ID • A long-term identity (ID) key pair (pkA , skA ) PK PK • A medium-term signed prekey (PK) pair (pka , ska ) of which the public PK ID key pka is digitally signed with skA OT OT • A pool of n ephemeral one-time (OT) prekey pairs (pka,1 , ska,1 ), OT OT OT OT (pka,2 , ska,2 ), …. , (pka,n , ska,n ) PK • The n+2 public keys (and the signature of pka ) are uploaded to the , where they are stored together with the identifier of A (represen- ting a «prekey bundle» for A) • The signed prekey pair must be renewed on a regular basis • The pool of one-time prekeys pairs must be refilled whenever needed

2021 Rolf Oppliger Slide 36 • The first time A establishes a session with B, the following steps are executed • A requests B’s «prekey bundle» that ID PK comprises pkB , pkb (with signature), OT and optionally one pkb,j from B’s pool (1 ≤ j ≤ n) PK • A verifies the signature for pkb and continues iff it is correct • A generates an ephemeral public key pair (pka,ska) and uses B’s prekey bundle to compute a master secret s

2021 Rolf Oppliger Slide 37 • A deletes its ephemeral private key ska and all ECDH outputs (→ perfect secrecy) • A generates associated data (AD) that comprises encodings of A and B’s ID ID public identity keys, i.e., AD = Encode(pkA ) || Encode(pkB ) • A sends an initial message to B that contains

ID • pkA

• pka OT • Index j specifying which pkb,j was used by A to establish the session • encrypted with master secret s using an AEAD encryption scheme (where AD refers to the associated data that is not encrypted)

2021 Rolf Oppliger Slide 38 • After B receives the initial message, it performs the following steps ID • B extracts pkA and pka from the inital message ID • B uses these keys together with its private identity key skB , private signed PK OT prekey skb and private one-time prekey skb,j (if used by A) to generate the master secret s

ID PK ID PK OT s = ECDH(pkA ,skb ) || ECDH(pka,skB ) || ECDH(pka,skb ) [ || ECDH(pka, skb,j ) || ] • Again, it deletes all intermediate values ID ID • B uses pkA and pkB to construct AD, and uses it to decrypt the ciphertext with s • If decryption succeeds, • then it deletes any one-time private key that was used and continues to use s or keys derived from it in post-X3DH communication • otherwise, the protocol aborts (and may return an error message)

2021 Rolf Oppliger Slide 39 • The valiation model for identity keys is trust on first use (TOFU) ID version, A, pk ID, B, pk ID • At any time, A and B can compare pkA and A B ID pkB through an authentic channel (→ authen- tication ceremony) • Both keys are encoded in a Quick Response (QR) code or 60-digit security number

2021 Rolf Oppliger Slide 40 • After having executed the X3DH protocol and optionally verified the secu- rity number, A and B can use the to exchange encrypted messages and derive new keys • Each entity maintains three «key chains» (aka «KDF chains») • Root chain (Type I) • Sending chain (Type II) • Receiving chain (Type II) • The root chain ratchets forward a root key, whereas the sending and receiving chains ratchet forward a respective chain key

2021 Rolf Oppliger Slide 41 A selects an ephemeral public key pair (ska,pka) PK and uses pkb to compute a new DH output as PK ECDH(ska,pkb ) It triggers the KDF with this value and derives a new root key and a new chain key for the sending chain The new chain key is used to trigger the sending chain’s KDF and to derive a new chain key and a new message key Finally, the message is encrypted with the new message key and sent to B together with pka

B recomputes the same DH output as PK ECDH(pka,skb ) It triggers the KDF with this value and derives a new root key and a new chain key for its receiving chain The new chain key is used to trigger the receiving chain’s KDF and to derive a new chain key and a new message key Finally, the message is decrypted with the new message key

A’s sending chain and B’s receiving chain are now in sync (A’s receiving chain and B’s sending chain can be synchronized similarly)

2021 Rolf Oppliger Slide 42 • Group messaging in Signal employs a client-side fan-out mechanism • This improves privacy, because the server need not be aware of group memberships (→ groups cannot be administered by the server)

2021 Rolf Oppliger Slide 43 • The security of the Signal protocol has become a major research topic • The generic protocol name is ratcheted key exchange (RKE) • Sometimes, people refer to an asynchronous RKE (to emphasize the fact that it is used in an asynchronous setting) or a bidirectional asynchronous RKE (to emphasize the fact that messages are exchanged in either direction) • The use of formal methods has not revealed serious vulnerabilities or security problems • The 2-party case is considered to be secure • In the case of group messaging (with more than 2 parties), a few subtle and unspectacular vulnerabilities and shortcomings have been found

2021 Rolf Oppliger Slide 44 • Privacy improvements • Encrypted profile Some complementary user profile data (e.g., display name, picture, .. ) is stored in encrypted form and can be decrypted only with a profile key that is sent with each E2EE message (→ profile data remains invisible for all other users) • Private contact discovery Uses trusted hardware (i.e., Intel SGX enclaves) to protect the contact discovery process (→ the server doesn’t get any information about the users’ contacts) • Sealed sender Hides information about the sender of a message (using short-lived sen- der certificates and delivery tokens that are part of the recipient’s encrypted profile)

2021 Rolf Oppliger Slide 45 • The Signal protocol represents the state of the art in secure and E2EE messaging on the Internet • It is omnipresent and used in many other messengers and messenger apps (either natively or in minor variations) • WhatsApp • ’ «secret conversations» • • Google Allo «incognito mode» (before Google abandoned Allo in 2019) • Google Messages (more recently) • • Silent Circle’ Silent Phone • …

2021 Rolf Oppliger Slide 46 • There are a few independent open source implementations, such as Proteus and Olm (C++) • Proteus is based on the cryptographic library libsodium (fork of NaCl) and is the basis of (launched by GmbH in 2014) • Olm is used, for example, in the project and its messenger Riot • Furthermore, the Signal protocol is the basis for an XMPP extension called Multi-End Message and Object Encryption (OMEMO) • OMEMO is implemented by several E2EE messengers, like Conversations, (discontinued in 2019), and ChatSecure

2021 Rolf Oppliger Slide 47 WhatsApp • WhatsApp is an instant messaging service provided Brian Acton by WhatsApp Inc. (founded in 2009 by two former Yahoo employees) • In 2014, Facebook acquired WhatsApp (19 billion USD) • After the revelations of , there was a lot of market pressure to incorporate some form of encryption (preferrably end-to-end) into WhatsApp • In 2016, the Signal potocol was implemented in Whatsapp and activated by default • Today, WhatsApp is probably the most widely deployed E2EE app on the Internet (> 2 billion users worldwide) • WeChat does not provide E2EE messaging

2021 Rolf Oppliger Slide 48 • The technical white paper (last updated in October 2020) is not compre- hensive and does not stand by itself • The mobile number serves as a user identifier (but is not verified again after the initialization) • Cryptographic implementation choices • The elliptic curve is Curve25519 • Message encryption uses AES-256 in CBC mode • Message authentication uses HMAC-SHA256 • Every root or chain key is 32 bytes long • Every message key is 80 bytes long • 32 bytes for AES-256 • 32 bytes for HMAC-SHA256 • 16 bytes for IV

2021 Rolf Oppliger Slide 49 • The «normal» Signal HKDF is used in the root chain (type I), i.e., to derive chain keys from root keys • HMAC-256 is used in the sending and receiving chains (type II), i.e., to derive message keys from chain keys • message key = HMAC-SHA256(chain key, 0x01) • chain key = HMAC-SHA256(chain key, 0x02) • Message attachments of any type are also E2E-encrypted

• The sender randomly generates an ephemeral 32-byte AES-256 key Ke and an ephemeral 32-byte HMAC-256 key Ka Note that Encrypt-then-MAC defeats all known • The sender encrypts the attachment with Ke using AES-256 oracle attacks against CBC in CBC mode and a random IV, and appends a MAC of the mode; Facebook messenger ciphertext using HMAC-256 and Ka alternatively uses AES-GCM • The sender uploads the now encrypted and authenticated attachment (denoted as attachment*) to a blob store

2021 Rolf Oppliger Slide 50 • The sender sends a normally encrypted message to the recipient that comprises

• Ke and Ka • A SHA-256 hash of attachment* • A pointer to attachment* in the blob store • The recipient decryps this message and uses the pointer to retrieve attachment* from the blob store • The recipient then verifies the SHA-256 hash value of attachment*, verifies the MAC with Ka and decrypts the attachment with Ke • Voice or video call • The initiator sets up an encrypted session to the recipient • The initiator generates a random 32-byte SRTP master secret • The initiator uses the session to send an encrypted message to the recipient (to signal the call and to transmit the master secret)

2021 Rolf Oppliger Slide 51 Noise pipe with Curve25519, • Group messaging AES-GCM, and SHA256 • WhatsApp uses the «Sender Keys» variant of the Signal protocol SK = sender key • Each user sends a sender key and a public signature key to all other others (using E2EE channels) • Afterwards each group message is E2EE with the sender key and digitally signed • The server fans out the message • Each recipient can verify the signature and decrypt the message

• When a member leaves the group, all group members have to clear the state and the protocol must start from scratch • Because groups are administered, the server need to be trusted

2021 Rolf Oppliger Slide 52 8. Conclusions and Outlook

• For a long time, secure messaging was considered to be a solved problem (→ «just encrypt and digitally sign messages») • Solutions like PGP, OpenPGP, and S/MIME were implemented and integrated into (COTS) products • OTR changed the field and led to a paradigm shift in secure messaging • Many subsequent solutions (except iMessage, , and a few others) have followed this path • More sophisticated cryptographic techniques are used, like AKE protocols, Diffie-Hellman and double ratchets, MACs, authenticated encryption, and malleable encryption

2021 Rolf Oppliger Slide 53 • Furthermore, people are looking for alternatives to public key certificates and fingerprints, e.g., SMP and QR codes • Social authentication (e.g., Keybase, Confidante on top of it, … ) • Use of distributed ledger technologies (e.g., ARPKI, CONIKS, … ) • The Signal protocol refers to the culmination point and state of the art in E2EE messaging on the Internet • Cryptographic research topics • More efficient cryptographic techniques to provide forward secrecy and PCS • Forward secure public key encryption (FS-PKE) • puncturable encryption • More distributed approaches (e.g., , Elixxir, … ) • Message franking • Censorship circumvention (e.g., )

2021 Rolf Oppliger Slide 54 • More recently, the IETF has started to address the topic and chartered a message layer security (MLS) WG within the security area • The is to provide an architecture and a respective protocol that can be used for any messaging-type application (be it sychronous or asynchronous) • The basis for the work of the IETF MLS WG is the Signal protocol and some prior work related to group key exchange • More specifically, it explores the use of Diffie-Hellman trees for group messaging • Asynchronous ratcheting tree (ART) • Tree-based key encapsulation mechanism (TreeKEM) • Continuous group key agreement (CGKA) • …

2021 Rolf Oppliger Slide 55 • With regard to security, E2EE «only» protects messages in transfer • On the (sending and receiving) devices, the messages are either up- loaded to the cloud and/or remain locally stored and protected by the • If somebody can log into the device, then he or she has usually also access to this user’s messages • This should be kept in mind when chats are stored and archived for long periods of time (→ «self-destroying messages») • It also leads to legal disputes between manu- facturers and legal forces (e.g., Apple vs. FBI) • As usual, making a user interface as simple as possible (and making everything transparent to the user) is a double-edged sword

2021 Rolf Oppliger Slide 56 2021 Rolf Oppliger Slide 57 2021 Rolf Oppliger Slide 58