Welcome to the Acumen Security Blog

Pros and Cons of Using an Embedded FIPS-module

As more and more procurement requirements necessitate the use of FIPS validated cryptography, a popular strategy for meeting those requirements is to leverage an already existing validated cryptographic provider (and get all of the “FIPS-goodness” that comes with using validated modules). This strategy is particularly popular with large product vendors who have multiple product lines for which the level of effort to do a full validation for each product would be prohibitive. There are many benefits to this approach,

  • Time to market of a certified solution (weeks vs months/year)
  • Cost (order of magnitude less)
  • Level of Effort (changing libraries vs multiple bugs + coordinating with labs/gov’t)
  • Maintenance (small crypto boundary means fewer re-certs)
  • Scalability (reduces overall burden on engineering teams)

And the best part about it is it is explicitly allowed by the CMVP. In fact, FIPS 140-2 Implementation Guidance G.5 discusses the specifics about porting/using an already validated module within a product. With that being said, why wouldn’t all companies go and pick up the latest version of their favorite 3rd party module and call it a day? There are some potential draw backs to using an embedded module (meaning it’s not right for everyone), for example,

  • Coverage (some functionality the product needs may simply not be available to the module that works for on the system)
  • Relevance (some modules are not updated regularly and may only support deprecated versions of algorithms)
  • Maintenance (since the code doesn’t necessarily below to the product team, bug fixes may be slow)
  • Marketing (since it’s not the vendor’s product, their name doesn’t go on the list)

As can be seen from the above, developing a FIPS validation strategy for a company’s product(s) takes more consideration than just identifying where product gaps are and coding. If you’re interested in more info about the pros and cons of using an embedded FIPS-module, check out the slides I presented at ICMC this year or drop me an email or call me. I (seriously) like to talk, so, you’ll be doing me a favor 🙂

PS: Follow us on Twitter and like us on Facebook, we’ll keep you up-to-date on the ever changing world of government certifications.

The Mostly Forgotten USB Drive PP

The oldest Protection Profile (PP) currently on NIAP’s approved PP list is also one that has not gotten much attention. The Protection Profile for USB Flash Drives was approved in December of 2011 but in the nearly half-decade since its approval no successful evaluations have been performed against it. It is interesting to take a look at this largely forgotten PP and it may be worth it for vendors with compliant products to consider the benefits of certification in the future.

The USB PP was written for USB flash drives which encrypt data with an onboard processor. AES is the only encryption algorithm which is allowed. While most of the PP’s encryption requirements will be familiar to anyone who was worked in CC it does contain an unusual key masking requirement in FCS_COP.1(4). The purpose of that SFR is to ensure that the Data Encryption Key (DEK) used to encrypt the data stored on the TOE is masked by a Key Encryption Key (KEK). Similar requirements are found in newer PPs for encrypted data storage products such as the Full Drive Encryption cPP but the USB PP’s requirements are more proscriptive.

One of the USB PP’s most obvious weaknesses is its very basic authentication requirements. Split authentication factors are optional and the use of a password is the only mandatory requirement. The PP does not require any specific minimum password length. This is acknowledged as a weakness in an application note for FCS_CKM.1(3) but is accepted because of perceived convenience. There is nothing preventing a TOE from implementing stronger password requirements, but PP conformance is possible without any meaningful password strength enforcement mechanism. The PP does contain an assumption that users will follow guidance on strong password creation but real-world experience has shown that this is probably not realistic if the TOE is to be deployed on a large scale.

The USB PP’s non-cryptographic SFRs focus on self-tests, user authorization and the prevention of malware distribution by the TOE. Unsurprisingly considering the nature of the TOE there are no audit requirements, nor are there any requirements for individual user identification.

Even though the USB PP has fallen by the wayside it is still a NIAP-approved PP with no current planned sunset date. Vendors who make FIPS-approved encrypted flash drives should keep in mind that it may take relatively little effort to get their products CC certified as well. The data encryption assurance activities for this PP are drawn directly from CAVP tests and any product which meets FIPS 140-2 self-test requirements will satisfy the self-test requirements of this PP. A vendor will have to determine for themselves if CC certification would give them a competitive advantage, but the USB PP is still available should anyone decide that they are in the market.