Federal Agencies and PKIFederal Agencies and PKI

Richard Guida, P.E.

Member, Government Information Technology Services Board

Chair, Federal PKI Steering Committee

Richard.Guida@cio.treas.gov; 202-622-1552

http://gits-sec.treas.gov

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 CertificatePublic Key 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

Intra-Agency PKI ExamplesIntra-Agency PKI Examples

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

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

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

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

Potential Interagency UsesPotential Interagency Uses

• VA and SSA on medical evidence

• Dept of Education, SSA, VA on student loan applications, disbursements, etc.

• USDA/NFC for on-line payroll matters

• DOD/Treasury re: payments

• FDIC/other financial regulators re: sharing information

Federal PKI ApproachFederal PKI Approach

• Establish Federal PKI Policy Authority

• Develop/deploy Bridge CA using COTS– Four levels of assurance (emulate Canada)– Prototype early 2000, production mid 2000

• Deal with directory issues in parallel– Border directory concept; “White Pages”

• Use ACES for public transactions

FPKIPA and Bridge CA TopicsFPKIPA and Bridge CA Topics

• Federal PKI Policy Authority Overlay

• FBCA Overview

• Technical Boundary Conditions

• Policy/Political Boundary Conditions

• Potential Architectures

• Current Status

• Schedule

Federal Policy Authority OverlayFederal Policy Authority Overlay

• Federal PKI Policy Authority facilitates interoperability through FBCA (e.g., determines cert policy mappings)

• All agencies that interoperate through FBCA are voting members

• FPKIPA members = FPKISC members

• Interoperability through the FBCA is NOT required (but hopefully attractive)

FBCA OverviewFBCA Overview

• Non-hierarchical hub for interagency interoperability

• Ability to map levels of assurance in disparate certificate policies

• Ultimate “bridge” to CAs external to Federal government

• Directory contains only FBCA-issued certificates and ARLs

FBCA PKI Architecture

US Federal

Technical Boundary ConditionsTechnical Boundary Conditions

• Comply with FIPS (140-1, 186)– Level 3 Crypto Module for FBCA

• Meet MISPC to maximum extent practical

• Interoperate with as many COTS as possible

• Comply with X509V3 (certs, policy processing)

Policy/Political Boundary ConditionsPolicy/Political Boundary Conditions

• Desire to use COTS if possible

• Desire solution which is as fully “inclusive” for vendors as possible

• Support four levels of assurance– Rudimentary, Basic, Medium, High– Analogous to Canadian PKI

• FBCA use not mandatory

• Requirements focus on agencies as certificate issuers, not relying parties

Potential ArchitecturesPotential Architectures

• Multiple CAs within membrane, with single signing key

• Single CA

• Multiple CAs within membrane, cross-certified among themselves

Multiple CAs, One KeyMultiple CAs, One Key

• Avoids cross-certification within membrane, so:– minimizes certificate path length– reduces overall path processing complexity

• May require porting key to other tokens (allowed under 140-1 if encrypted)

• Creates complications in directory postings for ARLs and cross-certs to external CAs

Single CASingle CA

• Most straightforward technical solution

• Pushes interoperability issues to Bridge membrane

• Is worst political solution– one winner, many losers– non-inclusionary

Multiple CAs, Cross-certifiedMultiple CAs, Cross-certified

• In essence, the “quark” model

• Certificate path length may be +1

• Adding CAs within membrane should be straightforward albeit not necessarily easy

• Requires solving inter-product interoperability issues within membrane rather than outside - which is good

Current StatusCurrent Status

• Decision: cross-certified CAs within membrane

• Initial vendor products: Entrust and GTE for “prototype” FBCA

• Migration from prototype to production FBCA will entail adding other CAs inside the membrane

• GSA/FTS has responsibility to execute

ScheduleSchedule

• Draft Bridge Certificate Policy: late 1999

• Draft FPKIPA Charter/CONOPS: late 1999

• Prototype Bridge: early 2000

• Operational Bridge: mid to late 2000

28

Initial Border Directory ConceptInitial Border 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) to FBCA DSA

Initial Border Directory ConceptInitial Border Directory Concept

InternalDirectory

Infrastructure

PCA 2

FBCADSA

InternalDirectory

Infrastructure BorderDSA 2

X.500 DSA

BorderDSA 1

X.500 DSA

PCA 1

Agency 1 Agency 2

FBCA

DSP

chaining

DSP

chai

ning

30

Concerns with Initial ConceptConcerns with Initial Concept

• Agencies must stand up X.500 DSA

• But:– Some agencies have no X.500 directories;

instead use LDAP servers (and may be tied to OS or major applications), proprietary, or nothing

– X.500 DSAs seen as expensive; initial cost, plus care and feeding (X.500 DSAs complex, and chaining can be challenging)

31

Expanding the ConceptExpanding the Concept

• Approach must provide for more than just agency X.500 directories

• FBCA directory can be directory nexus– Link to X.500 border DSAs via DSP chaining– Link to LDAP oriented agencies via referrals

• There are other possibilities– CIO Council “White Pages”– GSA– Commercial services

Expanded FBCA Directory ConceptExpanded FBCA 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)

• Contract has provisions for ACES-enabling applications

• Agency’s do interagency agreement with GSA

• Certificates available within three to six months

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)

• Gives electronic signature full legal effect• Focus: transactions with Federal agencies• Draft OMB Guidance 3/99; final 4/00

OrganizationOrganization

O ffice o f M an ag em en t an d B u d g et

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

G overn m en t In fo rm ation Tech n o log y S ervices B oard

N ation a l P artn ersh ip fo r R e in ven tin g G overn m en t

O F F IC E O F TH E V IC E P R E S ID E N T

Federal PKI Steering CommitteeFederal PKI Steering Committee

• Over 50 members from two dozen agencies• Three Working Groups

– Business– Technical– Legal and Policy

• Minutes/activities on the web• http://gits-sec.treas.gov

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

Misunderstanding what it can and can’t doMisunderstanding what it can and can’t do

• Technical vs. legal non-repudiation– Probably to the former, possibly to the latter

• Establishing a PKI <> making clients PKI-aware– Building the highway is not the same as

building the cars that ride on the highway

Requiring legacy fixes to implementRequiring legacy fixes to implement

• Fixing directory anarchy– Don’t expect directory problems to abate -

they will be exacerbated

• Mapping to legacy data bases– Back end applications remain

Waiting for standards to stabilizeWaiting for standards to stabilize

• Far too much to expect– Evolution is constant process, it does not stop

for anyone

• And, not necessary– Internet standards are not stable but it still

works (fitfully at times…)– PKI standards are good enough for enterprise

deployment, getting there for interoperability

High cost - a yellow herringHigh cost - a yellow herring

• Cost of ownership is not low– Registration, certificates, CRLs, PKI-aware

clients, repositories, directories, and so on

• But, compared to what?– Multiple stove-piped PIN applications with

poor security?

Interoperability woes - a red herringInteroperability woes - a red herring

• Interoperability often not needed in enterprise applications (single product)

• Even where needed, interproduct interoperability getting much better (Federal Bridge CA will help drive)

• No reason to delay use of this technology

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