IBM Cloud Docs
Introducción a PKCS #11 -Plan estándar

Introducción a PKCS #11 -Plan estándar

PKCS #11 es un estándar que especifica una interfaz de programación de aplicaciones (API), denominada Cryptoki, para los dispositivos que contienen información criptográfica y realizan funciones criptográficas. La API Cryptoki sigue un método simple basado en objetos. El método abarca los objetivos de independencia tecnológica y el uso compartido de recursos, y presenta a las aplicaciones una vista lógica común del dispositivo denominada señal criptográfica.

Cryptoki aísla una aplicación de los detalles del dispositivo criptográfico. La aplicación no tiene que cambiar la interfaz a otro tipo de dispositivo ni a ejecutarse en un entorno distinto. Por lo tanto, la aplicación es portátil.Las funciones de la API Cryptoki se organizan en las categorías siguientes:

No todas las funciones de PKCS #11 están implementadas por IBM Cloud® Hyper Protect Crypto Services. Para las funciones de PKCS #11 implementadas, consulte Funciones de PKCS #11 soportadas.

Para revisar la documentación estándar de PKCS #11, consulte:

Componentes de implementación de PKCS #11

Para conectar y utilizar la API de PKCS #11, debe comprender la API de PKCS #11 que implementa Hyper Protect Crypto Services y la relación con la API de GREP11. Para obtener más información, consulte Comparación de la API de PKCS #11 con la API de GREP11. Con el soporte de la API PKCS #11, no es necesario cambiar las aplicaciones existentes que utilizan el estándar PKCS #11. Hyper Protect Crypto Services también proporciona los almacenes de claves aislados para almacenar claves criptográficas generadas por las funciones PKCS #11. Estas claves están protegidas por la clave maestra y las aplicaciones no ven nunca los archivos de claves localmente.

Para poder utilizar la API de PKCS #11, en primer lugar instale la biblioteca de PKCS #11. De este modo, la aplicación PKCS #11 puede interactuar con la biblioteca de PKCS #11, que luego invoca las funciones criptográficas implementadas por Hyper Protect Crypto Services mediante gRPC. El diagrama siguiente muestra las partes de claves que implementa la biblioteca Hyper Protect Crypto Services PKCS #11 y las interacciones entre las diferentes partes.

Realización de operaciones criptográficas con la API de PKCS #11
Figura 1. Realización de operaciones criptográficas con la API de PKCS #11

Las siguientes secciones explican en detalle cada componente de PKCS #11.

Aplicación

Una aplicación se ejecuta dentro de un único espacio de direcciones. Todas las hebras de control se ejecutan en la aplicación. Una aplicación se convierte en una aplicación de Cryptoki llamando a la función de Cryptoki C_Initialize desde una de las hebras. Después de realizar esta llamada, la aplicación puede llamar a otras funciones de Cryptoki. Cuando la aplicación finaliza utilizando Cryptoki, invoca la función Cryptoki C_Finalize y deja de ser una aplicación Cryptoki.

Si está ejecutando una aplicación Java PKCS #11 utilizando el proveedor SunPKCS11 en la plataforma IBM Z (s390x), asegúrese de que utiliza la JVM Semeru de IBM más reciente y especifique la opción -Xjit:noResumableTrapHandler Java al iniciar la aplicación. Puede descargar la última versión de s390x de la JVM de IBM Semeru cambiando el campo de filtro Arquitectura a s390x en la página de descargas de tiempo de ejecución deIBM Semeru.

Usuario

El estándar PKCS #11 define dos tipos de usuarios para el inicio de sesión: un responsable de seguridad (SO) y un usuario normal.Si un usuario no inicia sesión utilizando la función de Cryptoki C_Login, el usuario también se conoce como usuario anónimo. Solo el usuario normal puede acceder a los objetos privados de la señal y dicho acceso solo se otorga después de que se haya autenticado el usuario normal. En la implementación de PKCS #11 de Hyper Protect Crypto Services, los oficiales de seguridad y los usuarios normales están autenticados por claves de API. También se da soporte a usuarios anónimos.Para obtener instrucciones sobre cómo configurar los tipos de usuario de PKCS #11, consulte Mejores prácticas para configurar los tipos de usuario de PKCS #11.

Sesión

La API de Cryptoki requiere que una aplicación abra una o varias sesiones con una señal para obtener acceso a los objetos y las funciones de la señal. Una sesión proporciona una conexión lógica entre la aplicación y la señal. Una sesión puede ser una sesión de lectura/escritura (R/W) o una sesión de solo lectura (R/O).

