Public Key Infrastructure 101
Mark L. Silverman, CISSP
DHHS PKI Program Manager
December 7, 2005
A Riddle
You are standing in a room. On the wall are three
toggle light switches, clearly marked on/off and
currently all in the off position. One of the switches
controls a normal 100 watt table lamp, located in the room
next door. It does not matter what the other two switches
control. From your room, there is no way
that you can see the light from the lamp (no mirrors,
extension cords, etc.).
By entering the room with the lamp only once, how
can you determine which switch controls the lamp?
2
Today’s Objectives

Why PKI




PKI Tutorial




Legislative Requirements
E-Authentication
HSPD-12
Cryptographic Overview
SMIME and Digital Signatures
PKI Components and Operations
HHS PKI Overview



Certificate Issuance System
Certificate Validation Service
Obtaining HHS Digital Certificates
3
Today’s Objectives (continued)

Microsoft Outlook






Signing with Adobe 7.0
Signing a MS Word Document
Managing Certificates



Configuring
Sending signed/encrypted email
Receiving signed/encrypted email
Backup (Export)
Copy/Restore (Import)
Web based authentication and signatures (LRA)
4
Why PKI?
5
Extended Trust
PKI is the only technology that extends trust
beyond the enterprise with no a priori
relationship between the trusted parties.
6
President’s Management Agenda
Agencies will undertake a Federal Public Key
Infrastructure (PKI) to promote digital
signatures for transactions within the federal
government, between government and
businesses and between government and
citizens.
7
Federal PKI Drivers

Government Paperwork Elimination Act (GPEA) 1998
Requires Agencies to accept transactions, and maintain records electronically, when
practicable

Electronic Signatures in Global and National Commerce Act (E-Sign) 2000
An electronic signatures can not be denied legal status.




E-Government Act of 2002
Achieve interoperable implementation of electronic signatures for appropriately secure
electronic transactions with Government. OMB to oversee implementation of electronic
Government.
Memorandum Streamlining Authentication and Identity Management (OMB
7/03/03)
Agencies will acquire PKI services from shared service providers (see also OMB M 05-05)
E-Authentication Guidance for Federal Agencies (OMB M-04-04 - 12/16/03)
Ensure that authentication processes provide the appropriate level of assurance.
SP 800-63 - Electronic Authentication Guideline
Policy for a Common Identification Standard for Federal Employees and
Contractors (HSPD-12 – 8/27/04)
Smartcard ID badge for logical access to Agency IT systems.
FIPS 201 - Personal Identity Verification (PIV) of Federal Employees and Contractors
8
E-Authentication OMB M-04-04
Authentication Mechanism
Potential Impact of Authentication Errors
1
2
3
4
Inconvenience, distress, reputation
Low
Mod
Mod
High
Financial loss or agency liability
Low
Mod
Mod
High
Harm to agency program or public interests
--
Low
Mod
High
Unauthorized release of sensitive information
--
Low
Mod
High
Civil or criminal violations
--
Low
Mod
High
Personal safety
--
--
Low
Mod
Web Pages
Time Card
Patient Data
E-Authentication Risk Assessment: http://www.cio.gov/eauthentication/documents/eraguide.pdf
9
Homeland Security Presidential Directive 12
Policy for a Common Id Standard for Federal Employees and Contractors
 Mandates new Federal ID Badge that is:




Based on sound criteria to verify an individual employee’s identity
Resistant to fraud, tampering, counterfeiting, and terrorist exploitation
Rapidly verified electronically
Issued only by providers whose reliability has been established by an official
accreditation process
 Agencies shall, to the maximum extent practicable, require the use of
identification by Federal employees and contractors that meets the
Standard in gaining physical access to Federally controlled facilities and
logical access to Federally controlled information systems.
 FIPS 201 - Personal Identity Verification of Federal Employees and
Contractors
 PIV-1: Identity proofing process
 PIV-2: Smartcard ID Badge
October 2005
October 2006
10
FIPS 201 PIV Process
Authorize
Local sponsor fills out applicant’s badge request
form, which is then approved by an Authorizing
Official and forwarded to the Registration Authority.
Register
Registration Authority checks applicant’s identity
documents; obtains applicant’s photograph, fingerprints
and other background check data. Background check
must be completed before badge issuance.
Issue
Issuing Authority verifies applicant against registration
data. Then creates and issues badge.
Badge loaded with applicant’s biometrics (fingerprints
and photograph), PIN and PKI certificate information.
Use
Badge accepted / electronically validated by all Agencies.
PIN / biometrics used for stronger physical authentication.
PKI certificates used for logical authentication to IT systems.
PIV-1
Oct 05
PIV-2
Oct 06
Each step must be performed independently by different people.
Entire process and support systems must be accredited.
11
Tutorial
12
Foundations of PKI
13
Cryptography

