Por qué se necesita MD5 para la inicialización de JCE

Question

Estoy experimentando con la activación de FIPS 180-3 en mi aplicación Java. FIPS 180-3 solo permite el uso de 5 [hashes] seguros (http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf), MD5 no es uno de ellos. Por lo tanto, estoy tratando de eliminar programáticamente los algoritmos MD5 del proveedor de Sun. Este es el código de muestra.

---

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");     
} 

---

Pero esto es tirar la siguiente excepción. Si comenta "sun.remove (..." el programa funciona bien. Si elimino MD2, en lugar de MD5, también funciona bien.

Para mí, parece que las jre libs están usando MD5 para su firma, pero he comprobado jre/lib ext/firmante/sunjce_provider.jar y su uso de SHA1.

Cualquier idea de por qué mi código está fallando con este error?

Excepción en el hilo "principal" java.lang.ExceptionInInitializerError en javax .crypto.Cipher.getInstance (DashoA13 * ..) en TestRemoveMD5.main (TestRemoveMD5.java:20)

causada por: java.lang.SecurityException:. No se puede configurar para los CERT CA de confianza en javax.crypto.SunJCE_b (DashoA13 * ..) ... 3 más

causada por: java.lang.SecurityException: Las clases de firma han sido adulteradas con en javax.crypto.SunJCE_b.d (DashoA13 * ..) en javax.crypto.SunJCE_b.c (DashoA13 * ..) en javax.crypto.SunJCE_b $ 1.run (DashoA13 *. .) en java.security.AccessController.doPrivileged (Método nativo) ... 4 más

Answer 1

Esta es una función de seguridad que impide que un código no confiable elimine un proveedor de Sun. Hay una manera de hacerlo que implica tener los permisos adecuados para hacerlo. Si va a este enlace http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html y se desplaza hacia abajo hasta el título del título La clase de seguridad puede leer sobre cómo eliminar un proveedor y qué sucederá.

EDITAR

Extractos de los documentos que van otra vez que los proveedores instalados que no son extensiones pueden recompensar a un archivo de política para llevar a cabo ciertas acciones tales como agregar y quitar un proveedor. Vale la pena intentarlo.

La documentación del proveedor de cada proveedor que utilizará debe incluir información sobre qué permisos requiere y cómo otorgar tales permisos. Por ejemplo, los siguientes permisos pueden ser necesarios por un proveedor si no es una extensión instalada y un gestor de seguridad está instalada

-

La clase de seguridad gestiona los proveedores y de toda la seguridad instaladas propiedades. Solo contiene métodos estáticos y nunca se crea una instancia. Los métodos para agregar o eliminar proveedores, y para establecer las propiedades de Seguridad, solo pueden ser ejecutados por un programa confiable.Actualmente, un "programa de confianza" es o bien

• una aplicación local no se ejecuta en un controlador de seguridad, o
• un applet o aplicación con permiso para ejecutar el método especificado (véase más adelante).

La determinación de que el código se considera de confianza para realizar un intento de acción (como agregar un proveedor) requiere que el applet tenga los permisos adecuados para esa acción en particular.

-

Cada "concesión" declaración en un archivo de este tipo de subvenciones una fuente de código especifica un conjunto de permisos, especificando los que se permiten acciones.

Aquí es un archivo de configuración de política de muestra:

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

Answer 2

supongo que podría haber descubierto la causa principal, pero todavía no le encontré averiguar desde donde su entrada. Intenté depurar X509CertImpl y obtuve un certificado firmado por "JCE Development" que usa MD5. Pero todos los demás certificados cargados fueron firmados correctamente usando SHA1withDSA. No estoy seguro de si esto debería ser un error en jre.

[ [ Version: V1 Asunto: CN = JCE Desarrollo, OU = Java Software, O = Sun Microsystems, L = Cupertino, ST = CA, C = US Algoritmo Firma: MD5withRSA, OID = 1,2. 840.113549.1.1.4

clave: clave pública RSA Sun, 512 bits módulo: 9182591386680323574119504178341234548416270629561070323164514737894957593991212767744352158438329809500219147803751143974067780130174290713135793698837217 exponente público: 65537 validez: [Desde: Mar Oct 31 de 2002 20:57:44 IST, Para: Mar Nov 31 de 20:57:44 IST 2007] Emisor: CN = Desarrollo JCE, OU = Java Software, O = Sun Microsystems, L = Cupertino, ST = CA, C = US SerialNumber: [02]

] Algoritmo: [MD5withRSA] Firma: 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

Así que mi inferencia a partir de este ejercicio es que desde JCE en sí necesita MD5 para verificar sus clases a efectos de firma, que no podemos eliminar el algoritmo MD5 de JRE y por lo tanto JRE 1.6 en sí no se puede hacer FIPS 180-3 queja .

C# en FIPS no se puede cargar MD5. Consulte Is there an alternate hashing algorithm to MD5 for FIPS-enabled systems?. Con la prueba anterior, supongo que java no puede hacer ese comportamiento.

Háganme saber si alguien objeta por observación o cualquier error obvio que pueda haber pasado por alto.