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 privacy) → 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 cryptography 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 Internet (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 (instant messaging) • 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 transport layer security 2021 Rolf Oppliger Slide 8 • RFC 3923 specifies how to invoke S/MIME for message signing and encryption 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 • Facebook 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 messaging apps 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 • Google is also heading towards RCS with its Jibe platform and RCS client Messages (that replaces Google Allo) • Since November 2020, Google Messages imple- ments E2EE with the Signal 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 (cryptosystems) • There are many systems to choose from Unkeyed (keyless) Secret Key (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 authentication • Public key certification • Authenticated encryption • 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 key exchange To provide (perfect) forward secrecy • Ratchet-based key derivation and post-compromise security (PCS) • Message authentication codes (MACs) • Deniable authentication To provide plausible deniability • 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 shared secret 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., Microsoft 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 • Pretty Good Privacy (PGP) was originally developed by Phil Zimmermann 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 free software 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 • Digital signature • Compression • Encryption • Transfer encoding • PGP/OpenPGP uses a distinct for- mat for public key certificates and a web of trust • 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