Science of secret (hidden) writing
kryptos – hidden
 graphen –to write


Encrypt / encipher


Convert plaintext into ciphertext
Decrypt / decipher

Convert ciphertext into plaintext
14
Early Examples of Cryptography

Spartan Scytale – fifth century BC

Julius Caesar (49 BC) substitution cipher
Plaintext:
3 characters
Ciphertext:
ET TU BRUTE
Shift Algorithm
HW WX EUXWH
15
Symmetric Key Cryptography
Same key used to encrypt and decrypt
Alice
Bob
ciphertext
Dear Bob:
I am leaving you.
Goodbye forever.
Alice


decrypt
Alice
Computationally fast
Data Encryption Standard (DES)



encrypt
011100111001001
110011100111001
001110000111111
Dear Bob:
I am leaving you.
Goodbye forever.
Block Cipher, 56 bit key
Triple DES 112 bit key
Advanced Encryption Standard (AES)



Rijndael Algorithm
Belgian cryptographers, Joan Daemen and Vincent Rijmen.
128, 192, 256 bit keys
16
Symmetric Encryption Issues


Key (shared secret) vulnerable to discovery
Need to share a unique secret key with each
party that you wish to securely communicate


N * (N – 1) Problem
Key management becomes unmanageable
17
Asymmetric Key Cryptography

Two mathematically related keys


Unable to derive one from the other
Based upon hard problem




Public Key Cryptography


Bob
Dear Carol:
Alice is gone. Now
we can be together
Love, Bob
RSA - Integer Factorization (large primes)
Diffie-Hellman - Discrete Logarithms
ECES - Elliptic Curve Discrete Logarithm
One public key published for all to see
Other is private key kept secret by owner
Works both ways
Can encrypt with either key – decrypt with the other
encrypt
011100111001001
110011100111001
001110000111111
Carol’s
Public Key
Bob:
Leave me alone!
Carol
Carol
decrypt
decrypt
Dear Carol:
Alice is gone. Now
we can be together
Love, Bob
Carol’s
Private Key
011100111001001
110011100111001
001110000111111
encrypt
Bob:
Leave me alone!
Carol
18
Asymmetric Advantages


No shared secret key
Public key is public



Private key known ONLY to owner


Can be freely distributed or published
Key management is much easier
Less vulnerable, easier to keep secret
Supports Non-repudiation



Encrypt with sender’s private key (only known by sender)
Sender can not deny sending message
Basis for digital signatures
19
Electronic Signatures
Electronic Signature != Digital Signature
Electronic Signatures in Global and National
Commerce Act (E-Sign) defines:
The term ‘‘electronic signature’’ means an
electronic sound, symbol, or process, attached to
or logically associated with a contract or other
record and executed or adopted by a person with
the intent to sign the record.
20
Digital Signatures
A digital signature is a a type of electronic signature.
It is a hash of a document encrypted with the author’s private key
Sue
Dear Mr. Bob:
Dear Mr. Bob:
We have asked the
Court to issue a
restraining order
against you to stay
away from Carol.
Sincerely,
Sue Yew
Dewey, Cheatam &
Howe, Law Firm
Sue’s
Private Key
Hash
Function
We have asked the
Court to issue a
restraining order
against you to stay
away from Carol.
Sincerely,
Hash
Value
0F47CEFF
AE0317DB
AA567C29
Sue Yew
Dewey, Cheatam &
Howe, Law Firm
encrypt
0101011110000110101
1011110101111010111
Digital
Signature
21
Validating a Digital Signature
1. Re-compute the hash value
2. Obtain the author’s public key
3. Decrypt the original hash
4. Compare hash values – if match signature is valid
Dear Mr. Bob:
0F47CEFF
AE0317DB
AA567C29
We have asked the
Court to issue a
restraining order
against you to stay
away from Carol.
Sincerely,
Sue Yew
Dewey, Cheatam &
Howe, Law Firm
0101011110000110101
1011110101111010111
decrypt
0F47CEFF
AE0317DB
AA567C29
Hash proves document unchanged
 integrity
Public key proves authorship
 non-repudiation
Sue’s
Public Key
22
Asymmetric Issues

More computationally intensive


100x symmetric encryption
Generally not used to encrypt data


