Sample U.S. Government Cryptography and Key Management Methods
and Policies Information Security Management Spring 2005 Presented
by Ling Wang Slide 2 Presentation Agenda Crypto & Key
Management Overview Evolving Direction Current Status Caveat
DoD/NSA Cryptography Policy DoD/NSA Approved Cryptography DoD PKI
Roadmap 2000 CAW & Fortezza Card Usage Policy X.509 Certificate
Policy for Federal PKI Slide 3 Direction of Government Cryptography
& Key Management Policies Evolving, particularly for classified
information Trying to move from all expensive custom equipment to
leverage off COTS products and standards where feasible Trying to
move from point to point encrypted links to more modern and dynamic
environments (e.g. SecureXML) Complicated by new types of foreign
military coalitions Complicated by new types of domestic coalitions
(local law enforcement, fire departments., etc.) in homeland
security Slide 4 Status of Government Cryptography & Key
Management Policies Changes still being made Recent roadmaps are
being changed Major problems still unsolved, especially for
coalitions Patriot Act supposedly removed the coalition data
sharing issue between FBI law enforcement and intelligence But lots
of very expensive old crypto gear is still used by military and
intelligence (legacy problem) Slide 5 CAVEAT This talk has the most
recent information released on the web (and even pre-web info) Some
of it is already out of date for new deployments But a most of is
still currently in use in places When you start your federal job,
find out what is in place for your organization Slide 6 DoD/NSA
Approved Cryptography - 1. Certified Components & Policies An
NSA-approved cryptography consists of 3 certified components: An
approved algorithm An implementation that as been approved for the
protection of classified information in a particular environment;
nearly always a dedicated device A supporting key management
infrastructure Plus: Appropriate Cryptography Policies!!! Slide 7
DoD/NSA Approved Cryptography - 2. Background Documents Privacy Act
(1974): requires government to safeguard personal data on
government systems DoD Directive C-5200.5 (1982) (revised 1990)
defined basic crypto for classified data National Security Decision
Directive 145 (1984):Mandates protection of both classified and
sensitive (SBU) data. Guidance to come from NSA. (Revised by NSD
42, 1996) OMB Circular A-130 (1985) Management of Federal
Information Resources: All federal IT systems required to provide a
level of security against unauthorized access, commensurate with
sensitivity, risk, and harm that could result from such access.
Slide 8 DoD/NSA Approved Cryptography - 3. Background Documents
(continued) Computer Security Act of 1987 (1988): updates the
Privacy Act of 1974. Standards and guidance for non Warner
Amendment unclassified intelligence related data to come from NIST
(then called the National Bureau of Standards) National Security
Directive 42 (1990): Limits NSA involvement to classified and
Warner Amendment unclassified data Note that these relate primarily
to confidentiality. NSA, DoD, NIST all have policies based on these
and other basic laws/directives. Slide 9 DoD/NSA Approved
Cryptography - 4. Four (4) Encryption Levels Type 1 - U.S.
Classified Type 2 - U.S. Federal Inter-Agency For Sensitive but
Unclassified (SBU) government communications; Warner Amendment
unclassified data Type 3 - Interoperable Inter-Agency (Federal,
State and Local) & Commercial Use NIST-approved data encryption
standards (DES, AES, etc.) Type 4 - Proprietary Not a federal
standard, not used for federal info Exportable, for Commercial
& International use NSA is responsible for Type I, II; NIST for
Type III standards Slide 10 DoD/NSA Approved Cryptography - 5. Type
I devices Algorithms Last 2 decades: Baton (crypto), Skipjack
(crypto), Firefly (Key exchange) originally classified; now
declassified Since 2003, AES is also allowed 128 bit and higher for
Secret 192 bit and higher for TS and above Keys True random numbers
needed Generation based on physical phenomena Historic: centrally
generated and tested by NSA Difficult distribution problem Now used
for special purpose keys Session keys generated by NSA approved
embedded hardware (e. g.,leaky resistor for random noise
generation) Slide 11 DoD/NSA Approved Cryptography - 6. Type I
devices (continued) Hardware design approved by NSA Usually a
separate hardware device (box, card) is required Careful attention
to red-black separation Orange Book B2 equivalent or better Check
for covert channels, sneak circuits Check for cross-talk (EMSEC)
Failure modes cannot allow for red to black link to open Slide 12
DoD/NSA Approved Cryptography - 7. Sample Type I devices Historic:
link encryptors; e. g. KG-84, KG-192, KIV Still lots in use New
technology used to emulate old devices for compatibility Recent KG
175 Taclane classic IP (7 Mb/sec) and ATM KG 75 Fastlane
Asynchronous Transfer Mode (ATM) virtual circuit encryptor KG 189
SONET backbone encryptor STE encrypting phone Current and projected
High Assurance IP Encryption (HAIPE) program Multiple products now
and in development NSA adaptation of IPSEC protocol for session
setup, mutual authentication, key exchange, and headers Slide 13
DoD/NSA Approved Cryptography - 8. 2003 Type I High Speed Products
Slide 14 Secure Terminal Equipment (STE) Key materials on Fortezza
Smart Card/Crypto Engine Approved for Classified use Phone not
classified when card is removed Slide 15 DoD/NSA Approved
Cryptography - 9. Classification & Crypto Usage Class User
Identification User TokenAlgorithms 2 (Basic)Not in
personSoftwareType 2 3 (Medium)In personSoftwareType 2 4 (High)In
person Hardware (SmartCards/ Fortezza) Type 2 5 (Classified)In
person Hardware (STE Fortezza Plus card ) Type 1 Slide 16 DoD/NSA
Approved Cryptography - 10. Cryptography Usage Policies For
Encryption: key & device must have classification &
assurance level not lower than contents encrypted For Key
Management: key issuer must have classification & assurance
level not lower than key user; issuer may invalidate keys For PKI:
PKI & CA must have classification & assurance level not
lower than certificates it issues Two communication endpoints must
have same classification & assurance level Slide 17 DoD/NSA
Approved Cryptography - 11. Government AES Usage Policy NIST/FIPS
approved for protecting sensitive (SBU) electronic data Reviewed
& analyzed by NSA for classified data Algorithm allowed for
classified, unclassified, & commercial use Crypto device needs
NSA approval for classified Government agencies may send system
specification to NSA for an NSA-developed implementation NSA
approves AES for classified info: 128-bit key & above are
suitable for SECRET info TOP SECRET info requires 192 or 256 bits
Slide 18 Key Management - 1. Keys for Classified Information Keys
and key material (e. g., hardware tokens) have a classification
level (S, TS, SBU, etc.) Key classification level must be >=
information classification Keys are handled the same as any other
information at that level Identify and labels Access control, with
storage in approved containers Inventory Possible compromises
reported to ISSO Approved destruction When a secure communication
link is set up using PKI, endpoints make sure that the other end is
using a key of the right classification level. Slide 19 Key
Management - 2. Key Transfer Key material: Paper (not used any
more) Physical data storage examples DS 101 Fill Device CIK--Crypto
Ignition Key Fortezza PCMCIA card OTAR (Over the Air Rekeying)
Sending new keys to a remote device over the communications link
(keys are encrypted) & automatically loading the crypto devices
Slide 20 KMI/PKI Today NSA Commercial Class 3 and below PKI
Physical ManualSystems KMI PRSN Pilot High Grade Electronic
Applications EKMS Operations DISA Current DoD Class 3 PKI Root
X.509 Certificate Based Applications Current Class 4 PKI (DMS) Root
Slide 21 DoD PKI Roadmap 2000 - 1. Overview Part of DoD Key
Management Infrastructure (KMI) being a Critical Defense in Depth
(DoD multi-layer defense system) Layer A framework for generation,
production, distribution, control, revocation, recovery, &
tracking of public keys (certificates) & their corresponding
private keys Uses CAW & Fortezza cards for a X.509-based PKI
Specially designed to suit DoD needs, maintained by DoD Has a
modular design, conforms to federal standards, being an integral
component of DoD KMI, focuses on a single (Class 4) assurance
level, evolves in phases Implemented in phases: Existing: Class 3
PKI: Releases 1.0, 2.0, 3.0 (DoD PKI 1999) Underway: Class 4 PKI:
Releases 4.0, 5.0, 6.0 (DoD PKI 2000) Slide 22 DoD PKI Roadmap 2000
- 2. PKI System Context in DoD Slide 23 DoD PKI Roadmap 2000 - 3.
PKI System Elements Slide 24 DoD PKI Roadmap 2000 - 4. PKI
Functional Units (Elements) The Users: Subscribers (direct users)
& Relying Parties (indirect users) Uses the certificates
(encryption & signing) Registration (by Registration
Authorities, RAs) Binds user to public key pair Level of trust
determined by level of info verification Certificate Management (by
Certificate Authorities, CAs; hierarchical & centralized)
generate, produce, distribute, control, track & destroy
public/private key pairs & associated PK certificates Slide 25
DoD PKI Roadmap 2000 - 5. DoD PKI Architecture Slide 26 DoD PKI
Roadmap 2000 - 6. DoD PKI Deployment Slide 27 DoD PKI Roadmap 2000
- 7. DoD PKI Risk Management Funding/Resources (managed by NSA/DISA
& relevant agencies) Scheduling (uses project management
strategies) Application Development Risks (availability &
interoperability of PKI implementations) Technical Risks (managed
by technical strategies) Scalability, interoperability,
transparency, security. Directories, transition, support for
tactical operations, support to OCONUS/Theater Operations,
communication capabilities, etc. Slide 28 DoD PKI Roadmap 2000 - 8.
DoD PKI Roles DOD PKI Web-Based Cert Auth (CA) DOD Directory
Services LRA User 1 User Registration Web-based 2 Password Relying
Party Local Registration Authority 5 Pull Cert 4 Auto Cert Private
Key 3 Web-based Public Key Cert Slide 29 Certificate Authority
Workstation (CAW) & Fortezza Cards CAW is a trusted hardware
platform used to create certificates & place X.509 certificates
on Fortezza cards CAW is operated by a certificate authoring team
Certificate Authority (CA): certification work System Security
Officer/System Administrator (ISSO/SA): hardware operator Fortezza
cards are tamper-resistant PCMCIA- compliant devices (portable
hardware tokens) used to store DoD-issued X.509 certificates &
private keys, trademarked by NSA Slide 30 Fortezza Cards PCMCIA
(card bus)-compliant hardware Implements NSA/NIST-compliant crypto
standards for network security Used by DoD organizations &
individuals tamper-resistant = destroy key on malicious attempts
Slide 31 Fortezza Card Usage Policies Classifications &
Labeling: SECRET Classified: Fortezza for Classified (FFC) [Red
label] Unclassified: Sensitive but Unclassified (SBU) [White label]
PIN-protected: Unclassified when locked with owners PIN Classified
as same level as its highest-level certificate (if multiple
certificates present) 3 consecutive failed PIN checks disables
card; only CAW can re-enable card and/or change PIN Security
breaches & policy violations associated with a Fortezza card
must be reported E.g. card loss/misuse/tampering/duplication, PIN
compromise, user info changes/user leaves, certificate misuse,
unattended terminals, etc. Slide 32 user must sign & return the
User Advisory Statement (UAS) within (up to) 60 days of delivery or
the certificate will be considered compromised Slide 33 X.509
Certificate Policy for the U.S. Federal PKI Common Policy Framework
3 certificate policies for different entities: Users w/ software
crypto modules (class 2/3) Users w/ hardware crypto modules (class
4/5) Policy for devices Mandates 2048-bit RSA or 224-bit elliptic
curves & SHA-224 or SHA-256 hashing Consistent with RFC-2527
X.509 certificate format, with only the certificate management
policies, identity verification methods, various certificate field
formats (unique name formats, revocation list formats, etc.), and
key archival policies being specified for usage in governmental
programs / DoD Includes a guideline for operational security
(physical / procedural / personnel) & technical security
controls Used in the civilian side of the government Slide 34
References Public Key Infrastructure Roadmap for the Department of
Defense, Version 5.0, 18 December 2000 X.509 Certificate Policy for
the U.S. Federal PKI Common Policy Framework, Version 2.2, 29 March
2005 The Certificate Authority Workstation white paper CNSS15FS
CNSS Policy No. 15, Fact Sheet No. 1, National Policy on the Use of
the Advanced Encryption Standard (AES) to Protect National Security
Systems and National Security Information, June 2003 DoD Public Key
Infrastructure Tutorial
http://www.e-publishing.af.mil/contentmgmt/PKI%20Tutorial.ppt
