CMSC 414 Computer and Network Security Lecture 19

CMSC 414 Computer and Network Security Lecture 19 Jonathan Katz

Administrative ¨ Exam April 22 – Based on material through April 15 ¨ If you submit code for part 2 of HW 2, please name it “HW 3” to prevent collisions ¨ Include name of whose implementation you attacked ¨ HW 3 out

PKI in practice: web of trust ¨ PGP “web of trust” model ¨ Key distribution ¨ PGP keyserver

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

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

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

“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

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

Beyond secrecy: deniability, anonymity, and privacy

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

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

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

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?

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?

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

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 0 s for its randomness) and uses this as proof of its vote?

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)

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”

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 = 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)

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 xb mod N – Server checks that c 2 = a yb mod N – Repeat many times (in parallel, say)

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

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

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…

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