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
 Legislative Requirements
 E-Authentication
 HSPD-12
 PKI Tutorial
 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
 Configuring
 Sending signed/encrypted email
 Receiving signed/encrypted email
 Signing with Adobe 7.0
 Signing a MS Word Document
 Managing Certificates
 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
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

PKI
Authentication Mechanism

level 3 & 4

es
User ID
ro cess
Password
es sP
s in
level 2 Bu

Anonymous
Access
level 1
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 October 2005
 PIV-2: Smartcard ID Badge October 2006

10
 FIPS 201 PIV Process
Local sponsor fills out applicant’s badge request form,
Authorize which is then approved by an Authorizing Official and
forwarded to the Registration Authority.
Registration Authority checks applicant’s identity documents; PIV-1
obtains applicant’s photograph, fingerprints and other Oct 05
Register background check data. Background check must be
completed before badge issuance.
Issuing Authority verifies applicant against registration
data. Then creates and issues badge.
Issue Badge loaded with applicant’s biometrics (fingerprints and
photograph), PIN and PKI certificate information.
PIV-2
Badge accepted / electronically validated by all Agencies. Oct 06
PIN / biometrics used for stronger physical authentication.
Use PKI certificates used for logical authentication to IT systems.

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: ET TU BRUTE

Shift Algorithm
3 characters

Ciphertext: HW WX EUXWH
15
 Symmetric Key Cryptography
Same key used to encrypt and decrypt

Alice Bob
Dear Bob:
ciphertext Dear Bob:
I am leaving you. I am leaving you.
Goodbye forever. 011100111001001 Goodbye forever.
110011100111001
Alice encrypt 001110000111111 decrypt Alice

 Computationally fast
 Data Encryption Standard (DES)
 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

RSA - Integer Factorization (large primes)
 Diffie-Hellman - Discrete Logarithms
 ECES - Elliptic Curve Discrete Logarithm
 Public Key Cryptography
 One public key published for all to see Carol
 Other is private key kept secret by owner
Works both ways
Bob Can encrypt with either key – decrypt with the other
Dear Carol: 011100111001001 Dear Carol:
Alice is gone. Now
encrypt 110011100111001 decrypt Alice is gone. Now
we can be together 001110000111111 we can be together
Love, Bob Love, Bob

Carol’s Carol’s
Public Key Private Key
Bob: Bob:
Leave me alone! Leave me alone!
Carol decrypt 011100111001001
110011100111001 encrypt Carol
001110000111111

18
 Asymmetric Advantages
 No shared secret key
 Public key is public
 Can be freely distributed or published
 Key management is much easier
 Private key known ONLY to owner
 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 We have asked the

Court to issue a Sue’s Court to issue a
restraining order restraining order
against you to stay Private Key against you to stay
away from Carol. away from Carol.

Sincerely, Sincerely,
Hash Hash
Sue Yew Sue Yew
Dewey, Cheatam & Function Value Dewey, Cheatam &
Howe, Law Firm Howe, Law Firm

0F47CEFF 0101011110000110101
AE0317DB encrypt 1011110101111010111
AA567C29

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
We have asked the AE0317DB
Court to issue a AA567C29
restraining order
against you to stay
away from Carol.
Hash proves document unchanged
Sincerely,  integrity
Sue Yew
Dewey, Cheatam &
Public key proves authorship
Howe, Law Firm

0101011110000110101
0F47CEFF  non-repudiation
1011110101111010111 decrypt AE0317DB
AA567C29

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: Carol
I am still hoping I am still hoping
when I get out of when I get out of
prison we can be prison we can be
together. together.

Love, Bob Love, Bob

A032F17634
E57BC43356
743212b9c9
encrypt 8FA2917342
5633A22201
decrypt
807732ECF1
3344567520
ABCE4567CD

0111001110
encrypt 1100111001 decrypt
0011100001

Carol's Carol's
Public Key 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

