1. Information Security Management Spring 2005 Presented by Ling Wang
Sample U.S. Government Cryptography and Key Management Methods and Policies
Information Security Management
Spring 2005
Presented by Ling Wang

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

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

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)

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

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

7. DoD/NSA Approved Cryptography - 2. Background Documents
Privacy Act (1974): requires government to safeguard personal data on government systems
DoD Directive C (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.

8. DoD/NSA Approved Cryptography - 3. Background Documents (continued)
Computer Security Act of 1987 (1988): updates the Privacy Act of 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.

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

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)

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

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

13. DoD/NSA Approved Cryptography - 8. 2003 Type I High Speed Products

14. Secure Terminal Equipment (STE)
Key materials on Fortezza Smart Card/Crypto Engine
Approved for Classified use
Phone not classified when card is removed

15. DoD/NSA Approved Cryptography - 9. Classification & Crypto Usage
User Identification
User Token
Algorithms
2 (Basic)
Not in person
Software
Type 2
3 (Medium)
In person
4 (High)
Hardware
(SmartCards/ Fortezza)
5 (Classified)
(STE Fortezza Plus card )
Type 1

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

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

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.

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

20. High Grade Electronic Applications
KMI/PKI Today
NSA
Operations
DISA
Current DoD Class 3 PKI
Root
X.509 Certificate
Based Applications
Current Class 4 PKI
(DMS)
Commercial
Class 3 and below PKI
Physical
Manual
Systems
KMI PRSN Pilot
High Grade Electronic Applications
EKMS

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)

22. DoD PKI Roadmap 2000 - 2. PKI System Context in DoD

23. DoD PKI Roadmap 2000 - 3. PKI System Elements

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

25. DoD PKI Roadmap 2000 - 5. DoD PKI Architecture

26. DoD PKI Roadmap 2000 - 6. DoD PKI Deployment

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.

28. DoD PKI Roadmap 2000 - 8. DoD PKI Roles1
User Registration
Web-based
Local Registration Authority
LRA
Web-Based
Cert Auth (CA)
Private
Key 3
Web-based
Public
Cert 2
Password 4
Auto
Cert 5
Pull
Cert
DOD
Directory
Services
User
Relying
Party
DOD PKI

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

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

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 owner’s 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.

32. user must sign & return the User Advisory Statement (UAS) within (up to) 60 days of delivery or the certificate will be considered compromised

33. X. 509 Certificate Policy for the U. S
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

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