stringtranslate.com

conjunto de cifrado

Un conjunto de cifrado es un conjunto de algoritmos que ayudan a proteger una conexión de red. Las suites suelen utilizar Transport Layer Security (TLS) o su predecesor obsoleto Secure Socket Layer (SSL). El conjunto de algoritmos que suelen contener los conjuntos de cifrado incluye: un algoritmo de intercambio de claves , un algoritmo de cifrado masivo y un algoritmo de código de autenticación de mensajes (MAC). [1]

El algoritmo de intercambio de claves se utiliza para intercambiar una clave entre dos dispositivos. Esta clave se utiliza para cifrar y descifrar los mensajes que se envían entre dos máquinas. El algoritmo de cifrado masivo se utiliza para cifrar los datos que se envían. El algoritmo MAC proporciona comprobaciones de integridad de los datos para garantizar que los datos enviados no cambien durante el tránsito. Además, los conjuntos de cifrado pueden incluir firmas y un algoritmo de autenticación para ayudar a autenticar el servidor o el cliente.

En general, existen cientos de conjuntos de cifrado diferentes que contienen diferentes combinaciones de estos algoritmos. Algunas suites de cifrado ofrecen mayor seguridad que otras. Pero con la adopción de TLS 1.3, solo se han definido y admitido oficialmente cinco conjuntos de cifrado. [2]

La estructura y el uso del concepto de conjunto de cifrado se definen en el documento estándar TLS. [3] TLS 1.2 es la versión más frecuente de TLS. La versión más reciente de TLS (TLS 1.3) incluye requisitos adicionales para los conjuntos de cifrado. Los conjuntos de cifrado definidos para TLS 1.2 no se pueden utilizar en TLS 1.3 y viceversa, a menos que se indique lo contrario en su definición.

En el Registro de conjuntos de cifrado TLS se proporciona una lista de referencia de conjuntos de cifrado con nombre. [4]

Historia

El uso de cifrados ha sido parte del protocolo de tránsito Secure Socket Layer (SSL) desde su creación. TLS ha reemplazado a SSL en la mayoría de los usos. Sin embargo, el nombre Cipher Suite no se utilizó en el borrador original de SSL. En cambio, la capacidad de un cliente y un servidor de elegir entre un pequeño conjunto de cifrados para asegurar su conexión se denominó Cipher-Choice. [5] [6] No fue hasta SSL v3 (la última versión de SSL) que se utilizó el nombre Cipher Suite . [7] Todas las versiones de TLS desde entonces han utilizado Cipher Suite en su estandarización. El concepto y propósito de Cipher Suite no ha cambiado desde que se acuñó el término por primera vez. Se ha utilizado y se sigue utilizando como una estructura que describe los algoritmos que admite una máquina para que dos máquinas decidan qué algoritmos utilizar para asegurar su conexión. Lo que ha cambiado son las versiones de los algoritmos compatibles con los conjuntos de cifrado. Cada versión de TLS ha agregado soporte para versiones más potentes de los algoritmos y ha eliminado el soporte para versiones de los algoritmos que han sido identificadas como inseguras.

TLS 1.3 marca un cambio en la forma en que se coordinan los conjuntos de cifrado entre máquinas. El conjunto de cifrado elegido para que lo utilicen dos máquinas comunicantes está determinado por el proceso de protocolo de enlace. Se realizaron modificaciones en TLS 1.3 al proceso de protocolo de enlace para reducir la cantidad de mensajes necesarios para enviar. Esto permite menos procesamiento, menos tráfico de paquetes y más eficiencia en comparación con versiones anteriores de TLS.

Esquema de nombres

Cada conjunto de cifrado tiene un nombre único que se utiliza para identificarlo y describir su contenido algorítmico. Cada segmento en el nombre de un conjunto de cifrado representa un algoritmo o protocolo diferente. Un ejemplo de nombre de conjunto de cifrado: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

El significado de este nombre es:

TLS
define el protocolo para el que es este conjunto de cifrado; normalmente será TLS.
ECDHE
indica el algoritmo de intercambio de claves que se está utilizando.
RSA
Mecanismo de autenticación durante el protocolo de enlace.
AES
cifrado de sesión.
128
Tamaño de la clave de cifrado de sesión (bits) para el cifrado.
GCM
tipo de cifrado (dependencia del bloque de cifrado y opciones adicionales).
sha
(SHA2) función hash. Para un resumen de 256 y superior. Mecanismo de firma. Indica el algoritmo de autenticación de mensajes que se utiliza para autenticar un mensaje.
256
Tamaño del resumen (bits).

Apretón de manos completo: coordinación de conjuntos de cifrado