Encrypt symmetric key (S/MIME)
SSL session key
23
SMIME Encryption
Encrypted email uses the recipient's public key
Bob
Dear Carol:
Dear Carol:
I am still hoping
when I get out of
prison we can be
together.
I am still hoping
when I get out of
prison we can be
together.
Love, Bob
Love, Bob
A032F17634
E57BC43356
743212b9c9
8FA2917342
5633A22201
807732ECF1
3344567520
ABCE4567CD
encrypt
encrypt
Carol's
Public Key
0111001110
1100111001
0011100001
Carol
decrypt
decrypt
Carol's
Private Key
24
Source of Public Key


Keys can be published anywhere
Attached as a signature to e-mail

Pretty Good Privacy (PGP)
-----BEGIN PGP SIGNATURE----Version: PGP 7.0.4
iQCVAwUBOx6SgoFNSxzKNZKFAQGK+gP6AnCVghZqbL3+rM5JMSqoC5OEYIkbvYZN
92CL+YSCj/EkdZnjxFmU9+wGsWiCwxvs/TzSX6SZxlpG1bHFKf0OPu7+JEfJ7J5z
cPCSqbFXiXzmukMl5KNx0p0veIDW4DmwleDpkmhT05qnCheweoNyvTSzfA1TGeLl
mpjBi6zUjiY=
=Xq10
-----END PGP SIGNATURE-----
25
But…

How do you know for sure who is the owner of a
public key?
26
Public Key Infrastructure
Public Key Infrastructure (PKI) provides the
means to bind public keys to their owners
and helps in the distribution of reliable public
keys in large heterogeneous networks. NIST
The set of hardware, software, people, policies
and procedures needed to create, manage, store,
distribute, and revoke Public Key Certificates based
on public-key cryptography.
IETF PKIX working group
PKI is electronic identity management!
27
X509.V3 Digital Certificate

Issued by a TRUSTED third party Certificate Authority (CA)



Creates and digitally signs Certificates
Issues Certificate Revocation Lists (CRLs) or
Online Certificate Status Protocol (OCSP)
Identity Proofing done by Local Registration Authority (LRA)
28
PKI Users

Subscribers

Entity who obtains certificates from a CA


Person, device, application, etc.
Owns private key associated with public key in certificate



Non-repudiation requires only subscriber has access to private key
CA may escrow private key used for encrypted email
Owner must protect private key



Password
Safer with hardware token / smart card
Relying Party


Entity who receives digital certificate
Trusts CA who attests to certificate holder’s identity
29
How Certificates are used
Subscriber signs
message to A
Private
key
Relying Party A
Get CRL to
Validate
Certificate
Certificate
010111
102101
Relying Party B
encrypts message
to Subscriber
Directory
Get Subscriber's
Certificate
30
SSL Server Authentication
3
1
Trust Issuing CA?
2
4
CRL
Validate
Certificate
6
5
WWW
7
1. Client sends https request to server
2. Server sends its certificate to the client
3.
4.
5.
6.
Client decides if certificate (and issuing CA) is trustworthy
Client validates certificate
Client sends to server session key - encrypted with server’s public key
Server decrypts session key with its private key
7. Client – Server transactions are now encrypted with session key
31
Ever See this?
What do you do?
32
Trusted Third Party
PKI is built upon the concept of the
trusted third party (i.e., CA)
But, who are you going to trust?
33
Who do you Trust?

Everyone trusts their own CA (trust anchor)

Trust all certificates issued by their CA
CA
George

Martha
Clark
Single CA model does not scale well

Difficult to manage across large or diverse user
communities
34
Hierarchical PKI

CAs have superior-subordinate relationships



Higher level CAs issue certificates to subordinate CAs
Subordinate CA issues certificate to subscriber
Forms a certification path (aka certificate chain)


Chain of certificates from subscriber to root CA
Root CA is top-level, self-signed (i.e., certified) CA
35
Certificate Chain
Self Signed
Root CA
Root CA
Certificate Info
Root CA's Private Key
Root Signature
Sub CA
Subordinate CA
Certificate Info
Root CA's Private Key
Root Signature
Subscriber
Certificate Info
Subordinate CA's Private Key
SubCA's Signature
Text
Document
Subscriber's Private Key
Subscriber's
Signature
36
Relying Party Certification Path
A relying party builds a
certificate path from the
other subscriber to the
relying party’s trust anchor
Green CA
Yellow
Blue
Gold
Red
Mark
Phyllis
Mark gets cert from Phyllis
1. Phyllis's cert signed by Red CA
2. Red's cert signed by Blue CA
3. Blue's cert signed by Green CA
Green CA is Mark's trust anchor,
therefore Mark trust's Phyllis's cert
37
What about other CAs?
How do you know if you can trust the CA?
Then, how much do you trust them?
38
Trust Lists
Commercial CAs often come pre-loaded
Why and how much do you trust a CA?
39
PKI Policies



