We Keep Coding

keytool versus FIPS when handling PKCS12 keystores

Background: What Works
From time to time we have to use a piece of Java software that reads PKCS#12 keystores. For this particular project, we have to create public/private pairs on an as-needed basis, and we store the keys in PKCS12 files because it's stable and pretty much everything can read that format.
Because we do a lot of Java in-house, we have keytool sitting around, and so we figured hey, just use keytool to create the private key and certificate. A typical instance looks like this:
keytool -keystore MyLuggage.p12 -storepass 123456 -storetype pkcs12
-alias "......"
-genkeypair -keyalg RSA -keysize typically_2048_or_3072 -sigalg SHA256withRSA
-ext "KeyUsage=dataEncipherment,digitalSignature,keyEncipherment"
-startdate ....
-dname "......."
The actual -keysize varies between 2048 and 8192 in practice; for the purposes of this question it hasn't seemed to make a difference what gets used, but obviously we use key lengths appropriate to the task if we get to choose them at all (usually dictated by the constraints of other software, or dictated by some regulation that's handed to us).
This has always worked, in that other software -- including the Java software mentioned at the start -- can read the keystore and make use of the private keys within. (And the public key can be exported and used, etc.)
Here's What Breaks
The software recently got upgraded to a version that uses the FIPS 140 certified Java libraries from RSA. ("BSAFE" or "JSAFE" depending on who you ask.) And now, trying to open previously-created PKCS#12 files fails with
java.lang.SecurityException: Algorithm not allowable in FIPS140 mode: PBE/PKCS12/SHA1/RC2/CBC/40
at ......
at java.security.KeyStore.load(Unknown Source)
The elided ...... frames are in the RSA source that we don't have and looks to use function names that have been obfuscated in any case. So looking at their source to try and figure out what exactly it's testing to cause this, isn't an option.
So, what is causing this? The only algorithms we've chosen are the "RSA" key generation and "SHA256withRSA" signature, both of which are permitted by FIPS 140-2. I've been looking again through keytool -genkeypair -help output and there don't seem to be any other algorithm or security options. (We've avoided using -keypass because PKCS#12 tools really hate it when the keystore password and the key password are different, and keytool -genkeypair defaults the key password to the keystore password.) The rest of the error message is confusing, as we don't specify the use of SHA-1 or RC2 (!) anywhere.
Googling around points to people having trouble with creating SSL certificates, which we're not doing here, and the solutions given seem to be specific to Tomcat.
Is this a problem with how we're creating the keystore, how we're creating the key pair in the keystore, or some "feature" of FIPS 140 that we haven't previously encountered?