Para obtener acceso a los objetos privados de la señal, el usuario normal necesita iniciar sesión y se autentica. Consulte la publicación PKCS #11 Cryptographic Token Interface Usage Guide para obtener una visión detallada de las sesiones.

Objeto de clave

Los objetos de clave se almacenan en el almacén de claves en memoria que reside con la aplicación PKCS #11 o en un almacén de claves con soporte de base de datos.Si el atributo CKA_TOKEN se establece en true para el objeto de clave, el objeto de clave se almacena en el almacén de claves respaldado por base de datos. De lo contrario, el objeto de clave se almacena en el almacén de claves en memoria.

Los objetos clave del almacén de claves en memoria no se rotan automáticamente después de la rotación de la clave maestra. Si los almacenes de claves PKCS #11 están habilitados en la instancia de servicio, debe reiniciar todas las aplicaciones PKCS #11 activas para borrar el almacén de claves en memoria después de que se haya completado la rotación de la clave maestra.

Tal como se muestra en el diagrama siguiente, un objeto de clave PKCS #11 es un ejemplo de una clase de objeto PKCS #11:

  • Datos: un objeto de datos se define mediante una aplicación.
  • Certificados: un objeto de certificado almacena un certificado.
  • Claves: un objeto de clave almacena una clave criptográfica. La clave puede ser una clave pública, una clave privada o una clave secreta. Cada tipo de estas claves tiene subtipos para su uso en mecanismos específicos.
    • Clave pública: el componente público de un par de claves utilizado por cualquiera para cifrar mensajes pensados para un destinatario concreto que tiene acceso a la clave privada del par de claves. La clave pública también se utiliza para verificar firmas creadas por la clave privada.
    • Clave privada: el componente privado de un par de claves que se utiliza para descifrar mensajes. La clave privada también se utiliza para crear firmas.
    • Clave secreta: una clave secreta es una corriente generada de bits que se utiliza para cifrar y descifrar mensajes de forma simétrica.

Clases de objeto PKCS #11
Figura 2. Clases de objeto PKCS #11

Cloud Identity and Access Management

IBM Cloud Identity and Access Management (IAM) proporciona autenticación de usuario y control de acceso para la implementación de la API de PKCS #11. Al utilizar las claves de API, la biblioteca de PKCS #11 obtiene señales de portador que se utilizan para realizar llamadas a la API Cryptoki.

Esta implementación de PKCS #11 equipara una clave de API con el PIN de un usuario. Para obtener más información sobre la configuración del ID de servicio y la clave de API correspondiente, consulte Crear los ID de servicio para el usuario de SO, el usuario normal y el usuario anónimo.

Servicio criptográfico

Como parte del proceso de inicialización de la biblioteca de PKCS #11, se realiza una conexión gRPC desde la biblioteca PKCS #11 a IBM Cloud. La conexión gRPC facilita que la biblioteca PKCS #11 llame a las funciones de Cryptoki, como C_Encrypt, C_Decrypt, C_Signy C_Verify, que requiere el uso de un módulo de seguridad de hardware (HSM).

Almacén de claves

Hay dos tipos principales de almacenes de claves disponibles:

  • Almacenes de claves en memoria: Almacena objetos de claves temporalmente en la memoria. Los objetos de clave que se almacenan en el almacén de claves en memoria también se conocen como objetos de sesión. Los objetos de sesión de una sesión específica se destruyen cuando se llama a la función C_CloseSession para dicha sesión. Los objetos de sesión de todas las sesiones se destruyen después de que se llame a la función C_Finalize.
  • Almacenes de claves respaldados por base de datos: Almacena objetos en bases de datos. Los objetos de clave que se almacenan en el almacén de claves respaldado por base de datos también se conocen como objetos de señal. Si se ha habilitado el parámetro sessionauth y se ha configurado una contraseña para el almacén de claves, se cifra y autentica el almacén de claves respaldado por la base de datos. De forma predeterminada, el parámetro sessionauth está inhabilitado. Para cada instancia de servicio, se da soporte a un máximo de cinco almacenes de claves autenticados. Puede habilitar el parámetro sessionauth para cifrar las claves generadas en el almacén de claves o para descifrar la clave antes de utilizarla. La contraseña puede tener 6-8 caracteres.

Las contraseñas del almacén de claves no se almacenan en la instancia de servicio. Como administrador del almacén de claves, es responsable de mantener una copia local de las contraseñas. Si se pierde una contraseña, debe ponerse en contacto con el equipo de soporte para restablecer el almacén de claves, lo que significa que se borran todos los datos del almacén de claves.

Tanto los almacenes de claves en memoria como los almacenes de claves respaldados por base de datos están formados por los siguientes tipos de almacenes de claves:

  • Almacén de claves público: almacena claves que son menos sensibles y a las que puede acceder cualquier tipo de usuario.
  • Almacén de claves privado: almacena claves que cifran datos confidenciales y a los que solo pueden acceder los usuarios normales.

