DOE Public Key Infrastructure

1
DOE Public Key Infrastructure

• MaryAnn Breland, N. Daniel Lonnerdal
• Brian C. Soisson, Jebby S. Varghese
• 
  Office of the Chief
  Information Officer
• 
  U.S. Department of
  Energy
• 
  Information
  Management Conference
• 
  New Orleans,
  Louisiana
• 
  March, 2009

2
Topics

• Enterprise Overview
• DOE PKI Program Structure
• Certificate Policy
• Federal Bridge Structure
• Operations
• The Future

3
PKI Program Goals

• An agency-wide, interoperable Public Key
  Infrastructure
• Support OMB mandates for securing Department
  sensitive information, i.e., OMB-06-16 and
  HSPD-12
• Provide full Federal transitivity and recognition
  across the Federal Bridge
• Meet e-Authentication goals with Certificate
  Based Authentication and Authorization
• Enhance integrated use of PKI in applications to
  leverage single sign-on, authentication,
  authorization, digital signature

4
PKI Benefits

• Confidentiality, Integrity, Availability
• Statutory mandates for e-GOV PMA
• Personal identity verification of Department
  certificate holders is at medium hardware
  assurance level
• Encryption of Department business sensitive
  unclassified information, UCNI/OUO, PII
• Electronic signature technology, i.e., Adobe MS
  Office products
• PKI enabled applications
• Non-repudiation
• A signed digital document that ties a public key
  to a users identity
• DOE certificates are signed by the CA and held
  within the DOE enclave. The signature can be
  verified in a trusted way and the procedures are
  published and trusted

5
PKI Services

• Enterprise x.500 directory services
• Roaming services - provides seamless use of PKI
  credentials
• Secure logon to support applications
• Adobe
• NNSA portal and Smartcards at KCP
• FTMS (Foreign Travel Management System)
• Workflow application -Electronic signature on
  forms at PNNL
• Identity Proofing for PKI, RSA 2FA, and remote
  access
• Government to Business (G2B) for DOE use
• Providing file, folder, hard drive, and media
  encryption capabilities
• Management of Entrust, RSA, Pointsec enterprise
  pricing licensing

6
What is Trust?

• Confidentiality (encryption)
• Who can read my data?
• Can I be sure recipients of my data are the only
  ones that can read it?
• Data Integrity (encryption and digital
  signatures)
• Has my data been modified without my knowledge?
• Can I trust that someone elses data wasnt
  modified in-transit?
• Authentication (certificate revocation digital
  IDs)
• Is the source of the data trustworthy?
• Non-Repudiation (digital signatures)
• Can someone deny they produced the data?

7
PKI using Entrust

• Summary of Entrust client certificates
• DOE owns 70,000 clients
• 5,000 are for classified
• 65,000 are for unclassified
• Organization mission will determine usage
• Data that must be encrypted
• Sensitive unclassified information
• UCNI
• OUO
• PII
• Business sensitive

8
Public Key Infrastructure

• Expanding how we use Entrust at DOE
• Fully integrate Entrust with Microsofts
  CryptoAPI
• Support Digital Signatures in Microsoft Office
  and Adobe
• Digitally sign Macros, Code, Databases, and
  Applications
• Secure Messaging at the SMTP Gateway
• Vista, Linux, MAC, and Office 2007 Support
• Support for Inter-Agency secure communication

9
The Problem

• Each Federal Agency operates their own Public Key
  Infrastructure (PKI).
• Disparity between PKI software and hardware
  vendors utilized.
• Competing protocols and formats.
• Agency level decision as to which agency PKI is
  trustworthy.
• Complexity on the network because of multiple
  paths to reach each Agency PKI end-point.
• Complexity for the employee trying to locate PKI
  certificates belonging to cross-Agency colleagues.

10
PKI in IM-60
11
Roles and Responsibilities

• DOE PKI
• Mary Ann Breland DOE PKI Program Manager and
  DOE-Operational Authority (OA)
• Brian Soisson DOE OA Representative
• Daniel Lonnerdal DOE Policy Approving
  Authority (PAA) and DOE Policy Management
  Authority (PMA) Chair
• Jebby Varghese Alternate DOE-PAA and PMA
  Representative

12
DOE PKI PMA

• DOE PKI PMA
• Serves to maintain the DOE Certificate Policy
  (CP) and as a forum to address high level PKI
  issues. It creates a common and consistent
  DOE-wide PKI service which also helps to comply
  with Federal regulations.
• Members Currently in re-organization, currently
  have one voting member from each DOE site
  Certification Authority (CA). Goal is to have a
  cross-representation across DOE.
• Supports DOE Under-Secretary (Energy, NNSA,
  Office of Science, Power Marketing
  Administration, Chief Information Office)
