The Evolving Federal PKIThe Evolving Federal PKI

Gary Moore

Entrust Technologies

Richard Guida

Chair, Federal PKI Steering Committee

E-Transaction LandscapeE-Transaction Landscape

• Intra-agency– personnel matters, agency management

• Interagency– payments, account reconciliation, litigation

• Agency to trading partner– procurement, regulation

• Agency to the public

E-Transactions DriversE-Transactions Drivers

• Long-term cost savings

• Trading partner practices (e.g., banks)

• Public expectations

• Federal/State Statutes (e.g., GPEA) and policies

• International competition

Challenges All Applications FaceChallenges All Applications Face

• Authentication of Users

• Non-repudiation for transactions

• Confidentiality (privacy)

• Interoperability

• Liability

• Scalability/extensibility

Public Key TechnologyPublic Key Technology

• Authentication

• Technical non-repudiation

• Data integrity

• Confidentiality

• Interoperability

• Scalability/extensibility

6

How PK Technology WorksHow PK Technology Works

• Two keys, mathematically linked

• One is kept private, other is made public

• Private not deducible from public

• For digital signature: One key signs, the other validates

• For confidentiality: One key encrypts, the other decrypts

Digital Signature (exampleDigital Signature (example)

• Sender hashes document, signs hash with private key and sends with document

• Recipient hashes document he or she received, creating “raw hash”

• Recipient applies public key of sender to signed hash to get sender’s raw hash

• If raw hashes are same, transaction validates

Confidentiality (example)Confidentiality (example)

• Sender generates symmetric encryption key and encrypts document with it

• Sender encrypts symmetric key with public key of recipient, sends that and encrypted document to recipient

• Recipient decrypts symmetric key with his or her private key

• Recipient decrypts document with symmetric key

The Critical QuestionsThe Critical Questions

• How can the recipient know with certainty the sender’s public key? (to validate a digital signature)

• How can the sender know with certainty the recipient’s public key? (to send an encrypted message)

A document which -

• is digitally signed by a trusted third party (called Certification Authority)

• is based on identity-proofing done by a Registration Authority

• contains the individual’s public key and some form of the individual’s identity

• has a finite validity period

Public Key (Digital) CertificatePublic Key (Digital) Certificate

11

X.509 v3 CertificateX.509 v3 Certificate

Public Key InfrastructurePublic Key Infrastructure

• Registration Authorities to identity proof users

• Certification Authorities to issue certificates and CRLs

• Repositories (publicly available data bases) to hold certificates and CRLs

• Some mechanism to recover data when encryption keys are lost/compromised

• Certificate Policy and related paper

Federal PKI ApproachFederal PKI Approach

• Establish Federal PKI Policy Authority (for policy interoperability)

• Implement Federal Bridge CA using COTS (for technical interoperability)

• Deal with directory issues in parallel– Border directory concept

– Use ACES for public transactions

Federal PKI Policy Authority Federal PKI Policy Authority

• Voluntary interagency group - NOT an “agency”

• Governing body for interoperability through FBCA– Agency/FBCA certificate policy mappings

• Oversees operation of FBCA, authorizes issuance of FBCA certificates

Federal Bridge CAFederal Bridge CA

• Non-hierarchical hub (“peer to peer”)

• Maps levels of assurance in disparate certificate policies (“policyMapping”)

• Ultimate bridge to CAs external to Federal government

• Directory initially contains only FBCA-issued certificates and ARLs

FBCA ArchitectureFBCA Architecture

• Multiple CAs inside membrane, cross certified– Adding CAs straightforward albeit not

necessarily easy

• Solves inter-product interoperability issues within membrane - which is good

• Single consolidated X.500 directory (but also support LDAP access)

Current StatusCurrent Status

• Prototype FBCA: Entrust, Cybertrust– Initial operation 2/8/00

• Production FBCA: add other CAs– Operation by late 00

• FBCA Operational Authority is GSA (Mitretek technical lead and host site)

• FBCA Certificate Policy (by mid-00)

• FPKIPA Charter (done)

Intra-Agency PKI ExamplesIntra-Agency PKI Examples

• DOD (>250K certs => >>4M by 2002; high assurance with smartcards)

• FAA (~1K certs => 20K+ in 2000; software now, migrating to smartcards)

• FDIC (~4K certs => 7K+ in 2000)

• NASA (~1K certs => 25K+ in 2000)

• USPTO (<1K certs => 15K+ in 2000)

19

Border Directory ConceptBorder Directory Concept

• Each agency would have Border Directory for certificates and CRLs– May shadow all or part of local directory system

(allows for agency discretion)

– CAs may publish directly in border directory

– Unrestricted read access

• Directory resides outside agency firewall– chain (X.500 DSP) or LDAP referral to FBCA DSA

Border Directory ConceptBorder Directory Concept

InternalDirectory

Infrastructure

PCA 2

FBCADSA

InternalDirectory

Infrastructure BorderDSA 2

X.500 DSA

BorderDSA 1

LDAP Server

InternalDirectory

Infrastructure

PCA 1 PCA 3

Agency 1 Agency 2

Agency 3

FBCA

LD

AP

Que

ry-R

espo

nse

X.500 - D

SP

chaining

Access Certs for Electronic ServicesAccess Certs for Electronic Services

• “No-cost” certificates for the public

• For business with Federal agencies only (but agencies may allow other uses on case basis)

• On-line registration, vetting with legacy data; information protected under Privacy Act

• Regular mail one-time PIN to get certificate

• Agencies billed per-use and/or per-certificate

Access Certs for Electronic ServicesAccess Certs for Electronic Services

• RFP 1/99; bids received 4/99; first award 9/99 (DST), second award 10/99 (ORC), third award 10/99 (AT&T)

• Provisions for ACES-enabling applications, and developing customized PKIs

• Agencies do interagency agreement with GSA

• Certificates available now

Electronic Signatures under GPEAElectronic Signatures under GPEA

• Government Paperwork Elimination Act (October 1998)

• Technology neutral - agencies select based on specifics of applications (e.g., risk)– But full recognition of dig sig strengths

• Gives electronic signature full legal effect

• Focus: transactions with Federal agencies

• Draft OMB Guidance 3/99; final 5/00

OrganizationOrganization

S ecu rity, P rivacy, C rit ica l In fras tru c tu re C om m ittee

B u s in ess W G Tech n ica l W G L eg a l/P o licy W G

F ed era l P u b lic K ey In fras tru c tu re S teerin g C om m ittee

E n terp rise In te rop erab ility C om m ittee

F ed era l C h ie f In fo rm ation O ffice r C ou n c il

PKI Use and Implementation IssuesPKI Use and Implementation Issues

• Misunderstanding what it can and can’t do

• Requiring legacy fixes to implement

• Waiting for standards to stabilize

• High cost - a yellow herring

• Interoperability woes - a red herring

• Legal trepidation - the brightest red herring

Legal trepidation - the brightest red herringLegal trepidation - the brightest red herring

• PK technology is NOT the most complex subject presented in a courtroom

• Case law only develops when you use something

• Technology and commerce marches on regardless of legal uncertainties

• Unreasonable to demand standard of proof higher than in paper world