Proveedor SunPKCS11 en Java 9

java-9 pkcs#11

Question

Hasta Java 8, el proveedor de SunPKCS11 se cargó así:

Provider provider = new sun.security.pkcs11.SunPKCS11 (new ByteArrayInputStream (configFile.getBytes ()));
Security.addProvider (provider);

configFile es una cadena con los parámetros de configuración. Por lo tanto, si la aplicación tuviera que trabajar con varias tarjetas inteligentes conectadas, podría crear múltiples proveedores. Para acceder a cada proveedor, el nombre utilizado fue "SunPKCS11-" seguido del nombre que indicamos en la configuración.

En Java 8, la clase sun.security.pkcs11.SunPKCS11 se eliminó en el JDK. Entonces, tuve que programar la convocatoria anterior por reflexión.

El funcionamiento del proveedor PKCS # 11 en Java 9 parece muy diferente:

• El constructor SunPKCS11 se ha cambiado a uno vacío. La configuración se carga mediante el método de "configuración", por lo que es obligatorio que esté en un archivo en el disco y ya no puedo cargarla a través de una secuencia a una cadena.

• Si intentamos utilizar el reflejo aparecen las siguientes advertencias:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by PruebaTarjeta (file:/C:/temp/pkcs11java9/classes/) to constructor
sun.security.pkcs11.SunPKCS11()
WARNING: Please consider reporting this to the maintainers of PruebaTarjeta
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

• En Java 9, un proveedor SunPKCS11 se genera automáticamente y está en la lista de proveedores criptográficos. Se puede obtener de la lista y configurar. El problema es que solo puede tener un proveedor PKCS # 11 cargado en la lista. La documentación de Java 9 indica que podemos obtener el proveedor PKCS # 11 con "SunPKCS11-" seguido del nombre que indicamos en la configuración, pero no es cierto. Si miramos la lista de proveedores, el único es "SunPKCS11", por lo que no puedo tener un proveedor por tarjeta inteligente.

¿Esto también le sucede a alguien más? ¿Alguna solución?

Answer 1

El problema es que solo puede tener un proveedor PKCS # 11 cargado en la lista.

La solución de su problema parece estar definida en el documento enlazado.

Para usar más de una ranura por implementación de PKCS#11 , o para usar más de una implementación de PKCS#11 , simplemente repita la instalación para cada uno con el archivo de configuración apropiado. Esto dará como resultado una instancia del proveedor Sun PKCS # 11 para cada ranura de cada implementación PKCS#11 .

La configuración de muestra siguiendo el attribute=value formato attribute=value sería:

name = FooAccelerator
library = /opt/foo/lib/libpkcs11.so
slot = 1

Además, puede hacer uso de los atributos en el archivo de configuración del proveedor PKCS # 11 en el mismo enlace para configurar más de un proveedor con diferentes Id. De ranura e índice de lista y diferentes atributos.

Answer 2

Noté mirando el javadoc para configure :

Aplique el argumento de configuración suministrado a esta instancia de proveedor y devuelva el proveedor configurado. Tenga en cuenta que si este proveedor no se puede configurar in situ, se creará y se devolverá un nuevo proveedor . Por lo tanto, las personas que llaman siempre deben utilizar el proveedor devuelto.

Esto me indica que el patrón prototipo se está utilizando aquí, y que el nuevo flujo de control para crear múltiples proveedores sería algo como:

Provider prototype = Security.getProvider("SunPKCS11");
Provider provider1 = prototype.configure(...);
Provider provider2 = prototype.configure(...);
...

En cuanto al uso de argumentos directamente en lugar de un nombre de archivo, investigué un poco el código fuente y lo encontré en sun.security.pkcs11.Config :

Config(String fn) throws IOException {
this.filename = fn;
if (filename.startsWith("--")) {
// inline config
String config = filename.substring(2).replace("//n", "/n");
reader = new StringReader(config);

Observe la línea con filename.startsWith("--") , este nombre de archivo proviene directamente del argumento a configure . Por lo tanto, debería poder pasar los argumentos de configuración como una cadena siempre que inicie la cadena con -- , y luego delimite los pares key=value con /n . (Actualmente no puedo probar esto).

Sin embargo, no puedo encontrar este hecho públicamente documentado en ninguna parte, por lo que podría estar sujeto a cambios, y también podría funcionar de manera diferente para diferentes proveedores, es decir, ¡ usarlo bajo su propio riesgo! .