High level document
Describes security policy for operating the CA
Defines roles and responsibilities



How CA will be managed
How registration will be performed (i.e., identity proofing requirements)
How subscribers use and handle their certificates and keys
Certification Practices Statement (CPS)




CPS
Certificate Policy (CP)


PKI CP
Detailed document
Describes mechanisms and procedures followed by CA to meet the
requirements of their CP
Effectively the CA's operations manual.
Together, Determines Assurance Level

How much you should trust the CA’s certificates
40
However….
Users generally don’t examine policies
Most users just click YES
to trust CA
for expediency


41
Cross-Certified PKIs

Peer-to-peer trust relationship



Between CAs or hierarchical PKI root CAs
CAs review polices and issue certificates to each other
Advantages

CAs are organizationally independent





Blue CA
Gold CA
Red CA
Mark
Phyllis
Have independent policies
CA compromise does not effect others
Disadvantages

Green CA
Can form a MESH PKI
CA needs to maintain multiple
relationships with other CAs
Hard to build certification path


Multiple possible paths
Loops and dead ends
42
Bridge PKI Architecture

Bridge is trust arbitrator


Only cross-certifies with other CAs
Relationships still peer-to-peer





Bridge
CA
Bridge is NOT a root CA
Certification path construction is
much easier
Bridge does all policy management
Blue CA
Green CA
Gold CA
Red CA
Mark
Phyllis
Less work for the CAs
Maintains list of revoked CAs (CARL)
43
Federal Bridge Certificate Authority
Illinois
PKI
DOD
PKI
NASA
PKI
NFC
PKI
Health
Care
BCA
Hospital
PKI
Higher
Ed
BCA
CANADA
PKI
University
PKI
 All trust relationships handled by bridge CA
