[ksk-change] HSM's - FIP 140-2 L4 comments

[Michael StJohns]

Hi -

I recently exchanged emails with an HSM vendor on the subject of Fips 
140-2 Level 4 products.  What he told me was that all of their products 
had sufficient hardware protections to meet the L4 requirements, but 
that the cost of going through all the rest of the requirements (mainly 
the formal design analysis and modeling), as well as a lack of customers 
specifically asking for L4, generally meant that they ended up going for 
and getting the L3 certification.

One of the things I commented on to NIST during the FIP140-3 second 
comment period was that the standard's focus on implementing specific 
FIPS defined policies for the HSM was overreaching - that instead the 
FIPS 140 standard should be ensuring that the HSM enforces policies set 
by the user and not imposing their own.

For example, there's this requirement for L3 and L4 that you have 
identity based control of the key material, and that a specific user has 
to be logged in before the material can be used.  That's problematic for 
three different use cases:  a) The embedded HSM which provides identity 
information and possibly key management for the associated embedded 
firmware and processor - why would you want to have to login??  b) the 
case where you want to wrap key material in a more comprehensive policy 
- say where the HSM only emits a signature over a piece of data if its 
presented with N signatures over the same data it can verify against 
configured public keys. c) - and this one is why so few TPMs have made 
it through FIPS certification - the ability for an HSM to certify key 
material generated or contained on the HSM as originating from that HSM; 
there's no concept of separation of module keys (a key pair owned by the 
HSM itself, rather than a user) and user keys and treating them differently.

Strangely enough, there's no requirement in the 140-2 L4 set that the 
login credential be anything stronger than a PIN.

The FIPS 140-2 (and -4 if and when it comes out) is somewhat broken in 
that it thinks of the HSM in 1995  and PKCS11 terms.  What I actually 
want out of an HSM is one that will enforce policies that I set on keys 
that I generate, not impose a set of policies that might not fit my 
needs - or in some cases actively prevent satisfaction of those needs.  
In some ways, FIP140 is actively bad in that things like Javacard 
Connected could never be certified under that standard which means that 
I can't get a certified product that is flexible enough for most needs.

All that said, I do think we need a HSM with L4 hardware protection; we 
need something like the FIPS process to verify the operation of the 
various algorithms; we need something possibly more like the UL process 
to verify that key material that you want to stay in the HSM stays in 
the HSM.

The FIPS 140 Level 4 incantation is a handy shorthand for requirements, 
but I think we should probably break it down to a finer grain on the 
next discussion go around.

Mike