Para utilizar conjuntos de cifrado, el cliente y el servidor deben acordar el conjunto de cifrado específico que se utilizará en el intercambio de mensajes. Tanto el cliente como el servidor deben admitir el conjunto de cifrado acordado. Si el cliente y el servidor no se ponen de acuerdo sobre un conjunto de cifrado, no se realizará ninguna conexión. [8] Este proceso de selección ocurre durante el protocolo de protocolo de enlace TLS. TLS 1.3 incluye un protocolo de protocolo de enlace TLS que difiere de la versión anterior y actual de TLS/SSL.

Después de coordinar qué conjunto de cifrado usar, el servidor y el cliente aún tienen la capacidad de cambiar los cifrados coordinados utilizando el protocolo ChangeCipherSpec en el protocolo de enlace actual o en un nuevo protocolo de enlace.

Para probar qué cifrados TLS admite un servidor, se puede utilizar un escáner SSL/TLS.[1]

Apretón de manos TLS 1.0–1.2

Representación visual de cómo un cliente y un servidor que operan en TLS 1.2 coordinan qué conjunto de cifrado usar

Este cliente inicia el proceso enviando un mensaje clientHello al servidor que incluye la versión de TLS que se está utilizando y una lista de conjuntos de cifrado en el orden de preferencia del cliente. En respuesta, el servidor envía un mensaje serverHello que incluye el conjunto de cifrado elegido y el ID de la sesión. A continuación, el servidor envía un certificado digital para verificar su identidad al cliente. El servidor también podrá solicitar la certificación digital de un cliente si es necesario.

Si el cliente y el servidor no utilizan claves precompartidas , el cliente envía un mensaje cifrado al servidor que permite al cliente y al servidor calcular qué clave secreta se utilizará durante los intercambios.

Después de verificar con éxito la autenticación del servidor y, si es necesario, intercambiar la clave secreta, el cliente envía un mensaje finalizado para indicar que ha terminado con el proceso de protocolo de enlace. Después de recibir este mensaje, el servidor envía un mensaje finalizado que confirma que el protocolo de enlace se ha completado. Ahora el cliente y el servidor están de acuerdo sobre qué conjunto de cifrado utilizar para comunicarse entre sí.

Representación visual de cómo un cliente y un servidor que operan en TLS 1.3 coordinan qué conjunto de cifrado usar

Apretón de manos TLS 1.3

Si dos máquinas se corresponden a través de TLS 1.3, coordinan qué conjunto de cifrado usar mediante el protocolo de protocolo de enlace TLS 1.3. El protocolo de enlace en TLS 1.3 se redujo a solo un viaje de ida y vuelta en comparación con los dos viajes de ida y vuelta requeridos en versiones anteriores de TLS/SSL.

Primero, el cliente envía un mensaje clientHello al servidor que contiene una lista de cifrados admitidos en el orden de preferencia del cliente y adivina qué algoritmo de clave se está utilizando para poder enviar una clave secreta para compartir si es necesario.

Al adivinar qué algoritmo clave se está utilizando, se elimina el viaje de ida y vuelta. Después de recibir clientHello , el servidor envía un serverHello con su clave, un certificado, el conjunto de cifrado elegido y el mensaje terminado .

Después de que el cliente recibe el mensaje terminado del servidor, ahora se coordina con el servidor qué conjunto de cifrado utilizar. [9]

Algoritmos soportados

En TLS 1.0–1.2

Para obtener más información sobre los algoritmos admitidos en TLS 1.0–1.2, consulte también: Seguridad de la capa de transporte § Aplicaciones y adopción

TLS 1.3

En TLS 1.3, muchos algoritmos heredados que eran compatibles con las primeras versiones de TLS se eliminaron en un esfuerzo por hacer que el protocolo sea más seguro. [11] Además, todos los algoritmos de cifrado y autenticación se combinan en el algoritmo de cifrado de cifrado autenticado con datos asociados (AEAD). Además, ahora se debe utilizar un algoritmo hash en la derivación de claves basada en HMAC ( HKDF ). [12] Todos los cifrados que no son AEAD se han eliminado debido a posibles debilidades o vulnerabilidades y los cifrados deben utilizar un algoritmo de intercambio de claves efímero para que se generen nuevos pares de claves para cada intercambio. [13]

DTLS con conjuntos de cifrado

Datagram Transport Layer Security (DTLS) se basa en TLS, pero se utiliza específicamente para conexiones UDP en lugar de conexiones TCP . Dado que DTLS se basa en TLS, puede utilizar la mayoría de los conjuntos de cifrado descritos para TLS. Hay casos especiales que se deben considerar al utilizar conjuntos de cifrado TLS con DTLS. DTLS no admite el cifrado de flujo RC4, lo que significa que no se puede utilizar ningún cifrado TLS que utilice RC4 con DTLS. [14]

