1 / 26

The Evolving Federal PKI

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

habib
Download Presentation

The Evolving Federal PKI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Evolving Federal PKI Gary Moore Entrust Technologies Richard Guida Chair, Federal PKI Steering Committee

  2. E-Transaction Landscape • Intra-agency • personnel matters, agency management • Interagency • payments, account reconciliation, litigation • Agency to trading partner • procurement, regulation • Agency to the public

  3. 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

  4. Challenges All Applications Face • Authentication of Users • Non-repudiation for transactions • Confidentiality (privacy) • Interoperability • Liability • Scalability/extensibility

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

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

  7. Digital 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

  8. 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

  9. 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)

  10. Public Key (Digital) 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

  11. X.509 v3 Certificate

  12. 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

  13. 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

  14. 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

  15. Federal 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

  16. 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)

  17. Current 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)

  18. Intra-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 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

  20. FBCA DSA Border DSA 1 Border DSA 2 LDAP Server X.500 DSA Border Directory Concept Agency 3 PCA 1 Internal Directory Infrastructure PCA 3 PCA 2 FBCA Agency 2 Agency 1 LDAP X.500 - DSP Internal Directory Infrastructure chaining Query-Response Internal Directory Infrastructure

  21. 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

  22. 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

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

  24. Organization

  25. 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

  26. 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

More Related