Marco de protocolo de ruido

El Noise Protocol Framework , a veces denominado " Noise " o " Noise Framework ", es un marco criptográfico de dominio público ^{[ 1 ]} para crear protocolos de comunicación seguros basados ​​en el intercambio de claves Diffie-Hellman . ^{[ 2 ]} Desarrollado por Trevor Perrin , el marco define una serie de patrones de handshake (secuencias predefinidas de intercambio de mensajes) que describen cómo las partes inician la comunicación, intercambian claves y establecen secretos compartidos . Estos patrones se pueden combinar y personalizar para cumplir con requisitos de seguridad específicos, como la autenticación mutua , el secreto hacia adelante y la protección de la identidad.

Varias aplicaciones y protocolos de software populares , incluidas las plataformas de mensajería WhatsApp y Slack ^{[ 3 ]} y el protocolo VPN WireGuard , han utilizado implementaciones del Noise Framework para garantizar el cifrado de extremo a extremo para las comunicaciones de los usuarios. El framework sigue siendo objeto de desarrollo, incluidas adaptaciones post-cuánticas . ^{[ 4 ]} Actualmente, el framework se encuentra en la revisión 34, publicada en julio de 2018. ^{[ 1 ]}

La mayoría de los protocolos de canal seguros se basan en el intercambio de claves autenticado (AKE) utilizando firmas digitales (para autenticación ) y Diffie-Hellman (para intercambio de claves ). En las décadas de 2000 a 2010, creció el interés en desarrollar AKE basados ​​puramente en Diffie-Hellman, sin firmas, ^{[ 5 ]} lo que condujo a avances tanto teóricos (por ejemplo, Kudla-Paterson, ^{[ 6 ]} NAXOS, ^{[ 7 ]} Ntor) ^{[ 8 ]} como prácticos (por ejemplo, Ntor, ^{[ 8 ]} NaCl , CurveCP , DNSCurve , OPTLS). ^{[ 9 ]} Estos a menudo se desarrollaron desde cero. El Noise Protocol Framework fue desarrollado por Trevor Perrin, con el apoyo de Moxie Marlinspike , introduciendo dos innovaciones clave: ^{[ 5 ]}

1. Combinar elementos simples para construir diversos protocolos.
2. Utilizando criptografía simétrica “tipo esponja” , inspirada en el marco del protocolo Strobe del criptógrafo Mike Hamburg ^{[ 10 ]} . ^{[ 11 ]}

El marco de trabajo evolucionó a partir del trabajo realizado inicialmente en Open Whisper Systems , la organización de software de la que surgieron el Protocolo Signal y la aplicación de mensajería Signal . Si bien no guarda relación con el concepto de ruido en el procesamiento de señales , la elección de "Noise" como nombre para este protocolo criptográfico podría ser un juego de palabras que alude al concepto de señal frente a ruido.

Originalmente mantenido como una wiki desde el 10 de febrero de 2013, ^{[ 12 ]} el desarrollo del marco comenzó con una confirmación inicial de su especificación el 4 de agosto de 2014. ^{[ 13 ]} El marco evolucionó a través de numerosas revisiones siguiendo discusiones de la lista de correo hasta la versión 34 el 11 de julio de 2018. ^{[ 14 ]} El Noise Protocol Framework reconoce ^{[ 15 ]} la inspiración de diseños criptográficos anteriores (por ejemplo, NaCl , CurveCP o las cadenas KDF utilizadas en el algoritmo Double Ratchet ) y contribuciones de figuras en criptografía y computación (por ejemplo, Jason Donenfeld , Hugo Krawczyk ).

Durante su desarrollo, el Noise Protocol Framework evolucionó junto con TLS 1.3 , incluyendo discusiones en 2015 ^{[ 16 ]} que comparaban los protocolos, en particular la propuesta "OPTLS" ^{[ 17 ]} . Ambos proyectos se extendieron desde 2014 hasta 2018, con el primer borrador de TLS 1.3 RFC 8446 ^{[ 18 ]} publicado en agosto de 2014 y el Estándar Propuesto final en agosto de 2018. El Noise Framework proporcionó un enfoque alternativo, permitiendo la selección de patrones de intercambio de claves y algoritmos criptográficos específicos para diseñar protocolos adaptados a propiedades de seguridad y necesidades de rendimiento específicas.

