General - NIST FIPS 140-3 Accreditation

[makinako]

With the pre-validation conducted in Feb 21, the OpenFIPS201 validation for FIPS 140-3 began officially last month! It's a slow process, but we're looking forward to our initial product review.
I thought I would put this discussion up in case anyone wanted to discuss the process or ask questions! I will try and post up any particular insights from the process, either to help future crypto module vendors or perhaps simply for future civilisations to understand more about what kind of quaint rituals their human ancestors spent far too much time on.

[makinako]

Hi folks,

So I've been meaning to give a quick overview on the FIPS accreditation process, and now that there are a few people asking about it I'll put it up here for the benefit of all. I'm going to put it in a FAQ format because I keep getting asked the same questions and so it makes sense to do it this way.

Q - What certification is OpenFIPS201 being accredited for?

The OpenFIPS201 applet will be certified under two different accreditation schemes:

• NIST CMVP (FIPS 140-3), which generically covers any cryptographic modules sold to US federal government, as well as other nations/organisations that recognise it.
• NIST NPIVP (FIPS 201-2), which is specific to implementations of PIV cards, issuance systems and middleware
  Note that it is not enough to get an NPIVP certification for a PIV card to be recognised. CMVP validation of the module is a strict dependency of NPIVP.

Q - What is CMVP / FIPS 140?

FIPS 140 is a standard managed by the NIST Cryptographic Module Validation Program for certifying products that provide or contain cryptographic functionality. FIPS 140 has been around for a long time, but it has only just recently been updated, after 18 years of virtually no change to the standard!

FIPS 140-3 is the latest version and it is captured in the following documents:

• ISO 19790 - Covers the design, development and security requirements. It is broken up into 9 requirement categories and each one of those is further broken down into Security Levels 1 to 4 (SL1 least strict/onerous and SL4 the most). Each category can be accredited to a different SL, but the overall module SL is the lowest of any category
• ISO 24759 - Covers the testing requirements. It basically re-phrases ISO 19790 into:
  • Asserations (AS - The distilled wording of the 19790 requirement)
  • Vendor Evidence (VE - What the vendor must do to satisfy the requirement)
  • Test Evidence (TE - What the tester must show to demonstrate the requirement is met)
• NIST SP800-140[A-F] - This is the NIST-centric overlay to the above ISO documents. It contains specific additions and modifications to the ISO AS, VE and TE stipulations and the A-F documents additionally include specific listings of algorithms, protocols, physical/logical attacks/etc that must be adhered to. This is where the US gets to apply their own requirements in addition to the international standards, without the need to feed it back into the ISO process and wait for it to be approved.
• FIPS 140-3 Management Manual - The management manual provides background and guidance for labs and vendors going through the process of certification.
• FIPS 140-3 Implementation Guidelines - The 'IG' as it refers to is a strange beast. The best way I can describe it is that the ISO standards are necessarily generic in nature (applicable to all crypto modules and scenarios) and rigidly formalised when it comes to change management. The IG however is an agile creature, providing corrections, clarifications and expansions for specific scenarios as questions are asked by labs and vendors. It is where the utopian ideals of international standards meets the mean, gritty streets of cryptographic product design and is a compendium of lessons learned. Though not totally formal, if you want your product certified it is every bit as important as the ISO standards.

The categories that the standards cover are:

• Cryptographic Module Specification - The central document behind all FIPS-140 products is the 'Security Policy', a detailed specification of the cryptographic module, its interfaces, and modes of operation. You have probably seen these.
• Cryptographic Module Interfaces - A clear definition of the cryptographic boundaries of the product (what is accredited crypto vs what is generic functionality). In the case of OpenFIPS201 this is a description of the ISO 7816 and ISO 14443 regarding electrical and I/O.
• Roles, Services, and Authentication - The standard requires a definition of roles (e.g., user, security officer, administrator, etc), the authentication methods for the various roles and the services (cryptographic functions) that the roles can access. For example: The 'User' role is authenticated with the 'Verify PIN' authentication method to access the 'General Authenticate' service
• Software/Firmware Security - Restrictions and guidelines for how software is loaded, protected, configured and possibly updated, including integrity protection.
• Operational Environment - Defines the environment in Module runs, including requirements for secure operation, how/if it can be modified, how access control is managed, auditing, etc
• Physical Security - Defines requirements that govern how the Module protects from physical tampering.
• Non-Invasive Security - Addresses the spectrum (no pun intended) of side-channel attacks associated out there (SPA/DPA/DFA/timing/clock/cache/acoustic/optical/blah/blah)'
• Sensitive Security Parameter Management - This covers the generation, storage, usage and overall protection of any cryptographically sensitive information the Module handles, including keys and keygen, randomness, certificates, authentication data such as PIN values, etc. Quick terminology: CSP = Critical Security Parameters like keys/pins/random bits; intermediate protocol values; PSP = Public Security Parameters basically public keys and certs; SSP = Sensitive Security Parameters is just an umbrella term for all CSP's and PSP's
• Cryptographic Key Management - Rules for the generation, access, and protection of cryptographic keys.
• Self-Tests - Mandating self-tests that are run on power-up and periodically to ensure the module's ongoing security. This largely covers integrity of the algorithm implementation blocks and involves things like KAT's, or Known Answer Tests (running an algorithm with known static inputs to produce a known static output).
• Life-Cycle Assurance - Ensuring that the design and implementation adhere to a good engineering process and meet essential security best practices and requirements.
• Mitigation of Other Attacks - A placeholder where you can describe any implementation-specific security measures you have put in place that aren't described by the standards or supplementary documents

Q - What is NPIVP?

The NIST Personal Identity Verification Program is far less involved than FIPS 140. It is basically there to ensure that the PIV-compliant card, issuance system or middleware you build complies with the technical interface, data model and basic security requirements.

Practically speaking, it is mostly based on the successful execution of the NIST PIV Test Runner tool and the submission of the test artifacts generated by it (logs/reports).

Q - What does OpenFIPS201 need to do to comply?

• The majority of the work that has gone into compliance has been around documentation and testing, though a few changes have been necessary to comply with the design assurance requirements. The up-side is that no significant (breaking) changes have so far been required with the key functionality of the applet, including the proprietary extensions for administration and flexibility.
• In order to operate in the FIPS 140 'Approved Mode', a 'FIPS_APPROVED' boolean constant has been added. This ensures that non-approved functionality is baked out of the FIPS mode, such as support for TripleDES 192 and RSA-1024. We are currently reviewing the Dynamic Configuration aspects of the applet for any more limitations that must be baked into the FIPS binary.

More detail on the changes made to the applet will be made available when the beta is released.

It's not all good news however. One very notable restriction with FIPS 140 is summarised as follows:

1. A Java Card applet is not a cryptographic module and can not therefore be accredited under FIPS 140. This is because it typically does not implement the actual cryptographic primitives (AES/RSA/ECC/etc), but relies on the underlying hardware to do this.
2. More surprisingly, a Java Card is also not a cryptographic module by itself, as it does not provide cryptographic services (it is the applets that actually makes use of the cryptography to do useful things)
3. So... to be a cryptographic module, you must have a [Java Card Applet] on a [Java Card]. The implication here is that we were required to pick a Java Card (in our case, the NXP P71D600) and certify our applet on it. Our module will in fact be named something like OpenFIPS201 v2.0 PIV Applet on NXP P71D600.

Q - What restrictions will be placed on OpenFIPS01 once certified?

After testing, but prior to submission, the 'FIPS' code base will be locked and a binary generated from it. This will be the FIPS approved binary and it cannot be changed (or even re-compiled) without invalidating the certificate. The FIPS release will be hashed, digitally signed by us and counter-signed by the lab to provide assurance that is the accredited version.
So the implications are:

1. If you change anything, it is no longer FIPS approved
2. If you re-compile even the unchanged source code, it is still no longer FIPS approved
3. Any changes will require either a partial or full revalidation, depending on the nature of the change.

Unfortunately, the news gets worse from here. One significant restriction with FIPS 140 can be summarised as follows:

1. A Java Card applet is not a cryptographic module and can not therefore be accredited under FIPS 140. This is because it typically does not implement the actual cryptographic primitives (AES/RSA/ECC/etc), but relies on the underlying hardware to do this.
2. More surprisingly, a Java Card is also not a cryptographic module by itself, as it does not provide cryptographic services (it is the applets that actually makes use of the cryptography to do useful things). Have you ever installed an applet on your shiny FIPS approved Java Card? You are almost certainly no longer FIPS approved!
3. So... to be a cryptographic module, you must certify as a [Java Card Applet] on a [Java Card]. The implication here is that we were required to pick a Java Card (in our case, the NXP P71D600) and certify our applet on it. Our module will in fact be named something like OpenFIPS201 v2.0 PIV Applet on NXP P71D600.
4. The FIPS binary will be compiled against an NXP proprietary library, specifically so that we don't need additional certifications for the PIV Secure Messaging implementation.
5. Specific instructions in how you configure/deploy the hardware platform must be followed. If you don't, it is not considered FIPS approved.

