Chapter 8: Public Key Infrastructure

1
Chapter 8 Public Key Infrastructure Previous
material covered the basic tools that
provide Authentication of systems
people Integrity of files and messages Confident
iality, secrecy, privacy Non-repudiation An
infrastructure is required to use these in a
network. It supports public key (asymmetrical)
cryptography as well as the option to use secret
key (symmetric) systems for confidentiality.
2
Re-Cap of a Robust Exchange Users generate
private/public key pairs, keep private keys
secret and exchange public keys with others.
Assume Alice wants to communicate with Bob. She
wants - strong authentication, - to exchange
confidential information, - be sure messages
arrive with high integrity, and - ensure she
has non-repudible evidence that Bob received
and opened her messages. Bob wants to be
assured he is communicating with Alice and only
Alice. 1. Challenge from Alice to Bob. 2.
Response from Bob to Alice and Challenge from Bob
to Alice. 3. Exchange of secret keys. 4. Exchange
of secret information.
3
Step in a Robust Exchange Alice initiates
communication and Bob responds Alice Challenges
Bob. Bob responds to Alice and Challenges
her. Once they are mutually authenticated,
they Exchange secret keys. Exchange of secret
information. Each exchange can be tested for
integrity.
4
The Challenge - Alice to Bob
5
The Response - Bob to Alice
6
Key Exchange
7

• Requirements
• Bob and Alice need a trusted means of exchanging
• public keys, otherwise Eve could impersonate
  
• either of them. This exchange does not have
  to be
• secret, but Bob must have a means of
  trusting that the
• key represented as Alices public key really
  is hers
• (and vice versa).
• 2. A means to know if the keys are still valid at
  the time
• of use (a key may have been compromised or
  changed).
• 3. A means to identify and agree on the digest
  and