Las verificaciones formales ^{[ 19 ]} del marco del protocolo Noise han evaluado sus propiedades de seguridad . Los estudios han empleado herramientas automatizadas para modelar y verificar varios patrones de intercambio de claves dentro del marco, ^{[ 20 ] [ 21 ]} evaluando su resistencia frente a una variedad de ataques .

Un protocolo de canal seguro tiene dos fases:

• La fase de establecimiento de la conexión: autentica y establece claves secretas compartidas mediante el intercambio de claves Diffie-Hellman (DH) para el intercambio de claves autenticado (AKE).
• La fase de transporte: utiliza claves secretas compartidas para cifrar los datos.

El patrón de establecimiento de conexión se puede describir en un diagrama como un conjunto de mensajes, cada uno anotado con una lista de tokens que describen las operaciones criptográficas realizadas sobre el estado de establecimiento de conexión de una de las partes.

La especificación enumera tres patrones de protocolo de enlace unidireccionales y 12 patrones fundamentales de protocolo de enlace interactivos. Existen variaciones de algunos de estos:

• patrones diferidos, donde los DH de autenticación se difieren al siguiente mensaje. 1Se utiliza un número después del primer y/o segundo carácter, por ejemplo NK1oX1X1
• una clave simétrica precompartida para admitir protocolos donde ambas partes tienen una clave secreta compartida de 32 bytes, por ejemplo Npsk0oXpsk1
• protocolos compuestos en los que los roles de iniciador y respondedor se invierten como mecanismo de negociación a través del fallbackmodificador. Un Noise Pipe es un ejemplo que se encuentra en §10.4 ^{[ 22 ].}

Un ejemplo del mundo real proviene de WireGuard, cuya construcción en la página 10 del Libro Blanco es Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s.

Cada patrón de intercambio de claves se puede combinar con una de las 16 combinaciones de los 8 algoritmos criptográficos enumerados en la especificación. Estos algoritmos son de calidad comparable y no amplían el espacio de diseño.

La especificación describe una API en el §5 ^{[ 23 ]} utilizando los siguientes objetos , cada uno con un pequeño conjunto de métodos :

• Un CipherStateobjeto contiene k y n variables, que utiliza para cifrar y descifrar textos cifrados. Durante la fase de establecimiento de la conexión, cada parte tiene un único objeto CipherState, pero durante la fase de transporte, cada parte tiene dos CipherStateobjetos: uno para enviar y otro para recibir.
• Un SymmetricStateobjeto contiene las variables a, CipherStateck y h . Se denomina así porque encapsula toda la "criptografía simétrica" ​​utilizada por Noise. Durante la fase de establecimiento de la conexión, cada parte tiene un único SymmetricState, que puede eliminarse una vez finalizado el establecimiento de la conexión.
• Un HandshakeStateobjeto contiene SymmetricStatevariables DH ( s , e , rs , re ) y una variable que representa el patrón de handshake. Durante la fase de handshake, cada parte tiene un único HandshakeState, que puede eliminarse una vez finalizado el handshake.

La implementación de un protocolo concreto implica el diseño de la representación de mensajes, así como aspectos ajenos al marco de trabajo Noise Framework. Un ejemplo de esto último se da con protocolos que utilizan transportes UDP , como WireGuard , que emplea una ventana deslizante para gestionar la llegada de mensajes fuera de orden.

Las propiedades de seguridad de varios patrones de intercambio de claves se describen en la Especificación y pueden admitir autenticación mutua, secreto hacia adelante, cifrado de ida y vuelta cero, ocultación de identidad y otras características avanzadas. En la literatura académica han aparecido análisis criptográficos formales de patrones de intercambio de claves comunes. ^{[ 24 ] [ 25 ]} El segundo esfuerzo ha dado como resultado la herramienta en línea Noise Explorer. ^{[ 26 ]}