So in summary:

• If you wish to use OpenFIPS201 in fully FIPS approved mode, you will need to install it on an NXP P71D600 and follow the specific deployment instructions. There is no way around this
• If you have a FIPS-approved token and decide to add another applet later, you are no longer approved (this is true of all FIPS approved smart cards btw, meaning that practically speaking many schemes probably don't realise they are not FIPS approved).

We don't like this, it is a clear gap in the FIPS 140 standard in our opinion and one that encourages monolithic design and vendor lock-in. But we are not here to change the system, so we will release two versions of the binary:

• The FIPS approved version, which contains the proprietary NXP bindings
• The generic version, which is identical except the NXP platform references will be replaced with generic functionality

We hope that the attainment of a FIPS approval will provide some confidence in the overall project, but understand that this choice between actual certification and choice of platform is not ideal. As we understand it, there are discussions in place within NIST to look at this. We will see.

Q - What is the certification timeline?

The transition from FIPS 140-2 to FIPS 140-3 has apparently overwhelmed the NIST CMVP team and as such, there are long delays in certification. The current estimated timeline is:

• Mar 2022 - Pre-validation of the module was completed, giving an initial insight into the kinds of changes that would be needed.
• Feb 2023 - Implementation Under Test (IUT) Phase - The official certification started, beginning with a more comprehensive product review and the creation of the first drafts of the Security Policy and Compliance Summary documents.
• (Implementation Under Test) phase.
• Nov 2023 - Review Pending Phase - The targeted lab submission date, which will put OpenFIPS201 into the NIST CMVP queue <insert thumb twiddling here>.
• Oct 2024 - Module In Process (MIP) Phase - The start of the NIST evaluation of the submission, based on the current queue time of around 11 months!
• ??? - Certification granted. This is the date we don't have yet and are chasing, but with the fluidity of the new FIPS 140-3 process and the fact that this is our first certification, there are no definitive answers.

Q - OK so presuming it is certified, now I have a perfectly secure PKI token right?

So the FIPS 140-3 accreditation is about ensuring (from the applet's perspective):

• You implemented algorithms that NIST have approved, not some home-brew crypto math you baked up in university to impress your prospective mates. In short, that your algorithms are called AES, RSA and ECC-P256, not KIM64 and ROT13.
• You used the algorithms in a way that NIST approves of (like, you didn't use AES in ECB mode... which we totally do... but don't worry it's for a good reason)
• That you followed some basic good practices when you designed it, like writing down how you did things, you put a few tests in and a controversial fixation on Finite State Machines.
• That you haven't put any deliberate backdoors in

What FIPS 140-3 is not:

• A comprehensive design review to make sure you made good choices from a security perspective (i.e. that you validate your inputs properly, don't mis-use memory, don't re-use code etc etc)
• An independent threat modelling
• An independent source code review (there is sort of, but only strict compliance against the VE/TE assertions described above).
• A pen test or other offsec style approach to security (i.e. if the lab can break it you failed)

So for this reason, we still have very much on our wish list a fully independent security-centric code audit. At this point, cost is the main inhibitor, with rough estimates of US$70-100K being thrown around. If you use OpenFIPS201 in your department/organisation and want to contribute to the overall security, this would be a great way to do it!

Q - Can I improve or make changes to the FIPS OpenFIPS201 source code?

Of course! We encourage forking, pull requests, raising issues and generally being a part of the improvement of OpenFIPS201. Unfortunately none of this will effect the actual FIPS approved version unless it is rolled into a future re-validation. Security bugs will obviously get highest priority here.

Thanks for reading and please post any questions, opinions, corrections or general musings in this discussion! I'll try to keep the FAQ up-to-date as we go forward.

[makinako]

We are official! From the CMVP IUT web site:

To be clear this just means we are officially 'under test', it does not mean we have our cert yet. Still, our little project is in big company now.