ICMC: Impact FIPS 140-2: Implementation Guidance

Presenters: Kim Schaffer, Apostol Vassilev, and Jim Fox - all from NIST (CMVP).  The talk walked us through some of the most confusing/contentious recent updates to the Implementation Guidance document.

Implementation Guidance 9.10

Default Entry Points are well-known mechanisms for operator independent access to a crypto module. When an application loads, static default constructs, dynamically loaded libraries, etc - these access points are linked into the application.  When this default entry point is called, power on self tests must be called with out application or operator intervention.

This guidance exists in harmony with IG 9.5, which is regarding, essentially making sure there isn't a way for the module to skip power-on-self-tests.

Implementation Guidance 3.5

All services need to be documented in your security policy, even the non-approved ones.  Each service needs to be listed individually.  Some services can be documented externally, but those need to be publicly accessible (via URL or similar).

Operational Environment

This is defined as the OS and platform [Ed note: emphasis mine].

Today, processors are becoming nonstandard, so NIST can no longer just consider the OS alone and needs to reinvigorate the intent seen in the original document.  This gets more complicated with virtual machines (VMs) in the mix.

What they used to call GPC (general purpose processor), they are now referring to them as Special Processing Capability (SPC) because of the cryptography being added to the processors.

What do they mean by SPC?  extended calls to enhance cryptographic algorithm without full implementation.  Processors include Intel, Arm and SPARC.

If the module can demonstrate independence of SPC, then it won't necessarily be considered a hybrid implementation.  If the lab can show this, even though an implementation can leverage an SPC, they may still be considered a software or firmware implementation.

Questions

An audience member showed irritation that the new IG does not give time to implement (ie no grace period).  Mr. Randy Easter reiterated  that this is not a new requirement, but something that was formerly missed by the testing that the labs did. They want to nip these lapses in the bud and get people back on track.  Essentially correcting assumptions that CMVP was making about what the labs were testing. There are some changes/clarifications on this lack of grace period that were sent to the labs last night (not sure what's in that, but the labs all seem happy and are anxiously checking their mail).

Another question about why the very specific platform is required on the certificate. Mr. Easter noted that this is due to how dependent entropy is on the underlying platform - this becomes important to test and verify. This is a frustrating for Android developers.  Mr. Easter noted that most consumers, though, are happy to use the same module on slight variations of platforms (for example, different releases of Windows on slightly different laptop hardware - too many variations to actually test).

Mr. Schaffer noted that certificates do not need to go down to the patch level, unless the vendor requests it.


This post syndicated from: Thoughts on security, beer, theater and biking!