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