1 / 34

Sample U.S. Government Cryptography and Key Management Methods and Policies

Sample U.S. Government Cryptography and Key Management Methods and Policies. Information Security Management Spring 2005 Presented by Ling Wang. Presentation Agenda. Crypto & Key Management Overview Evolving Direction Current Status Caveat DoD/NSA Cryptography Policy

phaedra
Download Presentation

Sample U.S. Government Cryptography and Key Management Methods and Policies

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

  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.

  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

  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. NSA DISA Commercial Operations Root Root Current DoD Class 3 PKI EKMS Current Class 4 PKI (DMS) Class 3 and below PKI KMI PRSN Pilot Physical Manual Systems High Grade Electronic Applications X.509 Certificate Based Applications KMI/PKI Today

  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. User Registration Web-based 1 Key 2 4 Cert Password Public Key Web-based Auto 3 Cert Cert Pull Cert 5 Private Key DoD PKI Roadmap 2000 - 8. DoD PKI Roles Local Registration Authority Web-Based Cert Auth (CA) LRA 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. 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 http://www.e-publishing.af.mil/contentmgmt/PKI%20Tutorial.ppt

More Related