CMSC 414 Computer and Network Security Lecture 18

1
CMSC 414Computer and Network SecurityLecture 18

• Jonathan Katz

2
Administrative

• Exam April 22
• Based on material through April 15
• Next HW out later today, will be Exercises rather
  than a project
• One more project (buffer overflows) later in the
  semester

3
WireShark demonstration

• NYTimes sends the password in the clear
• View SSL/TLS session
• Old (insecure) Yahoo! email authentication

4
Certificate authorities and PKI
5
PKI overview

• In our discussion of public-key crypto, we have
  assumed users know each others public keys
• But how can public keys be reliably distributed?
• Download from web page insecure against
  man-in-the-middle attack
• Can be obtained from CD-ROM or in person, but
  this is impractical in general
• One solution bootstrap new public keys from
  public keys you already know!
• Certificates vouch for binding of public keys to
  names

6
Certificates

• One party can vouch for the public key of another
• Cert(A?B) SignSKA(B, PKB, info)
• info can contain expiration time, restrictions,
  etc.
• Can view this as a directed edge in a graph
• If you know As public key (and trust its
  certification), you can learn Bs public key

7
Transitivity/certificate chains

• Can learn keys via multiple hops
• Semantics are slightly different here you may
  trust A to certify B, but do you trust A to
  certify that B can certify others?

8
Transitivity

• Can also infer trust from multiple (disjoint?)
  paths to the same public key for the same
  identity
• Edges may also have weights indicating level of
  trust
• A difficult problem in general

PKD
PKE
Public keys I already know
9
Usage of certificates

• Trust anchors set of public keys already
  known (and trusted to certify others)
• How to obtain certificates?
• Some possibilities
• B collects certificate(s) for itself, sends
  these all when starting a connection
• A finds certificates/certificate chains beginning
  at its own trust anchors and terminating at B
• A tells B its trust anchors, B (finds and) sends
  certificates or certificate chains beginning at
  those trust anchors and terminating at itself

10
PKI components

• Certificates
• Distributing the keys of the trust anchors
• (Means for retrieving certificates)
• (CAs)
• (Naming conventions)
• (Trust model/method for evaluating a certificate
  chain)
• (Revocation)

11
CAs and certificates

• A certificate authority (CA) is just a widely
  used trust anchor
• CA authentication policy determines the level of
  authentication needed to identify the principal
  before the certificate is issued
• CA issuance policy describes the principals to
  whom the CA will issue certificates
• A single CA can act as multiple CAs, each with
  their own policies
• Use distinct public keys (with different security)

12
Example Verisign (1996)

• Three levels of authentication
• Verification of valid email address
• Verification of name/address
• Background check
• Different authentication policies same issuance
  policy (individuals only)
• Another issuance policy was for issuing
  certificates to corporations/web servers

13
Naming

• Identifiers correspond to principals
• Must uniquely identify the principal
• (Real) names alone are not enough!
• Need disambiguation
• A principal may have multiple identifiers
• Depending on that principals roles
• E.g., work/personal

14
E.g., X.509 certificates

• Distinguished names identify a principal
• Series of fields, each with key and value
• E.g. /OUniversity of Maryland/OUCollege
  Park/OUComputer Science/CNJ. Katz
• O - organization OU - organizational unit
  CN common name

15
What does identity mean?

• Ultimately, identity is proved using physical
  means
• Drivers license, fingerprints, etc.
• If these are compromised, then certificates are
  irrelevant!
• Certificate is just a binding between external
  identity and (DN, PK)

16
Trust

• How much to trust a particular certificate?
• Based on
• CA authentication policy
• Rigor with which policy is followed
• Assumptions inherent in the policy

17
Trust models

• Define valid trust anchors, how a verifier
  chooses trust anchors, and what certification
  paths create a legal chain from trust anchor to
  target

18
Monopoly model

• A single CA certifies everyone
• Drawbacks
• Single point of failure
• Not very convenient
• Complete monopoly
• Pure monopoly not used in practice

19
Monopoly RAs

• The CA can appoint RAs
• RAs check identities and vouch for keys, but the
  CA does all actual signing
• Certainly more convenient
• Not necessarily more secure
• (Note RAs can be integrated into other models as
  well)

20
Monopoly delegated CAs

• CA can issue certificates to other CAs
• Vouch for their key and their trustworthiness as
  a CA
• Delegated CA can sign certificates itself
• Users must now obtain a certificate chain
• (Note delegation can be incorporated into other
  models as well)

21
CA hierarchy

• Hierarchical structure of CAs
• Nodes correspond to CAs
• Children of a CA are constrained by the policies
  of their parents

22
Conflicts

• What if two CAs have the same distinguished name?
• What if two different CAs issue certificates for
  the same distinguished name (but to different
  principals)?
• An easy way to address these is to have
  hierarchical names for CAs, and to incorporate CA
  distinguished name into issued certificates

23
Oligarchy

• Multiple trust anchors
• E.g., multiple keys pre-configured in software
• User can add/remove trust anchors
• Issues
• Less resistant to compromise!
• Who says the user trusts the trust anchors?
• Can users be tricked into using bad trust
  anchors?
• Issuer name may be bogus
• Can public keys of good trust anchors be
  changed in the software?

24
Anarchy model

• Users responsible for defining the trust anchors
  they want to use
• Drawbacks
• Scalability/usability?
• How much trust to place in a certificate chain

25
PKI in practice

• PKIs are implemented in web browsers
• A certificate is meaningless without verifying
  the name in the certificate
• A certificate from an unknown CA is useless
• Trust is only as good as your trust anchors
• Do you know who your trust anchors are?
• PGP web of trust model
• PGP keyserver