1 / 25

The Evolving Federal PKI

The Evolving Federal 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 Landscape. Intra-agency personnel matters, agency management

sgunning
Télécharger la présentation

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

  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 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 • 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

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

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

  16. Policy/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

  17. Current Status • Prototype FBCA: Entrust and Cybertrust (Baltimore) CAs • Began operation 2/8/00 • Used for EMA Challenge 4/6/00 • Migration from prototype to production FBCA will entail adding other CAs inside the membrane • GSA/FTS has responsibility to execute

  18. Schedule • Draft Bridge Certificate Policy: late 1999 (done - CIO Council reviewing) • Draft FPKIPA Charter/CONOPS: late 1999 (done - CIO Council reviewing) • Prototype Bridge: early 2000 (done - 2/8) • Operational Bridge: late 2000

  19. FBCA DSA Border DSA 1 Border DSA 2 LDAP Server X.500 DSA FBCA 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

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

  21. 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) • Contract has provisions for ACES-enabling applications • Potential use with state/local government • Certificates available very shortly

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

  23. Organization

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

  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

More Related