Public Key Infrastructure

(PKI)
Trusted Intermediaries

Symmetric key problem: Public key problem:

 How do two entities  When Alice obtains Bob’s
establish shared secret key public key (from web
over network? site, e-mail, diskette),
Solution: how does she know it is
Bob’s public key, not
 trusted key distribution Trumpy’s?
center (KDC) acting as
intermediary between Solution:
entities  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!
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.