Geekly articles weekly

Token PKCS # 11: generación de pares de claves y no extractabilidad de clave privada (Continuación)

imagenEn el artículo anterior "PKCS # 11 Tokens: certificados y claves privadas " examinamos cómo asociar de forma exclusiva el trío Certificado x Clave pública x Clave privada almacenada en el token / tarjeta inteligente con la interfaz PKCS # 11 v.2.40. En este artículo hablaremos sobre la generación de pares de claves. Confiaremos , como la última vez, en “GOST R 34.10-2012 Tecnología de la información. Seguridad de la información criptográfica. Los procesos de formación y verificación de firmas digitales electrónicas " .

Entonces, ¿qué es un par de claves?


El par de claves incluye dos claves:

  • / /Private key — , . / ;

  • / / Public key — , , .

Debe recordarse que las claves privadas y públicas no son solo sus valores (para la clave pública GOST R 34.10-2001 es 512 bits), sino también los parámetros del esquema de firma digital (cláusula 5.2 de GOST R 34.10-2012 ). En el futuro, por simplicidad, llamaremos a los parámetros del esquema de firma digital los parámetros (parámetros criptográficos) del par de claves.

La clave pública de la firma se calcula como el valor de alguna función de la clave privada, pero el conocimiento de la clave pública hace que sea imposible determinar la clave privada.

Para los pares de claves GOST R 34.10-2001 y GOST R 34.10-2012 con una longitud de clave privada de 256 bits (respectivamente, una clave pública es de 512 bits), se definen los siguientes parámetros criptográficos:
  1. id-GostR3410-2001-CryptoPro-A-ParamSet;
  2. id-GostR3410-2001-CryptoPro-B-ParamSet;
  3. id-GostR3410-2001-CryptoPro-C-ParamSet;
  4. id-GostR3410-2001-CryptoPro-XchA-ParamSet;
  5. id-GostR3410-2001-CryptoPro-XchB-ParamSet.

Para los pares de claves GOST R 34.10-2012 con una longitud de clave privada de 512 bits (respectivamente, una clave pública es de 1024 bits), se definen los siguientes parámetros criptográficos ("Tecnología de la información. Protección criptográfica de la información. Parámetros de curva elíptica para algoritmos y protocolos criptográficos"):
  1. id-tc26-gost-3410-2012-512-paramSetA;
  2. id-tc26-gost-3410-2012-512-paramSetB.

La composición de los criptoparámetros se define en la cláusula 5.2 de GOST R 34.10-2012 . Esta estructura incluye un primo q : el orden del subgrupo del grupo de puntos de la curva elíptica:

imagen

Y determina la longitud de la clave privada / pública y la corrección de la clave privada:

imagen- la longitud de la clave privada es de 256 bits;

imagen- La longitud de la clave privada es de 512 bits.
Y así, la clave pública se obtiene de la clave privada.

¿Y de dónde viene la clave privada?


Para obtener una clave privada, primero debe decidir cuánto durará la clave privada (256 o 512 bits), luego decidir los parámetros criptográficos del par de claves. Ahora tomamos el sensor de números aleatorios y obtenemos un número aleatorio de la longitud correspondiente. En realidad, este número aleatorio debería convertirse en el valor d de la clave privada (clave de firma d). Este valor debe satisfacer la siguiente regla:

0 <d <q , donde q es un número primo de parámetros criptográficos.

¿Qué pasa si no se cumple esta condición? Si d == 0 , simplemente genera un nuevo número aleatorio. De lo contrario, es suficiente tomar el resto de dividir por un entero el valor de d , que excede q , porq (d% q) . El resto se convertirá en el valor de la clave privada.

Es por eso que el regulador (FSB de Rusia) hace demandas especiales sobre el sensor de números aleatorios.

Como ejemplo de la fuente principal para llenar el búfer:

  • los números aleatorios incluyen:
  • registro TSC del procesador - contador de reloj del procesador;
  • Contador de tiempo GTC
  • contador de incremento automático en un hilo separado;
  • función estándar rand ();
  • coordenadas del mouse

Como fuentes adicionales para llenar este búfer pueden ser:

  • El contador de procesos en modo de usuario;
  • Temporizador de alta resolución de Windows.

Por lo tanto, para que el token / tarjeta inteligente PKCS # 11 genere un par de claves dentro de sí mismo, es necesario tener un token / tarjeta inteligente con un sensor de número aleatorio de hardware incorporado que cumpla con los requisitos del controlador. Y solo entonces podemos hablar sobre la no remoción de la clave privada.