Gran parte del siguiente texto consiste en extractos de la Especificación con formato:

• IKpara nombres de protocolo que constan de patrones de intercambio de claves, criptografía y modificadores
• Comprobación de variables en la máquina de estados de protocolo de enlace
• e para tokens en un patrón de mensaje
• El prefijo § hace referencia a secciones de la Especificación.

con el enfoque en:

• patrones de apretón de manos
• Propiedades de seguridad y compensaciones
• Responsabilidades de la aplicación y consideraciones de seguridad

Para generar un nombre de protocolo de ruido, Initialize()concatene la cadena ASCII Noise_con cuatro secciones de nombre separadas por guiones bajos, que designan secuencialmente el patrón de intercambio de claves, las funciones DH, las funciones de cifrado y, a continuación, las funciones hash. El nombre resultante debe tener 255 bytes o menos. ^{[ 27 ]} Ejemplos:

• Noise_XX_25519_AESGCM_SHA256
• Noise_N_25519_ChaChaPoly_BLAKE2s
• Noise_IK_448_ChaChaPoly_BLAKE2b

Cada sección del nombre debe constar únicamente de caracteres alfanuméricos (es decir, caracteres en uno de los rangos "A"...Z", "a"...z" y "0"...9"), y los dos caracteres especiales "+" y "/".

Se aplican reglas adicionales a cada sección de nombre, tal y como se especifica a continuación.

Los protocolos de ruido tienen una entrada de prólogo que permite que se asignen datos arbitrarios a la variable h mediante una función hash. Si ambas partes no proporcionan datos de prólogo idénticos, el protocolo de enlace fallará debido a un error de descifrado. Esto resulta útil cuando las partes participaron en una negociación previa al protocolo de enlace y desean asegurarse de que comparten puntos de vista idénticos sobre dicha negociación. ^{[ 42 ]}

Por ejemplo, supongamos que Bob le comunica a Alice una lista de protocolos de ruido que está dispuesto a admitir. Alice elegirá y ejecutará un único protocolo. Para garantizar que un atacante no modifique la lista de Bob eliminando opciones, Alice y Bob podrían incluir la lista como datos de prólogo.

Cabe señalar que, si bien las partes confirman que sus prólogos son idénticos, no mezclan los datos de los prólogos con las claves de cifrado. Si una entrada contiene datos secretos destinados a reforzar el cifrado, se debe utilizar un protocolo de enlace PSK (véase el apartado 9).

Una aplicación construida sobre Noise debe tener en cuenta varios aspectos: ^{[ 57 ]}

• Elección de funciones criptográficas : 25519Se recomiendan las funciones DH para usos típicos, aunque 448podrían ofrecer seguridad adicional en caso de que se desarrolle un ataque criptoanalítico contra la criptografía de curva elíptica . Las 448funciones DH deben usarse con un hash de 512 bits como SHA512o BLAKE2b. Las 25519funciones DH pueden usarse con un hash de 256 bits como SHA256o BLAKE2s, aunque un hash de 512 bits podría ofrecer seguridad adicional en caso de que se desarrolle un ataque criptoanalítico contra las funciones hash más pequeñas. AESGCMes difícil de implementar con alta velocidad y tiempo constante en software.
• Extensibilidad : Se recomienda que las aplicaciones utilicen un formato de datos extensible para las cargas útiles de todos los mensajes (por ejemplo, JSON , Protocol Buffers ). Esto garantiza que se puedan añadir campos en el futuro que las implementaciones anteriores ignoran.
• Se recomienda que las aplicaciones de relleno utilicen un formato de datos para las cargas útiles de todos los mensajes cifrados que permita el relleno. Esto permite que las implementaciones eviten la filtración de información sobre el tamaño de los mensajes. Utilizar un formato de datos extensible, como se indicó anteriormente, puede ser suficiente.
• Finalización de la sesión : Las aplicaciones deben tener en cuenta que un atacante podría truncar una secuencia de mensajes de transporte de Noise. Deben incluir campos de longitud explícitos o señales de finalización dentro de las cargas útiles de transporte para indicar el final de una sesión interactiva o el final de un flujo unidireccional de mensajes de transporte.
• Campos de longitud : Las aplicaciones deben gestionar cualquier campo de longitud adicional o de formato para los mensajes de ruido, teniendo en cuenta que un mensaje de ruido puede tener una longitud de hasta 65535 bytes. Si se requiere un campo de longitud explícito, se recomienda que las aplicaciones añadan un campo de longitud de 16 bits en formato big-endian antes de cada mensaje.
• Datos de negociación : Las aplicaciones podrían necesitar transmitir datos de negociación antes del establecimiento de la conexión y/o antes de cada mensaje de establecimiento de conexión. Estos datos podrían incluir información de versión e identificadores para los protocolos Noise. Por ejemplo, un enfoque sencillo sería enviar un campo de un solo byte antes de cada mensaje de establecimiento de conexión Noise. Enfoques más flexibles podrían enviar estructuras extensibles como protobufs. Los datos de negociación introducen una complejidad significativa y riesgos de seguridad, como ataques de reversión (véase la siguiente sección).

Esta sección recopila diversas consideraciones de seguridad: ^{[ 58 ]}

• Autenticación : Un protocolo de ruido con claves públicas estáticas verifica que los participantes posean las claves privadas correspondientes, pero es la aplicación la que debe determinar si la clave pública estática de la parte remota es aceptable. Los métodos para lograrlo incluyen certificados que firman la clave pública (y que pueden transmitirse en la información de la comunicación), listas preconfiguradas de claves públicas o enfoques de "fijación" o "continuidad de clave", donde las partes recuerdan las claves públicas que encuentran y verifican si la misma parte presenta la misma clave pública en el futuro.
• Finalización de sesión : Impide que los atacantes trunquen un flujo de datos.
• Reversión : Si las partes deciden un Protocolo Noise basándose en una negociación previa que no se incluye como prólogo, entonces podría ser posible un ataque de reversión. Este es un riesgo particular con los protocolos compuestos y requiere especial atención si el protocolo Noise está precedido por comunicación entre las partes.
• Reutilización de claves estáticas : Un par de claves estáticas utilizado con Noise debe emplearse con un único algoritmo hash. Este par de claves no debe utilizarse fuera de Noise ni con múltiples algoritmos hash. Es aceptable utilizar el par de claves estáticas con diferentes protocolos Noise, siempre que se utilice el mismo algoritmo hash en todos ellos. (Reutilizar un par de claves estáticas de Noise fuera de Noise requeriría un análisis extremadamente minucioso para garantizar que los usos no comprometan la seguridad de los demás y que se conserven las pruebas de seguridad).
• Reutilización de PSK : Una PSK utilizada con Noise debe usarse con un único algoritmo hash. La PSK no debe usarse fuera de Noise ni con múltiples algoritmos hash.
• Reutilización de claves efímeras : Cada participante en un Protocolo Noise debe enviar una clave pública efímera nueva antes de enviar cualquier dato cifrado. Las claves efímeras nunca deben reutilizarse. Incumplir estas reglas puede provocar una reutilización de claves catastrófica. Esta es una de las razones que justifican los patrones descritos en la sección 7 y las reglas de validez de la sección 7.3. También es el motivo por el cual los protocolos de enlace unidireccionales solo permiten el envío de mensajes desde el remitente, no desde el destinatario.
• Uso indebido de claves públicas como secretos : Puede resultar tentador usar un patrón con una clave pública previa al mensaje y asumir que un intercambio de claves exitoso implica que la otra parte conoce la clave pública. Desafortunadamente, esto no es así, ya que establecer claves públicas con valores no válidos puede provocar una salida de DH predecible. Por ejemplo, un Noise_NK_25519iniciador podría enviar una clave pública efímera no válida para generar una salida de DH conocida de ceros, a pesar de desconocer la clave pública estática del respondedor. Si las partes desean autenticarse con un secreto compartido, este debe usarse como una clave precompartida (PSK).
• Enlace de canal : Dependiendo de las funciones de DH, un atacante podría participar en múltiples sesiones que deriven la misma clave secreta compartida al establecer claves públicas con valores no válidos que generen una salida DH predecible (como en el punto anterior). También podría establecer claves públicas con valores equivalentes que generen la misma salida DH para diferentes entradas. Por ello, un protocolo de nivel superior debería usar el hash de handshake ( h ) para un enlace de canal único, en lugar de ck , como se explica en el §11.2.
• Incremento de nonces : Reutilizar un valor nonce para n con la misma clave k para el cifrado sería catastrófico. Las implementaciones deben seguir cuidadosamente las reglas para los nonces. Los nonces no pueden volver a cero debido al desbordamiento de enteros , y el valor máximo de nonce está reservado. Esto significa que las partes no pueden enviar más de ^2⁶⁴ - 1 mensajes de transporte.
• Nombres de protocolo : El nombre del protocolo Initialize()debe identificar de forma unívoca la combinación del patrón de intercambio de claves y las funciones criptográficas para cada clave con la que se utilice (ya sea un par de claves efímeras, un par de claves estáticas o una clave precompartida). Si se reutiliza la misma clave secreta con el mismo nombre de protocolo pero con un conjunto diferente de operaciones criptográficas, podrían producirse interacciones erróneas.
• Claves simétricas precompartidas : Las claves simétricas precompartidas deben ser valores secretos con 256 bits de entropía.
• Volumen de datos : La AESGCMseguridad de las funciones de cifrado disminuye gradualmente a medida que aumenta el volumen de datos cifrados con una sola clave. Por ello, no se recomienda enviar más de 2⁵⁶ ^bytes (aproximadamente 72 petabytes) cifrados con una sola clave. Si es posible enviar volúmenes de datos tan grandes, se deben elegir funciones de cifrado diferentes.
• Colisiones de hash : Si un atacante encuentra colisiones de hash en los datos del prólogo o en el hash del handshake, podría realizar ataques de "colisión de transcripción" que engañan a las partes haciéndoles creer que tienen versiones diferentes de los datos del handshake. Es importante usar Noise con funciones hash resistentes a colisiones y reemplazar la función hash ante cualquier indicio de vulnerabilidad.
• Identificación de la implementación : Si este protocolo se utiliza en entornos con participantes anónimos, se debe garantizar que las implementaciones se comporten de forma idéntica en todos los casos. Esto puede requerir establecer un comportamiento exacto para el manejo de claves públicas DH no válidas.

• Protocolo de Google "Ruido certificado para entornos de ejecución confiables con bajo TCB"
• I2P (enrutador ntcp2)
• Iluminación
• libp2p
• Libra/Diem de Facebook (moneda digital) (cerrada en 2022 ^{[ 75 ]} )
• nQUIC ^{[ 76 ]}
• Nebula de Slack, ^{[ 3 ]} "Una herramienta de red superpuesta escalable"
• WhatsApp
• WireGuard

Otros usos del ruido en el sentido criptográfico general:

• Mecanismos de privacidad diferencial de ruido aditivo

• Sitio web oficial con especificaciones y wiki.
• repositorios de Github
• Diapositivas de una charla de 2017 titulada "El marco del protocolo de ruido".
• Introducción al marco del protocolo de ruido
• Utilización del marco de protocolo Noise para diseñar un sistema de capacidad distribuida
• noisecat: la navaja suiza del ruido

Presentaciones:

• Charla de 20 minutos en Real World Crypto 2018 a cargo de Trevor Perrin.
• Charla de 25 minutos a cargo de David Wong.