error creating PKCS#12 (PFX) in FIPS mode (JSS)
David Stutzman
of creating a PKCS#12 file I get the following token exception:
org.mozilla.jss.crypto.TokenException: Failed to import PBA key from
PBA-generated bits
at org.mozilla.jss.pkcs11.PK11KeyGenerator.generatePBE(Native Method)
at
org.mozilla.jss.pkcs11.PK11KeyGenerator.generate(PK11KeyGenerator.java:213)
at org.mozilla.jss.pkcs12.MacData.<init>(MacData.java:131)
at org.mozilla.jss.pkcs12.PFX.computeMacData(PFX.java:242)
The call that kicked off the exception was:
pfx.computeMacData(pw, salt, iterationCount);
where pw is a 10 character "strong" password (examples: h@7oVe3I2* and
%06+hz9LJd), salt is an 8 byte array populated with "nextBytes(salt)"
via JSS's SecureRandom and the iterationCount is 2048.
I enabled FIPS mode by setting:
initializationValues.fipsMode = FIPSMode.ENABLED;
before calling:
CryptoManager.initialize(initializationValues);
The private key I'm trying to include in the PKCS#12 was generated in
and exported from the software token moments right before this.
I can only guess that FIPS mode is being (understandably) stricter about
letting the private key go from the softtoken?
Is there a way to get past this with some different code or do FIPS
restrictions just flat out disallow what I am trying to do?
Thanks,
Dave
Wan-Teh Chang
> I turned on FIPS mode in our JSS-using application and in the last step
> of creating a PKCS#12 file I get the following token exception:
>
> org.mozilla.jss.crypto.TokenException: Failed to import PBA key from
> PBA-generated bits
This error message comes from
http://lxr.mozilla.org/security/source/security/jss/org/mozilla/jss/pkcs11/PK11KeyGenerator.c#263:
263 key = PK11_ImportSymKey( PK11_GetInternalSlot(), CKM_SHA_1,
264 PK11_OriginGenerated, CKA_SIGN, keyBits, NULL);
265 if( key == NULL ) {
266 JSS_throwMsg(env, TOKEN_EXCEPTION, "Failed to import PBA key from"
267 " PBA-generated bits");
268 goto finish;
269 }
where keyBits points to a SECItem buffer holding the symmetric key.
PK11_ImportSymKey ultimately calls the C_CreateKey function of
the softoken. In FIPS mode, the function does not allow a secret
or private key to be created:
http://lxr.mozilla.org/security/source/security/nss/lib/softoken/fipstokn.c#698
698 /* FIPS can't create keys from raw key material */
699 if (SFTK_IS_NONPUBLIC_KEY_OBJECT(*classptr)) {
700 rv = CKR_ATTRIBUTE_VALUE_INVALID;
Now let's go back to the JSS code. It hasn't changed since
we open-sourced it in 2000, and the comments say it is a
workaround for a bug:
http://lxr.mozilla.org/security/source/security/jss/org/mozilla/jss/pkcs11/PK11KeyGenerator.c#321
321 mech = JSS_getPK11MechFromAlg(env, alg);
322
323 if( mech == CKM_PBA_SHA1_WITH_SHA1_HMAC ) {
324
325 /* special case, construct key by hand. Bug #336587 */
326
327 skey = constructSHA1PBAKey(env, pwitem, salt, iterationCount);
328 if( skey==NULL ) {
329 /* exception was thrown */
330 goto finish;
331 }
332
333 } else {
It is possible that "Bug #336587" has been fixed. So please try
removing the special case for CKM_PBA_SHA1_WITH_SHA1_HMAC
and just keeping the code block in the 'else' branch. Does it
work for CKM_PBA_SHA1_WITH_SHA1_HMAC? If not, could
you try some other mechanism such as CKM_PBE_SHA1_DES3_EDE_CBC?
Wan-Teh
David Stutzman
> Now let's go back to the JSS code. It hasn't changed since
> we open-sourced it in 2000, and the comments say it is a
> workaround for a bug:
> http://lxr.mozilla.org/security/source/security/jss/org/mozilla/jss/pkcs11/PK11KeyGenerator.c#321
>
> 321 mech = JSS_getPK11MechFromAlg(env, alg);
> 322
> 323 if( mech == CKM_PBA_SHA1_WITH_SHA1_HMAC ) {
> 324
> 325 /* special case, construct key by hand. Bug #336587 */
> 326
> 327 skey = constructSHA1PBAKey(env, pwitem, salt, iterationCount);
> 328 if( skey==NULL ) {
> 329 /* exception was thrown */
> 330 goto finish;
> 331 }
> 332
> 333 } else {
>
> It is possible that "Bug #336587" has been fixed. So please try
> removing the special case for CKM_PBA_SHA1_WITH_SHA1_HMAC
> and just keeping the code block in the 'else' branch. Does it
> work for CKM_PBA_SHA1_WITH_SHA1_HMAC? If not, could
> you try some other mechanism such as CKM_PBE_SHA1_DES3_EDE_CBC?
I imagine what you are suggesting involves recompiling JSS as
PFX.computeMacData doesn't take any algorithm parameters. There is a
constructor for PFX that takes a MacData, but again, I don't see any way
to specify the algorithm (besides the hash algorithm).
I remember reading that JSS needed to be signed as it is a Java Security
Provider. Does the signature have to be from a "trusted" source or
"just signed". If the latter, we have no shortage of keys/certs here...
So if I need to do what I think I need to do, do you recommend using a
particular version or just grabbing the current CVS?
Thanks,
Dave
Wan-Teh Chang
> Provider. Does the signature have to be from a "trusted" source or
> "just signed". If the latter, we have no shortage of keys/certs here...
>
> So if I need to do what I think I need to do, do you recommend using a
> particular version or just grabbing the current CVS?
You should grab the CVS tag for the JSS release you're using.
Suppose you're using JSS x.y.x, then check out the source tree
as follows:
cvs co -r JSS_x_y_z_RTM mozilla/security/jss
cvs co -r NSS_3_11_7_RTM mozilla/security/coreconf
mozilla/security/nss mozilla/dbm mozilla/security/dbm
cvs co -r NSPR_4_6_7_RTM mozilla/nsprpub
cd mozilla/security/nss
gmake nss_build_all BUILD_OPT=1
cd ../jss
gmake BUILD_OPT=1
Then look for libjss4.so under a subdirectory under mozilla/dist and use
that.
JSS needs to be signed by keys that Sun issued certs for, so you
can't use arbitrary keys/certs to sign JSS. But JSS signing is only
necessary if you use the "Mozilla-JSS" JCE provider and only the
jar file is signed. Since you will be modifying the C code, JSS
signing is not an issue.
Wan-Teh
David Stutzman
> Now let's go back to the JSS code. It hasn't changed since
> we open-sourced it in 2000, and the comments say it is a
> workaround for a bug:
> http://lxr.mozilla.org/security/source/security/jss/org/mozilla/jss/pkcs11/PK11KeyGenerator.c#321
>
> 321 mech = JSS_getPK11MechFromAlg(env, alg);
> 322
> 323 if( mech == CKM_PBA_SHA1_WITH_SHA1_HMAC ) {
> 324
> 325 /* special case, construct key by hand. Bug #336587 */
> 326
> 327 skey = constructSHA1PBAKey(env, pwitem, salt, iterationCount);
> 328 if( skey==NULL ) {
> 329 /* exception was thrown */
> 330 goto finish;
> 331 }
> 332
> 333 } else {
>
> It is possible that "Bug #336587" has been fixed. So please try
> removing the special case for CKM_PBA_SHA1_WITH_SHA1_HMAC
> and just keeping the code block in the 'else' branch. Does it
> work for CKM_PBA_SHA1_WITH_SHA1_HMAC? If not, could
> you try some other mechanism such as CKM_PBE_SHA1_DES3_EDE_CBC?
>
> Wan-Teh
Now that I'm able to build NSS/JSS on windows I finally got around to
trying this out.
I commented out the if block and left the else...when the code gets
there it bombs big and takes the java vm down with it with no warning.
I'm not sure how I could try another algorithm. I'm not specifying one
in the call that is throwing the exception
(org.mozilla.jss.pkcs12.PFX.computeMacData). Based on the javadoc for
that method I tried passing in null for the salt so it would make its
own and used 1 for the iteration count and got the same (expected) error.
I *can* successfully build the PKCS12 if I omit that call, but the
resulting PKCS12 has issues with at least nss itself and openssl. java
keytool lists the contents but I don't know if I could actually use it:
mbn public # nsspk12util -l 1.1.1.1-ID.p12
Enter password for PKCS12 file:
nsspk12util: PKCS12 decoding failed: security library: improperly
formatted DER-encoded message.
nsspk12util: PKCS12 decode not verified: security library: improperly
formatted DER-encoded message.
nsspk12util: PKCS12 decode not verified: security library: improperly
formatted DER-encoded message.
mbn public # openssl pkcs12 -nodes -in 1.1.1.1-ID.p12
Enter Import Password:
Mac verify error: invalid password?
15335:error:2307E06C:PKCS12 routines:PKCS12_verify_mac:mac
absent:p12_mutl.c:110:
mbn public # keytool -list -keystore 1.1.1.1-ID.p12 -storetype PKCS12
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
cn=1.1.1.1, Oct 18, 2007, PrivateKeyEntry,
Certificate fingerprint (MD5):
74:C2:1E:D0:95:4F:76:BB:75:9C:24:0F:9A:2E:B3:58
A quick aside, I filed a bug with gentoo and got them to edit the ebuild
for nss to add a flag for installing the command-line utils. They added
the "utils" use flag. They all get "nss" prepended to their names
because the dev didn't like the idea of an executable called "example"
or "digest". That's why I used "nsspk12util" above.
Dave
David Stutzman
> PK11_ImportSymKey ultimately calls the C_CreateKey function of
> the softoken. In FIPS mode, the function does not allow a secret
> or private key to be created:
> http://lxr.mozilla.org/security/source/security/nss/lib/softoken/fipstokn.c#698
>
> 698 /* FIPS can't create keys from raw key material */
> 699 if (SFTK_IS_NONPUBLIC_KEY_OBJECT(*classptr)) {
> 700 rv = CKR_ATTRIBUTE_VALUE_INVALID;
Just posting on this old thread to provide some closure should anyone
else be reading this.
Reading the "/* FIPS can't create keys from raw key material */" comment
made me do some investigation...
Page 61 of the "Implementation Guidance for FIPS PUB 140-2 and the
Cryptographic Module Validation Program" available at
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf
says the following:
"Password-Based Key Establishment Methods: all password-based key
establishment methods such as PKCS#5 are not to be used in the FIPS mode."