Tendencias de desarrollo de seguridad de los protocolos de tecnología de recursos básicos de Internet
Autor: Yao Jiankang, Centro de Información de Redes de Internet de China
En primer lugar, el Grupo de Trabajo Internacional de Ingeniería de Internet (IETF) es el campo base para el desarrollo de protocolos de tecnología de Internet
El desarrollo de Internet cambia el mundo. Los estándares técnicos básicos y los protocolos técnicos básicos para el funcionamiento de Internet provienen principalmente del Grupo de Trabajo Internacional de Ingeniería de Internet (IETF). El IETF se estableció a principios de 1986 y es 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. El IETF formula más de 90 estándares técnicos de Internet. formulación de estándares técnicos que garanticen el funcionamiento estable a largo plazo de Internet. Una gran parte 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 temas de investigación. Antes de establecer un grupo de trabajo, el IETF suele establecer un grupo de interés (BOF) para llevar a cabo el trabajo preparatorio del grupo de trabajo. 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 asistentes.
Fundada en 1983, la Junta de Arquitectura de Internet (IAB) es el máximo órgano de gobierno del IETF y está formada por 13 miembros, incluido el presidente del IETF. Una de las principales responsabilidades de la IAB es estandarizar la arquitectura del protocolo de Internet, captar la dirección de la evolución a largo plazo de la tecnología de Internet y proteger el desarrollo a largo plazo de Internet. Es responsable de determinar las reglas para formular estándares de Internet; guiar la edición y publicación de estándares técnicos de Internet y proteger el desarrollo a largo plazo de Internet. También es responsable de determinar las reglas para establecer estándares de Internet, guiar la edición y publicación de estándares técnicos de Internet, administrar la numeración de Internet y coordinar el trabajo con otras organizaciones internacionales de estandarización.
El IETF divide los grupos de trabajo en varias áreas, y cada área está dirigida por varios directores de área. Los directores de cada área forman el Grupo Directivo de Ingeniería de Internet (IESG). Las áreas específicas son las siguientes.
El primero son los campos de aplicación y tiempo real. Esta área se centra principalmente en estándares relacionados con la capa de aplicación, pero también incluye protocolos de red relacionados en tiempo real.
El segundo es el campo general. Este campo de estudio incluye investigaciones que no son compatibles con otros campos de estudio.
En tercer lugar, el campo de Internet. El campo de Internet estudia principalmente cómo transmitir paquetes de datos IP en diferentes entornos de red.
En cuarto lugar, el ámbito de operación y gestión. Esta área de investigación se centra en el funcionamiento y gestión de Internet. Con el rápido desarrollo y popularización de Internet, se han planteado mayores requisitos para la operación y gestión de la red, por lo que este campo de investigación ha recibido cada vez más atención.
En quinto lugar, el campo de enrutamiento. Esta área de investigación se encarga de desarrollar estándares para determinar rutas de transmisión en redes con el fin de enrutar paquetes IP a sus destinos.
El sexto es el campo de la seguridad. Esta área de investigación se encarga principalmente del estudio de la autorización, autenticación, auditoría y otros protocolos y estándares relacionados con la protección de la privacidad de las redes IP. La seguridad de Internet ha recibido cada vez más atención, por lo que esta área se ha convertido en una de las áreas de investigación más activas del IETF.
El séptimo es el campo de transmisión. Este campo es el principal responsable de estudiar la transmisión de un extremo a otro de tipos especiales de paquetes de datos 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 involucran 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 del IETF utiliza cadenas 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 que los datos la fuente es confiable y los datos integridad y resistencia a la manipulación.
(a) 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 servicio de Internet distribuido. sistema que puede asignar nombres de dominio a ciertos tipos predefinidos de registros de recursos (como direcciones IP). Como recurso de la capa de aplicación de Internet que aborda el servicio de infraestructura, los servicios de nombres de dominio son la base para otros servicios de aplicaciones de Internet. Los servicios comunes de aplicaciones de Internet (como servicios de acceso remoto 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 una firma digital basada en un algoritmo de cifrado asimétrico al mensaje de respuesta DNS y luego envía su propio nombre de dominio público al dominio principal a través del. sistema de nombres de dominio de abajo hacia arriba *** Clave para lograr la autenticación de seguridad nivel por nivel de todo el sistema de nombres de dominio para garantizar que los datos no sean manipulados y provengan de la fuente correcta. DNSSEC proporciona tres garantías de seguridad para los datos DNS: primero, verificación de la fuente de datos, que garantiza que los mensajes de respuesta DNS provengan de servidores autorizados; segundo, verificación de la integridad de los datos, que garantiza que los mensajes de respuesta DNS no hayan sido manipulados durante la transmisión; tercero, verificación de existencia negativa; Garantiza que cuando un usuario solicita un nombre de dominio que no existe, el servidor DNS pueda dar un mensaje de respuesta negativa que contenga una firma digital para garantizar la confiabilidad de la respuesta negativa. Cuando un usuario solicita un nombre de dominio que no existe, 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 es esencialmente un sistema de firma/verificación basado en criptografía. Se basa en el sistema de autorización en forma de árbol del sistema de nombres de dominio, es decir, el sistema de cadena de confianza, que garantiza el DNS. consultas a través de una cadena de confianza de verificación de seguridad paso a paso, la verdadera confiabilidad, integridad de los datos y no repudio de los resultados.
La Corporación de Internet para la Asignación de Nombres y Números (ICANN) ha estado promoviendo el despliegue de DNSSEC a nivel mundial. En julio de 2010, ICANN firmó oficialmente las DNSSEC de la zona raíz. Para gestionar mejor las claves raíz, ICANN ha desarrollado un Programa de gestión de claves raíz. El programa selecciona representantes comunitarios de confianza (TCR) a nivel mundial para que sean responsables de generar y administrar claves raíz. ICANN seleccionó 21 TCR y varios TCR de respaldo en ****, que son personas de la comunidad de Internet. Catorce de los TCR son criptozoólogos (CO), siete en la costa este de EE. UU. y siete en la costa oeste de EE. UU., involucrados en la generación de claves raíz. Otros siete TCR son titulares de claves de recuperación (RKSH) que son responsables de realizar copias de seguridad y administrar el contenido del módulo de seguridad de hardware (HSM) para restaurar el HSM a sus condiciones de funcionamiento en caso de una emergencia. En junio de 2010, se celebró en Culpeper, Virginia, EE. UU., la primera ceremonia de generación de claves raíz DNSSEC del mundo.
La ICANN tiene dos HSM idénticos, uno en la costa este de EE. UU. y otro en la costa oeste de EE. UU., para la generación de claves raíz. La clave para iniciar el HSM la guarda el CO. Las ceremonias de generación de claves raíz se alternan entre las costas este y oeste. Si hay un problema con el HSM o hay una emergencia con la clave raíz, RKSH debe viajar a los Estados Unidos para restaurar el HSM y recuperar la clave raíz. De acuerdo con las reglas de administración de claves raíz establecidas por ICANN, ICANN no puede generar la clave raíz sin la participación de TCR. TCR participa en la generación y gestión de claves raíz, lo que hace que la generación y gestión de claves raíz de ICANN sea más transparente, formando una situación en la que el mundo participa conjuntamente 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 secreta raíz para garantizar. la seguridad y confiabilidad de los datos.
DNSSEC solo garantiza la credibilidad de los datos DNS, pero no cifra los datos DNS en sí.
(ii) El protocolo PKI de recursos utiliza la cadena de confianza de clave pública para resolver el problema de la falsificación de notificaciones de enrutamiento.
Como la infraestructura de Internet que soporta la interconexión, el sistema de nombres de dominio y la El sistema de enrutamiento entre dominios tiene un impacto en la seguridad de Internet y tiene un impacto vital. Dado que Border Gateway Protocol (BGP) carece de garantías sobre la autenticidad de los anuncios de rutas, tanto los ataques deliberados de los piratas informáticos como los parámetros de red mal configurados pueden provocar el 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 Resource Public Key Infrastructure (RPKI), que se propuso por primera vez en un documento que describía el esquema Secure Border Gateway Protocol (S-BGP). Propuso un mensaje BGP con un formato de firma, utilizado para verificar el enlace. del prefijo de dirección IP en el anuncio de ruta y el número de dominio autónomo (AS) en la ruta de propagación, evitando así el secuestro de ruta. Esto es para evitar el secuestro de rutas. Sobre la base de este diseño, se introducen certificados digitales y mecanismos de firma en BGP y se utiliza la infraestructura de clave pública (PKI). Para verificar la clave pública que posee un firmante de un anuncio de enrutamiento, el superior que asigna la dirección IP del firmante emite un certificado que verifica tanto su clave pública como la propiedad de la entidad del prefijo de dirección IP. La relación de asignación de recursos de direcciones IP formada sobre la base del sistema de certificado de clave pública constituye el marco básico de RPKI.
El sistema RPKI consta de tres módulos clave: el sistema de certificado de clave pública (RPKI) de recursos subyacente, objetos de firma digital y un repositorio RPKI distribuido que almacena objetos de firma RPKI. RPKI permite al titular legítimo de una dirección IP autorizar y autenticar un AS como fuente de enrutamiento para esa dirección. Esta autorización verificable se puede utilizar para crear filtros de tabla de enrutamiento más seguros.
Para facilitar la implementación de RPKI, la arquitectura RPKI aprovecha las tecnologías y prácticas existentes. La estructura de RPKI corresponde a los sistemas de asignación de recursos existentes y puede verse como una extensión tecnológica natural de la forma en que operan actualmente las organizaciones de gestión de recursos, y la forma en que se asignan y recuperan los recursos existentes está claramente definida en la nueva arquitectura.
(c) TSP utiliza una cadena de confianza de clave pública para resolver la falsificación de certificados de nombres de dominio y los problemas de autenticación de clientes.
Los certificados utilizados para la autenticación segura en Internet generalmente se emiten mediante la denominada certificación. autoridades (CA) de emisión. Sin embargo, el modelo de CA es relativamente vulnerable a los 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, generando así ataques de intermediario y provocando riesgos de seguridad en Internet. El IETF propuso la tecnología DANE (Protocolo de autenticación de entidades de nombres) basada en DNS en el estándar técnico 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 modo que solo el controlador real del nombre de dominio controlado puede emitir un certificado de seguridad para el nombre de dominio correspondiente, garantizando así la seguridad del TLS. certificado. DANE utiliza la infraestructura DNSSEC para almacenar y firmar las claves y certificados utilizados por TLS, y DANE proporciona un mecanismo para vincular claves públicas a nombres de dominio DNS. Dado que la entidad que administra los datos de clave pública y la entidad que administra el nombre de dominio DNS son la misma, se reduce la oportunidad de ataques de intermediario utilizando nombres de dominio. Las claves asociadas con un nombre de dominio solo se pueden firmar y asociar con la clave del dominio principal. Por ejemplo, la clave "example.cn" solo puede firmarse con la clave "cn", y la clave "cn" solo puede firmarse con la clave raíz DNS. Las claves de firma para cualquier nombre de dominio se pueden consultar y distribuir mediante el protocolo DNSSEC estándar, o se pueden implementar certificados firmados por el usuario a través del DANE. Inicialmente, los certificados autofirmados se consideraban inseguros, pero con DNSSEC, los certificados autofirmados para nombres de dominio se pueden utilizar de forma segura en el DANE.
En 2021, el IETF estableció el grupo de trabajo Network Client DANE Authentication (DANCE) para fortalecer la seguridad de los protocolos relacionados con el cliente de red que utilizan DANE. Actualmente se están formulando normas técnicas pertinentes. Varios protocolos de servicios de transporte pueden abordar la falsificación de certificados de nombres de dominio y problemas de verificación de clientes a través de la cadena de confianza de clave pública en el mecanismo DANE, haciendo así las comunicaciones más seguras.
En tercer lugar, los protocolos tecnológicos de recursos básicos de Internet se están desarrollando en la dirección de la protección de 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ó un seminario técnico para 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 fortalecerse y la IAB continuará trabajando con el IETF para mejorar la protección de la privacidad en Internet. La IAB concluyó que los protocolos técnicos del IETF deben reforzarse completamente con cifrado de extremo a extremo para evitar ataques de intermediarios. Desde entonces, el protocolo IETF ha fortalecido las consideraciones de seguridad para proteger la privacidad del usuario de la interceptación por parte de intermediarios y promover el desarrollo de protocolos de Internet en la dirección de la protección de la privacidad.
(a) 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) se basa en el protocolo de red desarrollado e implementado por Protocolo de transporte Google Basic. Ha sido estandarizado por el IETF. Google reconoció los problemas con el Protocolo de control de transmisión (TCP) y quería diseñar un nuevo protocolo de transmisión, por lo que propuso un concepto de diseño basado en UDP en 2012 y lo anunció por primera vez en Chromium versión 29 lanzada en agosto de 2013. El protocolo QUIC se publicó como RFC 9000 en mayo de 2021.
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 las necesidades que enfrentan las capas de transporte y aplicaciones actuales, incluido el manejo de más conexiones, mejor seguridad y baja latencia. QUIC se basa en el transporte UDP y combina protocolos como TCP, Transport Layer Security (TLS) y Hypertext Transfer Protocol versión 2 (HTTP/2). Uno de los principales objetivos de QUIC es reducir la latencia de la conexión. Cuando un cliente se conecta por primera vez a un servidor, QUIC requiere solo un retraso de ida y vuelta (RTT) para establecer una conexión confiable y segura, que es más rápido que los 13 retrasos de ida y vuelta de TCP TLS. Luego, el cliente puede almacenar en caché la información de autenticación cifrada localmente y lograr una latencia de 0 RTT cuando se conecta nuevamente al servidor. QUIC también reutiliza las capacidades de multiplexación del protocolo HTTP/2 y evita con éxito los problemas de bloqueo de encabezados de HTTP/2 mediante el uso de UDP.
(2) El protocolo de transmisión DNS se desarrolla en la dirección de proteger la privacidad del usuario
Debido al diseño explícito de DNS, los usuarios que consultan los datos DNS del nombre de dominio revelarán el comportamiento del usuario, y terceros Los servidores externos recopilarán el registro de consultas del usuario, por lo que 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 cada vez sin exponer el nombre de dominio completo al servidor raíz y al servidor de nivel superior. Al mismo tiempo, algunos investigadores también han propuesto algunos métodos, como confundir cada consulta real en múltiples consultas virtuales e iniciar transmisiones en caliente de nombres de dominio por parte del servidor para reducir el riesgo de filtración de la privacidad del usuario.
Seguido por los mecanismos DNS (DoH) basados en HTTPS y DNS (DoT) basados en TCP, que utilizan tecnologías HTTPS y TCP para implementar el cifrado DNS, y ambos están basados en TLS.
Actualmente, estos dos mecanismos se han publicado como estándares técnicos RFC del IETF. El IETF también ha establecido un Grupo de Trabajo de Intercambio de Transferencia de Privacidad del DNS para estudiar temas relacionados con la protección de la privacidad del DNS. El IETF también ha establecido un grupo de trabajo de intercambio de transferencia 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 ha denominado HTTP/3. Después de que DoH/DoT fuera lanzado como estándar formal, los problemas relacionados con la privacidad del IETF se centraron principalmente en el descubrimiento automático de analizadores criptográficos y el mecanismo de cifrado de privacidad recursivo de los analizadores autorizados.
(c) Ampliar el protocolo de seguridad de la capa de transporte para admitir más tecnologías de privacidad
TLS 1.3 es el nuevo estándar TLS del IETF que proporciona cifrado y seguridad para cada sitio web y aplicación HTTPS. (API) autenticidad para proteger la web (y más dominios). El estándar RFC 8446 al que pertenece TLS 1.3 fue lanzado en 2018 y supuso la primera modificación importante del protocolo, con importantes mejoras en seguridad y rendimiento. TLS 1.3 se basa en el TLS 1.2 anterior, pero también tiene diferencias significativas con respecto a TLS 1.2, como la reducción del retraso del protocolo de enlace, la mejora de la resistencia a los ataques y el diseño de algoritmos de verificación y negociación de claves que son independientes de los paquetes de cifrado. Por ejemplo, TLS 1.3 reduce los retrasos en el protocolo de enlace, mejora la resistencia a los ataques, separa los algoritmos de autenticación y negociación de claves de los paquetes criptográficos y elimina algoritmos vulnerables y poco comunes, como el algoritmo de eliminación de resúmenes de mensajes (MD5) y el algoritmo hash seguro (SHA-). 224) apoyo, etc. Aunque la mayor parte de la información transmitida está cifrada, la información de indicación del nombre del servidor (SNI) proporcionada por TLS 1.3 no aparece en la sesión ClientHello enviada. La información de indicación del nombre del servidor (SNI) proporcionada por TLS 1.3 no aparece en la sesión ClientHello enviada. Terceros pueden acceder fácilmente a SNI cuando las partes de TLS 1.3 intercambian información, y el IETF actualmente está avanzando en tecnología para cifrar SNI (ECH). Si se implementa ECH, ambas partes comunicantes cifran el SNI, lo que dificulta que terceros accedan a la información del SNI y hace que las comunicaciones sean más privadas.
4. Los protocolos tecnológicos de recursos básicos de Internet se desarrollan hacia una seguridad y confiabilidad integrales
Internet se ha integrado en todos los aspectos de la vida y el trabajo de las personas, y los datos transmitidos por Internet se están volviendo cada vez más cada vez más importante. Los datos del protocolo de tecnología de recursos básicos de Internet han pasado gradualmente de la transmisión de texto sin formato a la autenticación de la confiabilidad, integridad y protección contra manipulaciones de la fuente de datos de texto sin formato. Algunos datos centrales se han cifrado y también se han cifrado algunos parámetros del protocolo. cifrado. La confiabilidad y seguridad de la transmisión de datos en Internet están garantizadas mediante firmas, cadenas de confianza y cifrado, reduciendo la posibilidad de que intermediarios obtengan información privada. Con base en el análisis anterior, se pueden extraer 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 se transmitirán más aplicaciones basadas en el protocolo QUIC en lugar del protocolo TCP.
En segundo lugar, el protocolo TLS 1.3 se está implementando gradualmente para reemplazar la versión anterior del protocolo. Si se implementa en combinación con la tecnología ECH en el futuro, permitirá la transmisión de Internet de un extremo a otro. Es más seguro y confiable, pero esta tecnología puede provocar que parte de la funcionalidad del firewall que utiliza el indicador de nombre del servidor (SNI) para la administración de políticas de seguridad esté deshabilitada.
En tercer lugar, debido a los problemas de gestión de seguridad de las cadenas de confianza y los anclajes de confianza, RPKI es difícil de implementar a gran escala en el corto plazo.
Si RPKI no se utiliza correctamente, una mala configuración del certificado o una revocación maliciosa también pueden provocar una serie de problemas de seguridad.
En cuarto lugar, dado que la tecnología DNSSEC se ha implementado en la zona raíz de nombres de dominio global de Internet durante más de diez años, la tasa de implementación actual no es alta porque la inversión en implementación de tecnología no es proporcional a los beneficios. trae. Durante la próxima década, DNSSEC tendrá dificultades para lograr una adopción masiva sin el apoyo de aplicaciones clave.
(Este artículo se publicó en el número 4 de 2022 de la revista "China Information Security")