En función de los tipos de usuario y de los valores de atributos de clave, las claves generadas se almacenan en distintos almacenes de claves. En la lista siguiente se resumen los criterios de cómo se almacenan las claves:

  • El valor de atributo CKA_TOKEN decide si la clave generada se almacena en un almacén de claves en memoria o en un almacén de claves respaldado por la base de datos.

    Si desea almacenar la clave en el almacén de claves respaldado por la base de datos, establezca CKA_TOKEN en TRUE en las plantillas de generación de pares de claves o claves. El proceso de inicialización de la biblioteca de PKCS #11 establece una conexión gRPC con IBM Cloud, lo que facilita el almacenamiento y la recuperación de objetos de claves a o desde el almacén de claves respaldado por base de datos.  De forma predeterminada, CKA_TOKEN se establece en FALSE, lo que significa que el objeto de clave se almacena en un almacén de claves en memoria dentro del espacio de direcciones de proceso de la aplicación PKCS #11 .

  • El valor de atributo CKA_PRIVATE decide si una clave generada por los usuarios normales se debe almacenar en un almacén de claves público o privado.

    De forma predeterminada, si un usuario ha iniciado la sesión como un usuario normal, las claves generadas se almacenan en los almacenes de claves privados, excepto en el caso de que CKA_PRIVATE esté establecido en FALSE. Si un usuario ha iniciado la sesión como un usuario de SO o no está conectado (conocido como un usuario anónimo), las claves generadas siempre se almacenan en los almacenes de claves públicas. Si un usuario de SO o un usuario anónimo especifica CKA_PRIVATE como TRUE en las plantillas de generación de claves, el servidor devuelve un error.

    Para un par de claves asimétricas, debe establecer el atributo CKA_PRIVATE por separado para las claves públicas y privadas, lo que significa que los pares de claves se pueden almacenar en distintos almacenes de claves.

Consulte la tabla siguiente para obtener explicaciones detalladas de la relación entre los tipos de usuario, los atributos de claves y los almacenes de claves, y cómo se almacenan las claves.

Tabla 1. Casos de almacenamiento de claves EP11 en distintos almacenes de claves
Tipo de usuario CKA_TOKEN CKA_PRIVATE Almacén de claves para claves ¿Privado o público?
Usuario de SO FALSE N/D Almacén de claves en memoria Público
Usuario de SO TRUE N/D Almacén de claves con soporte de base de datos Público
Usuario anónimo FALSE N/D Almacén de claves en memoria Público
Usuario anónimo TRUE N/D Almacén de claves con soporte de base de datos Público
Usuario normal FALSE FALSE Almacén de claves en memoria Público
Usuario normal FALSE TRUE Almacén de claves en memoria Privado
Usuario normal TRUE FALSE Almacén de claves con soporte de base de datos Público
Usuario normal TRUE TRUE Almacén de claves con soporte de base de datos Privado

Soporte de criptografía postcuántica

Con la API de PKCS #11 , también puede realizar operaciones criptográficas posteriores a la cuántica. La criptografía tradicional se basa en complicados problemas matemáticos que son difíciles de resolver para los ordenadores clásicos. Sin embargo, con su capacidad informática, los ordenadores cuánticos pueden resolver estos problemas. La criptografía postcuántica se considera resistente a los ataques criptoanalíticos de los ordenadores cuánticos. Por lo general, utiliza algoritmos asimétricos y tiene múltiples enfoques.

La API de PKCS #11 proporciona el algoritmo Dilithium para la criptografía posterior a la cuántica. Es un esquema de firma digital basado en Lattice y se puede utilizar para la generación y verificación de firmas. Actualmente, solo se da soporte a la versión de alta seguridad de la ronda 2 Dilithium y no está disponible para las operaciones C_SignUpdate y C_VerifyUpdate.

El algoritmo Dilithium solo está soportado por la tarjeta criptográfica IBM 4769, también denominada Crypto Express 7S (CEX7S). Si crea sus instancias en regiones basadas en Virtual Private Cloud (VPC), donde se utilizan las tarjetas criptográficas CEX7S, puede utilizar el algoritmo Dilithium para la criptografía postcuántica con la API PKCS #11. Para ver una lista de las regiones basadas en VPC, consulte Regiones y ubicaciones.

Para obtener más información sobre el soporte del algoritmo Dilithium en PKCS #11, consulte Referencia de API PKCS #11. También puede encontrar ejemplos de código de algoritmo de Dilithium en el repositorio de ejemploGitHub.