1. CMSC 414 Computer and Network Security Lecture 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 Z N * is a square –I.e., y is a quadratic residue if y = x 2 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 = x 2 mod N  The protocol: –User sends a = r 2 mod N for random r –Server sends a bit b –User responds with c = r x b mod N –Server checks that c 2 = a y b 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 Z N * –Set a = c 2 /y b 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