Meets FIPS 201, Now Really? Redux

OK so after that first take on FIPS 201 let's get to round two.

At a very basic level (and why I believe FIPS 201 and PKI is such an important step forward for the security industry and the way to achieve interoperability and the wide range of associated security and economic benefits) FIPS 201 is about an approach, a policy, a basis for trust and then finally and maybe least importantly about technology. Therefore when vendors invoke FIPS 201 I tend to get out the magnifying glass.

Even when you create a fully FIPS 201 compatible credential loaded with four digital certificates you have made a very smart decision for a credential that can achieve high assurance for logical and physical security but you have not created something anyone else can trust. With very little training a wide range of people could set up a Microsoft CA using server 2003 or 2008 or other CA products and follow the FIPS 201 specification, create a credential that looks and acts like a Federal credential but then become a somewhat dangerous fraud. Only by validation (checking expiration, revocation and trust chain to the issuer) of the credential can I unequivocally determine the domain in which it is or is not valid.

Just because something is on the APL or meets some aspect of FIPS 201 or the related special publications does not mean that the related security system meets the high level of assurance possible with FIPS 201. This is the reason that NIST put out SP 800-116 to help organizations understand the different levels of assurance particularly for physical access control systems (PACS). In some cases PACS vendors make the claim of meeting FIPS 201 but do so by getting over the lowest possible bar. One option under FIPS 201 for PACS is to use the free read of the smart card number with no additional security factors and no additional cryptographic techniques. If an organization chooses to do so they are implementing FIPS 201 with effectively no assurance!

As another example, FIPS 201 has a defined bar code symbology but there is nothing to stop someone from copying the bar code and using this as a means of fooling a system. Again someone could make a claim that they have implemented FIPS 201 by using the bar code symbology but this again implements an easily defeated system that provides no assurance from a security perspective. What is required at the end of the day is cryptographic soundness, an ability to defeat or deter a determined attacker not simply using one part of the specification.

Just because you use an interoperable biometric (FIPS 201 calls out ANSI 378 fingerprint templates) does not mean you have a FIPS 201 credential, while better than a FIPS 201 bar code it still does not mean you have a FIPS 201 credential.

OK, take a breather .....