PKCS#12 stores the private key encrypted with a password derived key. It looks like keytool uses pbeWithSHAAnd128BitRC2-CBC (pkcs-12PbeIds 5), an PBES1 algorithm for doing so. Even the keytool.exe of Oracle Java 9 does use this algorithm as you can verify by uploading a .p12 file to the online ASN.1 decoder decoding a sample PKCS#12 file.
If I read the PKCS#12 standard correctly PBES1 was long ago superseeded by the "newer" version of the key derivation system named "PBES2" (mostly PBKDF2 based) with should be used instead. But keytool does not make use of it. This is my interpretation of the error message.
Therefore the certificate and the key may be acceptable, but the PKCS#12 container is not acceptable. You may try to extract key and certificate and save them in a new PKCS#12 file using a current software like OpenSSL (or you simply generate the whole PKCS#12 file directly using OpenSSL).
OpenSSL has the option to specify the PBE used for key and certificate encryption (parameters -keypbe and -certpbe in PKCS#12 mode). I have not checked it but and algorithm like AES-256-CBC should be FIPS140 compatible.

EV Code Signing extremely slow

Since February, GlobalSign only issues EV Code Signing certificates. This means that code signing has to be done with a hardware token (Safenet USB eTokens).
Since I had to switch to EV Code Signing, I noticed a huge time increase while signing my application. From a few minutes with a regular java keystore, to over 40 minutes with the eToken.
According to the GlobalSign site, I should sign my jars as following:
jarsigner -keystore NONE -storetype PKCS11 -tsa http://timestamp.globalsign.com/scripts/timestamp.dll -providerClass sun.security.pkcs11.SunPKCS11 -providerArg eToken.config -storepass mypass myapp.jar myalias
I contacted GlobalSign support, but they were unable to help me further as the signing actually works... just very slow.
Things I tried:
Alternative TSA
Signing without a TSA
Put project on the same disk and partition of the jarsigner's location
Using the command line instead of maven profile (configured in my IDE)
Nothing had impact on the slow signing. Does anyone have other ideas or has had the same issue?

Try adding -sigalg SHA512withRSA to your jarsigner options.
The problem seems to be, that PKCS11 is actually using the token to compute the hash.
(as noted in this comment Java : PKCS11 SafeNet eToken 5110 : Slow; and How to code for EBICS signature mechanism A006?)
The Gemalto SafeNet 5110 hardware only supports SHA256, so setting SHA512 forces software computation of the hash, which speeds up things a lot.

I was in contact with GlobalSign several times.
The answer was:
a performance of signing a single jar with about 1900 class files inside
==> taking about nearly 3 minutes is normal for a usb hardware security token.
In comparision:
using a local pfx file with certificate and private key took 5 seconds.
Why is it so slow?
Answer by Globalsign: For each class file the certificate will be retrieved from the token and the OCSP will be checked if the certificate was revoked.
Used hardware security token: Gemalto SafeNet 5110.
Globalsign told me, I can try to use another token, if it's faster.
I wonder, if https://www.yubico.com/products/yubihsm/ may be faster? Someone have experience with this? How do others code signing in java?

If you can verify that a JKS keystore has not been changed is there any benefit from passwording it?

For example, say the keystore is being tracked in Git, so we can be certain it has not been tampered with. Would having a password on the keystore add anything security-wise? Is omitting the keystore password in any way a security risk in this situation?
NB: In case it matters, the keystore is being used to store public/private key certificates for signing Android apps, and the private keys inside the keystore are encrypted with strong passphrases.

In my opinion, private keys should always be stored as safe as possible.
As taken from Sun/Oracle official documentation
There is a built-in default keystore implementation type known as "jks" that is provided by Sun Microsystems. It implements the keystore as a file, utilizing a proprietary keystore type (format). It protects each private key with its own individual password, and also protects the integrity of the entire keystore with a (possibly different) password...
http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html#KeystoreImplementation

I've done a lot of Googling, reading and experimenting and I believe the answer to my question is "no".
The keystore password is only used as part of signature generation: it protects against tampering, but does not prevent inspection. If you can guarantee the file has not changed one bit, you can guarantee is has not been tampered with, and so adding a keystore password in this scenario does not provide any additional security.
Sources:
The Java keytool documentation only refers to the keystore password as verifying integrity, never encryption - but doesn't explicitly say it only protects against tampering.
The Bouncy Castle specifications (section 5.4) states that when operating "in the same fashion" as JKS, "The keystore is resistent to tampering but not inspection." - which strongly suggests this is true for JKS
Most concrete but least official is the reverse-engineered implementation of JKS which also backs up the claim that the keystore is not encrypted with the keystore password.
Experiments:
My first experiment was to change the password on a keystore and see how much changed in a hex editor, and it looked like only the last few bytes of the file changed.
Second experiment: Create a keystore with a password, generate and store a key with a different password. Retrieve the key from the keystore both with the correct keystore password, and a blank password. You get bit-for-bit identical results.

Using an empty keystore password used to be possible?

When signing an apk after a long break from Android development I was surprised that I'm no longer able to enter an empty keystore password to unlock it. Is it just me or has this been possible before? If so, when did that change and how can I manage to unlock the keystore anyway?
Some background: maybe I'm just crazy and didn't use an empty password for the keystore before, but the one and only possible password that I could have been using instead doesn't work either (I swear, there's no chance I'd have used another password!).

The keystore can be manipulated using the keytool in the Java sdk.
Try executing the keytool on your keystore, and extract the certificates with the empty password. After that, import it into a new keystore. This time, use a real password.
The switch -exportcert will help you accomplish that.
It could be that you updated your java sdk and therefor you cannot enter empty password (due to some security upgrade of the tool). In that case, you can try to install an older sdk and do the above.
Good luck!

You cannot use an empty password for your keystore.
I checked, as far as jdk 1.3 keytool does'nt allow it, see http://docs.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html where doc explicitely states that:
storepass must be at least 6 characters long. It must be provided to all commands that access the keystore contents. For such commands, if a -storepass option is not provided at the command line, the user is prompted for it.
For fun, I wanted to try keytool from jdk 1.2 and downloaded it since its documentation doesn't state that password is mandatory, but I need a Windows NT box to install it!
I absolutely don't think Android ever used this keytool version.
Sorry, but it looks like you have either: forgotten your password, or typed it with caps locks / a wrong keyboard layout activated. :(
EDIT:
If it is not a layout problem you can try to
Use this reverse engineered code to extract key using an empty string password: http://metastatic.org/source/JKS.java.
If this doesn't work you are screwed, your only hope will be to brute force the key using http://code.google.com/p/android-keystore-password-recover/ or http://code.google.com/p/patator/ (test and use the fastest one)

Try default android debug mode keystore password which is android or java cacerts default changeit/changeme.

I faced this issue as well and it was very weird. I had a legacy keystore that was not protected by any password. I could use it successfully in SoapUI but keytool and keystore explorer failed to open it. I had to create new keystore that already had a password and since then everything was fine.
I suspect that Java 8 is more picky that Java 7 was.
keytool -importkeystore -srckeystore client.jks -destkeystore client2.jsk -srcstoretype JKS -deststoretype JKS -deststorepass changeit

Instead of using keytool, you could write a simple Java SE program that tries to use your key or lists aliases. The API should (not a 100% on this) allow you to use an empty ("") password.
You can also try third party tools like portecle to list/extract keys.

I've just faced the same problem when trying to use the key store provider for hadoop, which uses none as default password, see: JavaKeyStoreProvider.java
I ended up copying the original keytool from OpenJDK8 and removed the restrictions in this new implementation (it is the same but without the 6 characteres limitation): KeytoolWithoutPasswordLimits
In this way, I managed to use none as password.

If all of the above fail you can try cracking it. Related question: Android - Forgot keystore password. Can I decrypt keystore file?

That works for me:
keytool -list -keystore keyStoreFileWithotPassword.jks -protected
CORRECTION: It turn out the list feature works without entering the actual password! But the import features do require a password

Verify certificate against Java certificate store via CLI

How can I verify an X509 (or DER-formatted) certificate against the Java certificate store via the command line?
I've looked into using the keytool utility, but it looks like it only handles import/export/display functionality (no verification).
EDIT: It looks as though keytool can be used for verification, but only if an import is attempted. I suppose a better way of asking this questions is whether or not a more passive approach (as in: not modifying the keystore) is available. Thanks!

You can use keytool to export the needed certificates (those that are in the chain for the one you need to verify) from the Java keystore into X.509 files. Then, concatenate them together into one file. Finally, use openssl to do the verification.
openssl verify -CAfile concatenated-certs.crt cert-to-verify.crt
Not a perfect solution since it involves popping the certs out of the truststore, but it ought to work given what you are starting with.

This page could be oversimplifying:
http://java.sun.com/docs/books/tutorial/security/toolfilex/rstep1.html
But it doesn't look like even import with keytool does a true verification of a certificate. I'm not seeing any description of verifying the signature of the incoming certificate against the signature of another trusted certificate.
jarsigner will verify a signature on a signed jar, but doesn't do anything to verify the signature on the certificate used to sign the jar.
I'm afraid you'd either have to write a tool to do the verfication, or look for a commercial tool that does it. I would think that some of the PKI tool kits would have a certificate verification tool that would do this.