Ir al contenido

Integración mediante PKCS#11

Introducción

PKCS#11(Public Key Cryptography Standards number 11) define una API también llamada Cryptoki(Cryptographic Token Interface Standard) que se utiliza para gestionar los ciclos de vida de las claves y realizar operaciones criptográficas dentro de un dispositivo.

Estas API normalizadas permiten a las aplicaciones utilizar servicios de cifrado con independencia de los proveedores de dispositivos.

Dinamo PKCS#11 permite la integración entre una aplicación que utilice el estándar y elHSM. Este Cryptoki está construido sobre la API nativa del HSM y proporciona los algoritmos presentes en el HSM.

A partir de la versión 3.1.0 del paquete cliente HSM y de la versión 3.9.0.0 del firmware, se ha actualizado la arquitectura de la aplicación.

Atención

La versión de la biblioteca PKCS#11 y el firmware del HSM deben ser compatibles para poder migrar a esta nueva versión.

Dinamo Dinamo Si tiene versiones anteriores a 3.1.0 del cliente, 2.0.0.0 de la librería PKCS#11 y/o versión del firmwaredel HSM anterior a 3.9.0.0 y desea migrar a la nueva versión, póngase en contacto con el soporte de su proveedor.

Visión general

Inicialmente, con el aumento del uso de dispositivos de cifrado portátiles (SmartCards, Tokens, PCMCIA...) se identificó la necesidad de una API(Interfaz de Programación de Aplicaciones) de cifrado estándar que permitiera la interoperabilidad entre las aplicaciones y los distintos dispositivos y fabricantes.

PKCS#11 ha venido a resolver este problema de forma simplificada, portátil y con API de alto nivel, definiendo interfaces y comportamientos básicos de los tokens.

Con el tiempo, PKCS#11 se ha utilizado ampliamente y se ha convertido en el estándar del mercado para dispositivos que almacenan y realizan operaciones criptográficas, e incluso se ha utilizado con HSM.

Los objetivos de PKCS#11 son

  • Una visión sencilla de los objetos criptográficos.
  • Independencia tecnológica. Poder utilizar cualquier dispositivo.
  • Uso compartido de recursos. Varias aplicaciones pueden utilizar varios dispositivos. Permite el uso de diferentes tokens criptográficos sin cambiar el código de la aplicación.
  • Vista lógica común del dispositivo, denominada "Token criptográfico".
  • Portabilidad. Funciona en diferentes sistemas operativos.
  • Definir los tipos de objetos y sus atributos.
  • Definir las operaciones criptográficas.

Información sobre la API Cryptoki PKCS#11:

  • Lenguaje: ANSI C
  • Nombre API: Cryptoki, PKCS#11
  • Responsable: OASIS
  • Formato: Biblioteca (puede ser dinámica o estática)
  • Cabeceras: pkcs11.h incluye los archivos pkcs11t.h e pkcs11f.h

Modelo general

Pasos para que una aplicación realice una operación criptográfica en el modelo PKCS#11:

  1. Carga una librería Cryptoki (una dll en windows o una so en linux);
  2. Realiza una llamada a una de sus API;
  3. Esta llamada pasa por una ranura;
  4. Y finalmente llegas a la ficha.
---
title: Modelo Geral Cryptoki
---

%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%

