Welcome to the Acumen Security Blog

Archives for November 2015

SSH Tower of Babel

The world of government certification can be quite confusing, with many different sets of requirements and schemes depending on how a vendor chooses to position their product to sell to Federal customers at home or abroad. Sometimes, those requirements can even be contradictory, which is why taking into consideration up front any certifications you foresee a need to submit your product for can pay dividends and help avoid having to take a step back in the future.

One such place where contradictory requirements can rear their ugly head and become a frustrating reality is with the ubiquitous SSH protocol. Practically any device which supports remote administration is going to support SSH – it is the industry standard. Most SSH implementations, like the one from The OpenSSH Project, support numerous cipher suites to provide compatibility with various clients and servers. However, not all cipher suites are created equal, and not all product certifications take the same view of those cipher suites.

For instance, Common Criteria supports the use of AES-128-CBC and AES-256-CBC, as well as AES-128-GCM and AES-256-GCM for SSH. If your product needs to undergo a FIPS 140-2 evaluation, however, you can use AES-128-CBC, AES-256-CBC, AES-128-CTR, and AES-256-CTR. The IV generation scheme for AES-GCM within SSH is considered too fragile for FIPS 140 and may not be used at this time.

DISA (Defense Information Systems Agency) and JITC (Joint Interoperability Test Command), which administer the Unified Command Approved Product List (UC APL) and the Secure Technical Implementation Guidelines (STIG) generally require that FIPS-validated algorithms be used, with the caveat that CBC mode can’t be used, leaving CTR only.

  AES-CBC AES-CTR AES-GCM
UC APL X
FIPS X X
Common Criteria X X

 

In short, one cannot be simultaneously be compliant with Common Criteria, FIPS and UC APL.

Typically, this means having two modes of operation, one which is Common Criteria compliant for sale to civilian agencies in the US Federal government, and a “STIG Mode,” which configures a device to meet JITC standard to get on the UC APL for sale to the Department of Defense.

While there may be some reconciliation in the future which would allow one set of standards across all government certifications, that day isn’t yet (Note: there is hope in an SSH Common Criteria iTC that may possibly be used to bring SSH using AES-CTR to CC certifications), which is why it pays to take into account all three up front so that you can focus your development efforts and not spend time doing something that may need to be un-done later, extending the time it takes to get a product in front of the customer.

Upcoming crypto algorithm transitions: DH and ECDH as we know them might no longer be allowed

Acumen is at the annual FIPS lab managers’ meeting this week and has been involved in some interesting discussions about the direction of the FIPS program. One of the most interesting one and perhaps most materially impactful for our customers is the update to SP 800-131A currently in draft.

As you might recollect, SP 800-131A defined the key strength transitions from 80-bits to 112-bits of security strength. Now that we are beyond that transition deadline, NIST is looking at the next transition and in the process updating SP 800-131A. One of the key transition being proposed is to move away from DH and ECDH as identified in various RFCs to mandating compliance with SP 800-56A, SP 800-56B, and SP 800-56C. The proposed transition date is by end of 2017.

While it might seem this is some ways away, such a change has a potential to be extremely disruptive. While DH, ECDH, and RSA key wrapping (as defined in RFCs) is similar to SP 800-56A and SP 800-56B they are different enough such that a product implementing RFC based option will not be able to establish keys with a module implementing SP 800-56A/B! Moreover it will be quite difficult for a product to support both implementations without changes to the higher order protocols such as TLS, IKE, SSH that utilize these key establishment methods.

 
It is important that product vendors affected by this transition engage NIST immediately and discuss the ramifications as well as potential path forward. Acumen will be happy to facilitate these discussions.