Módulos HSM disponibles en la interfaz de usuario de CA

Puede administrar tokens criptográficos completamente en la interfaz de usuario o CLI de EJBCA CA, y la interfaz de usuario de CA muestra automáticamente los HSM disponibles en su sistema.

Al crear un nuevo token criptográfico ( Tokens criptográficos>Crear nuevo ), puede seleccionar entre tokens criptográficos Soft y PKCS#11.

• La opción PKCS#11 solo está disponible si EJBCA puede encontrar cualquier módulo PKCS#11 conocido en el sistema de archivos.

Si EJBCA encuentra módulos PKCS#11 conocidos en el sistema de archivos, puede seleccionar PKCS#11 como Tipo. Como Biblioteca PKCS#11, se incluye una lista de los HSM conocidos disponibles en el sistema de archivos.

Si la opción PKCS#11 no está disponible o el HSM deseado no está en la lista de bibliotecas disponibles, hay algunas opciones para configurar:

• Si utiliza JBoss 7, debe permitir la exportación de las clases PKCS#11 de Java. Para obtener más información, consulte Servidores de aplicaciones .

• Puede configurar módulos PKCS#11 que EJBCA aún no conoce en conf/web.properties. Consulte conf/web.properties.sample para saber cómo agregar nuevos módulos conocidos y sobrescribir los existentes (no debería ser necesario sobrescribirlos, ya que puede agregar nuevas ubicaciones con el mismo nombre).

Para obtener más información sobre la creación y el uso de tokens criptográficos para HSM, consulte Administrar tokens criptográficos y Administrar CA.

Las siguientes secciones describen las operaciones subyacentes y las características técnicas del uso de HSM y PKCS#11.

Configuración de HSM

La configuración GUI de las CA se basa en un campo de propiedades donde se especifican las propiedades exclusivas del uso del HSM por parte de una CA específica. Todos los módulos HSM implementados utilizan las mismas palabras clave de propiedad para definir la identidad y el propósito de las claves utilizadas. Estas palabras clave son:

• certSignKey: Clave utilizada al firmar certificados, puede ser RSA o ECDSA.

• crlSignKey: Clave utilizada al firmar CRLs, puede ser RSA o ECDSA.

• keyEncryptKey: Clave utilizada para el cifrado y descifrado de claves, debe ser una clave RSA.

• testKey: clave utilizada por las comprobaciones de estado del HSM, puede ser RSA o ECDSA.

• hardTokenEncrypt: Clave utilizada para el cifrado y descifrado de hardtokens. El PUK se descifrará con esta clave.

• defaultKey: Clave utilizada cuando no se define ninguna otra clave para un propósito. Si esta es la única definición, se usará para todos los propósitos.

• PIN: Código PIN opcional para la activación automática de un token de CA (véase más abajo). No se recomienda para configuraciones de alta seguridad, pero es muy útil en algunos casos.

Puede omitir defaultKey si desea asegurarse de usar la clave correcta, pero en ese caso, deberá especificar todas las demás claves. Se recomienda que las claves de firma del certificado y de la CRL estén vinculadas a la misma clave, ya que las aplicaciones de verificación rara vez admiten claves diferentes.

Al implementar la compatibilidad con un nuevo HSM, se podría usar la clase KeyStrings para gestionar las propiedades de clave descritas anteriormente. Si se trata de una API JCA/JCE para el HSM, también sería recomendable extender la clase BaseCAToken.

Se debe utilizar el mismo código de activación para todas las claves utilizadas por una CA.

Hay cuatro propiedades de clave adicionales que se pueden usar (opcionalmente) al renovar claves de CA y generar certificados de renovación. Algunas de estas (en particular, las siguientes claves) solo se usan al usar métodos de API (como WS).

• previousCertSignKey: alias de la clave de firma anterior, a diferencia de certSignKey , que es la clave de firma actual.

• previousSequence: Secuencia que identifica la clave de firma anterior, a diferencia de la secuencia actual contenida en el token de la CA. Esta secuencia reemplazará la secuencia actual en el campo caRef al firmar una solicitud con la clave anterior de la CA.

