Public Key Certification Authorities

1
Public Key Certification Authorities
2
Public Key Certification Authorities

• how to be sure you have the right public key for
  a particular principal
• A service is needed that will provide a binding
  between a principal's name and public key.
• In order to trust that this binding is correct,
  the service (henceforth referred to as the
  certification authority (CA)) signs the
  representation of the binding.
• The public key for the CA is well-known, and
  therefore interested parties can ascertain that
  the signature is valid.

3
Public Key Certification Authorities

• If the CA is compromised, however, there is
  obviously a problem
• The private key for the CA should therefore be
  kept in a very safe place
• unlike the KDC for secret key cryptography, the
  CA does not need to be online all the time
• The CA has two functions
• certify bindings (i.e. certification) and
• store the certificates.
• Once created, the certificates can be stored
  anywhere and can even be procured (once signed)
  from an untrusted source.

4
Public Key Certification Authorities

• What happens if a principal's private key is
  compromised?
• all the certificates associated with that
  principal will cause the wrong public key to be
  used.
• A solution is to insist that certificates have
  expiration dates
• limits damage but doesn't completely eliminate it
  
• KDC could have dealt with this problem just by
  deleting the KDC entry. Our problem with the CA
  is a direct consequence of not having the CA
  on-line all the time

5
Public Key Certification Authorities

• We need a scheme to assert that a certificate
  that has not yet expired is no longer valid
• A solution is to assign a unique serial number to
  each certificate and maintain a certificate
  revocation list (CRL)
• A certificate is of the form
• principal name, public key, serial number,
  expiration dateCA and
• a CRL is of the form
• time of issue, revoked serial number, revoked
  serial number, . . .CA.

6
Public Key Certification Authorities

• A certificate is considered invalid if the
  expiration date has expired or the serial number
  of the certificate appears on a recent CRL
• It is tempting to use the time of the message to
  compare to the expiration date,
• but this is a bad idea.
• An attacker that knows a compromised private key
  can use whatever time needed when creating a
  message (e.g. send a message that was sent
  "yesterday"). It is also important to use the
  most current CRL possible.

7
Public Key Certification Authorities

• existence of CRLs requires that the CA or some
  other source of CRLs be online
• Without access to a recent CRL, there is no way
  to know whether to trust a given certificate.
• There are also some engineering tradeoffs that
  arise when using CRLs.
• if the expiration time is small (not too far in
  the future), then certificates will be constantly
  reissued and lots of traffic will be generated.
• Large expiration times lead to long CRLs.
• If CRLs are issued frequently, then the amount of
  time vulnerable to compromise is short but lots
  of network traffic is generated.
• If the CRLs are issued infrequently, then the
  possibility of compromise increases.

8
Public Key Certification Authorities

• Having a single CA is unrealistic
• There is no one entity that is trusted by
  everyone for everything (even in real life).
• Performance will not scale well
• A solution is to have multiple CAs.
• The issue now becomes
• how does a principal in one CA's domain get a
  public key for a principal in a different CA's
  domain?

9
Public Key Certification Authorities

• Imagine there is a user A in the CIA domain. Call
  the certifying authority CA-CIA.
• Similarly, imagine there is a user B in the KGB
  domain and CA-KGB is the CA.
• How can A communicate with B? A needs to know how
  to determine that a certification encrypted under
  CA-KGB's private key is valid.
• Thus A needs the public key of CA-KGB. A
  receives CA-KGB, PCA-KGBCA-CIA from CA-CIA. It
  then receives B, PBCA-KGB from CA-KGB. If A
  trusts both CA-CIA and CA-KGB then A must
  conclude that PB is B's public key.
• But what should lead Alice to believe that she
  can trust CA-KGB?
• One solution is to have an agreed mapping from
  principal names to the name of the CA that is
  considered an authority on those names.

10
Public Key Certification Authorities
11
Logic of Authentication

