FIPS...common criteria...what does It all mean?

[Jon_Green]

First, let's talk about FIPS (which, by the way, stands for Federal Information Processing Standard in case you're ever asked during a game of Hacker Jeopardy.) Using a product validated under FIPS 140-2 means that you can be assured that cryptographic implementations are operating correctly, and are providing the correct and appropriate sort of security for a given application. As a Wi-Fi and remote access vendor, cryptography is really, really important to us and to our customers, and that's why we have invested and re-invested in FIPS 140-2 validation going as far back as 2004.

There are two major parts to FIPS 140-2. First, the algorithms. The Cryptographic Algorithm Validation Program (CAVP) is administered by NIST, and tests for correctness of a cryptographic algorithm implementation – meaning that the implementation does what it's supposed to do under all circumstances. To test the correctness, an accredited lab will generate test vectors – think of these as a series of blobs of data that you need to run through either your encryption or decryption routine. The vectors are specially designed to test edge cases where a developer might commonly make mistakes. These tests actually work – in the past, we've found errors in our implementation when we couldn't get the test vectors to pass correctly. Most of the time those errors are in software, and thus easier to fix, but we've found at least one hardware crypto bug where we then had to build a small workaround using software. FIPS testing therefore serves as an extra level of assurance, on top of standard quality assurance testing, for critical security components.

The other part of FIPS is the module itself. Validation of the module is performed under the – you guessed it – Cryptographic Module Validation Program (CMVP). A module is informally defined (at least by me) as "a thing that provides cryptographic services". In our case, a module could be a mobility controller, an AP, or a software library. Modules are validated at different levels, from level 1 (software only) to level 2 (hardware that includes certain physical protections) all the way up to level 4, which might as well be an impenetrable fortress. The vendor decides where they draw the boundary around their module, so you'll see different sorts of implementations out there. A validated module must meet certain requirements, the biggest of which is NOT using cryptographic algorithms that are not FIPS approved. You've seen a lot of  that perform HTTPS using the RC4 algorithm for example. Not gonna happen in a FIPS environment – AES and 3DES are your only real choices for symmetric crypto. Likewise, FIPS has phased out weaker algorithms like MD5, and more recently SHA1 – this helps to push vendors toward supporting better and stronger standards. Modules must also have very well-defined failure modes, self tests, and source code reviewed by an accredited lab.

Is FIPS 140-2 a panacea for security? No. First, the recent OpenSSL Heartbleed bug affected a number of FIPS-validated modules, including our own. Why wasn't that bug found during the extensive source code reviews done by FIPS labs? Well, for the same reason it wasn't found by the open-source community at large for such a long time. FIPS isn't perfect, but in security we try not to let perfection stand in the way of making things better. Second, FIPS only covers cryptography – there are many other security capabilities that are not evaluated under FIPS.