• encryption algorithms to use (there are several
  options
• for digests as well as encryption algorithms.

8
Alternatives We already know some alternatives.
For example, using secret key technology, Bob
and Alice could meet in person and exchange
keys. They could also use methods we have
described (e.g., Diffie Hellman key exchange,
symmetric encryption, etc.). However, Bob and
Alice may need to communicate with others. They
also must ensure that their public keys are
remain valid, and they need to be able to change
technology without meeting again. Doing this for
many users is not practical if they have to meet
all the time.
9
Requirements - Simplified 1. Create, manage, and
securely exchange public keys. 2. Serve trusted
credentials to bind users to their keys. 3. A
means to know if the keys are valid or trusted
(initially and over time - some time may have
elapsed since the keys were initially
exchanged). 4. A means to identify or agree on
the digest (hash) algorithm and/or
encryption/decryption algorithms.
10
A Solution A Public Key Infrastructure (PKI)
provides all these functions. A PKI is a
policy-based, technology infrastructure for
reliably and securely delivering cryptographic
services to users on a local, national, and/or
international basis, even if they never meet in
person. Web commerce is supported by PKI.
11

• Elements of a Public Key Infrastructure
• Public Key Certificates - a data structure.
• 2. Public Key Certificate Authority (CA) a
  server that
• creates/validates/manages public key
  certificates.
• 3. Public Key Repository - Directory server for
  certificates.
• 4. Registration Authority (RA) - a remote site
  proxy for
• the CA.

12
Elements of a Public Key Infrastructure
(more) 5. A Certificate Revocation List (CRL) -
a list of invalid certificates that were
previously issued. 6. A Certificate Practices
Statement issued by the CA describing the
policies and procedures of the CA. Sometimes
described in two parts A certificate
policy statement (the CA rules). A
certificate practices statement (the CA
procedures). 7. A validation process to
certify the CA (does it do what the rules
and procedures say it does?)
13
PKI Structure
As Certificate
Bs Certificate
Private key
Private key
User A
User B
Keeps certificate revocation list database
Certificate Authority
Directory Server (LDAP)
Enrolls users Creates certificates Signs issues
certificates Sends certificates to directory
server Revokes certificates Publishes Policy
Practices Cross certifies with other CAs
Revoked Certificate List
Signed Certificates
14
Certificate Authority - Policy Statement Scope
Policy for the issuance, management, and use of
public key certificates cryptographic
technology used for Identification, Authentic
ation, Confidentiality, Integrity,
and Non-repudiation Indicates the assurance
level for the policy (this can be low, medium,
or high assurance and defines the rigor of the
policy). High assurance would imply the
strictest policy. Defines the roles
responsibilities of all participants in
issuing, managing, and using certificates and
cryptographic materials.
15
Certificate Authority - Policy Statement Assuranc
e Indicates the assurance level for the policy
(this can be low, medium, or high assurance and
defines the rigor of the policy). High
assurance would imply the strictest policy (and
the most secure implementation). Roles
Responsibilities Defines the assignments and
behavior of all participants in issuing,
managing, and using certificates and
cryptographic materials (the dos And donts).
16
What are Certificates? Certificates are
electronic identifiers issued by the CA to bind
the name of a subject of a certificate to the
subjects public key and any other information
in the certificate. Entities can be
individuals, corporations, or systems The
binding is certified as valid by the
CA Certificates are generated, issued, managed
and signed (authenticated) by the CA using the
private key of the CA. Certificate content is
defined in the CA policy - Usually this mean the
international standard called X.509, V3.
17
X.509 Certificates Data Content Version Versio
n 3 Identifies the version being used by the
CA. Multiple versions may be in use. Serial
Number 1234567 Unique in the domain served by
the CA. Ensures that the certificate is unique
(no duplicates). Signature Algorithm RSA
with MD5 A number registered with a recognized
standards organization that specifies the
signing (Hash) and the public key
encryption algorithm used by the CA.
18
X.509 Certificates Data Content Certificate
issuer X.500 name c US, o Acme Corp. This
is the X.500 (another international standard)
distinguished name of the issuer of the
certificate, where c country code and o
organization code. Validity Period Start and
expiry dates for the certificate. Subject X.500
Name c US, o Acme Corp., cn John B. Doe,
where cn subjects distinguished name. This is
the name of the person (or entity) holding the
private key corresponding to the public key
contained in the certificate.
19
X.509 Certificate Contents - Continued Subject
Public Key KEY value, RSA encryption with MD5
digest. Holds the actual VALUE of the public
key and identifies the algorithm that is to be
used with the key (others cannot be used they
will not work, or would potentially breach the
CA policy). Why? The CA policy statement
describes appropriate uses of issued
certificates. Any other use violates the CAs
policy.
20
X.509 Certificate Contents - Continued Issuer
Unique identifier Any bit string. Used to
uniquely identify the issuing CA in case
duplicate X.500 names are issued (OPTION).
Needed if CAs need to cross-certify. Since
certificates are issued by specific CAs, it is
possible for a CA to be created with the same
X.500 name as another - there is no central
clearing house for these names. This number
reduces duplication possibilities. This points
out a problem with CAs. An optional field is Left
to the developer to specify bad idea.
21
X.509 Certificate Contents - Continued Subject
Unique Identifier Any bit string. Used to
uniquely identify the subject in case of a
duplicate s ubject name (OPTION). Reasoning is
the same as in the case of the issuer. Certificat
e Authority (CA) signing key The CAs public
key used to decrypt a digital signature on a
message that was signed (read authenticated) by
the CA. Usually this message will contain a
certificate that was requested.
22
X.509 Certificate Contents - Summary
Certificate format version
Version 3
Certificate serial number
1235467
Signature algorithm identifier
RSA with MD5 (for the CA)
Issuer X.500 name
c US, o Acme
Validity period
Start 01/08/99, expiry 01/08/00
Subject X.500 name
CUS, oAcme, cnJohn B. Doe
Subject public key information
AbDf., RSA with MD5
Issuer unique identifier (optional)
Subject unique identifier (optional)
RSA on MD5 hash of the certificate
CA Signature
23

• Certificate Authority
• A CA is operated in a secure environment and in
  accord
• with a strict set of rules (its policy and
  practices statement).
• The reason for strict policy and operating rules
  is that this
• server must be trusted by all users including
  other CA's.
• Users register with a CA by providing their
  subject name
• and public key information.
• 2. The CA issues an X.509 certificate that
• Binds the user's identity to a public key,
• contains the users public key, and
• is hashed and the hash signed by the CA.

24
Certificate Authority Registration To register,
a user presents his(her) public key and some
credential of personal identification (driver's
license, badge, a pint of blood for DNA
analysis, etc.). The CA policy statement will
indicate what forms of identification are
acceptable. Higher security requires better
credentials. The CA creates an X.509 certificate
for the user and stores it on the CA, and/or on
a Directory server (LDAP), and sends a copy to
the user. The CA issues the user a registration
number and identifier.
25
Certificate Authority Registration NOTE The
initial transaction between the user and the CA
is not cryptographically secure since the CA has
no knowledge of the user's identity or public
key. Neither does the user have a copy of the
CA's public key. A user might look it up on the
network, but there is no means to encrypt the
exchange. Thus, the user cannot trust that a
CA's public key really belongs to that CA
These exchanges need to happen securely!
26
CA - Registration Process
User A
2. Install Client 3. Generate key pair. 4.
Complete Certificate request
1. Deliver Certificate Client
Registration Authority
6. Approve Request
5. Present request to RA
9. Approve request 10. Generate certificate
7. Sign Request 8. Send to CA
I. Do.. Certify ..
Certificate Authority
12. Send Certificate to Requestor
11. Send Certificate to LDAP Server
27
Certificate Authority - Registration
Process Assume an organization has purchased a
CA license and set up a CA server. A user
typically registers as follows 1. User appears
in person with proof of identity. 2. CA issues a
registration number, and user identity. This
is a one-time password that will be used to
access the CA to electronically enroll. 3.
User installs the PKI client software (this could
occur before the previous steps, but must be
before step 4).
28
Certificate Authority - Registration Process 4.
The user logs in using the identifier and
registration number. 5. The PKI client
software generates a private/public key
pair, user selects a pass-phrase, a profile is
built and sent to the CA. 6. The CA creates
the user's certificate, signs it with the
CA's private key and sends it to the user. From
this point on, the cryptographic services of the
CA Can be used (e.g., encrypt e-mail for
transmission to another user by simply clicking
on an e-mail plug-in).
29
Certificate Authority - Typical Exchange
CA
Bob
Alice
Request for Alice's Certificate
Query Response
Validate Alice's public key with
CA, proceed with processing
Message
MD5 Digest
Alice's Certificate signed with CA private key
Message Signature
Alices Signing Key
30
Certificate Authority - Typical Exchange Alice
sends a message to Bob signed with her private
key. The message might also be encrypted. Bob
receives the message and forms a request to the
CA for Alice's public key. The CA returns
Alice's certificate. The returned certificate is
signed by the CA (signed means the certificate
digest (hash) is encrypted with the CA's private
key. Bob uses the CA's public key to open the
digest and validates the integrity of Alice's
certificate. If OK, Bob has Alice's signing
key. Bob uses Alice's public signing key to open
the digest and validate the message as being
from Alice unchanged in transmission. If the
message had been encrypted, Bob would do all of
the above and then get the secret key from
Alice. Alice would also need to verify Bob
through the CA.
31

• Certificate Authority - Result
• Seems like a lot of trouble. Bob and Alice could
  have
• done this using challenge-response,
  Diffie-Hellman, etc.).
• The value of a CA is that it provides all these
  functions in a
• very generalized way, most notably
• Everything is done within a common infrastructure
  
• with a common rule set - good business practice
  to have
• consistent, centralized, and enforceable rules.
• 2. The CA avoids negotiation and manual public
  key
• exchange between all of Bob's partners (Alice,
  Arnold, Beth,
• Bernard, Carrie, Chris, Donald, Donna, etc.).