• For authorization, we are concerned with who
  makes requests and what they say. For example,
  Ahmet said AB can read file X" or AB said "my
  public key is KAB". The general syntax is
• principal said statement

12
Logic of Authentication

• However, just because you say something doesn't
  make it true. Suppose AB said "the sun will rise
  today". Principal AB has no control over whether
  or not the sun will rise, so such a statement
  means nothing. If AB says "we will have a quiz in
  class today", however, then we have reason to
  believe that there will be a quiz, because we
  have this notion of authorities which looks likes
  the following (where -gt is a meta-logical
  operator used to separate the hypotheses from the
  conclusion of an inference rule)
• P controls S, P said S -gt S is true.
• When authorities make a statement about that
  which they are an authority of, we consider it as
  true. For example, we could have an authority on
  names and public key bindings (name lt-gt Kname)
  CA-A is an authority on A/, or CA-A/B is an
  authority on A/B/

13
Logic of Authentication

• In a distributed system, what principals say can
  be altered in transit.
• If we have a message m that is signed by some
  principal's private key, mka, then
• we know that KA said m (notice we're now
  thinking of principals as either a person or a
  key, because whoever has that key can say it)

14
Logic of Authentication

• We allow principals to speak for other
  principals.
• If P speaks for Q, then (P said m) implies (Q
  said m). Whatever P said can be regarded as
  having been said by Q. Stated as one of our
  rules,
• P speaks for Q, P said m -gt Q said m.
• So, we can have a Certificate Authority speak for
  another principal.

15
Logic of Authentication
16
PEM -- Privacy Enhanced Mail

• Privacy Enhanced Mail (PEM) is an example of a
  public key infrastructure
• A problem with public key cryptography is knowing
  what is a suitable CA for a given principal.
• The solution PEM employs is to tie CAs to the
  structure of the principal's name
• There are two versions of PEM

17
PEM -- Privacy Enhanced Mail

• In the first version, names are hierarchical
  (e.g. A/B/C/D).
• An e-mail address such as bener_at_boun.edu.tr is
  represented as tr/edu/boun/bener. (In such a
  scheme, it is easy to add a new name uniquely.)
• The PEM proposal is to have a CA for each subtree
  of the namespace.
• That is, a CA named A/B/C is responsible for all
  names of the from A/B/C/ (where is a
  wildcard.)
• A CA named A/B is responsible for all names of
  the form A/B/.
• A rule for certificates is that the issuer of a
  certificate must be a prefix of the principal's
  name in the certificate.
• That is, CA A/B can issue a certificate for
  A/B/C/D

18
PEM -- Privacy Enhanced Mail
A can sign the public key of B, while B can
certify the public key of A and of C.
19
PEM -- Privacy Enhanced Mail

• A problem with the above scheme is that the CA at
  the root is too sensitive
• Compromising A's private key in the above example
  would compromise everything below A
• A new scheme was therefore proposed.
• The root is the Internet Policy Registration
  Authority (IPRA) and
• there are three classes of PCAs (Policy
  Certificate Authorities) below the IPRA.
• The PCAs sign things.
• The rule is that there is only one path in the
  hierarchy to any principal.
• It is easy to find the path, and therefore easy
  to acquire the necessary certificates.

20
PEM -- Privacy Enhanced Mail

• There are three classes of PCAs
• High assurance -- Super secure with strict tests
  before issuing certificates to check identity.
  The same rules apply to all the CAs below the
  high assurance PCA in the subtree.
• Discretionary assurance -- Well-managed at the
  top level, but no rules are imposed on
  organizations that are certified below the top
  level.
• No assurance -- No statement can be made about
  the authority of this PCA.

21
Pretty Good Privacy (PGP)

• Created by Phil Zimmermann
• Selected the best available cryptographic
  algorithms as building blocks
• Integrated these algorithms into a
  general-purpose application that is independent
  of operating system and processor and that is
  based on a small set of easy-to-use commands
• Made the package and its documentation including
  the source code freely available via the Internet
  and bulletin boards and commercial networks such
  as AOL.
