CMSC 414 Computer and Network Security Lecture 19

1. CMSC 414Computer and Network SecurityLecture 19 Jonathan Katz

2. Administrative • Exam April 22 • Based on material through April 15 • If you submit code for part 2 of HW2, please name it “HW3” to prevent collisions • Include name of whose implementation you attacked • HW3 out

3. PKI in practice: web of trust • PGP “web of trust” model • Key distribution • PGP keyserver

4. Revocation • Revocation is a key component of a PKI • Secret keys stolen/compromised, user leaves organization, etc. • This is in addition to expiration dates included in certificates • Certificate might need to be revoked before expiration date • Expiration dates improve efficiency • Revocation may not be implemented

5. Cert. revocation lists (CRLs) • CA issues signed list of (un-expired) revoked keys • Must be updated and released periodically • Must include timestamp • Verifier must obtain most recent CRL before verifying a certificate • Using “delta CRLs” improves efficiency

6. OLRS • “On-line revocation server” • Verifier queries an OLRS to find out if a certificate is still valid • OLRS somewhat mitigates advantages of public-key model • But OLRS is not as security sensitive as a KDC/CA, and certs can be used even if OLRS is unavailable • If OLRS has its own key, it can certify for the target that its certificate is valid at a certain time

7. “Good lists” • The previous approaches basically use lists of “bad” certificates • Also possible to use a list containing only “good” certificates • Likely to be less efficient

8. Self revocation • Sign a message revoking your own public key; propagate throughout the network • This is essentially how revocation is done in the web of trust model • Deposit revocation into keyserver

9. Beyond secrecy: deniability, anonymity, and privacy

10. Secrecy is not everything • Deniability • No irrefutable evidence that you communicated with someone, even if that party is malicious • Anonymity/pseudonymity/privacy • No indication (to an external adversary) that you communicated with someone • No linkability, even to party with whom you are communicating • No information leakage beyond what is necessary

11. Standard crypto tools do not suffice! • Example: unidirectional authentication • Authenticated Diffie-Hellman leaves a trace that you communicated with a particular server • This trace is not something that could be fabricated! • It could be used as evidence in a court of law

12. Standard crypto tools do not suffice! • Example: signatures • A signed message from A to B leaves irrefutable evidence of the fact that you signed the message • Also leaves evidence of the fact that you signed something

13. Standard crypto tools do not suffice! • Example: encryption • What if A encrypts a message to B (using public-key crypto) and then a court order requires B to reveal its secret key?

14. Standard crypto tools do not suffice! • Example: credentials • I obtain a digital certificate from the MVA that proves I am over 21 • E.g., a signature on an appropriate statement • When I show this credential to someone else, it also reveals my name and address • Can this be avoided?

15. Standard crypto tools do not suffice! • Example: e-cash • How can I spend electronic cash securely yet anonymously? • On the one hand, need signatures for security • On the other hand, I don’t want the signature to be traced back to me

16. Standard crypto tools do not suffice! • Example: receipt freeness/coercibility (voting) • A can encrypt its vote to the central server, but what if A saves its randomness (or uses 0s for its randomness) and uses this as proof of its vote?

17. Standard crypto tools do not suffice! • Example: traffic analysis • Even if A encrypts its communication to B, an adversary monitoring the network can see that A and B are communicating • May be problematic when • Communication with B is not allowed • Communication reveals location of B (e.g., military) • A does not want to reveal its identity to B (e.g., voting)

18. Deniability • We need a protocol that A and B can execute such that, after running the protocol: • B is convinced it is talking to A… • …but B could have generated the transcript on its own! • Is this possible? • An analogy…“Ali Baba’s cave”

19. Background • Let N denote a product of two (large) primes p, q • A quadratic residue in ZN* is a square • I.e., y is a quadratic residue if y = x2 mod N for some x • Every quadratic residue has 4 square roots • It can be proved that computing square roots of random quadratic residues modulo N is as hard as factoring • (This is in contrast to RSA)

20. A public-key auth. protocol • A user’s public key is (N, y), where y is a random quadratic residue • User’s secret key is x, where y = x2 mod N • The protocol: • User sends a = r2 mod N for random r • Server sends a bit b • User responds with c = r xb mod N • Server checks that c2 = a yb mod N • Repeat many times (in parallel, say)

21. Why is this secure? • Look at any one iteration • If an adversary can answer both possible challenges, then it “must know” a square root of y • But computing square roots of y is hard

22. Why is this deniable? • We can generate honest-looking transcripts as follows: • Choose random bit b and random c in ZN* • Set a = c2/yb mod N • An execution (with an honest server) does not leave any evidence that could not be fabricated by the server itself!

23. Extensions… • The argument for deniability assumes an honest server • Can develop protocols that are deniable even against dishonest servers • Can also look at extensions of this idea to other settings…

24. Zero-knowledge protocols • (Informally:) Can prove something (e.g., that a given statement is true, that you “know” some value, etc.) to a verifier without revealing anything else! • E.g., proving knowledge of a square root of y • More generally, for any NP language L, can prove that x  L without revealing anything about the witness! • E.g., by reducing to 3-colorability