Presentation on theme: "Information Security Management Spring 2005 Presented by Ling Wang"— Presentation transcript:
1Information Security Management Spring 2005 Presented by Ling Wang Sample U.S. Government Cryptography and Key Management Methods and PoliciesInformation Security ManagementSpring 2005Presented by Ling Wang
3Direction of Government Cryptography & Key Management Policies Evolving, particularly for classified informationTrying to move from all expensive custom equipment to leverage off COTS products and standards where feasibleTrying to move from point to point encrypted links to more modern and dynamic environments (e.g. SecureXML)Complicated by new types of foreign military coalitionsComplicated by new types of domestic “coalitions” (local law enforcement, fire departments., etc.) in homeland security
4Status of Government Cryptography & Key Management Policies Changes still being madeRecent “roadmaps” are being changedMajor problems still unsolved, especially for coalitionsPatriot Act supposedly removed the “coalition” data sharing issue between FBI law enforcement and intelligenceBut lots of very expensive old crypto gear is still used by military and intelligence (legacy problem)
5CAVEATThis 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 deploymentsBut a most of is still currently in use in placesWhen you start your federal job, find out what is in place for your organization
6DoD/NSA Approved Cryptography - 1. Certified Components & Policies An NSA-approved cryptography consists of 3 certified components:An approved algorithmAn implementation that as been approved for the protection of classified information in a particular environment; nearly always a dedicated deviceA supporting key management infrastructurePlus: Appropriate Cryptography Policies!!!
7DoD/NSA Approved Cryptography - 2. Background Documents Privacy Act (1974): requires government to safeguard personal data on government systemsDoD Directive C (1982) (revised 1990) defined basic crypto for classified dataNational 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.
8DoD/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.
9DoD/NSA Approved Cryptography - 4. Four (4) Encryption Levels Type 1 - U.S. ClassifiedType 2 - U.S. Federal Inter-AgencyFor Sensitive but Unclassified (SBU) government communications; “Warner Amendment” unclassified dataType 3 - Interoperable Inter-Agency (Federal, State and Local) & Commercial UseNIST-approved data encryption standards (DES, AES, etc.)Type 4 - ProprietaryNot a federal standard, not used for federal infoExportable, for Commercial & International useNSA is responsible for Type I, II; NIST for Type III standards
10DoD/NSA Approved Cryptography - 5. Type I devices AlgorithmsLast 2 decades: Baton (crypto), Skipjack (crypto), Firefly (Key exchange) originally classified; now declassifiedSince 2003, AES is also allowed128 bit and higher for Secret192 bit and higher for TS and aboveKeysTrue random numbers neededGeneration based on physical phenomenaHistoric: centrally generated and tested by NSADifficult distribution problemNow used for special purpose keysSession keys generated by NSA approved embedded hardware (e. g.,leaky resistor for random noise generation)
11DoD/NSA Approved Cryptography - 6. Type I devices (continued) Hardware design approved by NSAUsually a separate hardware device (box, card) is requiredCareful attention to “red-black” separationOrange Book B2 equivalent or betterCheck for covert channels, “sneak circuits”Check for cross-talk (EMSEC)Failure modes cannot allow for red to black link to open
12DoD/NSA Approved Cryptography - 7. Sample Type I devices Historic: link encryptors; e. g. KG-84, KG-192, KIV…Still lots in useNew technology used to emulate old devices for compatibilityRecentKG 175 Taclane “classic” IP (7 Mb/sec) and ATMKG 75 Fastlane Asynchronous Transfer Mode (ATM) virtual circuit encryptorKG 189 SONET backbone encryptorSTE encrypting phoneCurrent and projectedHigh Assurance IP Encryption (HAIPE) programMultiple products now and in developmentNSA adaptation of IPSEC protocol for session setup, mutual authentication, key exchange, and headers
13DoD/NSA Approved Cryptography - 8. 2003 Type I High Speed Products
14Secure Terminal Equipment (STE) Key materials on Fortezza Smart Card/Crypto EngineApproved for Classified usePhone not classified when card is removed
15DoD/NSA Approved Cryptography - 9. Classification & Crypto Usage User IdentificationUser TokenAlgorithms2 (Basic)Not in personSoftwareType 23 (Medium)In person4 (High)Hardware(SmartCards/ Fortezza)5 (Classified)(STE Fortezza Plus card )Type 1
16DoD/NSA Approved Cryptography - 10. Cryptography Usage Policies For Encryption: key & device must have classification & assurance level not lower than contents encryptedFor Key Management: key issuer must have classification & assurance level not lower than key user; issuer may invalidate keysFor PKI: PKI & CA must have classification & assurance level not lower than certificates it issuesTwo communication endpoints must have same classification & assurance level
17DoD/NSA Approved Cryptography - 11. Government AES Usage Policy NIST/FIPS approved for protecting sensitive (SBU) electronic dataReviewed & analyzed by NSA for classified dataAlgorithm allowed for classified, unclassified, & commercial useCrypto device needs NSA approval for classifiedGovernment agencies may send system specification to NSA for an NSA-developed implementationNSA approves AES for classified info:128-bit key & above are suitable for SECRET infoTOP SECRET info requires 192 or 256 bits
18Key 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 classificationKeys are handled the same as any other information at that levelIdentify and labelsAccess control, with storage in approved containersInventoryPossible compromises reported to ISSOApproved destructionWhen 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.
19Key Management - 2. Key Transfer Key material:Paper (not used any more)Physical data storage examplesDS 101 Fill DeviceCIK--Crypto Ignition KeyFortezza PCMCIA cardOTAR (Over the Air Rekeying)Sending new keys to a remote device over the communications link (keys are encrypted) & automatically loading the crypto devices
20High Grade Electronic Applications KMI/PKI TodayNSAOperationsDISACurrent DoD Class 3 PKIRootX.509 CertificateBased ApplicationsCurrent Class 4 PKI(DMS)CommercialClass 3 and below PKIPhysicalManualSystemsKMI PRSN PilotHigh Grade Electronic ApplicationsEKMS
21DoD PKI Roadmap 2000 - 1. Overview Part of DoD Key Management Infrastructure (KMI)being a Critical Defense in Depth (DoD multi-layer defense system) LayerA framework for generation, production, distribution, control, revocation, recovery, & tracking of public keys (certificates) & their corresponding private keysUses CAW & Fortezza® cards for a X.509-based PKISpecially designed to suit DoD needs, maintained by DoDHas a modular design, conforms to federal standards, being an integral component of DoD KMI, focuses on a single (Class 4) assurance level, evolves in phasesImplemented 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)
22DoD PKI Roadmap 2000 - 2. PKI System Context in DoD
27DoD 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.
29Certificate Authority Workstation (CAW) & Fortezza® Cards CAW is a trusted hardware platform used to create certificates & place X.509 certificates on Fortezza® cardsCAW is operated by a certificate authoring teamCertificate Authority (CA): certification workSystem Security Officer/System Administrator (ISSO/SA): hardware operatorFortezza® cards are tamper-resistant PCMCIA-compliant devices (“portable hardware tokens”) used to store DoD-issued X.509 certificates & private keys, trademarked by NSA
30Fortezza® Cards PCMCIA (“card bus”)-compliant hardware Implements NSA/NIST-compliant crypto standards for network securityUsed by DoD organizations & individuals“tamper-resistant” = destroy key on malicious attempts
31Fortezza® 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 PINClassified 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 PINSecurity breaches & policy violations associated with a Fortezza® card must be reportedE.g. card loss/misuse/tampering/duplication, PIN compromise, user info changes/user leaves, certificate misuse, unattended terminals, etc.
32user must sign & return the User Advisory Statement (UAS) within (up to) 60 days of delivery or the certificate will be considered compromised
33X. 509 Certificate Policy for the U. S X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework3 certificate policies for different entities:Users w/ software crypto modules (class 2/3)Users w/ hardware crypto modules (class 4/5)Policy for devicesMandates 2048-bit RSA or 224-bit elliptic curves & SHA-224 or SHA-256 hashingConsistent 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 / DoDIncludes a guideline for operational security (physical / procedural / personnel) & technical security controlsUsed in the civilian side of the government
34ReferencesPublic Key Infrastructure Roadmap for the Department of Defense, Version 5.0, 18 December 2000X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework, Version 2.2, 29 March 2005The Certificate Authority Workstation white paperCNSS15FS – 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 2003DoD Public Key Infrastructure Tutorial