Introduction to
Cryptography and Security
Mechanisms
Dr Keith Martin
McCrea 349 01784 443099
keith.martin@rhul.ac.uk
Introduction to Cryptography and Security Mechanisms:
Unit 11
Public Key Infrastructures
Dr Keith Martin
McCrea 349 01784 443099
keith.martin@rhul.ac.uk
Learning Outcomes
• Explain the purpose of a digital certificate
• Appreciate the roles of a certificate authority
• Identify the security critical operations in the
certification process
• Discuss how to go about establishing trust in a PKI
• Compare different methods for joining certification
domains
• Compare different trust models for a PKI
• Recognise the limitations of a PKI
• Compare a traditional PKI with an identity-based
system
Introduction to Cryptography and Security Mechanisms 2005
3
Sections
1.
2.
3.
4.
Introduction to certification
The certification process
Managing trust in a PKI
PKI models
Introduction to Cryptography and Security Mechanisms 2005
4
1. Introduction to certification
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!
Write down as many things as you can think of that could mean that in
fact you do not have a valid signature by Alice on this message at all.
Introduction to Cryptography and Security Mechanisms 2005
6
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.
Introduction to Cryptography and Security Mechanisms 2005
7
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
Info
The actual public key and the identifier of the public key algorithm
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
Introduction to Cryptography and Security Mechanisms 2005
8
Digital certificates
A digital certificate is a set of data that binds an identity to a
particular piece of data.
1. What applications can you think of for digital
certificates other than public key certificates?
2. Which of the fields of a public key certificate
would you still need in these digital certificates?
Introduction to Cryptography and Security Mechanisms 2005
9
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.
Introduction to Cryptography and Security Mechanisms 2005
10
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.
For each of the above three recipient checks, what
are the precise implications of them not being done.
Introduction to Cryptography and Security Mechanisms 2005
11
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 Keith
Martin is
.......
1. Can you use a public key certificate directly to
encrypt messages or verify digital signatures?
2. If someone presents you with their public key
certificate, is this proof of their identity?
Introduction to Cryptography and Security Mechanisms 2005
12
Use of public key certificates
Alice
1
Bob
rA || sigA (Bob, rA ) || CertA
2
rB || sigB (Alice, rA , rB ) || CertB
3
4
5
sigA (Bob, rB )
6
Introduction to Cryptography and Security Mechanisms 2005
13
Certificate protocol questions
The previous protocol offers mutual entity authentication.
1. Why is Bob not able to authenticate Alice after he
receives her first message?
2. To what extent is Bob able to “identify” Alice at
the end of this protocol?
3. Do Alice and Bob always need to send their
public key certificates to one another as part of
this protocol?
Introduction to Cryptography and Security Mechanisms 2005
14
2. The certification process
Designing a PKI
Imagine that you have been asked to design a certification
process for your organisation from scratch. In other words, the
organisation has identified a need for a PKI that results in every
employee having a public key certificate that contains the
employee’s public key for internal use only within the
organisation.
It is your first day on this new project. Write down as many
(high level) questions as you can think of that you are going to
have to answer concerning the whole process of starting with
nothing, to ending up with a PKI for the organisation.
Introduction to Cryptography and Security Mechanisms 2005
16
Example certificate issuing process
Verifies
3
credentials
Certification
Creates
certificate
4
Authority
Distribution
Owner
1
2
Generates
key set
Presents public
key and
credentials
6
Receives
(and checks)
certificate
Introduction to Cryptography and Security Mechanisms 2005
5
17
Generating the public key pair
Pros
Cons
The owner is placed in
full control of their own
key material.
The owner might not have the
capability or skill to perform this
operation in a secure fashion.
It may be easier and
more secure to manage
the generation of key
material centrally.
The certification
process might appear
more seamless to the
owner.
Owner
The owner needs to prove to the
CA that they actually know the
private key before the certificate
can be issued.
Issuer (CA) The owner must trust the CA
to securely deliver the private
key to the owner and to
dispose of it afterwards.
Introduction to Cryptography and Security Mechanisms 2005
18
Registration
The stage of the certification process at which the owner presents their
credentials to the CA for checking is arguably the most vital stage in the
entire certification process.
In many application environments a separate entity known as a
Registration Authority (RA) performs this operation.
There are two arguments for keeping the roles of CA and RA at least
slightly separate:
1.
Most of the functionality of a CA can be essentially performed by
a computer, whereas for many applications the role of the RA
requires human intervention.
2.
Checking the credentials of a certificate applicant is often the
most complex part of the certification process. There is thus a
strong argument for distributing the registration activities across
a number of “local” RAs.
Introduction to Cryptography and Security Mechanisms 2005
19
Registration
Whether the CA and RA roles are incorporated as one, or kept entirely
separate, there remains an important problem to address:
What credentials should be presented
to the RA (CA?) in order to establish
the identity of the owner?
It is highly recommended that you attempt the
Exercise 1 on this unit concerning the selection of
suitable credentials.
Introduction to Cryptography and Security Mechanisms 2005
20
Levels of certificate
It is worth noting that many CAs issue different types of certificate
(sometimes referred to as levels of certificate) depending upon the
thoroughness of the process used to identify the owner.
These levels often correspond directly to the credentials by which the
owner was identified when the certificate was registered.
Certificates of different levels may then be used in different types of
application. The liability associated with a certificate is likely to be
different for different levels of certificate.
It is highly recommended that you attempt the Exercise 2
on this unit concerning the different levels of certificate
offered by commercial certificate issuers.
Introduction to Cryptography and Security Mechanisms 2005
21
Proof of possession
However registration is done, there is one very important check that
must be performed before proceeding with the issuing of a public key
certificate – that the owner actually knows the private key corresponding
to the public key in the certificate.
If the CA does the key generation then this problem does not arise, but if
the owner generates the key pair then this check is essential.
This process is referred to as demonstrating Proof of Possession.
1. Why should the CA check ownership of the
private key?
2. How can a CA check ownership of a private key
without the owner revealing the private key?
Introduction to Cryptography and Security Mechanisms 2005
22
Certificate distribution
• Pushing
– the owner of the certificate automatically provides the
certificate when it is required
– the problem with pushing is that the receiver of the certificate
needs to check that the certificate that they have just received
is still valid.
• Pulling
– users must request copies of certificates when they need
them.
– the problem will pulling is that this requires the relevant CAs to
be online to distribute the certificates when required to do so.
– an advantage is that the receiver is more likely to get the latest
valid certificate, although it may still be prudent that the
receiver performs checks to ensure that the certificate has not
been revoked.
Introduction to Cryptography and Security Mechanisms 2005
23
Certifying the certifiers
Someone, somewhere, must generate the CA’s public key pair, and
someone, somewhere, must certify this public key. However it is done, it
must be done securely. If someone gets hold of the private key of the
CA then they can generate certificates themselves, and the whole
system falls apart.
1. Who generates the public verification key of a CA?
2. How does a CA arrange to certify its own public
verification key?
3. How is the public verification key of a CA distributed
to those entities who need to rely on it?
Introduction to Cryptography and Security Mechanisms 2005
24
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 .
Introduction to Cryptography and Security Mechanisms 2005
25
Revocation
1. For what different reasons might a certificate need to
be revoked?
2. Who decides that a certificate can be revoked?
3. Who is responsible if someone uses a certificate
without realising it has been revoked?
4. How often should CRLs be updated?
5. What possible problem might arise from the “time
gap” between CRL updates?
Introduction to Cryptography and Security Mechanisms 2005
26
3. Managing trust in a PKI
Establishing a PKI
We need to consider how trust can be established and
managed within a PKI. For example:
• How is trust in a CA established?
• Who are the candidates for CAs?
• How do you choose a CA?
• How do CAs recognise one another?
• How is liability managed?
Introduction to Cryptography and Security Mechanisms 2005
28
Some requirements for a CA
• A physically secure operating environment
• Tamper resistant modules for cryptographic processing
(particularly for high-level keys)
• The ability to generate cryptographic keys (a pseudorandom
number generator?)
• The ability to check both written and digital signatures
• The ability to sign certificates
• Software to support various certificate formats
• The ability to transport keys securely (perhaps smartcards?)
• A clearly defined security policy
• Auditable procedures for producing certificates
• The ability to maintain certificate revocation lists
• The ability to cover potential financial liabilities
Introduction to Cryptography and Security Mechanisms 2005
29
Choosing a CA
1. What types of organisation are candidates for CAs,
and why?
2. How does a user go about selecting a CA to issue
their certificate?
3. How can you guarantee that a CA will behave
honourably?
Introduction to Cryptography and Security Mechanisms 2005
30
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.
Introduction to Cryptography and Security Mechanisms 2005
31
Cross certification
CA1 and CA2
each certify the
other’s public key
CA1
Clients of CA1
Introduction to Cryptography and Security Mechanisms 2005
CA2
Clients of CA2
32
Certificate hierarchies
Root CA
Root CA
certifies the two
CA’s public
keys
CA1
Clients of CA1
Introduction to Cryptography and Security Mechanisms 2005
CA2
Clients of CA2
33
Certificate chains
CA1
Alice
CA2
When Alice wants to check
the authenticity of Bob’s
public key she must verify
each link in the chain:
Public
key of
CA2
CA1
Public
key of
CA3
CA2
Public
key of
Bob
CA3
CA3
Bob
Introduction to Cryptography and Security Mechanisms 2005
34
Liability issues
You trust your London based CA, and it has cross-certified with
another CA in Luxembourg, who acts as the root CA for a small
CA in Belgium, and one of the Belgian CA’s clients has sent
you a certificate chain that connects back to its public
verification key. You want to use this public verification key to
verify the signature on a transaction that the Belgian customer
has promised you.
• What happens if it all goes wrong?
• Where does the liability lie?
• Who is responsible to whom?
• And how much protection is offered?
Introduction to Cryptography and Security Mechanisms 2005
35
4. PKI models
Straight line model
Subscriber
Introduction to Cryptography and Security Mechanisms 2005
Relying
Party
37
L-shaped model
Certificate
Authority
Issues
certificate
Digital signature
Subscriber
Introduction to Cryptography and Security Mechanisms 2005
Relying
Party
38
Triangular model
Single
organisation
Certificate
Authority
Issues
certificate
Digital signature
Subscriber
Introduction to Cryptography and Security Mechanisms 2005
Relying
Party
39
Four corner model
Certificate
validation
Certificate
Authority
Validation
Authority
Issues
certificate
Digital signature
Subscriber
Introduction to Cryptography and Security Mechanisms 2005
Relying
Party
40
The state of PKI
In the mid 1990’s it was widely forecast that PKIs would be implemented
on a broad scale to provide security services.
Every year it was widely forecast that PKI adoption was just round the
corner. The next year the same thing happened...
We are still waiting for this massive adoption of PKI to take place.
Progress has been substantial, but it has been slow and very unsteady.
There are any competent business organisations offering CA services,
and some efforts are underway to establish PKI standards.
We are still awaiting what David Lacey has
referred to as “the golden age of PKI”. For what
reasons do you think that this is the case?
Introduction to Cryptography and Security Mechanisms 2005
41
Identity-based public key cryptography
The whole reason that a PKI is needed at all is to vouch for the
authenticity of public keys.
One way of eliminating this problem is to make public keys “obviously”
authentic without third party certification. This is the motivation behind
identity-based public key cryptography (IDPKC).
In IDPKC:
1. Your “identity” is your public key. There is a public rule that
converts your “identity” into a string of bits, and then some
public rule that converts that string of bits into a public key.
2. Your private key can be calculated by a trusted centre from
your public key using some secret information. Only the trusted
centre can perform this calculation of your private key. The
trusted centre then issues you securely with your private key.
Introduction to Cryptography and Security Mechanisms 2005
42
IDPKC
1. Alice derives Bob’s public key PubB from
some public information and sends
message encrypted under PubB to Bob.
PubB(message)
Alice
Bob
PrivB
3. Authority
derives PrivB
from PubB and
some secret
value, and
returns this to
Bob.
Bob
Authority
Introduction to Cryptography and Security Mechanisms 2005
2. Bob identifies
himself to an
authority and
requests the
private key PrivB
corresponding to
PubB.
43
Identity-based public key cryptography
• IDPKC requires new algorithms – you cannot use existing public
key algorithms
• One “fixed” public key can be associated with many different
private keys since the trusted centre can use different secrets to
generate different private keys that correspond to that same
public key.
• Public keys do not have to be identities – they can be any data,
including decryption policies. For this reason some people
prefer to refer to IDPKC as Identifier-based public key
cryptography
Introduction to Cryptography and Security Mechanisms 2005
44
Identifier-based public key cryptography
Could incorporate policy into the identifier
• time to decrypt
• who is authorised to decrypt
• under what conditions decryption permissible
Could generate identifiers “on the fly” in browsers
• need trusted applications
• need effective policy management
Introduction to Cryptography and Security Mechanisms 2005
45
IDPKC v PKC
1. In what way is IDPKC an improvement over
traditional public key cryptography?
2. What problems with PKI remain?
3. What new problems have you created when using
IDPKC?
Introduction to Cryptography and Security Mechanisms 2005
46
Summary
• Public key infrastructures based on digital certificates and
certificate authorities remain the favoured method for trying to
securely implement public key cryptography.
• There are many complicated issues that arise when trying to
implement PKIs, most of which do not have simple or technical
solutions.
• PKI s will not be adopted on a large scale until some of these
problems are addressed satisfactorily – the best hope for this is
through the establishment of recognised standards and best
practice procedures that encourage interoperability between
different CAs and PKIs.
• There are alternatives to traditional PKIs, but these come with
their own problems and are most likely to be favoured in niche
application areas.
Introduction to Cryptography and Security Mechanisms 2005
47