Federal Agencies and PKI Richard Guida, P.E. Member, Government Information Technology Services...

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