flowchart TD

    classDef red_s stroke:#f00
    App1[Aplicação 1]
    Appk[Aplicação k]
    p11.1[Biblioteca PKCS#11<br>#40;CryptoKi#41;]
    p11.2[Biblioteca PKCS#11<br>#40;CryptoKi#41;]
    sync[Contenção/Sincronização]
    slot1[Slot 1]
    slotk[Slot k]
    token1[Token 1<br>#40;Device 1#41;]
    tokenk[Token k<br>#40;Device k#41;]

    App1 --> p11.1
    Appk --> p11.2
    p11.1 --> sync
    p11.2 --> sync
    sync --> slot1
    sync --> slotk
    slot1 --> token1
    slotk --> tokenk

La ranura corresponde a un lector físico (por ejemplo, un lector de tarjetas inteligentes). El token corresponde a un dispositivo (por ejemplo, una tarjeta inteligente).

Las ranuras y las fichas son representaciones lógicas.

La librería PKCS#11 Cryptoki está definida en C. Para acceder a Cryptoki desde otro lenguaje (Java, .Net, etc.) es necesario crear una interfaz entre los lenguajes. Existen en el mercado varias integraciones PKCS#11 en diferentes lenguajes, son fáciles de encontrar y algunas incluso son nativas.

Nota

Dinamo sólo tiene una ranura, que es la número 1.

Vista Token Logic

Cryptoki divide los objetos en 3 clases:

  • Datos
  • Certificados
  • Claves

Las llaves pueden ser:

  • Público
  • Privado
  • Secreto
---
title: Hierarquia de Objetos
---

%%{ init: { 'flowchart': { 'curve': 'bumpY' } } }%%

flowchart TD

    classDef red_s stroke:#f00
    obj[Objeto]
    data[Dado]
    key[Chave]
    cert[Certificado]
    pubk[Chave Pública]
    privk[Chave Privada]
    seck[Chave Secreta]

    obj --> data
    obj --> key
    obj --> cert
    key --> pubk
    key --> privk
    key --> seck

    linkStyle 0,1,2,3,4,5 stroke-width:1px;

Los objetos también pueden dividirse:

  • De por vida
  • Objetos token: son persistentes. Permanecen en el token aunque se cierre la sesión;
  • Objetos de sesión: son temporales. El objeto deja de existir cuando se cierra la sesión que lo creó.
  • Por nivel de acceso
    • Objetos privados: sólo se puede acceder a ellos si el usuario está autenticado;
    • Objetos públicos: se puede acceder a ellos incluso con una sesión no autenticada.

Dinamo no permite el acceso a un objeto a menos que el usuario esté debidamente autenticado. Todos los objetos son arquitectónicamente privados.

Los objetos también tienen atributos específicos según cada tipo, como el módulo o el exponente de una clave RSA.

Las implementaciones de Cryptoki no están obligadas a implementar todos los objetos y mecanismos. Se espera que haya una adaptación lógica de la implementación de Cryptoki para ajustarse a las particularidades de las definiciones de PKCS#11.

Usuarios

PKCS#11 define 2 tipos de usuarios:

  • Responsable de seguridad: realiza operaciones administrativas, como inicializar el token, establecer el PIN de un usuario normal y, posiblemente, manipular objetos públicos.
  • Usuario ordinario - tiene acceso a objetos privados (sólo cuando el usuario está autenticado).

Dinamo En , los operadores y los usuarios ordinarios pueden crear y utilizar objetos privados. No hay distinción entre tipos.

El usuario que utilizará Criptoki se define a través de la configuración o, alternativamente, mediante un parámetro de contraseña.

La operación de inicialización del token no está soportada a través de Cryptoki, por lo que puede descartarse. En HSM, la inicialización se realiza a través de la consola local.

La configuración del PIN no está soportada a través de Cryptoki y por lo tanto puede ser ignorada. El PIN sólo se crea/modifica cuando se crea el usuario o cuando el usuario lo modifica.

Hilos

Atención: afinidad entre hilos de sesión

Las sesiones de HSM tienen afinidad sesión-hilo. Esto significa que la misma sesión no puede ser utilizada por varios hilos al mismo tiempo.

Las sesiones sólo pueden realizar una operación a la vez. Esto significa que no se pueden realizar varias llamadas simultáneas a Criptoki utilizando la misma sesión. Se recomienda abrir una sesión por hilo o asegurarse de que la sesión se utiliza para realizar una sola operación a la vez.

Dinamo Criptoki utiliza su propio mecanismo decierre.

Sesión

Las sesiones pueden ser de sólo lectura (R/O) o de lectura-escritura (R/W). Sólo lectura se refiere a objetos tokenizados.

  • Sólo lectura: sólo se pueden leer objetos token.
  • Lectura-Escritura: puede crear, leer, escribir y destruir objetos de sesión y token.

Dinamo No hay distinción entre las sesiones de sólo lectura y las de lectura y escritura. El usuario siempre tiene permiso total sobre sus objetos.

Las sesiones pueden ser autenticadas o no autenticadas.

  • Autentificado: El usuario tiene permiso sobre objetos públicos y privados.
  • No autenticado: El usuario sólo tiene permiso sobre objetos públicos.

Dinamo On sólo puede ver los objetos propios del usuario, y éste debe estar autentificado.

Más información

Las claves privadas y secretas pueden marcarse como sensibles o no extraíbles:

  • sensible: la clave puede exportarse, pero sólo de forma cifrada.
  • inextractable: la clave no puede exportarse de ninguna manera.

Dinamo sólo tiene la opción de que la clave sea exportable o no, independientemente de la forma de exportación. Las opciones extraíbles y sensibles de PKCS#11 están relacionadas con la opción de claves exportables en HSM. Por ejemplo, una clave sensible no puede exportarse ni siquiera cifrada.

PKCS#11 HSM Dinamo

De acuerdo con las definiciones de PKCS#11, no se espera que una implementación de Criptoki soporte todas las opciones. Dinamo Criptoki de proporcionará las operaciones que ofrece elHSM y que están soportadas por la especificación PKCS#11.

Los mecanismos que admite HSM pueden verse aquí.

Dinamo A continuación se resumen algunos detalles de la aplicación.

  • Compatible con la versión v2.40 de PKCS#11;
  • Permite utilizar usr:password@ip en lugar de la contraseña, si la opción está activada.
  • Sólo tiene una Ranura(número 1).
  • Etiqueta de la ficha fija como Dinamo "HSM".
  • Permite el acceso a los objetos sólo a las sesiones autenticadas.
  • Los operadores y los usuarios ordinarios pueden crear y utilizar objetos privados. No hay distinción entre tipos.
  • Dinamo Criptoki utiliza su propio sistema decierre.
  • Se puede prescindir de la inicialización del token y de la configuración del PIN. Esto se hace a través de la configuración del propio dispositivo.
  • El usuario que utilizará Criptoki se define a través de la configuración o, alternativamente, mediante un parámetro de contraseña.
  • El usuario siempre tiene permiso total sobre sus objetos. No hay distinción entre sesiones de Sólo Lectura y de Lectura-Escritura.
  • No hay opción para sesiones no autenticadas.
  • DinamoConsulte la lista de posibles configuraciones de Criptoki para más detalles.
  • Las claves sólo tienen la opción de ser exportables o no, independientemente de cómo se exporten. Las opciones extraíbles y sensibles están relacionadas con la opción de claves exportables. Por ejemplo, una clave sensible no puede exportarse ni siquiera cifrada.

Referencias