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 HW2, please
name it “HW3” to prevent collisions
 Include name of whose implementation you
attacked
 HW3 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 0s 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 = 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)
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)
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 = c2/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