• nextCertSigningKey: Alias de una nueva clave generada en el HSM. Al actualizar una CA firmada por una CA externa, se utiliza para enviar una solicitud, pero la CA sigue activa con la clave anterior. Al recibir la respuesta del certificado, esta clave se activa y se transfiere a certSignKey/crlSignKey.

• nextSequence: secuencia que identifica la siguiente clave de firma.

A continuación se describen los HSM compatibles y probados, con configuraciones de muestra y documentación específica del HSM.

A partir de EJBCA 3.6, el conector HSM recomendado utiliza la interfaz PKCS#11. Las implementaciones JCE anteriores están obsoletas y se han eliminado. Contacte con PrimeKey si necesita migrar.

Prueba de claves PKCS#11 para su uso por EJBCA

Para probar claves en el HSM para su uso por EJBCA, puede utilizar la Caja de herramientas del cliente EJBCA .

El comando proporciona instrucciones adicionales sobre los parámetros requeridos, la biblioteca PKCS#11 y la ranura.

Activación automática de tokens criptográficos

La propiedad pin se utiliza para activar automáticamente un token de CA. El código de activación puede especificarse en el campo de propiedad con la palabra clave pin . Si no se especifica esta propiedad, la CA debe activarse manualmente después de cada reinicio o reimplementación de EJBCA. La activación manual se realiza en la interfaz gráfica de usuario de administración, en Funciones básicas > Ver información , o mediante la CLI bin/ejbca.sh ca activateca .

La propiedad pin puede utilizar una contraseña de texto claro o una encriptada.

Estas dos propiedades contienen la misma contraseña. El valor del PIN ofuscado se puede obtener con el comando bin/ejbca.sh encryptpwd :

HSM y DSA o ECDSA

La compatibilidad con DSA o ECDSA en HSM depende de la compatibilidad con los algoritmos en el HSM y es necesario confirmar si la compatibilidad está disponible.

Para obtener más información sobre HSM y ECDSA, consulte Claves y firmas ECDSA .

Información específica del proveedor

Para obtener información de instalación y configuración específica del proveedor de HSM, consulte las siguientes secciones.

• AEP Keyper

• ARX CoSign

• AWS CloudHSM

• AWS KMS

• Azure Key Vault y HSM administrado

• Módulo de seguridad de hardware BlackVault

• Tarjeta criptográfica PCI Bull Trustway

• Protección Bull Trustway

• Gerente de seguridad de datos de Fortanix

• Proveedor genérico de PKCS#11

• Sistema de gestión de claves de Google

• nCipher nShield/netHSM

• HSM de Nitrokey

• Servicio Securosys Primus HSM y CloudsHSM

• Tarjeta inteligente-HSM

• SoftHSM

• Thales DPoD

• Thales Luna HSM

• Servidor de protección Thales

• Thales TCT Luna SA

• HSM Trident

• Servidor criptográfico Utimaco CP5

• Servidor criptográfico Utimaco

• YubiHSM 2

• Control de clave sin límites

Compatibilidad con nuevos HSM

EJBCA usa PKCS#11 y, en teoría, admite cualquier HSM que ofrezca una implementación PKCS#11 adecuada. Si el HSM no es común, es posible que deba proporcionar parámetros de atributo específicos, como se describe para un archivo 'attributesFile'; consulte Proveedor genérico de PKCS#11.

Espía PKCS11

Puede depurar sesiones PKCS11 y todas las llamadas realizadas con P11Spy de OpenSC. A partir de EJBCA 6.8.0, P11Spy se incluye por defecto en la implementación conocida de P11 en con/web.properties.

Detenga JBoss, instale P11Spy y configure las variables de entorno utilizadas en la terminal JBoss:

Luego, inicie JBoss y cree un nuevo token criptográfico PKCS11 usando la biblioteca PKCS#11 PKCS11Spy.

Reenvío remoto de PKCS#11 mediante P11-Kit

P11-kit se puede usar para reenviar, por ejemplo, un HSM de token USB conectado a su portátil local a un servidor con EJBCA. Esto le permite controlar su HSM mientras ejecuta el servidor en otro lugar, por ejemplo, en la nube. Requiere cierta configuración y trabajo al desconectar y conectar el token, pero puede funcionar en implementaciones a pequeña escala.