• Voting Certificate Policy (CP) changes
• DOE - PAA
• Chair of PMA with veto power, owner of
  Certificate Policy
• Member of Federal PKI Policy Authority
  representing Department of Energy

13
PKI Certificate Policy (CP) and Certificate
Practice Statement (CPS)

• DOE Certificate Policy (CP)
• Owners PAA, PMA, OA
• Policy is approved by DOE PMA then by General
  Council
• Signed by Chief Information Officer
• Agency wide operational policy established to
  conform to FBCP and Common Policy CP as well as
  making it a binding agreement agency wide.
• Status
• We are currently under a major revision/update
• Living document, annually updated
• Public document
• All Subscriber holding credentials issued by a
  DOE CA are bound by policy
• DOE Certification Practice Statement (CPS)
• Each Certificate Authority is required to create
  their respective site CPS to conform to CP.
• Provides specifics on how each site CA operates
• Private document
• Auditable

14
DOE Certificate Policy Content

• The DOE Certificate Policy is comprised of 9
  Sections
• Section 1 Introduction
• Section 2 Publication and Repository
  Responsibilities
• Section 3 Identification and Authentication
• Section 4 Certificate Life-Cycle Operational
  Requirements
• Section 5 Facility, Management, and Operational
  Controls
• Section 6 Technical Security Controls
• Section 7 Certificate, CRL, and OCSP Profiles
• Section 8 Compliance, Audit, and Other
  Assessments
• Section 9 Other Business and Legal Matters

15
Common Policy

• Common Policy
• X.509 Certificate Policy for the U.S. Federal PKI
  Common Policy Framework
• What is X.509?
• An International Telecommunication Union
  Telecommunication Standardization Sector (ITU-T)
  standard for a public key infrastructure (PKI)
  for single sign-on and Privilege Management
  Infrastructure (PMI)
• Basis for Federal and Agency CP

16
Federal Bridge

• In the late 90s, the General Services
  Administration (GSA) took the lead in
  facilitating the interoperability of agency PKIs
  and established a working group and the Federal
  PKI Policy Authority (FPKIPA) to help guide the
  development of the US Federal government's PKI
  infrastructure.
• One of FPKIPA's centerpiece achievements is the
  establishment and operation of the Federal Bridge
  Certification Authority (FBCA). The FBCA helps
  facilitate and simplify secure information
  exchange by enabling cross-certified agencies'
  PKIs to recognize and trust digital signatures
  and certificates sent from and between other
  participating government organizations. This
  enables agencies to further expand the benefits
  achieved from PKI.

17
Federal Bridge (Continued)

• Federal Public Key Infrastructure Policy
  Authority (FPKIPA)
• Establishes X.509 Certificate Policy for the
  Federal Bridge Certification Authority (FBCA)
• GSA serves as the Operational Authority
• Membership
• Inter-Agency (DoD, Treasury, etc.) as well as
  private entities (Wells Fargo, State of Illinois)
• Determines participants levels of
  cross-certification (High, Medium HW, Medium)
• Participants become members of bi-monthly
  Certificate Policy Working Group (CPWG)
• Evaluate new Certificate Policies for adequacy
  and levels of assurance
• Map new requests against agreed upon policy
• Makes voting recommendations to FPKIPA
• Vote on changes to FBCP change proposals

18
The Federal Bridge

• A cross-governmental solution to make all
  agency-managed Public Key Infrastructures
  ubiquitous and interoperable.
• Allows for the interoperation of multi-vendor and
  multi-protocol directory service solutions.
• Energy is not currently joined to the Federal
  Bridge. DOE is participating as observing member
  as we make our necessary updates to re-join the
  bridge and become a voting member once again.

19
Re-joining the Federal Bridge as a Voting Member

• As a past voting member, DOE is considered a
  legacy member, and thus has the ability to
  re-join the Federal Bridge as an active voting
  member.
• Complete the annual independent PKI assessment
  audit.
• Address audit requirements for the
  cross-certified Energy Certification Authority
  servers housed at the National Laboratories
  other sites.
• Update the existing DOE x.509 Certificate Policy
  to incorporate language and requirements stated
  in the current Federal Bridge Certificate Policy
  and the Federal PKI Common Policy Framework.
• Obtain signed Memorandum of Agreement (MOA)
  between Energy and the Federal Bridge Policy
  Authority.

20
Current Members of Federal Bridge
21
Federal Bridge vs. Common Policy

• Why is DOE mapping to both?
• A more sound DOE PKI Certificate Policy
• Ensure compliance with all Federal PKI
  Regulations
• Federal Bridge CP and Common Policy CP are
  similar thus our CP can be easily mapped to both
• The Federal Government may decide on a different
  direction for PKI, thus the more we are aware of
  and involved with the Federal Bridge the better
  off we will be in the future
