CMSC%20414%20Computer%20and%20Network%20Security%20Lecture%2019

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 dont 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 analogyAli Babas 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 users public key is (N, y), where y is a
  random quadratic residue
• Users 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