Private Relying Party A

Subscriber signs key
message to A

Certificate Get CRL to

Validate
010111 Certificate
102101

Relying Party B Directory

encrypts message
Get Subscriber's
to Subscriber
Certificate
30
 SSL Server Authentication

3
1
Trust Issuing CA?
2
4
CRL 5 6 WWW
Validate
Certificate 7

1. Client sends https request to server

2. Server sends its certificate to the client
3. Client decides if certificate (and issuing CA) is trustworthy
4. Client validates certificate
5. Client sends to server session key - encrypted with server’s public key
6. 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
Root CA
Root CA Root CA's Private Key
Self Signed Certificate Info
Root Signature

Subordinate CA
Root CA's Private Key
Sub CA Certificate Info
Root Signature

Subscriber
Subordinate CA's Private Key
Certificate Info
SubCA's Signature

Text
Subscriber's Private Key
Document
Subscriber's
Signature

36
 Relying Party Certification Path
A relying party builds a
certificate path from the Green CA

other subscriber to the

relying party’s trust anchor Yellow Blue

Mark gets cert from Phyllis

Gold Red
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 Mark Phyllis

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
PKI CP

CPS

 Certificate Policy (CP)

 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)
 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
 Have independent policies Green CA Blue CA
 CA compromise does not effect others

 Disadvantages
Red CA
 Can form a MESH PKI Gold CA
 CA needs to maintain multiple relationships with
other CAs
 Hard to build certification path
 Multiple possible paths
 Loops and dead ends

Mark Phyllis

42
 Bridge PKI Architecture

Green CA Blue CA
 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 Gold CA Red CA
 Bridge does all policy management
 Less work for the CAs
 Maintains list of revoked CAs (CARL)

Mark Phyllis

43
 Federal Bridge Certificate Authority

DOD Illinois
PKI PKI

NASA
NFC
PKI
PKI

Health Higher
Care Ed
BCA BCA

Hospital CANADA University

PKI PKI 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 PKE

Maintain and operate a certificate Assist in PK-enabling (PKE)

acceptance infrastructure (CAI) to HHS business processes.
validate the certificates that we
receive from inside and outside
HHS.

47
 Certificate Issuance System
Subscriber goes to registration web
Directory
site enters MS credentials Record
Login
AD record is downloaded SSL AD

Subscriber selects pass phrase

Pass phrase
Subscriber’s data stored in RA database Edith Entity
HHS/NIH/CIT
Subscriber
Bldg 66, Room 99
(301) 495-7734 data
Subscriber prints (bar-coded) registration form
eenity@nih.gov

Edith Entity

Subscriber takes form to LRA.

Data RA App Border
LRA scans form, validates information
SSL Directory
and approves subscriber
Approval
Email sent to subscriber
Subscriber
Subscriber follows URL to web page data
and enters their pass phrase
SSL
Validated subscriber is redirected to CA
Pass phrase
along with subscriber’s data
Certificates downloaded to subscriber’s
browser and posted into Border Directory
(and subsequently imported into AD)
48
 Certificate Validation Service

4
3b
1 2
PKE
3d

3a 3c

1. Application receives certificate

2. PKI-enabled applications calls CAM HHS Trusted OTHER
PKI PKI 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
4. CAM logs validation to meet GPEA/NARA electronic records requirements

49
 Putting it all together

Other PKI

FBCA Cross-Certification
CRLs
Border
TLS Reg Staff Reg Directory Certificate Status
Information to other PKIs

+
Signed
SSL
Encrypted Documents
Email Relying From other PKIs
Subscriber Subscriber
Party A Certificate
Status
Certificate
Digitally
+ Certificate
Records
Signed Document Status
Relying
Party B
Archiv
e
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 Don’t sign / date until
(e.g., PM, AO) 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 Photocopy Government
badge doesn’t have unique picture ID onto form
ID number

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