Para generar un par de claves, se utiliza la función C_GenerateKeyPair . Dependiendo de qué par de claves (con qué longitud de clave privada es 256 o 512 bits) generamos, se utilizará el mecanismo apropiado:

  • CKM_GOSTR3410_KEY_PAIR_GEN para un par de claves con una clave privada de 256 bits;
  • CKM_GOSTR3410_512_KEY_PAIR_GEN para un par de claves con una clave privada de 512 bits.

Al generar un par de claves, sus atributos se establecen, por ejemplo, parámetros criptográficos:

imagen

Estamos interesados ​​en los atributos de recuperación de clave privada.


Este era anteriormente el atributo CKA_SENSITIVE, que es responsable de obtener el valor de la clave privada. Si el valor del atributo CKA_SENSITIVE está establecido en CK_TRUE, entonces la clave privada no se puede extraer del token en el borrado. El segundo atributo CKA_EXTRACTABLE le permite obtener la clave privada en forma cifrada. Para hacer esto, debe establecerse en CK_TRUE.

Establecer el atributo CKA_SENSITIVE en CK_TRUE y el atributo CKA_EXTRACTABLE en CK_FALSE cuando se genera el par de claves hace que la clave privada sea completamente irrecuperable. La capacidad de determinar si la clave es exportable está disponible en el navegador Redfox:

imagen

Alguien dirá: ¿y si cambiamos los valores de estos atributos? Como regla, esto no se puede hacer, la protección no se puede bajar, así como "no se puede bajar el grado". De la misma manera, puede hacer que la clave privada no sea recuperable después de que se importe al token (a menos que, por supuesto, el token / tarjeta inteligente permita la importación). Después de crear (o durante la creación) el objeto CKO_PRIVATE_KEY, debe establecer CKA_SENSITIVE = CK_TRUE y el atributo CKA_EXTRACTABLE = CK_FALSE .

