firma RSA en TLS

2

En un protocolo de enlace de TLS que usa ECDHE-RSA , el marco ServerKeyExchange debe incluir ECDHE ServerPublicKey, firmado con su clave privada RSA, como se especifica en RFC 4492 . Lo tengo.

Intentando implementar un ECDHE-RSA-like intercambiando esto con crypto++ , me enfrento a una pequeña interrogación: cuál es el esquema utilizado para firmar el marco ?

Es

  • Signature Schemes with Appendix (SSA)

o

  • Signature Schemes with Recovery (PSSR)?

La única ventaja de usar el PSSR, como se dice aquí , es que no envías el mensaje, es incorporado en la firma.

Además, no se menciona en ninguna parte en RFC 5246 , ni en RFC 4492 .

¿Es a discreción del programador?

    
pregunta EisenHeim 09.09.2015 - 13:36
fuente

1 respuesta

4

El esquema de firma exacto depende de la versión del protocolo; sin embargo, en todos los casos, se relaciona con lo que Crypto ++ llama "esquemas de firma con apéndice".

PKCS # 1 describe dos esquemas de firmas (y dos esquemas de cifrado asimétricos, que no son relevantes aquí): el " antiguo "(llamado" v1.5 ") y el" nuevo "(llamado" PSS "). SSL / TLS se basa en el antiguo (v1.5).

En la generación de firmas PKCS # 1 v1.5, ocurre lo siguiente:

  • Los datos que se van a firmar están en hash, con alguna función de hash. Llamemos a x la secuencia resultante de bytes. Por ejemplo, si la función hash es SHA-256, entonces la longitud de x es de 256 bits, es decir, de 32 bytes.

  • Se agrega un encabezado t a x . El encabezado es una secuencia fija de bytes que identifica la función hash (técnicamente, x se usa como parámetro en una estructura ASN.1 codificada en DER que también identifica la función hash con un OID; sin embargo, es más sencillo pensar que es un encabezado fijo).

  • Algunos bytes se agregan antes de la concatenación de t y x , para obtener la siguiente estructura:

    00 01 FF FF ... FF 00 t x

    Es decir, un byte de valor 0, luego un byte de valor 1, luego algunos bytes de valor FF, luego un byte de valor 0, luego t , luego x , se concatenan en ese orden. El número de bytes "FF" se ajusta de modo que la longitud total sea exactamente la longitud, en bytes, del módulo RSA (es decir, 256 bytes para una clave RSA de 2048 bits). Este paso se llama "PKCS # 1 tipo 1".

  • La cadena rellenada se interpreta como un entero grande (que usa la convención big-endian), que luego pasa a la exponenciación modular que está en el núcleo del esquema de firma RSA.

Con TLS-1.2 , el esquema de firma debe ser exactamente el de arriba, con una función hash que depende de lo que el cliente y el servidor admitan. Con la extensión Signature Algorithms , el cliente especifica en su mensaje ClientHello qué tipo de funciones hash que puede usar con el algoritmo RSA; si falta esa extensión, el servidor debe asumir que el cliente es compatible con SHA-1. El valor del encabezado t se proporciona explícitamente, para la función hash más común, en la sección 9.2 de PKCS # 1.

En versiones anteriores de TLS (SSL-3.0, TLS-1.0 y TLS-1.1) , el esquema es sutilmente diferente: el encabezado t está vacío y x es la concatenación del MD5 y los hashes SHA-1 de lo que se debe firmar. Por lo tanto, la longitud de t es 0, y la longitud de x es de 36 bytes (16 bytes para el MD5, 20 bytes para el SHA-1). No hay discusión entre el cliente y el servidor sobre qué funciones hash usar; siempre es MD5 + SHA-1.

Una mirada rápida al manual parece indicar que al menos las firmas "normales" (para TLS-1.2) se pueden calcular con Crypto ++ utilizando RSASS<PKCS1v15, H> donde H será SHA1 , SHA256 ... No sé si Crypto ++ incluye código para el esquema anterior donde el hash es la concatenación de MD5 y SHA-1, y no hay encabezado.

    
respondido por el Thomas Pornin 09.09.2015 - 14:33
fuente

Lea otras preguntas en las etiquetas