Softhsm
Se ha utilizado un wrapper PKCS#11 para implementar el soporte de tokens con librerías PKCS#11. El proveedor PKCS#11 se ha probado en algún momento con los HSM descritos aquí, en varias versiones de firmware y software (así como algunas que no se describen). Para obtener información sobre la compatibilidad con versiones específicas, consulte el soporte u otra documentación.
Además de las claves descritas en Módulos de seguridad de hardware (HSM), el campo de propiedad Crypto Token (que coincide con los valores fáciles de usar del Crypto Token en la GUI de administración) debe contener las siguientes propiedades:
Si no se especifica attributesFile, se utiliza una configuración predeterminada incorporada (a partir de EJBCA 3.11). Por lo general, NO se debe utilizar un attributesFile y, por tanto, sólo en casos excepcionales en los que se utilice un HSM poco común que no funcione bien con los valores predeterminados.
La configuración por defecto también deshabilitará ciertos mecanismos de firma. Los mecanismos deshabilitados son para la firma cuando los datos a firmar son hasheados por PKCS#11 antes de usar la clave privada en el HSM. Cuando estos mecanismos están desactivados, el proveedor de envoltura PKCS#11 de sun realiza el hash en lugar del HSM. Esto acelera la firma en la mayoría de los casos, especialmente cuando el HSM se encuentra en otro host, y no afecta a la seguridad, ya que no se utiliza ningún secreto del HSM para el hash.
Java security providerexception java lang reflect invocationtargetexception
La plataforma Java define un conjunto de interfaces de programación para realizar operaciones criptográficas. Estas interfaces se conocen colectivamente como Java Cryptography Architecture (JCA) y Java Cryptography Extension (JCE). Véase la Guía de referencia de la arquitectura criptográfica de Java (JCA).
Las interfaces criptográficas están basadas en proveedores. En concreto, las aplicaciones se comunican con las interfaces de programación de aplicaciones (API), y las operaciones criptográficas reales se realizan en proveedores configurados que se adhieren a un conjunto de interfaces de proveedores de servicios (SPI). Esta arquitectura admite diferentes implementaciones de proveedores. Algunos proveedores pueden realizar operaciones criptográficas en software; otros pueden realizar las operaciones en un token de hardware (por ejemplo, en un dispositivo de tarjeta inteligente o en un acelerador criptográfico de hardware).
El estándar de interfaz de tokens criptográficos, PKCS#11, ha sido elaborado por RSA Security y define interfaces de programación nativas para tokens criptográficos, como aceleradores criptográficos de hardware y tarjetas inteligentes. Las aplicaciones existentes que utilizan las API JCA y JCE pueden acceder a tokens PKCS#11 nativos con el proveedor PKCS#11. No es necesario modificar la aplicación. El único requisito es configurar correctamente el proveedor.
Pkcs11 ejemplo java
Para interactuar con una tarjeta inteligente o un dispositivo token con fines de autenticación o firma el PKCS#11 es uno de los estándares para hacerlo. Java proporciona el SunPKCS11 Provider, que es una especie de wrapper que podemos utilizar para interactuar con librerías nativas que se encargan de la comunicación con este tipo de dispositivos. Básicamente instalamos una librería (archivos dll, so, o dylib) en el sistema operativo, que suele ser proporcionada por el proveedor del dispositivo, y a través del proveedor SunPKCS11 indicamos el archivo de librería, el proveedor PKCS11 se encarga de interactuar con el dispositivo por nosotros.
Por lo tanto, Java tiene un soporte out of the box para interactuar con esos dispositivos. Sin embargo, en Java 9 se incluyeron algunos cambios sobre cómo podemos inicializar el SunPKCS11Provider y esos cambios ya no son compatibles con las versiones anteriores de Java.
Básicamente, dado un fichero /opt/bar/cfg/pkcs11.cfg con las configuraciones de ese proveedor (fichero de librería, nombre, etc). Conseguimos inicializar y configurar el SunPKCS11 en una sola línea, utilizando el constructor. Finalmente el nuevo proveedor es añadido al contexto de Seguridad.
Java 11 pkcs11
JCPROV es una envoltura Java para la API PKCS#11. JCPROV está diseñado para ser tan similar a la API PKCS#11 como lo permita el lenguaje Java, permitiendo a los desarrolladores que estén familiarizados con la API PKCS#11 desarrollar rápidamente programas basados en Java que ejerciten la API PKCS#11.
La biblioteca JCPROV se implementa en jcprov.jar, bajo el espacio de nombres com.safenetinc.jcprov. Va acompañada de una biblioteca compartida que proporciona los métodos nativos utilizados para acceder a la biblioteca PKCS#11 correspondiente. El nombre de la biblioteca compartida depende de la plataforma, como se indica a continuación:
Java VM en AIX no admite bibliotecas JNI de modo mixto. Las bibliotecas de modo mixto son bibliotecas compartidas que proporcionan interfaces tanto de 32 bits como de 64 bits. Por lo tanto, es esencial que seleccione la biblioteca JNI correcta para utilizarla con su Java VM.
1.Asegúrese de que el enlace simbólico /usr/safenet/lunaclient/jcprov/lib/libjcprov.a apunta a una versión de 32 bits de la biblioteca (libjcprov_32.a), por ejemplo /usr/safenet/lunaclient/jcprov/lib/libjcprov_32.a.
2.Asegúrese de que el enlace simbólico /usr/safenet/lunaclient/jcprov/lib/libjcryptoki.a apunta a una versión de 32 bits de la biblioteca (libjcryptoki_32.a), por ejemplo /usr/safenet/lunaclient/jcprov/lib/libjcryptoki_32.a.