Welcome to the Acumen Security Blog

RSA Key Generation and Common Criteria

Hi all! Does your application or HW product being considered for CC validation use the validated OpenSSL FOM for crypto? If so, you should pay close attention to a recent Technical Decision issued by NIAP (TD107). As many of you know, the open source validated version of the OpenSSL supports FIPS 186-2 Key Generation and not the more recent standard revision (FIPS 186-4). It is this functionality that the TD addresses. The following is an excerpt,

The referenced protection profiles (PPs) allow for the generation of asymmetric keys using RSA schemes that meet FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3. or ANSI X9.31-1998, Section 4.1.

Up until this point many of the Protection Profiles have allowed for FIPS 186-4 Key Generation or ANSI X9.31 Key Generation (with the caveat that the older PRNG listed in ANSI X9.31 is not used for randomness). This is allowance is included in several PPs which are commonly evaluated against, including, Application Software PP, Mobile Device PP, OS PP, VP Client PP, and VoIP PP.

The TD goes on to modify the Key Generation requirement, as follows,

Effective immediately, RSA schemes using ANSI X9.31-1998, Section 4.1 is no longer a valid selection. NIAP will not accept products into evaluation that claim RSA schemes that meet ANSI X9.31-1998 Section 4.1

While for typical network devices being evaluated against the NDcPP this has been a hard requirement for some time, this is essentially a new requirement for software applications planning to go through certification. It is no longer possible to use the stock validated OpenSSL FOM to meet the crypto requirements in the PPs listed above.

Now there are several lightweight modifications you can make to the OpenSSL FOM code bring it into conformance with FIPS 186-4, however, as you likely know it will invalidate the previous FIPS certification for the OpenSSL module. I anticipate that this will be a problem for vendors hoping to meet their FIPS validated cryptography requirements leveraging the embedded OpenSSL module and going against any of these PP.

Please do keep this in mind when considering your upcoming certification efforts. As always, if you have any questions please give me a call or send me an email. I love to talk 

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!