>> One point is that if this is a delivery for someone >> subject to the FIPS-only procurementrequirement >> imposed on various US Government related entities, >> then whatever OS theyuse, MUST (by that requirement) >> have already passed this for its password handling. > > This is *technically* true, in the narrow sense that supposedly any OS > used in DoD should be CC certified and so forth. Should not must. > > In practice it is very common -- at FIPS 140-2 Level 1 -- for software > *products* to use FIPS 140-2 validated crypto on non-certified, > non-validated operating systems. Just take a look at Table 2 in the > OpenSSL FIPS Object Module Security Policy: > > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf > > and note that of the 101 platforms ("OEs") appearing there, most of > those operating systems are neither CC certified nor have any other FIPS > 140-2 validated crypto. Keep in mind that at Level 1 the validation > applies to the cryptographic module, not the calling application that > uses that module nor the operating system that runs it. Another example is the various frameworks that provide the TextEdit boxes where passwords are entered. FIPS requires zeroization at level 1, and I guarantee none of those frameworks wipe the memory from the TextEdit. Hell, Apple has a secure allocator that does not even bother calling the secure deleter. It calls the default deleter for some reason. See the source code for libsecurity_utilities at [1,2,3]. And Apple really could have used zeroization: http://www.cnet.com/news/mac-os-x-lion-reveals-passwords-in-sleep-mode/. As this vulnerability shows, wiping secrets from memory is not a theoretical defense. [1] http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/SecKeychainItem.cpp [2] http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/Item.cpp [3] http://www.opensource.apple.com/source/libsecurity_utilities/libsecurity_utilities-38535/lib/alloc.cpp
