Difference between revisions of "Suite B"

Latest revision as of 17:15, 10 November 2024

Full Title or Meme

A list of the cryptographic algorithms that are approved for use in the US Federal Government.

Replacements

CNSA version 2.0

• the “Commercial National Security Algorithm Suite 2.0” (CNSA 2.0) Cybersecurity Advisory (CSA)}. 2022-09
• The Quantum replacement public key algorithms are to be:
  • CYSTALS-Kyber
  • CYSTALS-Dilithium

CNSA version 1.0

In 2015 the NSA abruptly replaced "Suite B" with a "CNSA Suite", saying that "the growth of elliptic curve use has bumped up against the fact of continued progress in the research on Quantum Computing Threat, which has made it clear that Elliptic Curve Cryptography is not the long term solution many once hoped it would be." This gave rise to much speculation on possible motives for the switch. In January, NSA published a long list of FAQs that discussed those motives in detail, and called for an effort to standardize quantum-resistant cryptographic algorithms. Earlier this month, NIST published a Report on Post-Quantum Cryptography that announces such a standardization effort.

I have written a blog post summarizing last summer's announcement and the FAQs, with links to all the documents.

The FAQs make sense, but do not explain one detail: why DSA has been omitted from the CNSA Suite. In the blog post I argue that DSA is being dropped at the wrong time. Another omission in the CNSA Suite is the requirement to provide forward secrecy in key establishment that was present in Suite B. Surprisingly, this comes at a time when forward secrecy is becoming the norm on the web.

Francisco Corella, PhD
Phone: +1.619.770.6765
Email: fcorella@pomcor.com
Twitter: @fcorella
Blog: https://pomcor.com/blog/
Web site: https://pomcor.com

Solutions

MSFT Suite B Support

An important feature of CNG is its support for the Suite B algorithms. In February of 2005, the National Security Agency (NSA) of the United States announced a coordinated set of symmetric encryption, asymmetric secret agreement (also known as key exchange), digital signature and hash functions for future U.S. government use called Suite B. The NSA has announced that certified Suite B implementations can and will be used for the protection of information designated as Top Secret, Secret, and private information that, in the past was described as Sensitive-But-Unclassified. Because of this, Suite B support is very important to application software vendors and system integrators as well as to Microsoft.

All Suite B algorithms are publicly known. They have been developed outside the scope of the government secrecy historically associated with cryptographic algorithm development. In this same time frame, some European countries and regions have also proposed the same Suite B requirements for protecting their information.

Suite B cryptography recommends use of elliptic curve Diffie-Hellman (ECDH) in many existing protocols such as the Internet Key Exchange (IKE, mainly used in IPsec), transport layer security (TLS), and Secure MIME (S/MIME).

CNG includes support for Suite B that extends to all required algorithms: AES (all key sizes), the SHA-2 family (SHA-256, SHA-384 and SHA-512) of hashing algorithms, ECDH, and elliptic curve DSA (ECDSA) over the NIST-standard prime curves P-256, P-384, and P-521. Binary curves, Koblitz curves, custom prime curves, and elliptic curve Menezes-Qu-Vanstone (ECMQV) are not supported by the Microsoft algorithm providers included with Windows Vista.

Auditing

To comply with some of the Common Criteria requirements in addition to providing comprehensive security, many actions that happen in the CNG layer are audited in the Microsoft software key storage provider (KSP). The Microsoft KSP adheres to the following guidelines to create audit records in the security log:

• Key import and export must be audited.
• Key destruction failures must be audited.
• Persistent keys need to be audited when they are written to and read from files.
• Pair-wise consistency check failures must be audited.
• Secret key validation failures, if any, must be audited, for example, parity checks on 3DES keys.
• Failures in encryption, decryption, hashing, signature, verification, key exchange, and random number generation must be audited.
• Cryptographic self-tests must be audited.

In general, if a key does not have a name, it is an ephemeral key. An ephemeral key does not persist, and the Microsoft KSP does not generate audit records for ephemeral keys. The Microsoft KSP generates audit records in user mode in the LSA process only. No audit record is generated by kernel mode CNG. Administrators need to configure the audit policy to obtain all KSP audit logs from the security log. An administrator must run the following command line to configure additional audits generated by KSPs:

References