class: big, middle # ECE 7420 / ENGI 9823: Security .title[ .lecture[Lecture 20:] .title[Private messaging] ] --- # Today ### Encrypted communication ### Private communiction ### Technology and society --- layout: true # Encrypted communications .floatright[ $$ \begin{align} A \rightarrow B &: \alpha^{X\_A} \pmod{q} \\\\ B \rightarrow A &: \alpha^{X\_M} \pmod{q} \\\\ A \rightarrow B &: \left\\{ k\_{AB} \right\\}\_{K\_A^{-1}} \\\\ B \rightarrow A &: \left\\{ k\_{AB} \right\\}\_{K\_B^{-1}} \\\\ A \rightarrow B &: \left\\{ \left\\{ M\_A \right\\}\_{K\_A^{-1}} \right\\}\_{k\_{AB}} \\\\ B \rightarrow A &: \left\\{ \left\\{ M\_B \right\\}\_{K\_B^{-1}} \right\\}\_{k\_{AB}} \\\\ A \rightarrow B &: \dots \end{align} $$ ] --- ??? If someone asked you to design a protocol for secure communication between two endpoints, it might look something like this. This protocol applies cryptographic primitives that we've learned about in various sensible ways, including: -- ### Diffie-Hellman ??? * Diffie-Hellman key agreement ensures that Alice and Bob can generate a key that even a Dolev-Yao attacker can't crack — unless they act as a middleperson -- ### Middleperson detection ??? * signing the symmetric key used by both parties will detect a middleperson if it's occurring, assuming Alice and Bob can know each other's public keys -- ### Digital signatures ??? * signing (or MAC'ing) all messages allows Alice and Bob to attest to who write them -- ### Encryption ??? * encrypting the signed (or MAC'ed) messages hides their contents from any network observer --- ## This gives us: ??? Q: **what security properties does this protocol give us?** -- ### Confidentiality -- ### Integrity -- ### ... the end of protocols? ??? So is this it? Do all protocols now follow this basic model? Some thought they would, but **what if we want different properties**? --- layout: false # Communications integrity ### What do we want when we talk about integrity? -- * **Contracts:** -- _non-repudiability_ -- * Alice can't claim she didn't seal this engineering drawing -- * Bob can _forever_ prove that Alice's private key signed it -- * **Personal communication:** -- _authenticity_ -- * Alice knows it was Bob who just said X -- ... _right now_ --- # Digital signatures ### Strong integrity ??? Digital signatures were designed with one set of constraints in mind, and they work really well for that use case. They do provide **strong integrity properties** assuming that **you can link a public key to an identity that you care about**. -- ### Strong non-repudiation ??? Digital signatures provide this integrity by providing non-repudiation. This is great for **legally-binding contracts**, where **a signature is forever**, but that's not always what we want! -- * ... even several years down the road -- * ... even after Bob loses his laptop -- * ... then someone can _prove_ what Alice said to Bob -- (**privately!?**) --- # Privacy and security ### Lots of overlap in: * tools * techniques * technologists ??? People often describe themselves as working in "privacy and security", because they are closely-related fields that are built on many of the same fundamental technologies. Cryptography can be used to help secure a company's intellectual property; it can also be used to help secure my private communincations. These two objectives have many overlapping objectives (confidentiality and integrity on behalf of a user or set of users), but they also have important differences. -- ### Privacy requires security... -- but not synonymous ??? You can't have electronic privacy without security: if your systems are vulnerable to your adversaries, they can compromise your privacy by breaking in and stealing (or manipulating!) your systems and information. --- # Private communication -- ### Only Alice and Bob can read each other's messages -- * **confidentiality** ― not just in the moment! -- * even if Eve acquires $k\_{AB}$, we'd like to minimize the harm done -- : _perfect forward secrecy_ ??? We don't just want to have our messages be private right now. Even if an attacker manages to "break into" our communication at time $t\_n$, we would like all communications from $t\_0$ to $t\_{n-1}$ to remain confidential. That seems like a stretch, but **it is indeed possible**. -- * Alice doesn't want to depend on Bob for her privacy -- : _repudiability_ -- ― this has implications for **integrity** regime ??? Unlike many security regimes, privacy often demands **repudiability**. You can violate my trust by repeating something that I told you in confidence, but it's a whole other level of violation when you record and can **prove** what I said. --- # Off-the-record (OTR)&dagger; .footnote[ &dagger; Borisov, Goldberg and Brewer, "Off-the-record communication, or, why not to use PGP", in _WPES '04: Proceedings of 2004 ACM Workshop on Privacy in the Electronic Society_, 2004. DOI: <a href="https://doi.org/10.1145/1029179.1029200">10.1145/1029179.1029200</a>. Also see: https://otr.cypherpunks.ca. ] -- ### Use short-lived symmetric _session keys_ -- Compromising Bob's computer provides no help decrypting messages: _perfect forward secrecy_ -- ### Use symmetric MACs rather than signatures -- "Either Bob said this or I did": _repudiability_ ??? We explicitly _want_ to be able to repudiate messages. Using symmetric MACs helps with this. Suppose I wanted to prove to someone else that you said something (message $M$). Using a protocol with digital signatures: $$ \begin{align} A \rightarrow B &: \left\\{ \left\\{ M \right\\}\_A^{-1} \right\\}\_{k\_{AB}} \end{align} $$ Bob could take message $\left\\{ M \right\\}\_A^{-1}$ and show it to someone else. "See? Here's proof that Alice said $M$!" If, however, Alice sends $\textrm{MAC}\_{k\_{AB}}(M)$ to Bob, Bob can only prove that **someone who knew $k_{AB}$ generated the message**. Since there are **two people who know $k_{AB}$**, this adds no evidence beyond Bob's say-so that Alice actually said $M$! --- # OTR protocol -- ### Broad strokes: ??? We'll focus on the initial version of the protocol as described in <a href="https://doi.org/10.1145/1029179.1029200">the original paper</a>. This leaves out some of the details that are required to actually implement something that works (e.g., message IDs and key IDs to help Alice and Bob keep track of the communication), but it contains the core ideas. The most recent, detailed version of the protocol can be found at https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html. -- 1. Authenticated key exchange (AKE) -- 2. Message exchanges -- 3. Frequent _re-keying_ --- # OTR message encryption .floatright[ $$ \begin{align} A \rightarrow B &: g^{x\_1} \\\\ B \rightarrow A &: g^{y\_1} \\\\ A \rightarrow B &: g^{x\_2}, \left\\{ M\_1 \right\\}\_{k\_{11}} \\\\ B \rightarrow A &: g^{y\_2}, \left\\{ M\_2 \right\\}\_{k\_{21}} \\\\ A \rightarrow B &: g^{x\_3}, \left\\{ M\_3 \right\\}\_{k\_{22}} \end{align} $$ where: $$ k\_{ij} = h\left( g^{x\_i y\_j} \right) $$ ] -- ### Diffie-Hellman key exchange ??? Is there anything missing from the protocol as shown on this slide? -- ### Symmetric-key encryption -- ### Re-key _every message_ ??? Every message adds a **new Diffie-Hellman parameter**, so we **never need to use the same key twice**. -- If $k\_{ij}$ exposed, Eve gets... -- **one message**. --- # OTR authentication ### How does Alice know she's talking to Bob? -- .floatright[ $$ \begin{align} A \rightarrow B &: \left\\{ g^{x\_1} \right\\}\_{K\_A^{-1}}, K\_A \\\\ B \rightarrow A &: \left\\{ g^{y\_1} \right\\}\_{K\_B^{-1}}, K\_B \end{align} $$ ] The **one** place for digital signatures: authenticating with long-term public keys to detect middleperson / impersonation. -- #### Then MACs: $$ A \rightarrow B : g^{x\_i+1}, \left\\{ M\_n \right\\}\_{k\_{ij}}, \textrm{MAC}\_{h\left( k\_{ij} \right)} \left( \left\\{ g^{x\_i+1}, \left\\{ M\_n \right\\}\_{k\_{ij}} \right\\} \right) $$ ??? This slide shows a little bit more detail: in addition to the new Diffie-Hellman parameter and the encrypted message, we also send along a MAC that uses a key **derived from $k_{ij}$** but which is **distinct from $k_{ij}$**. This means that anyone who knows the encryption key $k\_{ij}$ can **generate the MAC key and check the message**, but it's safe for MAC keys to leak without revealing confidential information in the way that leaking $k\_{ij}$ would. -- ... then **publish MAC keys** (???) ??? In fact, not only is it safe for MAC keys to leak, the protocol actually includes a step in which we _publish_ MAC keys! Why in the world would we want to publish our MAC keys to the world? -- ... to enhance **repudiability** ??? This step enhances _repudiability_. We already know that , even without this step, **anyone who knows $k_{ij}$** can fake up a message from Alice saying $\left\\{ M, \textrm{MAC}\_{h\left(k\_{ij}\right)}(M) \right\\}$. Normally, the set of people who **know $k_{ij}$** is just Alice and Bob. However, if we publish our MAC key $h\left(k\_{ij}\right)$ a few messages later, it's now possible for **anyone listening to the network** to generate a MAC'ed message. This, albiet counterintuitively, _increases_ Alice's privacy, since if **anyone** could have generated the message, there is **zero proof** that Alice did beyond Bob saying so. --- # OTR benefits ### Confidentiality with _forward secrecy_ ### Authentication with _repudiability_ ??? The goal of private messaging isn't to act like a confidential legal document. Instead, it's meant to act like a **private conversation**, in which the technology provides confidentiality and integrity properties that are **as close as possible** to two people talking to each other in the same room. OTR doesn't prevent your conversation partner from recording everything you say and sharing it with anyone they would like. However, it doesn't give them any technical evidence **beyond** what they could take away from a private conversation (their own recollection, contemporaneous notes, etc.). --- # OTR benefits .floatright[ <img src="fake-messages.png" width="300"/> .caption[[ifaketextmessage.com](https://ifaketextmessage.com)] ] ### Confidentiality with _forward secrecy_ ### Authentication with _repudiability_ ### Counterintuitive result: ??? The goal of private messaging isn't to act like a confidential legal document. Instead, it's meant to act like a **private conversation**, in which the technology provides confidentiality and integrity properties that are **as close as possible** to two people talking to each other in the same room. -- * if anyone could've faked that photo or video or message stream... --- # OTR benefits ### Confidentiality with _forward secrecy_ ### Authentication with _repudiability_ .floatright[ <img src="https://cdn.pocket-lint.com/r/s/660x/assets/images/140252-apps-news-famous-photoshopped-and-doctored-images-from-across-the-ages-image13-ajstxr61yv-jpg.webp?v1" width="400"/> .caption[Source: Fourandsix Technologies, Inc] ] ### Counterintuitive result: * if anyone could've faked that photo or video or message stream... * we all get (appropriately) skeptical about technical evidence's origins ??? The goal of private messaging isn't to act like a confidential legal document. Instead, it's meant to act like a **private conversation**, in which the technology provides confidentiality and integrity properties that are **as close as possible** to two people talking to each other in the same room. OTR doesn't prevent your conversation partner from recording everything you say and sharing it with anyone they would like. However, it doesn't give them any technical evidence **beyond** what they could take away from a private conversation (their own recollection, contemporaneous notes, etc.). Before it became widely known just widespread photo retouching was, a photograph might've been considered iron-clad evidence that an event happened. Once we all learned just how good the pre-Photoshoppers were, however, images lost that power. Everyone knows about [Stalin's zeal for erasing his enemies from photographic history](https://en.wikipedia.org/wiki/Censorship_of_images_in_the_Soviet_Union#Censorship_of_historical_photographs), but [photo tampering has been happening since the 1860s](https://www.cc.gatech.edu/~beki/cs4001/history.pdf). The image on this page shows that even King George VI wasn't safe from the power of the airbrush! Today, if you see an image of something that you don't want to believe, your first thought might well be, "it must be Photoshopped!" Soon we'll think the same thing about deepfake videos; we should already hold this level of skepticism towards chat messages. --- .floatright[ <img src="part-of-signal.png" width="450" alt="Part of the Signal messaging protocol"/> .caption.center[Part of the Signal protocol] ] # Signal .footnote[ &ast; Cohn-Gordon, Cremers _et al._, "A Formal Security Analysis of the Signal Messaging Protocol", in _EuroS&P17: Proceedings of the 2017 IEEE European Symposium on Security and Privacy_, 2017. DOI: <a href="https://doi.org/10.1109/EuroSP.2017.27">10.1109/EuroSP.2017.27</a>. ] -- * a wee bit more complicated! -- * everywhere (e.g., WhatsApp) -- * similar short-term session keys -- * additional _key ratcheting_ -- * support **multiple devices** --- # Almost-end-to-end messaging ??? We now know how security protocols can be used to provide strong security and/or privacy properties in end-to-end messaging. However, what we if _want_ to have more than two endpoints in communication? -- ### Signal, iMessage, etc., support multiple devices -- ### Requires _key distribution server_ ??? A _key distribution server_ can be used to keep track of all of the devices used by users and which public keys are associated with each. That way, I can send a message to **all of your devices**. However, something about this should make you nervous... -- * "dear KDS, please send me the device keys for Alice" -- * need to encrypt for multiple devices -- * scrutiny of this list of keys? ??? ... this means that you have to trust the KDS to **give you the correct keys and only the correct keys!** --- # Ghost protocol .floatright[ <img src="http://moviesmedia.ign.com/movies/image/object/856/856324/Mission-Impossible-Ghost-Protocol_Poster-FULL-1.jpg" width="300" alt="Poster from Mission Impossible: Ghost Protocol"/> ] -- Technology embodies values -- , affects power dynamics -- , including big questions around... -- #### Lawful interception/exceptional access ??? Privacy-enhancing technology for you also means privacy-enhancing technology for people you might not want to have private communications. Everyone may have different thresholds of who counts as "villanous", but everyone will disapprove of at least one of the following: * people who **criticize the government** * people who **share misinformation** * people who **sell illegal things** * people who **plot acts of violence** * people who **abuse children** All of these people can use private messaging technology to hide their activities from law enforcement... **how do you feel about that?** -- * A letter from GCHQ: ["Principles for a More Informed Exceptional Access Debate"](https://www.lawfareblog.com/principles-more-informed-exceptional-access-debate) -- * A response from... the Internet: ["Open Letter to GCHQ on the Threats Posed by the Ghost Proposal"](https://www.lawfareblog.com/open-letter-gchq-threats-posed-ghost-proposal) ??? Q: What do you think? --- # Operation Ironside ??? One alternative that law enforcement (and others) have available is going after the endpoints rather than cracking the crypto. -- ### [Phantom Secure](https://www.theregister.com/2018/10/03/phone_ceo_pleads_guilty) (Canadian company) ??? Phantom Secure was a company that would provide phones with private communication functionality (for over $1k per month per phone!) to large criminal organizations. The network was shut down in 2018 when the FBI arrested its CEO. This left an opening in the market for secure communications among non-techy organized crime types... -- ### AN0M ??? ... a gap that was filled by a new system called `AN0M`, sold to criminals by someone who'd been involved in Phantom Secure. That someone was up on charges in the US, so they... [offered it to the FBI](https://www.theverge.com/2021/6/8/22524307/anom-encrypted-messaging-fbi-europol-afp-sting-operation-trojan-shield-greenlight)! -- &ast; .footnote[ &ast; Robertson, ["The FBI secretly launched an encrypted messaging system for criminals"](https://www.theverge.com/2021/6/8/22524307/anom-encrypted-messaging-fbi-europol-afp-sting-operation-trojan-shield-greenlight), 8 Jun 2021. Corder, Perry and Spagat, ["How a Secret FBI App Kept Tabs on Crimintals in Australia, New Zealand"](https://www.bloomberg.com/news/articles/2021-06-08/down-under-criminals-tricked-into-using-fbi-run-message-app), _Bloomberg_, 8 Jun 2021. ] * 27 M messages among 9,000 devices ??? This system, which became even more popular when [BlackBerry shut down Gky Global](https://www.theregister.com/2021/03/19/sky_global_ecc_shuts_down_indictment_raids) (another Canadian company!) in 2021. Every message sent on the `AN0M` network was effectively carbon-copied to the Australian Federal Policy and the US FBI. -- * 800 arrests, 8 T of cocaine, 22 T of cannabis, 250 guns, $48 M ??? This led to a lot of busts, but making this arrests came at the cost of blowing the network's cover. What will criminals use next? -- * trust issues ??? Just disrupting the ability of multi-national criminal organizations to communicate with confidence will have some effect on their activities. However, the crooks won't just give up: they'll try something new. When they do, law enforcement and intelligence agencies also won't just give up. Q: How do you think free countries should balance the needs of privacy and security? --- # Summary ### Encrypted communication ### Private communiction ### Technology and society --- class: big, middle The End.