En el último caso (al importar), debe tenerse en cuenta que, aunque la clave privada se volvió no recuperable, apareció desde un lado (por ejemplo, desde PKCS # 12 ), y no hay garantía de que no haya duplicado en otra parte.

Y aquí no estaría de más recordarle, querido lector, quela seguridad es proporcionada solo por COMPLEJO de medidas organizativas y técnicas . Por lo tanto, no funcionará reparar los agujeros en la seguridad de la organización a expensas de los medios técnicos y viceversa: todo debe coordinarse orgánicamente. Incluyendo, al acceder al valor de la clave privada.

Asegúrese de que el token / tarjeta inteligente contenga objetos PKCS # 11 completos (CKO_PRIVATE_KEY, CKO_PUBLIC_KEY, CKO_CERTIFICATE) que están involucrados en operaciones criptográficas en el token en sí convenientemente usando la utilidad p11conf disponible para descarga gratuita:

$ /usr/local/bin64/p11conf -h
usage:  /usr/local/bin64/p11conf [-hitsmIupPred] -A APIpath [-c slotID -U userPin -S SOPin -n newPin -L label]
        -h display usage
        -i display PKCS#11 library info
        -s display slot(s) info (-c slotID is optional)
        -t display token(s) info (-c slotID is optional)
Others must use -c slotID
        -m display mechanism list
        -I initialize token 
        -u initialize user PIN
        -p set the user PIN
        -P set the SO PIN
        -r remove all objects
        -e enumerate objects
        -d dump all object attributes
Copyright(C) 2011-2016
$

Para ver qué objetos hay en el token, es suficiente ejecutar un comando de la forma:

bash-4.3$ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11sw2016.so -c 0 -e
Enter user PIN: ********
Token objects:
1: CKO_PRIVATE_KEY
         label: 'LS11SW2016:; ..;0x23855(145493)'
2: CKO_PUBLIC_KEY
         label: 'LS11SW2016:; ..;0x23855(145493)'
3: CKO_CERTIFICATE
         label: 'LS11SW2016:; ..;0x23855(145493)'
…
OK
bash-4.3$

Si tales objetos están ausentes en el token y dicen que se usa el token PKCS # 11 con la clave no recuperable, lo más probable es que este no sea el caso. Lo más probable es que el token se use simplemente como una unidad flash con un código PIN, y el certificado y las claves se almacenan como objetos CKO_DATA .

Y, por último, para ver no solo qué tipos de objetos están almacenados en el token, sino también los objetos con todos los atributos, debe usar el indicador –d además :

bash-4.3$ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11sw2016.so -c 0 –e -d
Enter user PIN: ********
Token objects:
1: CKO_PRIVATE_KEY
	 label: 'LS11SW2016:; ..;0x23855(145493)'
==================================
Object handle: 0x1
----------------------------------
CKA_CLASS
0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
CKA_TOKEN
0x01, 
CKA_PRIVATE
0x01, 
CKA_LABEL
0x4c, 0x53, 0x31, 0x31, 0x53, 0x57, 0x32, 0x30, 
0x31, 0x36, 0x3a, 0xd0, 0x9e, 0xd0, 0x9e, 0xd0, 
0x9e, 0x20, 0xd0, 0x9b, 0xd0, 0x98, 0xd0, 0xa1, 
0xd0, 0xa1, 0xd0, 0x98, 0x2d, 0xd0, 0xa1, 0xd0, 
0xbe, 0xd1, 0x84, 0xd1, 0x82, 0x3b, 0xd0, 0x9c, 
0xd0, 0xb0, 0xd1, 0x81, 0xd0, 0xbb, 0xd0, 0xbe, 
0x20, 0xd0, 0x90, 0x2e, 0xd0, 0x90, 0x2e, 0x3b, 
0x30, 0x78, 0x32, 0x33, 0x38, 0x35, 0x35, 0x28, 
0x31, 0x34, 0x35, 0x34, 0x39, 0x33, 0x29, 
CKA_VALUE: attribute sensitive
CKA_KEY_TYPE
0x03, 0x10, 0x32, 0xd4, 0x00, 0x00, 0x00, 0x00, 
CKA_SUBJECT
0x30, 0x81, 0x9b, 0x31, 0x0b, 0x30, 0x09, 0x06, 
0x03, 0x55, 0x04, 0x06, 0x13, 0x02, 0x52, 0x55, 
0x31, 0x1a, 0x30, 0x18, 0x06, 0x03, 0x55, 0x04, 
0x03, 0x0c, 0x11, 0xd0, 0x9c, 0xd0, 0xb0, 0xd1, 
0x81, 0xd0, 0xbb, 0xd0, 0xbe, 0x20, 0xd0, 0x90, 
0x2e, 0xd0, 0x90, 0x2e, 0x31, 0x1c, 0x30, 0x1a, 
0x06, 0x03, 0x55, 0x04, 0x0a, 0x0c, 0x13, 0xd0, 
0x9b, 0xd0, 0x98, 0xd0, 0xa1, 0xd0, 0xa1, 0xd0, 
0x98, 0x2d, 0xd0, 0xa1, 0xd0, 0xbe, 0xd1, 0x84, 
0xd1, 0x82, 0x31, 0x1f, 0x30, 0x1d, 0x06, 0x09, 
0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x09, 
0x01, 0x16, 0x10, 0x61, 0x6d, 0x61, 0x73, 0x6c, 
0x6f, 0x76, 0x40, 0x6c, 0x69, 0x73, 0x73, 0x69, 
0x2e, 0x72, 0x75, 0x31, 0x31, 0x30, 0x2f, 0x06, 
0x03, 0x55, 0x04, 0x08, 0x0c, 0x28, 0x35, 0x30, 
0x20, 0x20, 0xd0, 0x9c, 0xd0, 0xbe, 0xd1, 0x81, 
0xd0, 0xba, 0xd0, 0xbe, 0xd0, 0xb2, 0xd1, 0x81, 
0xd0, 0xba, 0xd0, 0xb0, 0xd1, 0x8f, 0x20, 0xd0, 
0xbe, 0xd0, 0xb1, 0xd0, 0xbb, 0xd0, 0xb0, 0xd1, 
0x81, 0xd1, 0x82, 0xd1, 0x8c, 0x20, 
CKA_ID
0x97, 0x46, 0x4e, 0xcc, 0x7c, 0xa9, 0xea, 0xb1, 
0x0a, 0xda, 0xec, 0x10, 0xf4, 0x49, 0x7e, 0x7f, 
0x2d, 0x71, 0x4b, 0xa7, 
CKA_SENSITIVE
0x01, 
. . .
CKA_GOSTR3410_PARAMS
0x06, 0x09, 0x2a, 0x85, 0x03, 0x07, 0x01, 0x02, 
0x01, 0x02, 0x01, 
CKA_GOSTR3411_PARAMS
0x06, 0x08, 0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 
0x02, 0x03, 
CKA_GOST28147_PARAMS
0x06, 0x07, 0x2a, 0x85, 0x03, 0x02, 0x02, 0x1f, 
0x01, 
…
OK
bash-4.3$

Todo lo dicho aquí es válido para un token / tarjeta inteligente con interfaz PKCS # 11, incluido un token en la nube.

En conclusión, recordamos que los tokens / tarjetas inteligentes con la interfaz PKCS # 11 son ampliamente utilizados en proyectos de Mozilla (navegadores, clientes de correo electrónico), en navegadores Chrome de Google y otros proyectos. Si hablamos de Rusia, entonces los tokens / tarjetas inteligentes con interfaz PKCS # 11 se utilizan con éxito para acceder al portal de Servicios del Estado.

Source: https://habr.com/ru/post/es400943/

More articles:


All Articles