Servidor de protección de Thales

A continuación se proporciona información para Thales ProtectServer .

Instalar software

Instale el software según las instrucciones de instalación de ProtectServer. A continuación, se muestran ejemplos de comandos para instalar el SDK rpm en un sistema Ubuntu, lo que implica convertirlo primero a un archivo deb.

Usando el SDK, puede usarlo como un buen emulador para pruebas y desarrollo. Si está instalando con un ProtectServer real, debería instalar el Runtime en lugar del SDK. Al usar el SDK, puede usar /opt/ETcpsdk/lib/linux-x86_64 en lugar de /opt/PTK/lib.

fakeroot alien -c $CDROM /Linux64/ptkc_sdk/ETcpsdk-3 .32.00-1.x86_64.rpm
sudo dpkg -i . /etcpsdk_3 .32.00-2_amd64.deb

Establecer contraseñas para el SO de administrador y el usuario de administrador

LD_LIBRARY_PATH=/opt/PTK/lib /opt/PTK/bin/ctconf

Crea 10 ranuras

LD_LIBRARY_PATH= /opt/PTK/lib /opt/PTK/bin/ctconf -c10

No establecer ninguna criptografía pública

Consulte Programación en modo FIPS en el Manual del programador de Protect Toolkit-C para obtener información sobre este indicador.

LD_LIBRARY_PATH= /opt/PTK/lib /opt/PTK/bin/ctconf -fc

Inicializar la ranura 5. Establece el SO y la contraseña del usuario.

LD_LIBRARY_PATH=/opt/PTK/lib /opt/PTK/bin/ctkmu t -s5 -lroot

Generar claves en la ranura 5

. /ejbcaClientToolBox .sh PKCS11HSMKeyTool generate /opt/PTK/lib/libcryptoki .so 2048 defaultSign 5
. /ejbcaClientToolBox .sh PKCS11HSMKeyTool generate /opt/PTK/lib/libcryptoki .so 2048 default 5
. /ejbcaClientToolBox .sh PKCS11HSMKeyTool generate /opt/PTK/lib/libcryptoki .so 512 test 5

Si se inició JBoss, debe reiniciar JBoss antes de que las claves estén disponibles en EJBCA.

Contenido de las propiedades del token de CA

Cuando crea la CA en EJBCA, ahora puede usar las propiedades de token de CA simples a continuación.

certSignKey defaultSign
crlSignKey defaultSign
defaultKey default
test testKey
sharedLibrary= /opt/PTK/lib/libcryptoki .so
slotLabelType=SLOT_NUMBER
slotLabelValue=5

Prueba y enumera las claves en la ranura 5

. /ejbcaClientToolBox .sh PKCS11HSMKeyTool test herramienta clave PKCS11HSM /opt/PTK/lib/libcryptoki .so 5
...
Testing of key: test
SunJCE version 1.7SunPKCS11-libcryptoki.so-slot3 version 1.7; modulus length: 2048; byte length 53. The docoded byte string is equal to the original!
SunPKCS11-libcryptoki.so-slot3 RSA private key, 512 bits ( id 4, token object, sensitive, extractable)
test Signature of key test1: signature length 64; first byte 3d; verifying true
Signings per second: 257
Decryptions per second: 260

Los atributos se enumeran como objeto de token, sensible, extraíble , y aquí es importante que diga sensible (extraíble solo significa que la clave se puede respaldar de forma segura usando herramientas de Thales).

Copia de seguridad y restauración

Cuando haya comprobado que todas las claves funcionan, debe hacer una copia de seguridad de ellas. Consulte cómo hacerlo en la documentación de ProtectServer. A continuación, borre la ranura de la que acaba de hacer una copia de seguridad:

ctkmu -s <slot nr> t

Luego, restaure la copia de seguridad según la documentación de ProtectServer y ejecute la prueba clientToolBox como se indicó anteriormente. Ahora, cuando sepa que las claves de la ranura se pueden restaurar desde el medio de copia de seguridad, debe configurar sus atributos para que no se puedan extraer del HSM por ningún medio. Lamentablemente, esto no se pudo hacer con la herramienta CLI ctkmu, ya que la clave privada no tiene etiqueta. En su lugar, utilice la interfaz gráfica de usuario de kmu . Para cada clave, haga lo siguiente:

  1. Seleccione el token e inicie sesión en él.

  2. Haga doble clic en la clave privada que desea proteger.

  3. Desmarque la casilla Exportable y presione OK

  4. Verifique que las casillas Exportable y Extraíble no estén marcadas y no se puedan cambiar.

  5. Verifique que las casillas Privado y Sensible estén marcadas y no se puedan cambiar

Ahora debería ser imposible realizar una copia de seguridad de la clave. Si tiene un protocolo de ceremonia de claves, conviene indicar que las claves se han convertido en no exportables . Tenga en cuenta también que el atributo Exportable debe estar desmarcado cada vez que se restaure la copia de seguridad.

El emulador tiene una característica molesta (solo el emulador, no el HSM real). Todas las claves de la misma longitud generadas son iguales, ya que la semilla del generador de números aleatorios es estática. Esto significa que una ranura solo puede tener una clave. Si se genera una segunda clave para una ranura, el objeto de certificado de la primera clave se elimina antes de escribir el objeto de certificado de la nueva clave. Esto se debe a que el proveedor de envoltorios Sun p11 no permite que haya dos claves iguales en un almacén de claves. Para solucionar esto, configure la variable de entorno ET_PTKC_SW_AUTOSEEDRNG=true.

Generación de claves mediante herramientas de ProtectServer

También puede generar claves y el certificado autofirmado necesario utilizando las herramientas de Thales incluidas con el HSM. Esto es útil, por ejemplo, si desea generar claves ECC con curvas no compatibles con el JDK (aunque es posible que deba aplicar un parche al JDK para poder usarlas).

Por ejemplo, los siguientes comandos generan una clave ECC con curva P-256 en la ranura 1, la almacenan en el HSM con el alias foo , le asignan un certificado autofirmado y finalmente enumeran el objeto de la ranura 1.

cd /opt/ETCprt/bin/linux-x86-64
. /ctkmu c -tec -nfoo -aPSVXxTRD -s1 -CP-256
. /ctcert c -s1 -lfoo
. /ctkmu l -s1

O puedes resumirlo todo en un solo comando...

./ctcert c -k -lfoo -tec -s1 -CP-256 -d30y

Si se inició JBoss, debe reiniciar JBoss antes de que las claves estén disponibles en EJBCA.