Para determinar si un conjunto de cifrado TLS es compatible con DTLS, mirar su nombre no ayudará. Cada conjunto de cifrado TLS seguirá incluyendo el espacio del identificador TLS en su nombre. por ejemplo: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 . En cambio, todos los registros de parámetros TLS ahora incluyen el indicador DTLS-OK para indicar si un conjunto de cifrado admite DTLS. [15]

Vulnerabilidades

Un conjunto de cifrado es tan seguro como los algoritmos que contiene. Si la versión del algoritmo de cifrado o autenticación en un conjunto de cifrado tiene vulnerabilidades conocidas, el conjunto de cifrado y la conexión TLS pueden ser vulnerables. Por lo tanto, un ataque común contra TLS y conjuntos de cifrado se conoce como ataque de degradación . Se produce una degradación de TLS cuando un cliente moderno se conecta a servidores heredados que utilizan versiones anteriores de TLS o SSL.

Al iniciar un protocolo de enlace, el cliente moderno ofrecerá el protocolo más alto que admita. Si la conexión falla, volverá a intentarlo automáticamente con un protocolo inferior, como TLS 1.0 o SSL 3.0, hasta que el protocolo de enlace sea exitoso con el servidor. El objetivo de la degradación es que las nuevas versiones de TLS sean compatibles con las versiones anteriores. Sin embargo, es posible que un adversario aproveche esta característica y haga que un cliente cambie automáticamente a una versión de TLS o SSL que admita conjuntos de cifrado con algoritmos conocidos por su seguridad débil y vulnerabilidades. [16] Esto ha resultado en ataques como POODLE .

Una forma de evitar este fallo de seguridad es desactivar la capacidad de un servidor o cliente para poder bajar a SSL 3.0. El inconveniente de esta solución es que el hardware más nuevo no puede acceder a parte del hardware heredado. Si se necesita compatibilidad con SSL 3.0 para hardware heredado, existe un conjunto de cifrado TLS_FALLBACK_SCSV aprobado que verifica que las degradaciones no se activen con intenciones maliciosas. [17]

Conjuntos de cifrado para dispositivos restringidos

Los algoritmos de cifrado, intercambio de claves y autenticación suelen requerir una gran cantidad de memoria y potencia de procesamiento. Para brindar seguridad a dispositivos con capacidad de procesamiento, memoria y duración de batería limitadas, como los que alimentan el Internet de las cosas, existen conjuntos de cifrado específicamente elegidos. Dos ejemplos incluyen:

  1. TLS_PSK_WITH_AES_128_CCM_8 ( clave previamente compartida ) [18]
  2. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ( clave pública sin formato )

Cada uno de estos conjuntos de cifrado se ha implementado para ejecutarse en dispositivos con limitaciones de potencia de procesamiento y memoria. Ambos están implementados en el proyecto de código abierto TinyDTLS. La razón por la que pueden funcionar en estos dispositivos restringidos es porque pueden implementarse de manera liviana. Las implementaciones del conjunto de cifrado de clave precompartida utilizaron solo 1889 bytes de RAM y 38266 de ROM flash, lo que consume muchos recursos en comparación con la mayoría de los algoritmos de cifrado y seguridad. [19] Este bajo uso de memoria se debe a que estos conjuntos de cifrado utilizan algoritmos eficientes comprobados que son seguros, pero tal vez no tan seguros como los algoritmos que requieren más recursos; exp: uso de cifrado de 128 bits frente a cifrado de 256 bits. Además, utilizan una clave precompartida o una clave pública sin formato que requiere menos espacio de memoria y potencia de procesamiento en comparación con el uso de la infraestructura de clave pública tradicional (PKIX). [20]

Referencias de programación

En programación, se hace referencia a un conjunto de cifrado tanto en forma plural como no plural. Cada uno tiene diferentes definiciones:

CipherSuitecipher_suites
una lista de las opciones criptográficas admitidas por el cliente. [21] Un ejemplo de cómo se suele utilizar cipher_suites durante el proceso de protocolo de enlace:
 estructura { ProtocoloVersión versión_cliente ; Al azar al azar ; ID de sesión id_sesión ; CipherSuite cipher_suites < 2 .. 2 ^ 16 - 2 >; Método de compresión métodos_compresión < 1 .. 2 ^ 8 - 1 >; seleccionar ( extensiones_presente ) { caso falso : estructura {}; caso verdadero : extensiones de extensión < 0 .. 2 ^ 16 - 1 >; }; } ClienteHola ;                         
