The Evolving Federal PKI Richard Guida P E

The Evolving Federal PKI Richard Guida, P. E. Chair, Federal PKI Steering Committee Richard. Guida@cio. treas. gov; 202 -622 -1552 (Steering Committee web page: http: //gits-sec. treas. gov)

E-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 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 Face • • • Authentication of Users Non-repudiation for transactions Confidentiality (privacy) Interoperability Liability Scalability/extensibility

Public Key Technology • • • Authentication Technical non-repudiation Data integrity Confidentiality Interoperability Scalability/extensibility

How 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 6

Digital Signature (example) (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) • 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 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)

Public Key Certificate 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

X. 509 v 3 Certificate 11

Public 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 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 • 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 CA • Non-hierarchical hub (“peer to peer”) • Maps levels of assurance in disparate certificate policies (“policy. Mapping”) • Ultimate bridge to CAs external to Federal government • Directory initially contains only FBCAissued certificates and ARLs

Boundary Conditions • Use COTS with “inclusive” architecture • Use X 509 v 3 • Support four levels of assurance – Rudimentary, Basic, Medium, High – Modeled after Canadian PKI • FBCA use cannot be mandatory • Focus requirements on agencies as certificate issuers, not relying parties

FBCA 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 Status • Prototype FBCA: Entrust, Cybertrust (replacing with Baltimore Unicert) – Initial operation 2/8/00 • Production FBCA: add other CAs – Operational by late 00 • FBCA Operational Authority is GSA (Mitretek technical lead and host site) • FBCA Cert Policy by mid-00 • FPKIPA operational 7/00

Cybertrust CA PCA Entrust CA PCA SFL PCA Entrust Client Do. D Bridge CA Client CA PCA PCA Entrust SFL Client CA CA CA Entrust PCA PCA CA CA Entrust SFL Entrust Client

Intra-Agency PKI Examples • DOD (>250 K certs => >>4 M by 2002; high assurance with smartcards) • FAA (~1 K certs => 20 K+ in 2000; software now, migrating to smartcards) • FDIC (~7 K certs => 20 K+ in 2000) • NASA (~1 K certs => 25 K+ in 2000) • USPTO (~1 K certs => 15 K+ in 2000)

Planned Interagency Uses • VA and SSA on medical evidence • Dept of Education, SSA, VA on student loan applications, disbursements • USDA/NFC for on-line payroll matters • DOD/Treasury re: payments • FDIC/other financial regulators re: sharing information

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) or LDAP referral to FBCA DSA 22

Border Directory Concept PCA 1 Internal Directory Infrastructure Agency 3 PCA 2 FBCA Respon LDAP Query- Internal Directory Infrastructure Border DSA 1 LDAP Server SP 0 -D X. 50 ing n chai Agency 1 se FBCA DSA Border DSA 2 X. 500 DSA Agency 2 Internal Directory Infrastructure

Access 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 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 (President used the first one in signing E-Sign bill 6/30/00)

USPS Issues • USPS very well positioned to serve as RA • USPS partnering with AT&T and IBM on branded secure e-mail • USPS intends to interoperate with FBCA and thus support multiple CA sources • Bottom line: USPS can become important source of PKI products and services to Federal agencies

Commercial Implementations • Scotiabank (300 K+ certs; 500 K transactions per month) • American Express “Blue” • Identrus bank consortium • Large manufacturing companies for internal uses (GE, automobile manufacturers)

Electronic 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 strengths • Gives electronic signature full legal effect • Focus: transactions with Federal agencies • Draft OMB Guidance 3/99; final 5/00

Organization

Federal 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 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 do • Technical vs. legal non-repudiation – Usually can do the former, probably can do the latter • Establishing a PKI <> making clients PKIaware – Building the highway is not the same as building the cars that ride on the highway – Enabling clients is usually CA-product centric

Requiring 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 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 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 herring • Interoperability often not needed in enterprise applications (single product) – “Plug and Play” CA products unachievable, but that is NOT a big problem • 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 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