• Entered into agreement with a company (network
  Associates) to provide a fully compatible,
  low-cost commercial version of PGP.

22
Pretty Good Privacy (PGP)

• There are certificates in PGP, but each user is
  responsible for maintaining their own set of
  public keys on a key ring.
• Users decide for themselves who to trust
• How are the public keys acquired?
• Keys can be sent signed by someone already
  trusted by the user.
• Keys are initially acquired in person.
• A chain of certificates is trusted if the user
  trusts every link in the chain, that is, believes
  that the signer gave the correct association of
  name and public key at every link

23
Pretty Good Privacy (PGP)

• PGP asks each user to assign a "trust rating" to
  each public key that is on the user's public key
  ring
• There are two parameters
• valid -- the user believes that the key is
  associated with whom the user was told it is
  associated with, and
• trust -- a measure of how much the user trusts
  the principal as a signer.
• The trust parameter is three-valued none,
  partial, and complete

24
Pretty Good Privacy (PGP)

• If a certificate is signed by a principal the
  user completely trusts, then that key is valid
• If a certificate is signed by two partially
  trusted users, then again the key is valid
• it is possible to devise very intricate trust
  management/key validity schemes.

25
Pretty Good Privacy (PGP)

• What are good properties for inferring trust?
• Should trust necessarily be transitive?
• Should trust be monotonic (once trusted, always
  trusted)?

26
Pretty Good Privacy (PGP)

• Keys are generated in PGP as follows
• the user specifies the size of the key (in bits)
  and then
• the user types a pass phrase. This pass phrase is
  then run through an MD5 cryptographic hash to
  obtain an IDEA key. The "private key" of the user
  is computed from the random timing in some typing
  that the user does.
• The private key is then encrypted locally with
  the IDEA key that was generated.
• having the private key always encrypted implies
  that if the computer was stolen, the private key
  is still secure.

27
Naming

• A name is a form of abstraction that allows us to
  designate without details
• Naming an object permits us to refer to that
  object without having to worry about the
  underlying details.

28
Naming

• Naming should possess the following properties
• The use of one name does not prevent other names
  from being used.
• For example, naming a file in the current
  directory shouldn't prevent you from naming a
  file in some other directory.
• If an object does not have a name, then it is not
  accessible. A name is the only way to denote an
  object.
• Singular objects do not require names.
• As an example, in uniprocessor machines, the
  single processor was unnamed and referred to
  implicitly. However, in multiprocessor or
  networked systems, each processor should have its
  own name.

29
Naming

• We can achieve several things by using names
• Sharing
• Different entities can share an object through
  its name.
• If there are two or more processes accessing the
  same object, they can set up names and use them
  to denote the object. In this case, each entity
  could use a different name for the same object.
• Secrecy
• Naming can provide secrecy. In a large name
  space, usually only a small fraction of possible
  names are used. Moreover, it is not obvious what
  this fraction will be. An entity that knows a
  certain name possesses knowledge that may not
  otherwise be available.
• For example, computer passwords are typically
  chosen from a large set of unguessable character
  sequences, and provide a mechanism for secrecy.
• Binding of names in programming languages also
  provide secrecy.

30
Naming Concerns

• ScalabilityIt is generally a bad idea in system
  design to assume that only a small number of
  names will ever be needed. Such an assumption is
  inherent in a fixed name size. For naming to be
  scalable, we need the following
• variable length names The name space is
  potentially infinite.
• unique names The same name cannot be used to
  refer to two different objects. Duplicate names
  would preclude controlled sharing and secrecy.
  Verifying the uniqueness of a new name can be
  done by comparison against existing names and
  takes linear time.
• no single central authority to produce names At
  best, a single authority becomes a performance
  bottleneck, and at worst it is a single point of
  failure. Multiple entities should be able to
  check a name against existing names for
  uniqueness.
• a manageable cost to produce new names A
  distributed linear algorithm is usually not good
  enough.

