Chapter 8: Public Key Infrastructure

1
Chapter 8 Public Key Infrastructure We have
covered the basic tools that provide Authentica
tion of systems people Integrity of files and
messages Confidentiality, secrecy,
privacy Non-repudiation Infrastructure is
needed for 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.
• Alice wants to communicate with Bob.
• She wants
• - strong authentication,
• - to exchange confidential information,
• be sure messages arrive with high integrity,
• ensure she has non-repudible evidence that
• Bob received and opened her messages.

3

• Re-Cap of a Robust Exchange
• Bob wants to be assured he is communicating
• with Alice and only Alice.
• - Challenge from Alice to Bob.
• Response from Bob to Alice and Challenge
• from Bob to Alice.
• - Exchange of secret keys.
• - Exchange of secret information.

4
Step in a Robust Exchange Alice initiates
communication/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.
5
The Challenge - Alice to Bob
6
The Response - Bob to Alice
7
Key Exchange
8

• Requirements
• 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 (may have been compromised or
• changed).
• 3. A means to agree on the digest and encryption
• algorithms to use (there are several options
• for digests as well as encryption algorithms).

9
Alternatives We already know some alternatives.
For example, using secret key technology, Bob
and Alice could meet in person and exchange
keys. Could also use methods we have described
(e.g., Diffie Hellman key exchange, etc.). Bob
and Alice may need to communicate with others.
They also must ensure that their public keys
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.
10

• Requirements - Simplified
• 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 over time - time may have
• elapsed since the keys were first exchanged).
• 4. Means to identify/agree on the digest (hash)
• and encryption/decryption algorithms.

11
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.
12

• Elements of a Public Key Infrastructure
• Public Key Certificates - a data structure.
• 2. Public Key Certificate Authority (CA) a
• Server(s) 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.

13
Elements of a Public Key Infrastructure 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 (rules).
A certificate practices statement (procedures).
7. A validation process to certify the CA
(does it do what the rules and procedures say it
does?)
14
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
15
Certificate Authority - Policy Statement Scope
Policy for the issuance, management, and use of
public key certificates cryptographic
technology used for Identification, Authentica
tion, Confidentiality, Integrity,
and Non-repudiation For example, would indicate
acceptable uses, like handling top-secret data.
16
Certificate Authority - Policy Statement Assuranc
e Indicates the assurance level for the policy
(low, medium, or high assurance and defines the
rigor of the policy implementation). 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).
17
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 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 by CA policy -
typically X.509, V3.
18
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.
19
X.509 Certificates Data Content Certificate
issuer X.500 name c US, o Acme Corp. The
X.500 (international standard) distinguished
name of the certificate issuer, and c country
code and o organization code. Validity
Period Start/expiration dates. Subject X.500
Name c US, o Acme Corp., cn John B. Doe,
where cn subjects distinguished name. Name of
the person (entity) holding the private key
corresponding to the public key contained in the
certificate.
20
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 breach the CA policy).
Why? The CA policy statement describes
appropriate uses of issued certificates. Any
other use violates the CAs policy (voids
warrantee).
21
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 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 names. This number reduces
duplication possibilities. A problem with CAs.
The optional field is left to the developer to
specify bad idea.
22
X.509 Certificate Contents - Continued Subject
Unique Identifier Any bit string. Used to
uniquely identify the subject in case of a
duplicate subject name (OPTION). Reasoning
same as in the case of the issuer. Certificate
Authority (CA) signing key The CAs public key
used to decrypt a digital signature on a message
signed (read authenticated) by CA. Usually this
message will contain a certificate that was
requested.
23
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
24

• Certificate Authority
• Operated in a secure environment and in accord
• with a strict set of rules (policy and
  practices).
• Reason for 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.