32
Certificate Authority More Functions 1.
Creates manages certificates over their full
life cycle. 2. Source repository for validated
certificates. 3. Maintains a list of valid
certificates, replicates them to the site
directory server. The directory server actually
serves them on request to users. 4. Maintains a
list of invalid certificates. Certificates
expire or are otherwise invalidated (e.g.,
compromised key, Stolen computer, employee dies,
etc.). Called a Certificate Revocation List
(CRL).
33
Certificate Authority More Functions 5.
Maintains a key backup and recovery system. 6.
Maintains a key history capability (may need to
use an old key to authenticate stored data). 7.
Performs cross-certification with other CAs in a
trust relationship. 8. Most CA's also support
the concept of a Registration Authority (RA).
34
Registration Authority - Functions If the CA is
located at some distance from its users, we need
a remote authority that can act as a proxy for
the CA. An RA is empowered to identify users
and issue registration and identity numbers, but
not generate certificates. RAs validate user
identities and securely enroll them in the CA
since the RA can do secure communications with
the CA. RA's must appear in person at the CA
when they are first identified and enrolled.
35
Registration Authority Functions Once an RA is
enrolled 1. User contacts RA with proof of
identity. 2. RA authenticates and issues
identifier and registration number (one-time
password). 3. User can then log into the CA and
complete the process as before. All users must
agree to comply with the policies of a CA. This
usually involves signing a statement of
compliance.
36
Key Backup - Escrow One CA consideration is key
recovery (escrow). Lost or forgotten
keys Terminated employees or employees that
die If the holder of a key used to encrypt
information is not available, it may be
necessary to recover the key. It is easy to
assume all keys need a recovery mechanism NOT
TRUE - Must distinguish between signing keys and
encryption keys!
37
Different Types of Keys Signing Key Private
half of a public key pair used solely for the
purpose of authenticating a message (sign with
private key, open with public key) Also called
Digital signature (encrypt a hash with a
private key, decrypt with a public key).
38
Different Types of Keys Encryption key Either
a public key pair, where the public key is used
to encrypt and the private key to decrypt (Alice
sends a secret message to Bob encrypted with
Bobs public key - only Bob can open the
message) OR, a symmetric key, exchanged with a
public key pair and used to encrypt message
traffic between Alice and Bob.
39
Key Escrow - Signing Key Non-repudiation is
provided by a signing key. To ensure signing
security, the owner of a signing key should
NEVER disclose the signing key to anyone else.
It must be kept secret for the life of the key.
SO.. 1. Signing keys are never backed up
(except by the user). 2. Signing keys are never
archived or escrowed. 3. Signing keys are never
disclosed to another party. 4. Signing keys are
securely destroyed at the end of their active
life. To do otherwise means it might be
disclosed and could be used to forge signatures
on old documents.
40
Key Escrow - Other Keys Symmetric secret keys
need to be backed up or archived in order to
recover information that is encrypted in certain
situations Keys are lost Employee that
encrypted the data is unavailable On legal
request (courts, law enforcement) Public Keys
used to encrypt information (not sign or
authenticate) also need to be archived. They can
be recreated from the private key. A private
encrypting key does need to be archived.
41
Key Escrow - Summary This means we need to have
three kinds of keys Signing key pairs never
escrow Encrypting key pairs always
escrow Encrypting secret keys always escrow
(except when used as session keys) A
session key is created for a specific session and
used to encrypt data traffic. The volume would
be large.
42
Certificate Policy Statement Recall A statement
of policy for issuing, managing, and using
certificates and cryptography for identification,
authentication, confidentiality, integrity, and
non-repudiation. Specifies 1. Certificate type
and version (typically X.509, V 3). 2. Intended
use of certificates (typically only to bind an
identity to a public key). 3. Types of keys used
and their intended use (e.g., signing,
encryption). 4. Escrow requirements.
43
Certificate Policy Statement 5. Components of
the CA CA and any agents of the CA RA and
any agents of the RA Repositories Users and
other entities certified 6. Applicability -
intended use (next page)
44

