the evolving federal pki
DESCRIPTION
The Evolving Federal PKI. Gary Moore Entrust Technologies Richard Guida Chair, Federal PKI Steering Committee. E-Transaction Landscape. Intra-agency personnel matters, agency management Interagency payments, account reconciliation, litigation Agency to trading partner - PowerPoint PPT PresentationTRANSCRIPT
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