25
Certificate Authority Registration To register,
a user presents his(her) public key and an id
credential (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. 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.
26
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!
27
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
28
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. Appears in
person with proof of identity. 2. CA issues
registration number, and user id. This is a
one-time password that will be used to
access the CA to electronically enroll. 3.
Installs PKI client software (could occur
before other steps, but must be before step 4).
29
Certificate Authority - Registration Process 4.
User logs in using the id and registration . 5.
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 user.
At this point, the cryptographic services can
be used (e.g., encrypt e-mail for transmission
to another user by simply clicking on an e-mail
plug-in, etc.).
30
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
31
Certificate Authority - Typical Exchange Alice
sends a message to Bob signed with her private
key. The message might be encrypted. Bob gets 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.
32
Certificate Authority - Typical Exchange 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.
33

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

34

• Certificate Authority More Functions
• Creates manages certificates over their full
• life cycle and serves as a source repository for
• validated certificates.
• 2. Keeps a list of valid certificates, replicates
  
• them to a site directory server. The directory
• server actually serves them on request to users.
• 3. Keeps a list of invalid certificates that have
  
• expired or are otherwise invalidated (stolen,
• compromised, employee dies, etc.). Called a
• Certificate Revocation List (CRL).

35
Certificate Authority More Functions 4.
Maintains a key backup and recovery system. 5.
Maintains a key history capability (may need to
use an old key to authenticate stored data). 6.
Performs cross-certification with other CAs in
a trust relationship. 7. Most CA's also support
the concept of a Registration Authority (RA).
36
Registration Authority - Functions If CA is
located at some distance from its users, 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 ids
and securely enroll them in the CA since the RA
can do secure communicationswith the CA. RA's
must appear in person at the CA when they are
first identified and enrolled.
37
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.
38
Key Backup - Escrow One CA consideration is key
recovery (escrow). Lost or forgotten keys
Terminated employees/employees that die If the
holder of a key used to encrypt information is
not available, it may be necessary to recover the
key. Easy to assume all keys need a recovery
mechanism - NOT TRUE - Must distinguish between
signing keys and encryption keys!
39
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).
40
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.
41
Key Escrow - Signing Key Non-repudiation is
provided by a signing key. To sign security, the
owner of a signing key NEVER discloses the
signing key to anyone. Must be kept secret for
the life of the key. SO.. Signing keys are not
backed up (only by user). Signing keys are never
archived or escrowed. Signing keys are never
disclosed to anyone. Signing keys are securely
destroyed at the end of their life. Otherwise
means it might be Disclosed used to forge
signatures on old documents.
42
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 unavailable On legal request
(courts, law enforcement) Public Keys used to
encrypt information (not sign or authenticate)
need to be archived. They can be recreated from
the private key. A private encrypting key does
need to be archived.
43
Key Escrow - Summary This means we 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 too
large to store and its pointless.
44
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/version (X.509, V 3). 2.
Intended use of certificates (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.
45
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)
46

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

47
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. If things go bad, who
is responsible? It is never a commercial CA or
at least they attempt to deny liability.
48
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). User (expected behavior protecting
keys, notifications for lost keys, agreement to
escrow policy). Sponsor (party approving the
issue of a certificate to employees, customers,
etc.). Relying party (one relying on the
certificate).
49
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.
50
Certificate Policy Statement - Continued 12.
Confidentiality (rules associated with access to
private keys) in normal and exceptional
operations (data recovery, disclosure to third
parties, diagnosing/troubleshooting problems).
13. Identification/Authentication
registration Names and uniqueness, proof of
identity (credentials). Forgotten passwords
(usually re-start from null). Re-key after
compromise. Revocation requests.
51
Certificate Policy Statement - Continued 14.
Operational Requirements Certificate
application process User acceptance of the
certificate (written agreement) Certificate
suspension revocation (conditions) 15. Audit
Requirements OS account creation, upgrades,
patches Configuration control, backups,
shutdowns, re-starts Audit log dumps (anytime
the audit log is reset)
52
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).
53
Certificate Policy Statement - Continued 21.
Procedural Controls - Who does what? Required
for CA/System admin, Security Officer). May
include a 2-person rule. 22. Personnel Security
User training. 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,
algorithms, controls, etc. 24. CA Computer
Security Controls. 25. Network Protection -
protection for the domain and segment hosting
the CA.
54
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.
55
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.
56
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 Trust
the government to back currency we use Seller
trusts the bank to honor a credit card Other
trusted instruments checks, notarized
documents, drivers license, passport, judicial
system documents, etc.
57
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 many real
cases have occurred.
58
PKI Summary Trusted Infrastructure to manage
certificates. Certificated bind user names to
identities to enable trusted interactions. Are
relatively expensive. Work well in single
companies and sometimes in groups (e.g., DOE,
DOD). Not been a killer application for general
Internet commerce.