Date post: | 21-Jan-2016 |
Category: |
Documents |
Upload: | dale-howard |
View: | 217 times |
Download: | 0 times |
Federal Agencies and PKIFederal Agencies and PKI
Richard Guida, P.E.
Member, Government Information Technology Services Board
Chair, Federal PKI Steering Committee
[email protected]; 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