A continuación, se presenta un esquema de comandos para que un HSM NitroKey (conectado localmente) esté disponible para un servidor remoto (remoto) mediante P11-kit. EJBCA se ejecuta en el servidor remoto. Esto se basa en información de Maxence Mohr sobre PKI y HSM en un SME y remote-hsm , y se ha probado en Ubuntu 16.04 y 18.04.

Uso de SHA256 con RSA y MGF1 (RSASSA-PSS)

Se pueden crear CA mediante HSM compatibles con el algoritmo SHA256WithRSAandMGF1, también conocido como SHA256WithRSASSA-PSS (y SHA384 y SHA512). El software de EJBCA lo admite, pero algunas versiones del proveedor Java PKCS#11 no.

La compatibilidad con RSASSA-PSS se implementó en OracleJDK 8u241, OpenJDK 8u272 y 11.0.6. En JDK 8, solo funciona con claves RSA mayores de 4096 bits debido a este error (corregido en JDK 11, pero no implementado en JDK 8). La compatibilidad predeterminada en Java PKCS#11 solo funciona con EJBCA 7.4.3.2 y versiones posteriores.

Las versiones anteriores de OpenJDK y OracleJDK no son compatibles con SHA256WithRSAandMGF1 (también conocido como RSASSA-PSS) en el proveedor PKCS#11. PrimeKey ha creado un parche para estas versiones del JDK. Los usuarios empresariales pueden obtener un parche compilado junto con un script de instalación para sistemas operativos basados en Debian desde PrimeKey . El parche debería funcionar con HSM compatibles con SHA256WithRSAandMGF1.

Los problemas relevantes en el rastreador de problemas de EJBCA son ECA-2014 y ECA-9679 .

Ampliación de Sun PKCS#11 para establecer CKA_MODIFIABLE=false

Para cambiar el atributo CKA_MODIFIABLE de una clave privada a FALSE directamente después de su generación, se debe extender la implementación de Sun PKCS#11. Esta extensión se realiza añadiendo clases a la ruta de clases de Extensiones instaladas . Consulte https://docs.oracle.com/javase/tutorial/ext/basics/install.html.

Esto se consigue mediante:

• Construyendo cesecore-p11.jar con el comando 'ant -Dbuild.cesecore.p11.jar=true build'

• colocando '$EJBCA_HOME/dist/ext/cesecore-p11.jar' en uno de los directorios definidos por la propiedad del sistema 'java.ext.dirs'.

Puedes colocar el archivo jar en '$JAVA_HOME/jre/lib/ext'. También puedes cambiar la propiedad para incluir el directorio del archivo jar. Aquí tienes un ejemplo:

Asegúrese de mantener '$JAVA_HOME/jre/lib/ext' en la ruta de clases.

Para habilitar la función en EJBCA, configure 'pkcs11.makeKeyUnmodifiableAfterGeneration=true' en $EJBCA_HOME/conf/cesecore.properties.

Si usa '$EJBCA_HOME/dist/ejbcaClientToolBox.sh' no tiene que configurar el parámetro java.ext.dirs ya que la configuración la realiza el script.

Todo funcionará sin este jar en el classpath, pero si no está en el classpath, CKA_MODIFIABLE será VERDADERO para cada clave que se genere y se escribirá una advertencia en el registro.

La razón para establecer CKA_MODIFIABLE como FALSO es que no debería ser posible establecer CKA_DERIVE como VERDADERO. Si CKA_DERIVE es verdadero, podría ser posible extraer la clave privada de algunos HSM (CVE-2015-5464), aunque la mayoría de los proveedores han corregido este problema al no permitir esquemas de derivación de claves débiles.

Ciertos HSM (por ejemplo, SoftHSM2) se niegan a establecer CKA_MODIFIABLE en FALSO (el estándar PKCS#11 dice que este comportamiento es correcto).

En resumen, la configuración requiere pruebas exhaustivas. Las pruebas se pueden realizar con la herramienta clientToolBox con un ciclo de generación y prueba:

Si también genera claves utilizando la GUI de administración, esto también debe probarse, junto con reiniciar JBoss entre la generación y el uso.