Welcome to the Acumen Security Blog

Archives for August 2016

Welcome Aboard!

At Acumen, are always looking for ways to improve both our customer experience and our testing. In addition to tooling, infrastructure, and training investments, we truly believe the best way to build a world class lab is to bring on the right people. I think we’ve done a great job of bringing not only excellent engineers but excellent people on board. Today is not exception, I am proud and pleased to announce the latest member of the Acumen family, Ryan Thomas.
Many of you may recognize Ryan’s name from his many years leading a FIPS lab, the many crypto related working group he’s a member of, or the conferences he is always at. Both Ashit and I have had the opportunity to work with Ryan both at Acumen and in our previously jobs at Cisco. It is an understatement to say that our experiences with Ryan were nothing but excellent. Ryan truly embodies the Acumen philosophy of putting the customers first and foremost in every interaction. This combined with his excellent technical grasp is why we are so excited to have him join Acumen.
So, if you have a call with us over the next couple weeks, you will likely hear Ryan on the bridge as well. True to form, Ryan is already overly eager to start jumping in and producing. Please say “Hi” if he’s on a call or email chain. Just like Ashit and I (and all of us here at Acumen really), he loves to chat and would love to help you navigate the certification process.
Welcome aboard Ryan, today Acumen is better than yesterday!

Two Different Takes on SSH

As we described in a previous blog entry, NIAP is attempting to standardize the requirements for SSH by creating an SSH EP that can be added to many different PP types. This should keep the requirements for SSH consistent across more evaluations and make it easier to incorporate updates to the standard into CC requirements. Unfortunately, the international nature of the NDcPP means that it cannot use a NIAP EP. We will take a look at some of the similarities and differences between these two sets of SSH requirements and hopefully provide some useful guidance to vendors who may be certifying multiple products with a common SSH implementation in the future.

Many of the differences between the SSH EP and the NDcPP are purely semantic. The EP contains a single FCS_SSH_EXT requirement and then a number of SSHC or SSHS requirements whose use is selection based. NDcPP on the other hand doesn’t have any FCS_SSH_EXT SFRs and puts everything into the server and client SFRs. In some other areas the SSH EP and the NDcPP currently differ, but the requirements will become more consistent in the next planned update of the NDcPP. One such requirement is FCS_SSHC/SSHS_EXT.1.2 in the cPP and FCS_SSHC/SSHS_EXT.1 in the EP. Right now the EP requires a TOE to use public-key based authentication but makes password-based authentication optional. The current version of the NDcPP requires both forms of authentication to be supported, but the most recent draft of NDcPP v1.1 will make password-based authentication optional.

Another area where the NDcPP and SSH EP currently differ is in the rekeying requirements in FCS_SSHC/SSHS_EXT.1.7 in the EP and FCS_SSHC/SSHS_EXT.1.8 in the cPP. The SSH EP allows vendors to select between packet limits, data limits and time limits when enforcing rekeying requirements while the current NDcPP requires TOEs to rekey after a certain number of packets have been transmitted. The updated NDcPP is planning to do away with the packet limit but will require TOEs to enforce limits based on both time and amount of data transmitted. This means that TOEs which conform to either version of the NDcPP will meet the SSH EP’s requirements in this area, but EP compliance will not guarantee compliance with the cPP.

The encryption algorithms required by the different PPs are different and will not be aligned after NDcPP v1.1 is released, however they will be similar and make compliance easier. The current NDcPP requires the use of AES in CBC mode while GCM is an optional selection. The SSH EP makes CTR mandatory (as our previous blog entry discussed this was intended to bring CC in line with FIPS an DoD UC APL standards) while CBC and GCM are optional. The current draft of NDcPP v1.1 will mandate AES but will allow a choice between CBC, CTR and GCM. The result of this will be that a product which meets SSH EP standards for this SFR will also meet NDcPP standards, but the reverse will not necessarily be true. All three CC standards require TOEs to reject SSH connections that are protected by non-AES encryption.

In most areas the requirements or SSH in the NDcPP and SSH EP are the same. This is good news for vendors who may be using a common SSH implementation in different products that they plan to certify against different PPs. There are a few differences though that could add challenges to a certification effort if they aren’t planned for in a shared SSH module. We hope that this will provide a useful summary of those differences for vendors who are considering how to implement SSH in future CC compliant products.