• Certificate Policy Statement - Continued
• Public key encryption or session key exchange for
  
• (defined classes of information like sensitive,
  business
• sensitive, etc. - organization dependent). May
  include what
• are not approved uses.
• B. Verify integrity of messages, documents, and
  data
• transmission through the use of digital
  signatures.
• C. Verify the signer of electronic messages,
  files,
• documents, and data transmission using a digital
  signature.
• D. Verify the identity of client computers,
  servers, and
• other computer systems in the organization.
• E. Verify the identity of recipients of sensitive
  information.

45
Certificate Policy Statement - Continued 7.
Where CA names must be registered (e.g., in the
corporate office of CA policy). 8.
Permissibility of cross-certification with other
CAs and assurance required prior to
cross-certification. Cross certification allows
a CA to trust the users of another CA (e.g.,
between two companies). 9. Liability. When
things go bad, who is responsible? It Is never a
commercial CA or at least they attempt to deny
liability.
46
Certificate Policy Statement - Continued 10.
Roles and obligations Certificate Authority
(accuracy, rejection policy, protection of keys,
types of certificates issued, revocation,
escrow). Registration Authority (approval,
delegation, etc.). User (expected behavior
protecting keys, notifications to CA for lost
keys, agreement to escrow policy). Sponsor
(someone approving the issue of a certificate to
an employee, customer, collaborator,
etc.). Relying party (anyone relying on the
certificates issued).
47
Certificate Policy Statement - Continued 11.
Publications and repositories (identifies
available data) Method of publication
(typically an on-line repository) Copies of the
policy practices statement Copies of any
cross-certification assurance agreements (who
else does this CA trust?) Copies of public key
certificates issued by the CA Copies of the
Certificate Revocation List (CRL) Copies of the
Assurance Revocation List (ARL), if any 12.
Confidentiality (rules associated with access to
private keys) in both normal and exceptional
operations (data recovery, disclosure to third
parties, diagnosing and troubleshooting problems,
etc.).
48
Certificate Policy Statement - Continued 12.
Confidentiality (rules associated with access to
private keys) in both normal and exceptional
operations (data recovery, disclosure to third
parties, diagnosing and troubleshooting
problems, etc.). 13. Identification
Authentication registration Names and
uniqueness, proof of identity (credentials). Forgo
tten passwords (usually re-start from
scratch). Re-key after compromise. Revocation
requests.
49
Certificate Policy Statement - Continued 14.
Operational Requirements Certificate
application process User acceptance of the
certificate (e.g., written agreement) Certificate
suspension revocation (conditions
invoking) 15. Audit Requirements OS account
creation, upgrades, patches Configuration
control, backups, shutdowns, re-starts Audit log
dumps (anytime the audit log is reset)
50
Certificate Policy Statement - Continued 16.
Records Archival Requirements. 17. Key Lifetime
(CA, RA, End users). 18. CA Compromise and
Disaster Recovery. 19. Termination of a CA
(what is to be saved, who is notified?). 20.
Physical Security Controls - CAs, RAs, users
(locked doors, entry controls, logs,
inspections, backup storage).
51
Certificate Policy Statement - Continued 21.
Procedural Controls - Who can do what? Required
for CA and System administrator, Security
Officer). May include a 2-person rule. 22.
Personnel Security - Training requirements for
users. 23. Technical Security Controls - key pair
generation, private key delivery, delivery of
public keys, CA public key delivery, key sizes,
key usage, private key protection, algorithm
standards, controls, etc. 24. CA Computer
Security Controls. 25. Network Protection -
protection for the domain and segment where the
CA resides.
52
Certificate Policy Statement - Continued 26.
Life Cycle Controls - Applied over the complete
life cycle of the CA. System development,
security management, change control, integrity
control. 27. X.509 Certificate profile - rules
for use of X.509 certificate fields - what is
permissible, and what isnt. 28. Policy Change
Control Procedures - approvals and notifications
for any change to the policy document. WHY ALL
THIS? 1. CAs hold the keys to the kingdom and
must be carefully managed. 2. Others rely on the
accuracy and integrity of the CA. 3. In some
settings, a CA must meet legal requirements. 4.
TRUST
53
Why All These Rules? CAs hold the keys to the
kingdom and must be carefully managed. Others
rely on the accuracy and integrity of the CA. If
the relying party is in another organization,
chances are that organization has no control over
the CA. In some settings, a CA must meet legal
requirements. TRUST. A CA is a trusted third
party.
54
Trusted Third Parties Defined Someone trusted
by all participants in action to behave fairly,
securely, and with no ulterior motive. Commerce
generally uses trusted third parties We trust
the government to back the currency we use
Seller trusts the bank to honor a credit card
Other trusted instruments checks, notarized
documents, drivers license, passport, judicial
system, etc.
55
Trusted Third Parties CAs are trusted third
parties, so must behave in strict accordance
with a set of rules so we know they can be
trusted (most of the time). They are also
subjected to rather rigorous audits and the
policies and practices statements give the
auditors a basis for determining
compliance. Example eBay fraud offer an item,
sell it, get funds, dont deliver real cases
have been prosecuted (110,000 fraud).