CipherSuitecipher_suite
el conjunto de cifrado seleccionado por el servidor entre los cipher_suites del cliente . [22] Un ejemplo de cómo se suele utilizar cipher_suite durante el proceso de protocolo de enlace:
 estructura { ProtocoloVersión versión_servidor ; Al azar al azar ; ID de sesión id_sesión ; CipherSuitecipher_suite ;Método de compresión método_compresión ; seleccionar ( extensiones_presente ) { caso falso : estructura {}; caso verdadero : extensiones de extensión < 0 .. 2 ^ 16 - 1 >; }; } ServidorHola ;                         

Ver también

Referencias

  1. ^ "Suites de cifrado en TLS/SSL (Schannel SSP) (Windows)". docs.microsoft.com . Consultado el 2 de julio de 2018 .
  2. ^ "Configuración de una lista de conjuntos de cifrado mediante TLS v1.3". www.microfocus.com . Consultado el 30 de noviembre de 2023 .
  3. ^ RFC  5246
  4. ^ Registro de conjunto de cifrado TLS
  5. ^ "El protocolo SSL 0.2". www-archive.mozilla.org . Consultado el 7 de diciembre de 2017 .
  6. ^ "borrador-hickman-netscape-ssl-00". herramientas.ietf.org . Consultado el 7 de diciembre de 2017 .
  7. ^ "Especificación SSL 3.0". www.freesoft.org . Consultado el 7 de diciembre de 2017 .
  8. ^ Villanueva, John Carl. "Una introducción a Cipher Suites" . Consultado el 25 de octubre de 2017 .
  9. ^ Valsorda, Filippo (23 de septiembre de 2016). "Una descripción general de TLS 1.3 y preguntas y respuestas". El blog de Cloudflare . Consultado el 1 de septiembre de 2020 .
  10. ^ ECDHE_PSK con conjuntos de cifrado AES-GCM y AES-CCM para TLS 1.2 y DTLS 1.2. doi : 10.17487/RFC8442 . RFC 8442.
  11. ^ "Compatibilidad con el protocolo TLS 1.3 | Biblioteca SSL/TLS integrada de wolfSSL". loboSSL . Consultado el 26 de octubre de 2017 .
  12. E. Rescorla (4 de noviembre de 2016). "Protocolo de seguridad de la capa de transporte (TLS) versión 1.3" . Consultado el 11 de noviembre de 2016 .
  13. ^ Sullivan, Nick (11 de agosto de 2018). "Una mirada detallada a RFC 8446 (también conocido como TLS 1.3)". El blog de Cloudflare . Consultado el 11 de agosto de 2020 .
  14. ^ N., Modadugu; E., Rescorla. "Seguridad de la capa de transporte de datagramas". herramientas.ietf.org . Consultado el 25 de octubre de 2017 .
  15. ^ Eric, Rescorla; Nagendra, Modadugu. "Seguridad de la capa de transporte de datagramas versión 1.2". herramientas.ietf.org . Consultado el 25 de octubre de 2017 .
  16. ^ Bodo, Moeller; Adán, Langley. "Valor del conjunto de cifrado de señalización de reserva de TLS (SCSV) para prevenir ataques de degradación de protocolo". herramientas.ietf.org . Consultado el 25 de octubre de 2017 .
  17. ^ Bodo, Moeller; Adán, Langley. "Valor del conjunto de cifrado de señalización de reserva de TLS (SCSV) para prevenir ataques de degradación de protocolo". herramientas.ietf.org . Consultado el 25 de octubre de 2017 .
  18. ^ Daniel, Bailey; David, McGrew. "Suites de cifrado AES-CCM para seguridad de la capa de transporte (TLS)". herramientas.ietf.org . Consultado el 26 de octubre de 2017 .
  19. ^ Perelmen, Vladislav (29 de junio de 2012). "Seguridad en redes de sensores inalámbricos habilitadas para IPv6: una implementación de TLS/DTLS para el sistema operativo Contiki" (PDF) : 38. Archivado desde el original (PDF) el 29 de agosto de 2017 . Consultado el 7 de diciembre de 2017 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  20. ^ Samuel, Weiler; Juan, Gilmore; Hannes, Tschofenig; Tero, Kivinen; Pablo, Wouters. "Uso de claves públicas sin procesar en seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS)". herramientas.ietf.org . Consultado el 7 de diciembre de 2017 .
  21. ^ RFC  5246, pag. 41
  22. ^ RFC  5246, págs. 42–43, 64