openssl: 'openssl fipsinstall' doesn't work as advertised
The manual has an example:
But trying it (with minimum adjustment for running it in the build tree) fails:
$ ./util/wrap.pl apps/openssl fipsinstall -module ./providers/fips.so -out fips.cnf -provider_name fips -section_name fipsinstall -mac_name HMAC -macopt digest:SHA256 -macopt hexkey:000102030405060708090A0B0C0D0E0F10111213
HMAC : (Module_Integrity) : Fail
INSTALL FAILED
C0:3D:A8:13:2F:7F:00:00:error:common libcrypto routines:provider_activate:init fail:../master/crypto/provider_core.c:503:
C0:3D:A8:13:2F:7F:00:00:error:configuration file routines:module_run:module initialization error:../master/crypto/conf/conf_mod.c:212:module=providers, value=provider_section, retcode=-1
Looking at what the test recipes do, it seems that only a MAC key with zeroes work:
$ ./util/wrap.pl apps/openssl fipsinstall -module ./providers/fips.so -out fips.cnf -provider_name fips -section_name fipsinstall -mac_name HMAC -macopt digest:SHA256 -macopt hexkey:00
HMAC : (Module_Integrity) : Pass
SHA1 : (KAT_Digest) : Pass
SHA2 : (KAT_Digest) : Pass
SHA3 : (KAT_Digest) : Pass
TDES : (KAT_Cipher) : Pass
AES_GCM : (KAT_Cipher) : Pass
RSA : (KAT_Signature) : Pass
ECDSA : (KAT_Signature) : Pass
DSA : (KAT_Signature) : Pass
HKDF : (KAT_KDF) : Pass
SSKDF : (KAT_KDF) : Pass
HASH : (DRBG) : Pass
CTR : (DRBG) : Pass
HMAC : (DRBG) : Pass
DH : (KAT_KA) : Pass
ECDH : (KAT_KA) : Pass
INSTALL PASSED
Eye-balling the code seems to confirm this, as the self test uses fixed_key is key data:
It’s initialized when defined:
… and not modified anywhere.
@slontis, you know these things better than most, is this an omission?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 37 (37 by maintainers)
Yup. This was actually hashed quite a while ago, back when we worked on the design document (which does talk about this). If memory serves, what I wrote in my previous comment just regurgitates what was said way back then… it seems like a reminder was needed.
The key serves no security purpose whatsoever. It is entirely for detecting inadvertent corruption of the executable image. It is not meant to be secret and for hardware modules a simple CRC32 is acceptable. Do not think this as a key - as it really isn’t. It is simply the input to a checksum algorithm. If someone feels the need to have a different value they can change the source to do so. It isn’t something that needs to be configurable - except in the sense of an easy way to test things during development which is what @slontis was doing.
Something gets easier if HMAC is used. I don’t remember exactly what and a quick dash in to the abyss of 140-2 documents didn’t remind me.
Deep in the maze, I did stumble over IG 7.4 which says that the integrity check key isn’t a CSP and doesn’t have to meet the zeroization requirements. One could extend this to mean that it doesn’t need to meet the other requirements for a CSP (in this case it can pass the module boundary freely) but it is safer not to.
Please don’t use the word ‘security’ in relation to this (unless you also use the words ‘false sense of’). This is a sanity check not a security check.