Why MD5 is required to initialize JCE

Question

I am experimenting on incorporating FIPS 180-3 into my Java application. FIPS 180-3 allows you to use only 5 secure [hashes] (http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf), MD5 is not included in their number. Therefore, I am trying to programmatically remove the MD5 algorithms from the Sun provider. This is sample code.

---

public static void main(String[] args) throws Exception { Security.removeProvider("SUN"); Sun sun = new Sun(); sun.remove("MessageDigest.MD5"); //Comment and it will work !!! Security.addProvider(sun); Cipher ciph = Cipher.getInstance("AES"); } 

---

But this throws the following exception. If you comment on "sun.remove (..", the program works fine. If I delete MD2, not MD5, then it works fine.

It seems to me that jre libs use MD5 to sign them, but I checked the jre / lib / ext / sunjce_provider.jar signer and its use sha1.

Any idea why my code is not working with this error?

An exception in the thread "main" java.lang.ExceptionInInitializerError on javax.crypto.Cipher.getInstance (DashoA13 * ..) on TestRemoveMD5.main (TestRemoveMD5.java:20)

Raised: java.lang.SecurityException: Cannot configure certificates for trusted certificate authorities on javax.crypto.SunJCE_b. (DashoA13 * ..) ... 3 more

Raised: java.lang.SecurityException: signature classes were tampered with javax.crypto.SunJCE_b.d (DashoA13 * ..) on javax.crypto.SunJCE_b.c (DashoA13 * ..) on javax.crypto.SunJCE_b $ 1.run ( DashoA13 * ..) in java.security.AccessController.doPrivileged (native method) ... 4 more

Answer 1

This is a security feature that prevents Sun from removing untrusted code. There is a way to do this, which requires proper permissions to do this. If you follow this link http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html and scroll down to the Security Class heading, you can read how to remove the provider and what will happen.

EDIT

Excerpts from documents that apply to installed providers that are not extensions may require a policy file to perform certain actions, such as adding or removing a provider. Worth trying.

The vendor documentation for each vendor that you will use should include information about what permissions are needed and how to grant those permissions. For example, a provider may require the following permissions if it is not installed and Security Manager is installed

-

The Security class manages established providers and security properties. It contains only static methods and is never created. Methods for adding or removing providers and for setting security properties can only be performed by a trusted program. Currently, a "trusted program" is

• a local application not running under the security manager, or
• an applet or application with permission to execute the specified method (see below).

Determining that the code is considered trusted to complete the attempt (for example, adding a provider) requires that the applet obtain the appropriate permissions for this particular action.

-

Each “grant” statement in such a file provides a specified source of code with a set of permissions, indicating which actions are allowed.

Here is an example policy configuration file:

 grant codeBase "file:/home/sysadmin/", signedBy "sysadmin" { permission java.security.SecurityPermission "insertProvider.*"; permission java.security.SecurityPermission "removeProvider.*"; permission java.security.SecurityPermission "putProviderProperty.*"; }; 

Answer 2

I think I could figure out the root cause, but still I could not understand where it came from. I tried debugging the X509CertImpl and got one certificate signed by "JCE Development" that uses MD5. But all other uploaded certificates were correctly signed using SHA1withDSA. I am not sure if this is a bug in jre.

[[Version: V1 Topic: CN = JCE Development, OU = Java Software, O = Sun Microsystems, L = Cupertino, ST = CA, C = US Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4

Key: Sun RSA public key, 512-bit module: 918259138668032357411950417834123454841627062956107032316451473789495759399121276774435215843832980950021914780375114397tentent_1111:1161111_010_037_0_0_0_0_0% JCE Development, OU = Java Software, O = Sun Microsystems, L = Cupertino, ST = CA, C = US Serial Number: [02]

] Algorithm: [MD5withRSA] Signature: 0000: 2F E5 9C 54 5C A3 FA 25 E5 11 53 55 41 B3 4E 39 / .. T ..% .. SUA.N9 0010: 49 56 9A 59 97 1A 23 4A 29 79 C8 74 D7 1C D5 95 IV.Y .. # J) yt ... 0020: 32 8B E2 56 D3 39 A5 7D 9E E2 53 F7 91 62 11 04 2..V.9 .... S..b .. 0030: 24 1C 1D AD 4A 32 88 63 86 2E 8E E9 8B A2 73 00 $ ... J2.c ...... s.

]

Answer 3

So my conclusion from this exercise is that since jce itself needs MD5 to validate its classes for signature purposes, we cannot remove the MD5 algorithm from jre and therefore jre 1.6 itself cannot be triggered by a FIPS 180- complaint 3.

C # in FIPS cannot load MD5. Refer Is there an alternative MD5 hash algorithm for FIPS-enabled systems? . With the above test, I think java can not do this behavior.

Let me know if anyone objects to the observations or any obvious errors that I might have missed.