• Proposed that CIO Council will form the
  Information Security and Identity Management
  Committee (ISIMC), which will have the sub group
  Identity, Credential, and Access Management
  Subcommittee (ICAMS), under which the Federal PKI
  Policy Authority (FPKIPA) will reside.

22
Public Key Infrastructure
23
FIPS Validation

• Federal Information Processing Standards
  Publications (FIPS) is NIST standards and
  guidelines for Federal computer systems.
• FIPS 140-1 and FIPS 140-2 define the security
  requirements for cryptographic modules.
• Energys Program Cyber Security Plan (PCSP)
  require that Energy employees authentication
  methods be compliant with FIPS 140-2 for systems
  that authenticate using a cryptographic module.
• The current Energy Entrust server components are
  validated at FIPS 140-2.
• Entrust Desktop Solutions (EDS) is the current
  Energy Entrust desktop software client and it is
  validated at FIPS 140-1.
• Entrust Security Provider (ESP) is a new Entrust
  desktop software client that will be rolled-out
  in the next 6 months. ESP is validated at FIPS
  140-2.

24
Entrust Certification Authorities

• Today there are multiple points where Trust is
  established.
• \

25
Entrust Certification Authorities

• Optional consolidation to one East/West PKI

26
Out-of-the-box Message Security

• How to we protect data as it travels over an
  untrusted network?
• Symmetric Key Cryptography single unique key
  used to encrypt decrypt
• Unique message keys are encrypted using
  device-unique master encryption key
• Encryption/decryption processes are fast
  invisible to the customer
• Data is encrypted between the BES device while
  it traverses the wireless network
• How do we protect data from its point of origin
  all the way to its destination?
• How do we leverage the departments Entrust PKI
  to enhance message security?

27
S/MIME Message Security

• Asymmetric Key Cryptography pair of unique keys
  are used to encrypt decrypt
• A public key is use to encrypt data that only the
  corresponding private key can decrypt
• Additional advantage of supporting Digital
  Signatures
• Encryption/decryption processes are slower and
  require customer interaction
• End-to-end encryption solution. Data is encrypted
  from point of origin all the way to the
  destination

28
Why did EITS implement S/MIME on BlackBerry?

• 12,000 EITS-managed Entrust subscribers were
  already sending and receiving Entrust-encrypted
  email at the desktop.
• BlackBerry use is increasing.
• There was a need to provide tools for wireless
  devices because DOE directives require certain
  types of data to be encrypted while at rest and
  in-transit

29
Services

• Service hours
• GTN MWF 9am-11am TTh 2pm-4pm
• FORS MWF 9am-11am
• Requirements to get account
• If registered in ID Mgmt have DOE email
  account, can pickup Entrust account and token
• Support 250 Registration Authorities and Trusted
  Agents (50sites)
• Platinum customers receive desk-side visit
• If emergency, customer should call Help Desk
• Site RAs issue local accounts
• A notary is used for identification of person not
  located near a site

30
DOE Locations Using PKI (2009)
31
Two-Factor Authentication
32
Two-Factor Authentication

• RSA tokens are used to positively identify users
  before they interact with mission-critical data
  and applications
• Benefits
• Reduces dependence on reusable passwords that can
  be written down, logically stored, forgotten, and
  susceptible to brute force password attacks.
• Provides positive identification of an
  individual
• EITS issues authentication tokens using the same
  DOE, Federal PKI and NIST requirements used to
  issue Entrust accounts.
• Only that individual ever knows the secret PIN
  associated with their particular authentication
  token.

33
Two-Factor Authentication

• Today there are multiple points where Identity
  is established.

34
Two-Factor Authentication

• Optional consolidation to one East/West RSA
  Solution

35
Two-Factor Authentication

• Expanding how we use RSA
• Integrate with Applications that support
  two-factor authentication
• Establish trust-relationships with other RSA
  implementations
• Incorporate into the Desktop Operating System and
  Active Directory

36
Full Disk Encryption
37
Full Disk Encryption

• OMB M-06-16 says we will encrypt all data on
  mobile computers which contain agency data.
• Foreign travel laptops and loaner laptops that
  leave the facility are currently being encrypted.
• EITS Offering
• SafeBoot
• Scalable Enterprise Solution
• Configuring the software to ensure
• Performance during encryption and decryption is
  minimal
• Master Root Keys stored properly
• Key Recovery handled is handled appropriately
• Working with vendors to leverage existing
  security products for authentication (Entrust,
  RSA, Smartcards)

38
The Future

• Establish an active, more encompassing Department
  PMA
• Establish automatic enrollment process
• Move to web-based training for system role
  holders and subscribers
• Provide an enhanced, more informational website
• Complete annual audits
• Remediate deficiencies from previous audits