44
In HHS CA we Trust
DST is cross-certified with the FBCA
DST root is preloaded in browser/outlook trust lists
DST/ACES part of Federal PKI
HHS Certificates issued by Digital Signature Trust,
(a commercial CA under GSA ACES)
Trusted TLS (SSL) certificates also available
45
HHS PKI Program
46
Project Goals
Maintain and operate a public key infrastructure (PKI) to
issue digital certificates to HHS entities (e.g., staff,
applications, devices).
PKI
CAI
Maintain and operate a certificate
acceptance infrastructure (CAI) to
validate the certificates that we
receive from inside and outside
HHS.
PKE
Assist in PK-enabling (PKE)
HHS business processes.
47
Certificate Issuance System
Subscriber goes to registration web
site enters MS credentials
AD record is downloaded
Subscriber selects pass phrase
Subscriber’s data stored in RA database
Subscriber prints (bar-coded) registration form
Subscriber takes form to LRA.
LRA scans form, validates information
and approves subscriber
Directory
Record
Login
AD
SSL
Pass phrase
Subscriber
data
Edith Entity
HHS/NIH/CIT
Bldg 66, Room 99
(301) 495-7734
eenity@nih.gov
Edith Entity
Data
RA App
SSL
Border
Directory
Approval
Email sent to subscriber
Subscriber
data
Subscriber follows URL to web page
and enters their pass phrase
SSL
Validated subscriber is redirected to CA
along with subscriber’s data
Certificates downloaded to subscriber’s
browser and posted into Border Directory
(and subsequently imported into AD)
Pass phrase
48
Certificate Validation Service
4
3b
2
1
PKE
3d
3a
3c
1. Application receives certificate
2. PKI-enabled applications calls CAM
HHS
PKI
3. CAM validates certificate with:
a. HHS CA (DST)
b. Other ACES CAs
c. Other CAs directly trusted by HHS
d. Other CAs trusted through FBCA
Trusted
PKI
OTHER
PKI
4. CAM logs validation to meet GPEA/NARA electronic records requirements
49
Putting it all together
Other PKI
FBCA
Cross-Certification
CRLs
TLS Reg
Border
Directory
Staff Reg
Certificate Status
Information to other PKIs
+
SSL
Subscriber
Certificate
Records
Archiv
e
Subscriber
Encrypted
Email
Signed
Documents
From other PKIs
Relying
Party A
Certificate
Status
+
Digitally
Signed Document
Relying
Party B
Certificate
Status
Signature Validation records
50
Obtaining your HHS Certificate
51
Request Your Certificates
52
Identify Yourself
53
ActiveX Requirements
54
Review Steps
55
Identify your Employer
56
Verify Your Information
If incorrect, see your local system administrator
57
Pick One-Time Pass phrase
You will need this pass phrase to get your certificates in the last step
58
Download/Print Request Form
Click here to
download form
59
PKI Certificate Request Form
Contractors need
customer’s signature
(e.g., PM, AO)
Don’t sign / date until
you are before an LRA
Notary information is
ONLY collected if can
not appear in-person
before LRA
Second form of ID is
needed ONLY if Federal
badge doesn’t have
unique ID number
Photocopy Government
picture ID onto form
60
Take Completed Form to LRA
61
Enabling ActiveX
Tools -> Internet Options -> Security
62
Email Notification
Click on this URL to obtain your certificates
63
Enters Pass Phrase
Enter pass phrase
If you forgot your passphrase, you will need to repeat the form creation and LRA process
64
Install Active-X Module
Click YES to install. Some “locked down”
desktops may (currently) require system admin. support
65
Review & Accept Subscriber Agreement
Check this
box
66
Download Instructions
Click link to download PDF
Click box
Then click next
67
Begin Retrieval Process
Click
68
Microsoft Warning
Click YES
69
Change Security Level
You MUST click here to set security level to HIGH
in order to password protect your private key
70
Set Security Level to High
Check HIGH
Then click Next
71
Set Password for Private Key
You must REMEMBER this password.
It can not be reset by an administrator.
72
Click OK to Save Setting
After setting security level to HIGH
You may now click OK
73
Processing...
74
Review Your Certificates
75
Download Encryption Certificate
76
Repeated Microsoft Warning
Click YES
77
Repeat Setting Security Level to High
78
Set Encryption Password
You may use the SAME password you entered for your signing Certificate
79
Certificate Download Complete
80
Configuring Outlook
Tools → Options
81
Tools → Options → Security → Settings…
Security tab
Click Settings
82
Specify Signing Certificate
Specify ANY name you like
Click
Choose
83
Select DST ACES Certificate
If more than one pick
Certificate issued by
DST ACES Federal Employee CA
84
Specify Encryption Certificate
Click
Choose
85
Publish to GAL
86
Enter Certificate Password
Do NOT Check
You will be prompted to enter your password each time you use your certificate
87
Using Your Certificates
88
Sending Signed/Encrypted Email
89
Message Options
If using Microsoft Office Word to edit e-mail messages
90
Security Settings
91
Send
Enter PKI private key password to sign email
NEVER
92
Receiving Secure Email
93
Click Ribbon for Details
Lock shows
Message was
encrypted
94
Add Buttons to toolbar
Uncheck to set
to default
message editor
95
Configure Message Editor
Buttons automatically migrate to Word editor as well
96
Adobe 7.0
97
Create Adobe Signature
98
Position Adobe Signature
99
Select Certificate
100
Specify Reason for Signature
101
Private Key Password
NEVER
102
First Time – May not be Trusted
103
Enable Windows Trust
104
Validate Signature
Right Click
105
Add Trusted CA (Macintosh)
Right Click
106
Signing a Word Document
107
Signed Document
Double
Click
108
Managing Your Certificates
109
Export (backup/move)
110
Pick First Certificate
111
Specify File and Password
Filename
Password
This is a NEW password to protect the FILE!
112
Enter Certificate Password
This is the OLD password used to protect your private key
113
Repeat for Second Certificate
114
Import Certificate
Filename and
password
from export
Must enter a
name. Use
any name
you like.
115
Set Security Level to High
Import/export is way to password protect private key if you failed
to set security level when initially obtaining your certificates.
116
Create New Password
This is the password to protect your private key.
117
Repeat for Second Certificate
118
Internet Explorer
119
Tools → Internet Options → Content…
Content Tab
Click
Certificates….
120
Can Export/Import/Delete
121
LRA Subscriber Registration
122
HHS PKI LRA Home Page
123
Certificate Authentication
124
First Time Download
125
LRA Management Page
126
Collect Registration Data
127
Approve Request
128
Registration Complete
129
Questions
Answers:
http://www.pki.hhs.gov
http://www.pki-page.org/
http://www.rsasecurity.com/rsalabs/faq/
http://csrc.nist.gov/pki/
mls@nih.gov
130