Public Key Infrastructure

(PKI)
Trusted Intermediaries
Symmetric key problem:
 How do two entities
establish shared secret key
over network?
Solution:
 trusted key distribution
center (KDC) acting as
intermediary between
entities
Public key problem:
 When Alice obtains Bob’s
public key (from web
site, e-mail, diskette),
how does she know it is
Bob’s public key, not
Trumpy’s?
Solution:
 trusted certification
authority (CA)
 The need for a PKI

Suppose that you have received a digitally signed message that claims
to have been signed by Alice and that you want to verify this signature.
This requires you to possess a public verification key. By some means
(we won’t specify how) you are presented with a key and told “this key
is Alice’s public key”. You use it to verify the signature, and it seems to
work.
It may well be valid – but you should always be suspicious!
Announcing a public key

Problem: How can you know what you get is really Bob’s
public key?
Trusted Center

Problem:
How to prevent interception and modification?
Controlled Trusted Center

Problems:
• May create a heavy load on the center if the number of requests is large
• Bob wants two things: 1) he wants people to know his public key, and 2) he wants
no one to accept a public key forged as his.
Certification Authority
Certificate authorities
It should be clear that the “creator” of a public key certificate plays an
extremely important role.
A creator of a public key certificate is normally referred to as a
Certificate Authority (or CA).

1. The CA takes responsibility for ensuring that the information on a

certificate is correct. The CA creates (or issues) the public key
certificate to the owner.
2. Whenever anyone has need of the owner’s public key they request
a copy of the public key certificate. The certificate might be made
available on a central server, or the owner or even the CA might
send the certificate to whoever requires it.
3. The recipient of the public key certificate checks that the certificate
is in order, and if they are happy with it then they are free to use the
public key contained in the certificate.
Trusting a digital certificate
There are three things that the recipient “needs to be able to do” in
order to be satisfied that the public key certificate is in order:

1. The recipient needs to be able to trust (directly or indirectly) the CA

to have done their job correctly and to have gone through some
process to verify all the fields of the certificate.
2. The recipient needs to have access to the public verification key of
the CA in order to verify the CA’s digital signature on the certificate.
3. The recipient needs to check all the fields in the certificate. In
particular they must check that the certificate is valid, it applies to
the correct owner and that the other fields are all satisfactory.
Meaning of certificates
By digitally signing the information in the public key certificate, the
Certification Authority is effectively making the statement:

I, the CA, certify

that the public
key of Alice is
.......

Can you use a public key certificate directly to

encrypt messages or verify digital signatures?
Certification Authorities
 Certification authority (CA): binds public key to
particular entity, E.
 E (person, router) registers its public key with CA.
 E provides “proof of identity” to CA.
 CA creates certificate binding E to its public key.
 certificate containing E’s public key digitally signed by CA – CA
says “this is E’s public key”
- +
K CA(K B )
Bob’s digital
+
public +
signature KB
key KB (sign)
CA
certificate for
K-
Bob’s Signing/
identifying private CA Bob’s public key,
information key signed by CA
Certification Authorities
 When Alice wants Bob’s public key:
 gets Bob’s certificate (Bob or elsewhere).
 apply CA’s public key to Bob’s certificate,
get Bob’s public key
+
- +
K CA(K B ) digital Bob’s
KB signature public
+
(verify) K B key
CA

K+
Verification
/public CA
key
Public key certificates
A public key certificate is a set of data that binds an identity to a
particular public key value. The four core pieces of information that are
contained in a public key certificate are as follows:
 Name of owner
 could be a person, device, or even role.
 Should uniquely identify the owner within the environment in which
the public key will be employed.
 Public key value
 Validity time period
 identifies date and time from which the public key is valid, and more
importantly the date and time of its expiry.
 Signature
 Creator of certificate digitally signs all data that forms the public key
certificate. This binds the data and acts as a guarantee that the
creator of the certificate believes the data is correct.
 X509 v3 public key certificates
Version This specifies the X.509 version being used (in this case v3).
Serial Number A unique identifier for the certificate.
Signature The digital signature algorithm used to sign the certificate.
Issuer The name of the creator of the digital certificate.
Validity The dates and times between which the digital certificate is valid.
Subject The name of the owner of the digital certificate.
Subject Public Key The actual public key and the identifier of the public key algorithm
Info associated with it.
Issuer Unique ID An optional identifier for the creator of the digital certificate.
Subject Unique ID An optional identifier for the owner of the digital certificate.
Extensions A range of optional fields that include:
• a key identifier (in case owner owns more than one public key)
• key usage information that specifies valid uses of key
• the location of revocation information
• identifier of the certificate policy
• alternative names for the owner
A certificate contains:
 Serial number (unique to issuer)
 info about certificate owner, including algorithm and
key value itself (not shown)
 info about
certificate
issuer
 valid dates
 digital
signature
by issuer
Internet Web Security Architecture
Web Server B
CA
K +B

K-CA(K+B)

Client A Cert Request

K-CA(K+B)
K+B(KAB, R)

KAB(R) R (nonce) is used to

prevent replay attack

KAB(m)
 Joining CA domains
An owner of a public key certificate has by necessity placed some
trust in the CA who has issued this certificate.

However, for larger and more open PKIs, it is likely to be the case
that the owner of a certificate will:
• want users who do not have a business relationship with the owner’s
CA to be able to rely on the owner’s certificate
• want to rely on certificates that were not issued by the owner’s CA.

There is thus a need for techniques that somehow “join” different

certification domains and allow certificates issued by one CA to be
recognised by another CA.
 Cross certification

CA1 and CA2

each certify the
other’s public key

CA1 CA2

Clients of CA1 Clients of CA2

 Certificate hierarchies
Root CA

Root CA
certifies the two
CA’s public
keys
CA1 CA2

Clients of CA1 Clients of CA2

Public Key Infrastructure (PKI)

Notes:
•Everybody trusts the root.
•But people may or may not trust intermediate CAs. If Alice needs to get Bob's
certificate, she may find a CA somewhere to issue the certificate. But Alice may
not trust that CA. In a hierarchy Alice can ask the next-higher CA to certify the
original CA. The inquiry may go all the way to the root.
 Certificate chains
When Alice wants to check
the authenticity of Bob’s
CA1 CA2
public key she must verify
each link in the chain:

Public CA1
key of
CA2
Alice CA3
Public CA2
key of
CA3

Public CA3
key of
Bob Bob
 Revocation
We must consider how to handle certificates that need to be
“withdrawn” before their expiry date. This process is often referred to
as certificate revocation.

• Certificate Revocation List (or CRLs)

– A lists of certificates that have been revoked.
– CRLs need to be maintained carefully, with clear indications
of how often they are updated.
– CRLs need to be signed by the CA and be made available to
users as easily as possible.
• Online Certificate Status Protocol (OCSP)
– An online database containing the status of certificates
issued by the CA .
Internet Web Security Conditions

 Clients’ web browsers have built-in CAs.

 CAs are trustable
 Web servers have certificates in CAs.