FIPS Compliance of Industry Protocols in Edward Morris September 25, 2013

Transcription

1 FIPS Compliance of Industry Protocols in 2014 Edward Morris September 25, 2013

2 Topics Background DES SP SP The Protocols Recommendations 2 International Cryptographic Module Conference 2013

3 Background Security Strength of Cryptographic Algorithms Provides a measure of the amount of work needed to break the algorithm or determine the key Reflects the most efficient known attack which either incorporate known weaknesses (e.g., two & three key TDES) or resorts to an exhaustive or brute force (e.g., AES) attack. Allows comparison of disparate algorithms Strength of symmetric algs = key size (absent vulnerabilities) Strength of asymmetric algs much lower than the nominal key size Expressed as X bits of security time required is equivalent to 2 X-1 operations (of the algorithm) 3 International Cryptographic Module Conference 2013

4 Strengths of Some Algorithms Bits of security Symmetric key algs FFC (e.g, DSA, DH) 56 DES L = 512 N = TDEA, SKIPJACK L = 1024 N = TDEA L = 2048 N = AES-128 L = 3072 N = AES-192 L = 7680 N = AES-256 L = N = 512 IFC (e.g, RSA) ECC (e.g., ECDSA) k = 512 f = k = 1024 f = k = 2048 f = k = 3072 f = k = 7680 f = k = f = International Cryptographic Module Conference 2013

5 DES (or No More DES) DES withdrawn on May 19, 2005 (Federal Register vol 70, number 96) Not only DES, but NIST withdrew algorithms providing only less than 80-bits of security DSA, DH, and RSA algorithms using key sizes smaller than 1024-bits A DES Transition Plan provided to allow Federal Agencies and vendors to smoothly transition to AES and Triple-DES Two year transition allowed "transitional phase only - valid until May 19, 2007" use of DES. Vendor's faced potential challenges for validations submitted prior to May 19, 2007 (but potentially reviewed after that date) NIST actively working on SP to provide further clarification to future transitions. 5 International Cryptographic Module Conference 2013

6 NIST SP Recommendation for Key Management Three parts with the first published in August, 2005 Part 1: general guidance and best practices Part 2: guidance on policy and security planning requirements Part 3: guidance on configuration and use of industry protocols Part 1 contains Table 2: Comparable Strengths (found on page 64 of 147 of the PDF) seen in slide 4 of this presentation. Part 3 released in December, 2009 Allowed algorithms with 80-bits security through 2010, and Required algorithms with 112-bit security from 2011 to International Cryptographic Module Conference 2013

7 2011 Drawing Near While the DES Transition was fairly smooth for the most post, it was clear becoming clear that neither government nor industry was well positioned for the transition to 112- bits of security Established, widely deployed industry protocols presented problems Lack of standards (existence and adoption) Lack of available Approved products Sheer size of government deployments affected More time was needed, so NIST developed SP , the transition plan for transition to 112-bit. 7 International Cryptographic Module Conference 2013

8 NIST SP x Effectively a transition plan, released in January 2011 SP A provided more detail of the transitions, terminology, and dates To simplify, it allows deprecated use of 80-bit crypto through 2013 or 2015 depending upon the type of algorithm Allowed 80-bit signature, signature hashing, and key agreement/transport through 2013 Allowed 80-bit encryption*, key wrap, and legacy RNGs through Specifics for a given algorithm require careful consideration of the algorithm and its use. 8 International Cryptographic Module Conference 2013

9 NIST SP x SP A referenced SP B, which while released in draft form, ultimately became IG G.14. Though comprehensive, one cannot easily apply SP A to a common protocol For example, "SP A and SP DH and MQV schemes using finite fields" are acceptable in 2014 provided that " p = 2048 bits, and q = 224 or 256 bits" requires review of SP to conclude that say TLS, IPSec, SSH, and others may be acceptable come 2014 (provided that the correct protocol options are utilized). 9 International Cryptographic Module Conference 2013

10 The Protocols Internet Protocol Security (IPsec) Transport Layer Security (TLS) Secure Shell (SSH) Others 10 International Cryptographic Module Conference 2013

11 Internet Protocol Security (IPsec) Detailed in SP Part 3, which provides guidance including guidance regarding 112-bit strength Condensed configuration for FIPS compliance in 2014 ESP Encryption: AES in CBC mode ESP Integrity Protection: HMAC-SHA1 IKEv2 Encryption: AES in CBC mode IKEv2 Pseudo-random function: HMAC-SHA1 IKEv2 Diffie-Hellman group: 2048-bit MODP IKEv2 Integrity: HMAC-SHA1 IKEv2 Peer Authentication: 2048-bit RSA with SHA International Cryptographic Module Conference 2013

12 Transport Layer Security (TLS) Also detailed in SP Part 3, which again provides guidance including guidance regarding 112-bit strength All versions of TLS (1.0, 1.1, and 1.2), if appropriately configured, can provide 112-bits of security. To configure appropriately: Choose an appropriate set of cipher suites from the lists provided in SP Part3 Ensure that server (and client if present) certificates use avoid using SHA-1 and RSA keys smaller than 2048-bits Use appropriately sized Pre-shared Keys (PSK >= 112-bits) with PSK cipher suites. 12 International Cryptographic Module Conference 2013

13 Secure Shell (SSH) A future version of SP Part 3 may cover SSH, but does not currently provide detail. Only SSHv2 can be used (known vulnerabilities in v1). Transport Layer Protocol Example Configuration: Ciphers: 3des-cbc (required) & aes128-cbc (recommended) MACs: hmac-sha1(required) & hmac-sha1-96 (recommended) Key Exchange: diffie-hellman-group14-sha1 (required) but exclude diffie-hellman-group1-sha1 (required by RFC) Public Key: very tricky, ecdsa-sha2-nistp256 (or similar) and exclude RPC required options. 13 International Cryptographic Module Conference 2013

14 Other Protocols SP Part 3 provides guidance for other protocols: Public Key Infrastructures (PKI) Secure/Multipurpose Internet Mail Extensions (S/MIME) Kerberos Over-the-Air Rekeying of Digital Radios (OTAR) Domain Name System Security Extensions (DNSSEC) Encrypted File Systems (EFS) Conflict with other standards (Common Criteria PPs) Still many protocols not covered (e.g., SSL VPNs, i, etc.) 14 International Cryptographic Module Conference 2013

15 Challenges Conforming may break compatibility with standards (SSH in particular), break interoperability (if newer, optional cipher suites are required) with existing implementations, and prevent receipt of information from non-government sources Certificate chains (SHA-1 or MD5 used in the chain) Integration of other requirements (CC PPs, Suite B, UC APL) 15 International Cryptographic Module Conference 2013

16 Recommendations Agencies can look to their vendors or to system administrators to attempt configuring existing systems for compliance. Product vendors utilizing open source or drop in packages can check if they support 112-bit security (or whether a newer version does) Consider an independent review Gossamer has configuration guides for common packages (Apache, OpenSSH, Openswan, etc) Upgrade your random number generators before 2016! 16 International Cryptographic Module Conference 2013

17 Questions? Contacts: Ed Morris 17 International Cryptographic Module Conference 2013