31
Naming Solution

• hierarchical naming
• indefinite growth in both directions
• For example, we can add either area codes or
  extensions to expand phone numbers.
• distributed authority to create names
• For example, one authority would be in charge of
  names beginning with a/b/c, while another would
  be in charge of names beginning with a/b/d.
• As long as each authority maintains the
  uniqueness of names within its assigned
  sub-domain, we will have global uniqueness of
  names.

32
Naming

• we need more information about an object than
  only its name
• names accompanied by hints We must be able to
  access hints for a given name, and, if the hints
  are stale, we must be able to correct them.
• impure names A name is pure if there is no
  content in the name.
• An impure name contains attributes of the object
  it names. Intuitively, impure names are great,
  since we can easily extract necessary information
  from the name itself.
• On the other hand, impure names have a built-in
  consistency problem when the information is no
  longer correct, the name must change. A mechanism
  is required for changing names.

33
Naming

• In the past, there had been considerable
  discussion in the network community regarding a
  distinction between names, addresses, and routes.
  
• This distinction actually turns out to be a
  non-issue.
• By conventional wisdom,
• a name designated an entity,
• an address denoted its location, and
• a route described how to get to that location

34
Each Ethernet card has a unique address, and it
was common to use the card attached to a
processor to name the processor. The naming
fails, however, when two cards are attached to
the same processor, for then, there is the
illusion of having two processors. The two cards
provide names, routes and addresses for one CPU
and the distinction is no longer useful.
35
Binding

• Names are a way of denoting something, and
  associated with each name is an object. This
  association is called a binding
• The mapping is partial. Consider the use of names
  for secrecy only a small fraction of the name
  space is used.
• The mapping is subject to change, although it
  happens slowly and infrequently. E.g., after a
  file is edited, the same file name now refers to
  a different bit stream.
• The domain of the context is interesting. That
  is, it may be useful to determine what is in the
  domain. We enumerate the names in a domain or
  sub-domain when we need to create new, unique
  names.

36
Binding

• A simple example of a context is memory. Memory
  essentially associates with each address (name) a
  value
• Where are these contexts? Generally speaking,
  names must acquire meaning in one of the
  following ways
• Names can have a meaning in a universal context.
  For example, a country code followed by a
  national phone number is a universal context,
  under the presumption that calls to Mars do not
  occur.
• Names could be accompanied with the name of the
  context within which to evaluate the name. (For
  example, working directories for unqualified file
  names.)
• We could assume (ensure) that whoever evaluates
  the name will use the same context as whoever
  sent the name. This can lead to unfortunate
  situations, however.

37
Binding

• Context is another way in which to enforce
  security.
• For example, the name "write" may be bound to
  different things for different users depending
  upon their privileges.
• Context is thus also a form of protection.

38
Implementation of Hierarchical Naming

• how to manage binding?
• If there is no structure associated with a
  particular name then a global service is
  necessary.
• It makes more sense to regard a name such as
  /a/b/b as a list of simple names and implement it
  using a tree.

39
Implementation of Hierarchical Naming
the name a/b/b denotes a leaf object and circles
represent directories or contexts. A
hierarchically-structured name can be regarded as
defining a path in the tree.
40
Implementation of Hierarchical Naming

• What if we are trying to merging two
  organizations, effectively extending names to the
  "left"? By simply merging, we create a new root
  node, and make the two original trees its left
  and right children respectively. The trouble is
  that none of the old names will work anymore. We
  need a way to "jump" over parts of the tree, to
  equate the value of a name in a directory with
  the value of another name in another directory.

41
Implementation of Hierarchical Naming

• A solution is to provide a mapping from the path
  in the old names to paths in the new names.
• When we see an old name starting with a we map it
  to ibm/a. Similarly, b is mapped to ibm/b, c to
  dec/c, and so on.
• This technique works provided that we have no
  duplicate names between the original two trees.
• the naming trees can actually be merged at any
  level