Tendencias de desarrollo de seguridad de los protocolos de tecnología de recursos básicos de Internet
1. El Grupo de Trabajo Internacional de Ingeniería de Internet es la sede para el desarrollo de protocolos de tecnología de Internet.
El desarrollo de Internet ha cambiado el mundo. Los estándares y protocolos técnicos básicos para el funcionamiento de Internet provienen principalmente del IETF. El IETF se creó a principios de 1986. Es una importante organización responsable de formular estándares técnicos para Internet. Su tarea principal es ser responsable de la investigación y formulación de estándares técnicos relacionados con Internet. Más del 90% de los estándares técnicos de Internet son formulados por el IETF. El IETF garantiza el funcionamiento estable a largo plazo de Internet mediante la formulación de estándares técnicos. Una gran cantidad del trabajo técnico del IETF es realizado y completado por varios grupos de trabajo (WG) dentro del IETF. Estos grupos de trabajo se organizan según diferentes tipos de temas de investigación. Antes de establecer un grupo de trabajo, el IETF suele establecer un grupo de interés (BOF) para prepararse para el grupo de trabajo. Una vez completado el trabajo preparatorio y aprobado por la investigación de alto nivel del IETF, el grupo de trabajo puede establecerse formalmente. El IETF reúne a los mejores ingenieros en tecnología de Internet del mundo y celebra tres reuniones cada año, con más de 1.000 participantes.
La Junta de Arquitectura de Internet (IAB) se estableció en 1983 y es el máximo órgano de gobierno del IETF. Está compuesto por 13 miembros, incluido el presidente del IETF. Una de las principales responsabilidades de la IAB es supervisar la arquitectura del protocolo de Internet, captar la dirección de la evolución a largo plazo de la tecnología de Internet, proteger el desarrollo a largo plazo de Internet, determinar las reglas para formular estándares de Internet, guiar la edición y publicación. de estándares técnicos de Internet, gestionar la numeración de Internet y trabajar con otros Coordinados por la Organización Internacional de Normalización.
El IETF divide los grupos de trabajo en diferentes áreas, y cada área está dirigida por varios directores regionales. Los directores de dominio forman el Grupo Directivo de Ingeniería de Internet (IESG), con las siguientes áreas específicas.
Uno es el campo de aplicación e investigación en tiempo real. Este campo estudia principalmente los estándares relacionados con la capa de aplicación, incluidos los protocolos de red relacionados con el tiempo real.
La segunda es el área general. Este campo de estudio está destinado a contener contenido de investigación que no es adecuado para otros campos de estudio.
El tercero es el campo de Internet. El campo de investigación de Internet estudia principalmente cómo se transmiten los paquetes IP en diferentes entornos de red.
La cuarta área es el área de negocio y gestión. Esta área de investigación se ocupa principalmente del funcionamiento y gestión de Internet. Con el rápido desarrollo y popularización de Internet, se han impuesto mayores requisitos a la operación y gestión de la red. Por ello, este campo de investigación está recibiendo cada vez más atención.
La quinta es la zona de enrutamiento. Esta área de investigación es responsable de desarrollar estándares sobre cómo determinar rutas de transmisión en redes para enrutar paquetes IP a sus destinos.
El sexto es el campo de la seguridad. Este campo de investigación se encarga principalmente de estudiar protocolos y estándares relacionados con la protección de la privacidad en redes IP, como autorización, autenticación y auditoría. La seguridad de Internet ha atraído cada vez más atención, por lo que este campo se ha convertido en una de las áreas de investigación más activas del IETF.
Séptimo, ámbito del transporte. Este campo es principalmente responsable de estudiar los métodos de transmisión de extremo a extremo de tipos especiales o paquetes de datos para fines especiales en la red.
En los campos anteriores, además del campo de investigación de seguridad que se especializa en tecnología de seguridad, otros campos también involucrarán cuestiones de seguridad. Cómo mejorar la seguridad de los protocolos tecnológicos de Internet es un tema clave de investigación a largo plazo por parte del IETF.
En segundo lugar, el Protocolo de tecnología de recursos básicos de Internet utiliza una cadena de confianza de clave pública para mejorar la seguridad.
El Protocolo de tecnología de recursos básicos de Internet del IETF ha pasado de confiar en los datos de forma predeterminada a garantizar la credibilidad de las fuentes de datos, la integridad de los datos y la resistencia a la manipulación.
(1) El protocolo del sistema de nombres de dominio utiliza una cadena de confianza de clave pública para mejorar la seguridad.
El Protocolo del sistema de nombres de dominio (DNS) es el protocolo central de Internet. Es un sistema de servicios de Internet distribuido que asigna nombres de dominio a algunos tipos predefinidos de registros de recursos (como direcciones IP). Como servicio básico de direccionamiento de recursos de la capa de aplicaciones de Internet, el servicio de nombres de dominio es la base de otros servicios de aplicaciones de Internet. Los servicios comunes de aplicaciones de Internet, como servicios de acceso remoto a páginas web, servicios de correo electrónico, servicios de acceso remoto a archivos, etc., generalmente se basan en servicios de nombres de dominio para lograr el direccionamiento y posicionamiento de recursos.
El protocolo DNSSEC es una extensión de seguridad del protocolo DNS. Agrega firmas digitales basadas en algoritmos de cifrado asimétrico a los mensajes de respuesta DNS para garantizar que los datos no hayan sido manipulados y provengan de la fuente correcta. Luego envía su clave pública al dominio principal nivel por nivel a través del sistema de nombres de dominio de abajo hacia arriba para lograr una autenticación de seguridad nivel por nivel de todo el sistema de nombres de dominio. DNSSEC proporciona tres garantías de seguridad para los datos DNS: primero, verificación de la fuente de datos, asegurando que los mensajes de respuesta DNS provengan de servidores autorizados; segundo, verificación de la integridad de los datos, asegurando que los mensajes de respuesta DNS no hayan sido manipulados durante la transmisión; tercero, negación de la verificación; existencia. Cuando un usuario solicita un nombre de dominio inexistente, el servidor DNS también puede dar un mensaje de respuesta negativa que contenga una firma digital para garantizar la confiabilidad de la respuesta negativa.
En resumen, DNSSEC esencialmente establece un sistema de firma/verificación basado en criptografía basado en el sistema de autorización en forma de árbol del sistema de nombres de dominio, es decir, el sistema de cadena de confianza. garantiza la autenticidad, la integridad de los datos y el no repudio de los resultados de las consultas DNS.
ICANN ha estado promoviendo el despliegue de DNSSEC en todo el mundo.
En julio de 2010, ICANN firmó oficialmente un acuerdo de nombre de dominio raíz con DNSSEC. Para gestionar mejor las claves raíz, ICANN ha desarrollado un plan de gestión de claves raíz. El programa selecciona un representante de confianza de la comunidad (TCR) a nivel mundial para generar claves raíz administrativas. ICANN seleccionó 21 TCR y varios TCR de respaldo, y todos los candidatos eran personas de la comunidad de Internet. Entre ellos, 14 TCR son administradores de contraseñas (CO), 7 en la costa este y 7 en la costa oeste de Estados Unidos, responsables de generar claves raíz. Los otros 7 TCR son poseedores de claves de recuperación (RKSH), responsables de la copia de seguridad y la gestión del contenido del módulo de seguridad de hardware (HSM), y se utilizan para restaurar el estado de funcionamiento del HSM en caso de emergencia. En junio de 2010, se celebró la primera ceremonia de generación de claves raíz DNSSEC en Culpeper, Virginia, EE. UU.
ICANN tiene dos conjuntos de HSM idénticos, ubicados en la costa este y la costa oeste de Estados Unidos, para generar claves raíz. La clave para iniciar el HSM la conserva la empresa, y la ceremonia de generación de la clave raíz se lleva a cabo alternativamente en las costas este y oeste. Si hay un problema con el HSM o una emergencia con la clave raíz, RKSH debe ir a los Estados Unidos para restaurar el HSM y restaurar la clave raíz. Según las reglas de gestión de claves raíz formuladas por ICANN, ICANN no puede generar claves raíz sin la participación del TCR. A través de la participación de TCR en la generación y gestión de claves raíz, la generación y gestión de claves raíz de ICANN son más transparentes, formando una situación en la que el mundo participa en la generación y gestión de claves raíz.
El mecanismo DNSSEC utiliza el mecanismo de cadena de confianza de clave pública para construir un sistema de consulta de nombres de dominio confiable. Los datos de nombres de dominio de nivel superior de Internet en el servidor raíz global deben firmarse con la clave raíz para garantizar la seguridad. seguridad y credibilidad de los datos. DNSSEC solo garantiza la credibilidad de los datos DNS, pero no cifra los datos DNS en sí.
(B) El protocolo de infraestructura de clave pública de recursos maneja el problema de falsificación de anuncios de enrutamiento a través de la cadena de confianza de clave pública.
Como infraestructura de Internet que soporta la interconexión, el sistema de nombres de dominio y el sistema de enrutamiento entre dominios tienen un impacto vital en la seguridad de Internet. Dado que el Border Gateway Protocol (BGP) carece de garantía de autenticidad de los anuncios de rutas, los ataques deliberados de los piratas informáticos y la mala configuración de los parámetros de la red conducirán al secuestro de rutas. El secuestro de rutas tiene un gran impacto en el funcionamiento normal de Internet y puede provocar una parálisis de la red a gran escala. Por lo tanto, el IETF propuso el protocolo de infraestructura de clave pública de recursos (RPKI). El concepto de RPKI apareció por primera vez en el artículo que describe el Protocolo de puerta de enlace fronteriza segura (S-BGP). S-BGP propone un formato de mensaje BGP con firmas adicionales para verificar la relación vinculante entre el prefijo de dirección IP en el anuncio de ruta y el número AS en la ruta de propagación, evitando así el secuestro de ruta. Sobre esta base, BGP introduce certificados digitales y mecanismos de firma y utiliza una infraestructura de clave pública (PKI). Para verificar la clave pública que posee el firmante del anuncio de enrutamiento, se asigna la dirección IP del firmante a un superior para emitirle un certificado, que por un lado verifica su clave pública y por otro lado verifica la propiedad de la entidad. del prefijo de la dirección IP. El sistema de certificado de clave pública basado en la relación de asignación de recursos de direcciones IP constituye el marco básico de RPKI.
El sistema RPKI consta de tres módulos clave: sistema de certificado de clave pública (RPKI) de recursos básicos, objetos de firma digital y base de datos RPKI distribuida que almacena objetos de firma RPKI. Estos tres módulos aseguran que las entidades puedan verificar quién es el legítimo titular de una dirección IP o número AS. RPKI permite al titular legal de una dirección IP autorizar un AS como fuente de enrutamiento para la dirección y verificarla. Esta autorización verificable se puede utilizar para crear filtros de tabla de enrutamiento más seguros.
Para facilitar la implementación de RPKI, RPKI Construction aprovechó las tecnologías y prácticas existentes. La estructura de RPKI puede corresponder al sistema de asignación de recursos existente y puede considerarse como una extensión técnica natural del modelo operativo de organización de gestión de recursos existente. En este nuevo sistema, los métodos de asignación y recuperación de recursos existentes están claramente definidos.
(3) El protocolo de servicio de transmisión maneja la falsificación de certificados de nombres de dominio y la autenticación de clientes a través de la cadena de confianza de clave pública.
Los certificados utilizados para la certificación de seguridad en Internet suelen ser emitidos por una Autoridad Certificadora (CA). Sin embargo, el modelo CA es vulnerable a ataques. Hay miles de CA confiables en Internet que, en teoría, pueden emitir cualquier certificado. Las CA pueden emitir maliciosamente o por error certificados que no pertenecen a los usuarios de nombres de dominio de Internet, lo que genera ataques de intermediarios y posibles riesgos para la seguridad de Internet. El IETF propuso la tecnología de Protocolo de autenticación de entidades nombradas (DANE) basada en DNS en RFC6698. El DANE puede autenticar y emitir certificados de nombres de dominio a través de registros de recursos DNS llamados autenticación de Seguridad de la Capa de Transporte (TLSA). De esta manera, solo el controlador real que controla el nombre de dominio puede emitir el certificado de seguridad del nombre de dominio correspondiente, garantizando la autenticidad del mismo. Certificado TLS de seguridad. El DANE utiliza infraestructura DNSSEC para almacenar y firmar las claves y certificados utilizados por TLS. El DANE proporciona un mecanismo para vincular claves públicas a nombres de dominio DNS. Debido a que la entidad que administra los datos de clave pública y los nombres de dominio DNS es la misma, se reduce la oportunidad de ataques de intermediario utilizando nombres de dominio. Las claves asociadas con un nombre de dominio solo pueden firmarse y asociarse mediante la clave del dominio principal.
Por ejemplo, la clave de example.cn solo se puede firmar con la clave de cn, y la clave de cn solo se puede firmar con la clave raíz DNS. La clave de firma de cualquier nombre de dominio se puede consultar y distribuir utilizando el protocolo estándar DNSSEC, y los certificados autofirmados del usuario se pueden implementar a través del DANE. Originalmente, los certificados autofirmados se consideraban inseguros, pero con la bendición de DNSSEC, los certificados autofirmados para nombres de dominio se pueden usar de manera segura en el DANE.
En 2021, el IETF estableció el grupo de trabajo de Certificación DANE de Cliente de Red (DANCE) para fortalecer la seguridad de los protocolos relacionados con el cliente de red mediante el uso de DANE. Actualmente se están formulando las normas técnicas pertinentes. Varios protocolos de servicios de transmisión pueden manejar la falsificación de certificados de nombres de dominio y la autenticación de clientes a través de la cadena de confianza de clave pública en el mecanismo DANE, lo que hace que la comunicación sea más segura.
En tercer lugar, formular un protocolo de tecnología de recursos básicos de Internet para proteger la privacidad
Después de que estalló el incidente de Snowden en 2013, la IAB, el máximo órgano de gestión técnica del IETF, organizó una reunión especial seminario técnico Discutir cómo fortalecer la protección de la privacidad en Internet y evitar que los intermediarios escuchen e intercepten información. La IAB cree que los protocolos técnicos del IETF deben fortalecer integralmente el cifrado de extremo a extremo para evitar ataques de intermediario. Desde entonces, el protocolo IETF ha fortalecido las consideraciones de seguridad para proteger la privacidad del usuario de ser interceptada por intermediarios, promoviendo el desarrollo de protocolos de Internet para la protección de la privacidad.
(1) La evolución de los protocolos de transmisión de Internet al protocolo QUIC de Conexión Rápida y Segura
El protocolo de Conexión Rápida a Internet UDP (QUIC) es un protocolo de transmisión básico basado en el protocolo de red desarrollado e implementado por Google. Ha sido la estandarización del IETF. Google cree que hay muchos problemas con el Protocolo de control de transmisión (TCP) y quiere diseñar un nuevo protocolo de transmisión. La idea de diseñar basado en UDP se propuso en 2012 y se lanzó por primera vez en la versión 29 de Chromium lanzada en agosto de 2013. QUIC es uno de los muchos protocolos de red de capa de transporte que mejoran a TCP. El protocolo QUIC se lanzó oficialmente en mayo de 2021 con el número RFC9000.
QUIC puede considerarse como una aplicación de transporte de datagramas. Los protocolos de aplicación que utilizan QUIC utilizan el puerto UDP 443 para enviar y recibir paquetes. QUIC aborda diversas necesidades que enfrentan las capas de transporte y aplicaciones, incluido el manejo de más conexiones con mejor seguridad y baja latencia. QUIC se basa en la transmisión UDP y combina las características de protocolos que incluyen TCP, Seguridad de la capa de transporte (TLS) y Protocolo de transferencia de hipertexto versión 2 (HTTP/2) para hacer que el protocolo de transmisión sea más eficiente. Uno de los principales objetivos de QUIC es reducir la latencia de la conexión. Cuando el cliente se conecta al servidor por primera vez, QUIC solo requiere 1 retraso de ida y vuelta (RTT) para establecer una conexión confiable y segura, que es más rápida que los 1 3 RTT de TCP + TLS. Posteriormente, el cliente puede almacenar en caché la información de autenticación cifrada localmente y lograr un retraso de 0 RTT al establecer una conexión con el servidor nuevamente. QUIC también reutiliza la función de multiplexación del protocolo HTTP/2 y utiliza UDP para evitar con éxito el problema de bloqueo del encabezado de cola de HTTP/2.
(B) Protocolo de transferencia DNS para proteger la privacidad del usuario.
Debido al diseño de texto claro de DNS, se filtrará el comportamiento de los usuarios al consultar datos DNS de nombres de dominio. Al mismo tiempo, el servidor de terceros recopilará registros de consultas de los usuarios. El desarrollo técnico de la protección de la privacidad del DNS incluye principalmente dos aspectos.
El primero es el mecanismo de minimización de consultas. Es decir, el solucionador recursivo solo envía la información de consulta necesaria a la vez y no expone el nombre de dominio completo a los servidores raíz y de nivel superior. Al mismo tiempo, algunos investigadores propusieron confundir cada consulta real con múltiples consultas virtuales, y el servidor transmite activamente nombres de dominio activos para reducir el riesgo de fuga de privacidad del usuario.
El segundo tipo es el DNS basado en HTTPS (DoH) y el DNS basado en TCP (DoT), que utilizan tecnologías HTTPS y TCP para implementar el cifrado DNS respectivamente, y ambos están basados en TLS. Actualmente, ambos se han publicado como estándares técnicos IETF RFC. El IETF ha establecido un Grupo de Trabajo de Intercambio y Transmisión de Privacidad de DNS para especializarse en temas relacionados con la protección de la privacidad de DNS. Este grupo de trabajo también promueve el DNS (DoQ) basado en QUIC. HTTP-over-QUIC, por otro lado, se denomina HTTP/3. Después de que DoH/DoT fuera lanzado como estándar formal, los temas relacionados con la privacidad del IETF se centraron principalmente en el descubrimiento automático de analizadores con tecnología de cifrado y la investigación sobre mecanismos de cifrado de privacidad que recurren a analizadores autorizados.
(3) El protocolo de seguridad de la capa de transporte se amplía para admitir más tecnologías de privacidad.
TLS 1.3 es el nuevo estándar TLS desarrollado por el IETF. TLS se utiliza para proteger la web (y muchas otras áreas), proporcionando cifrado y garantizando la autenticidad de cada sitio web HTTPS y cada interfaz de programación de aplicaciones (API). RFC 8446 pertenece a TLS 1.3 y se lanzó en 2018. Es la primera reforma importante del protocolo y aporta importantes mejoras de seguridad y rendimiento. TLS 1.3 se basa en el TLS 1.2 anterior, pero también es muy diferente de TLS 1.2.
Por ejemplo, TLS1.3 puede reducir el tiempo de retraso del protocolo de enlace, mejorar la resistencia a los ataques, diseñar el algoritmo de autenticación y negociación de claves para que se separe del paquete criptográfico y eliminar algoritmos frágiles y poco utilizados, como eliminar el mensaje. algoritmo de resumen (MD5). TLS 1.3 cifra la mayor parte de la información transmitida, pero la información de indicación del nombre del servidor (SNI) proporcionada por TLS 1.3 no se cifra al enviar la sesión ClientHello. Cuando dos partes de TLS 1.3 intercambian información, el tercero puede obtener fácilmente la información de indicación del nombre del servidor. Actualmente, el IETF está promoviendo tecnología para cifrar la información de indicación de nombre de servidor (SNI) (ECH). Si se implementa la tecnología ECH, la información de indicación del nombre del servidor (SNI) de ambas partes se cifrará y será difícil para un tercero conocer la información del SNI, lo que hará que la comunicación entre las dos partes sea más privada.
4. Los protocolos tecnológicos de recursos básicos de Internet deben desarrollar seguridad y credibilidad integrales.
Internet se ha integrado en todos los aspectos de la vida y el trabajo, y los datos que se transmiten a través de Internet son cada vez más importantes. Los datos del protocolo de tecnología de recursos básicos de Internet pasan gradualmente del modo de transmisión de texto sin formato a la autenticación de la confiabilidad, integridad y resistencia a la manipulación de la fuente de los datos de texto sin formato. Algunos datos centrales están encriptados y algunos parámetros del protocolo también están encriptados. A través de medios como firmas, cadenas de confianza y cifrado, se garantiza la confiabilidad y seguridad de la transmisión de datos en Internet y se reduce la posibilidad de que intermediarios obtengan información privada. Con base en el análisis anterior, podemos hacer los siguientes juicios.
En primer lugar, el protocolo QUIC muestra un mejor rendimiento que el protocolo TCP, y el protocolo TCP de Internet puede ser reemplazado gradualmente por el protocolo QUIC. En los próximos diez años, el protocolo QUIC invadirá gradualmente el territorio del protocolo TCP, y más aplicaciones se basarán en el protocolo QUIC en lugar de la transmisión del protocolo TCP.
En segundo lugar, el protocolo TLS 1.3 se está implementando gradualmente para reemplazar la versión anterior del protocolo. Si la tecnología ECH se implementa de manera coordinada en el futuro, la transmisión de Internet de extremo a extremo será más segura y confiable, pero esta tecnología puede provocar fallas en algunas funciones de firewall que utilizan información de indicación de nombre de servidor (SNI). ) para la gestión de políticas de seguridad.
En tercer lugar, debido a los problemas de gestión de seguridad de la cadena de confianza y el ancla de confianza, RPKI es difícil de implementar a gran escala en un corto período de tiempo. Si RPKI no se opera correctamente, una mala configuración del certificado o una revocación maliciosa también pueden causar una serie de problemas de seguridad.
En cuarto lugar, la tecnología DNSSEC se ha implementado en la zona raíz global de Internet durante más de diez años. Dado que la inversión en implementación de tecnología no es proporcional a los beneficios que aporta, la tasa de implementación actual no es muy alta. alto. En los próximos diez años, sin el apoyo de aplicaciones clave, será difícil que DNSSEC se utilice ampliamente.
(Este artículo se publicó en el número 4 de la "Revista de seguridad de la información de China", número 4, 2022)