class: big, middle # ECE 7420 / ENGI 9823: Security .title[ .lecture[Lecture 19:] .title[Security protocols] ] --- # Today ### Security protocols ### Protocol notation ### Examples * Needham—Schroeder and Kerberos * Diffie-Hellman and TLS --- # Recall: Dolev-Yao attacker&ast; .footnote[ &ast; Dolev and Yao, "On the Security of Public Key Protocols", _IEEE Transactions on Information Theory_ 29(2), 1983. DOI: <a href="https://doi.org/10.1109/TIT.1983.1056650">10.1109/TIT.1983.1056650</a> ] ### Communications should assume an attacker can: 1. observe all messages (**passive eavesdropper**), 2. send messages impersonating users (**active** attacker) and 3. intercept messages and drop or replace them (**middleperson**). -- #### Be explicit about trust and communication: _security protocols_ --- # Security protocols ### Rules for interaction among multiple parties -- * notation and conventions -- * primitives -- ### Implicit: understandings of _belief_ ??? The protocol notation that we'll see in this class will describe things like messages that are sent from one party to another and cryptographic primitives that are used to protect them. -- * can be modeled formally ??? It's possible to model these beliefs formally. The [BAN logic](https://doi.org/10.1098/rspa.1989.0125) was an early example of this, with primitives such as: $P \mid\equiv X$: $P$ _believes_ $X$ $P \triangleleft X$: $P$ _sees_ $X$ $P \Rightarrow X$: $P$ _has jurisdiction_ over $X$ It's also possible to model protocols in such a way that automated _theorem proving_ can be applied to them, using tools like [ProVerif](https://bblanche.gitlabpages.inria.fr/proverif). -- * not our focus --- # Security protocol notation -- | Primitive| Notation | Meaning | |:---------|:---------|:--------| | Message | $A \rightarrow B : P$ | Alice sends the password $P$ to Bob -- | Hash | $A \rightarrow B : h(P)$ | Alice sends the hash of $P$ to Bob -- | Encryption | $A \rightarrow B : \\{P\\}\_{K\_B}$ | $P$ is encrypted under Bob's key -- | Shared key | $A \rightarrow B : \\{P\\}\_{k\_{AB}}$ | $k\_{AB}$ is shared by Alice and Bob -- | Signature | $A \rightarrow B : \\{P\\}\_{K\_A^{-1}}$ | Signature of $P$ using $K\_A$ -- | Nonce | $A \rightarrow B : N\_A$ | A _number used once_ -- | Timestamp | $A \rightarrow B : T$ | Alice sends Bob the current time ??? Note: this protocol notation includes no specification of **which** cryptographic algorithms are used! Instead, cryptographic primitives are assumed to work correctly and provide their promised poperties. Proofs can then be done using the [Standard Model](https://link.springer.com/referenceworkentry/10.1007/978-1-4419-5906-5_518), or more practically, in the [Random Oracle Model](https://link.springer.com/referenceworkentry/10.1007/978-1-4419-5906-5_220) that approximates cryptographic primitives with functions that produce random values. --- # Examples of common protocols ### Needham–Schroeder and Kerberos ### Diffie-Hellman key exchange ### TLS: Transport Layer Security ### OTR: Off-the-record messaging&ast;, Signal and friends .footnote[ &ast; Borisov, Goldber and Brewer, "Off-the-record communication, or, why not to use PGP", in _WPES '04: Proceedings of the 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>. }] --- # Security protocol example ### Needham–Schroeder protocol -- $$ \begin{align} A \rightarrow S &: A, B, N\_A \end{align} $$ ??? * Hi server, I'm Alice and I'd like to talk to Bob. Here's a random number. -- $$ \begin{align} S \rightarrow A &: \left\\{ N\_A, k\_{AB}, B, \left\\{ k\_{AB}, A \right\\}\_{k\_{BS}} \right\\}\_{k\_{AS}} \end{align} $$ ??? * OK, Alice, if you really are Alice you'll be able to decrypt this information. Here's your random number back (to prove that **I know $k_{AB}$**), a key you can use to talk to Bob, Bob's identity and a **ticket for you to give Bob**. -- $$ \begin{align} A \rightarrow B &: \left\\{ k\_{AB}, A \right\\}\_{k\_{BS}} \end{align} $$ ??? * Hi Bob, here's something that the server asked me to give you. -- $$ \begin{align} B \rightarrow A &: \left\\{ N\_B \right\\}\_{k\_{AB}} \end{align} $$ ??? * OK, if you really are Alice, you should be able to prove that **you know $k_{AB}$** by **decrypting and manipulating this nonce value**. -- $$ \begin{align} A \rightarrow B &: \left\\{ N\_B - 1 \right\\}\_{k\_{AB}} \end{align} $$ ??? * No problem, here's your nonce value minus 1. Now you should believe that **I know k_{AB}**, which I could only have **gotten from the server $S$**, which means that **$S$ says it's OK for us to talk**. ??? ### What's the flaw? **There could be an arbitrary gap between messages 2 and 3**, which means that if an attacker **can learn $k_{AB}$ even years later**, they can **replay this message to gain access to $B$**. This has been fixed in Kerberos through the use of **timestamps**. --- # Diffie-Hellman key exchange ??? We've described Diffie-Hellman key exhange before, using English prose, but now we'll see it written down with a more formal notation. Hopefully this will help us spot the **weakness** in the protocol! -- Alice chooses random number $X\_A$, Bob chooses $X\_B$ -- $$ \begin{align} A \rightarrow B &: \alpha^{X\_A} & \pmod{q} \\\\ B \rightarrow A &: \alpha^{X\_B} & \pmod{q} \end{align} $$ -- $$ \begin{align} k\_{AB} &= \alpha^{X\_A X\_B} & \pmod{q} \\\\ &= \left( \alpha^{X\_A} \textrm{ mod }{q} \right)^{X\_B} & \pmod{q} \\\\ &= \left( \alpha^{X\_B} \textrm{ mod }{q} \right)^{X\_A} & \pmod{q} \end{align} $$ -- But remember: **there is a weakness!** ??? At this point, $A$ and $B$ share a key. But **who are** $A$ and $B$? What basis do Alice and Bob have to **believe** that $A$ is Alice and $B$ is Bob? --- # Middleperson attack ??? Suppose we have a **middleperson** named Mallory ($M$) who acts as a Dolev-Yao attacker, sitting on the wire between Alice and Bob. -- $$ \begin{align} A \rightarrow M &: \alpha^{X\_A} \pmod{q} \\\\ M \rightarrow A &: \alpha^{X\_{M\_A}} \pmod{q} \end{align} $$ ??? When Alice sends her $\alpha^{X_A}$ message to Bob, Mallory can intercept it. Mallory can then impersonate Bob, so Alice and Mallory act out the first step of the protocol where Alice is $A$ and Mallory is $B$. -- $$ \begin{align} B \rightarrow M &: \alpha^{X\_B} \pmod{q} \\\\ M \rightarrow B &: \alpha^{X\_{M\_B}} \pmod{q} \end{align} $$ ??? The same then happens to Bob: Bob thinks he's talking to Alice (Alice is $A$ and Bob is $B$), but in fact he's talking to Mallory. Thus, from Bob's perspective, Mallory is $A$ and Bob is $B$. -- $$ \begin{align} k\_{AM} &= \alpha^{X\_A X\_{M\_A}} \pmod{q} \\\\ k\_{BM} &= \alpha^{X\_B X\_{M\_B}} \pmod{q} \end{align} $$ ??? After running the protocol with Mallory in the middle, Alice and Bob have established "secure" communications using symmetric-key cryptography, but only in a technical sense, not a meaningful sense! -- .centered[ <img src="dh-middleperson.svg" width="800" alt="Middleperson attack against Diffie-Hellman key exchange"/> ] --- # Middleperson detection .centered[ <img src="dh-middleperson.svg" width="800" alt="Middleperson attack against Diffie-Hellman key exchange"/> ] -- .floatright[ $$ \begin{align} A \rightarrow M &: \alpha^{X\_A} \pmod{q} \\\\ M \rightarrow A &: \alpha^{X\_M} \pmod{q} \\\\ B \rightarrow M &: \alpha^{X\_B} \pmod{q} \\\\ M \rightarrow B &: \alpha^{X\_M} \pmod{q} \\\\ A \rightarrow B &: \left\\{ k\_{AM} \right\\}\_{K\_A^{-1}} \end{align} $$ ] -- * "Wait a minute, that's not the same as my $k\_{BM}$!" ??? This works well as long as **Bob knows for sure what Alice's key is**. That's fine for point-to-point communications, but what about Web browsing, in which I'm connecting to — and needing to trust — services like my bank and my email provider? -- * **Q:** how do we check $K\_A$? -- * **A:** TLS _certificate authorities_ --- # Certificate authorities .floatright[ <img src="../17/Chain_of_trust.svg" width="500"/> .caption[ Source: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Chain_of_trust.svg) ] ] #### Recall: * Root CA signs (intermediate CA signs)&ast; entity certificate -- * Used for code signing -- , started with SSL/TLS -- #### Question: What if a certificate authority were compromised or malicious? ??? This is not a theoretical consideration! TLS puts a lot of trust in certificate authorities, so mistakes made at a CA can have wide-ranging effects. CAs can also be high-value targets for attackers seeking to break the confidentiality and integrity properties of TLS for large numbers of users or, more worrying, small numbers of users (even targeted individuals). -- Search terms: -- DigiNotar -- , TURKTRUST -- , **Certificate Transparency** --- # Certificate transparency .floatright[ <img src="https://certificate.transparency.dev/howctworks/img/with-ct-mix.svg" height="450"/> .caption[ Source: [certificate-transparency.org](https://www.certificate-transparency.org/how-ct-works) ] ] ### Certificate metadata: -- * certificate issuance ??? Before issuing a cerrtificate, a CA will first ensure that the certificate has been logged in a public append-only record (a kind of blockchain!). This gives them a Signed Certificate Timestamp, which indicates when the certificate should be merged to the public log. This SCT can then be included with certificate chains to say, "not only has my certificate been signed by a chain that goes back to this CA, the CA has publically committed to having issued that certificate." This means that, even if a CA goes rogue, they can't issue a certificate that my CT-expecting browser will accept unless they **tell the whole world that they issued it**. -- * certificate auditing ??? Website owners can then work with _monitors_ who watch the public certificate logs and look for funny business. For example, if a monitor notices that a new certificate was issued for `google.com` but Google doesn't know anything about it, they can raise the alarm that someone is trying to impersonate Google and they can **prove who issued the fraudulent certificate**. This dramatically increases the risk for a rogue CA of issueing a fraudulent certificate. -- * cross-signing -- ### Now _required_ by [Chrome](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/net/docs/certificate-transparency.md#Chrome-Policies) and [Safari](https://support.apple.com/en-gb/HT205280) -- (though not by [Firefox](https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency#browser_requirements)) --- # TLS: Transport Layer Security #### Most important protocol on the Internet -- * Most common example: HTTPS -- * Slow-moving train wreck from SSL 1.0 &rArr; successful [TLS 1.3](https://datatracker.ietf.org/doc/html/rfc8446) ??? There has been a steady parade of attacks against SSL 1.0 through SSL 3.0 and then TLS 1.0 through TLS 1.2. These have exploited things has subtle as improper ordering of primitives (encrypt-then-MAC vs MAC-then-encrypt) and incorrect padding within encryption. Weak Diffie-Hellman parameters, lack of forward secrecy... there's so much that we could go into if this were a course on the history of TLS vulnerabilities. -- * Amazing example of difficulty in herding cats -- #### Shockingly difficult to use correctly&ast; .footnote[ &ast; Georgiev et al., "The most dangerous code in the world: validating SSL certificates in non-browser software", in _Proceedings of the 2012 ACM conference on Computer and communications security (CCS ’12)_, pp. 38–49, 2012. DOI: [10.1145/2382196.2382204](https://doi.org/10.1145/2382196.2382204). ] ??? Aside from the difficulties of getting the protocol right, it's difficult to get people to use TLS APIs correctly! APIs that expose complex and subtle behaviours to experts are — surprise! — not always used correctly by non-experts who just want their app to "work". > Do not meddle in the affairs of wizards, for they are subtle and > quick to anger. — J.R.R. Tolkien, _The Fellowship of the Ring_ --- # Summary ### Security protocols ### Protocol notation ### Examples * Needham—Schroeder and Kerberos * Diffie-Hellman and TLS --- class: big, middle The End.