ES2950584T3 - Procedimiento y sistema para validar la prueba ordenada de tránsito de paquetes de tráfico en una red - Google Patents

Procedimiento y sistema para validar la prueba ordenada de tránsito de paquetes de tráfico en una red Download PDF

Info

Publication number
ES2950584T3
ES2950584T3 ES18382095T ES18382095T ES2950584T3 ES 2950584 T3 ES2950584 T3 ES 2950584T3 ES 18382095 T ES18382095 T ES 18382095T ES 18382095 T ES18382095 T ES 18382095T ES 2950584 T3 ES2950584 T3 ES 2950584T3
Authority
ES
Spain
Prior art keywords
node
metadata
transit
route
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES18382095T
Other languages
English (en)
Inventor
Martin Alejandro Aguado
Ayuso Vicente Martin
Diego R Lopez
Perales Antonio Pastor
Alvarez Víctor Lopez
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica SA filed Critical Telefonica SA
Application granted granted Critical
Publication of ES2950584T3 publication Critical patent/ES2950584T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/021—Ensuring consistency of routing table updates, e.g. by using epoch numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • H04L9/0656—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Abstract

Un sistema y método para validar la prueba de tránsito del tráfico de red a través de nodos de red (N), comprendiendo el nodo (N) un conjunto de interfaces de entrada (20) que reciben paquetes entrantes, un primer módulo (A) para identificar una ruta coincidente dentro de una tabla de enrutamiento (23) y medios de almacenamiento (22) para proporcionar a los siguientes módulos (B, C, D) dos claves privadas si el paquete coincide y/o los metadatos del paquete incluyen información OPoT. El segundo módulo (B) descifra los metadatos OPoT utilizando la primera clave privada asociada al enlace del nodo desde el que se reciben los paquetes entrantes. El nodo (N) dispone de metadatos SSS para ser procesados por un tercer módulo (C) para la correcta generación de parámetros de validación acumulativos. Cuando el tercer módulo (C) finaliza el proceso SSS, el cuarto módulo (D) vuelve a cifrar los metadatos OPoT utilizando la segunda clave privada antes de reenviar el paquete al nodo siguiente en la ruta a través de las interfaces de salida (21). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento y sistema para validar la prueba ordenada de tránsito de paquetes de tráfico en una red
Campo de la invención
La presente invención tiene su aplicación dentro del sector de las telecomunicaciones, más concretamente, se refiere a una prueba de tránsito para validar que un paquete ha atravesado una ruta en una red.
Más concretamente, la presente invención se refiere a un procedimiento y un sistema que proporciona una prueba de tránsito ordenada (OPoT) para paquetes reenviados a través de una ruta en una red.
Antecedentes de la invención
La tendencia actual a construir servicios de red implica su despliegue a través de entidades de reenvío asignadas dinámicamente que suelen formar túneles opacos que proporcionan conectividad de extremo a extremo. Estas rutas (configuradas con controladores centralizados o autogestionadas por nodos de red o sistemas de gestión de red) no disponen de técnicas de verificación para comprobar si el tráfico se reenvía en orden a través de una ruta verificada. Además, con la llegada de las técnicas de virtualización de redes, la verificación del correcto reenvío de paquetes a través de una infraestructura virtualizada se ha convertido en una necesidad, no sólo por razones de seguridad, sino también con fines legales o de otro tipo.
Varias tecnologías, como la ingeniería de tráfico (TE), el encadenamiento de funciones de servicio (SFC) y el encaminamiento basado en políticas, se utilizan para dirigir el tráfico a través de una ruta específica definida por el usuario.
Las áreas tecnológicas que comprenden las redes definidas por software (SDN), la virtualización de funciones de red (NFV), la WAN definida por software, el CPE universal (uCPE) y cloudVPN exigen procedimientos que garanticen la realización de las rutas de tráfico especificadas.
El borrador de Internet "Proof of Transit - draft-brockners-proof-of-transit-04" publicado el 30 de octubre de 2017 por el Grupo de Trabajo de Ingeniería de Internet (IETF) define mecanismos para demostrar de forma segura que el tráfico ha transitado por una ruta definida. Estos mecanismos permiten verificar de forma segura si, dentro de la ruta dada, todos los paquetes atravesaron todos los nodos que se supone que deben visitar. Este borrador del IETF propone un esquema doble (dos polinomios) basado en la técnica de Compartición de Secretos de Shamir (SSS), aplicada a la red para validar que flujos/tráfico específicos atraviesan un conjunto de nodos de una red (Prueba de Tránsito). La idea clave de SSS es distribuir un secreto en diferentes partes a los nodos incluidos en la ruta. Cada nodo reconstruye/crece el secreto utilizando su parte y los polinomios de Lagrange, obteniendo finalmente el valor deseado (el secreto, es decir, el coeficiente constante del polinomio) al llegar al nodo de salida de la ruta. Esta solución se mejora para soportar múltiples paquetes utilizando dos polinomios, uno de ellos secreto y el otro público (el utilizado para calcular el secreto) y aleatorizado por paquete.
Los documentos US2016/0315921A1 y US2016/0315819A1 encierran dos técnicas diferentes: la primera utiliza el cifrado anidado o acumulativo para cultivar cierta información mientras llega al nodo de verificación, mientras que la segunda es la misma que describe el borrador del IETF antes mencionado. El documento US2016/0315921A1 utiliza el cifrado acumulativo, que requiere que los distintos nodos posean claves secretas (distribuidas desde un servidor central de claves), un número aleatorio generado en el nodo de entrada y un número de secuencia o marca de tiempo que se cifra y combina con el valor de verificación. Al recibirlo, el nodo de salida reconstruye el mismo valor, ya que posee todas las claves de los nodos intermedios. La combinación del resultado de cifrado y el valor de verificación se realiza mediante OR exclusivo (XOR), mientras que para este esquema puede utilizarse cualquier valor de cifrado o hash. Como la combinación de cada resultado de cifrado se realiza mediante XOR (operación conmutativa), esta solución no depende del orden (el verificador puede construir la validación en el orden que desee, como en SSS), pero tampoco comprueba el orden durante la prueba de tránsito. El documento US2016/0315819A1 describe procedimientos para verificar la prueba de tránsito del tráfico de red a través de una pluralidad de nodos de red en una red. La información de verificación se lee de los metadatos en banda del paquete. Se genera información de verificación actualizada a partir de la información de verificación leída del paquete y basada en información de configuración asociada con el nodo de red. La información de verificación actualizada se vuelve a escribir en los metadatos en banda del paquete y el paquete se reenvía desde el nodo de red en la red.
La solución actual especificada por el mencionado borrador del IETF introduce un segundo polinomio en el esquema SSS para mejorar la reutilización de la solución para un flujo de tráfico, pero este enfoque conlleva ciertos problemas de vulnerabilidad. En este sentido, un atacante pasivo podría intervenir el tráfico en los enlaces intermedios (uno o varios) de la ruta, almacenar los metadatos del paquete y utilizarlos para calcular información como los coeficientes constantes del polinomio de Lagrange y el número primo del polinomio utilizado por el SSS, y con esa información, reproducir el valor de verificación y eludir cualquier nodo de la red. Más concretamente, a continuación se muestra cómo se puede engañar a esta técnica reuniendo pocos paquetes (ya sea a través de cada salto, o incluso antes y después de un único nodo):
Supongamos inicialmente que dos paquetes, el paquete1 y el paquete2, pueden reunirse justo después del primer nodo de la ruta. Sea f (xi) el resultado de un primer polinomio para un punto xi asignado al nodo "i", nodoi, de la ruta. Sea f2(xi) el resultado de un segundo polinomio sin el coeficiente constante. Entonces sea RNDj la parte constante del segundo polinomio para un paquete j dado y CML\ el valor acumulado del paquete después de atravesar el nodoi. LPC significa constante polinómica de Lagrange y LPCi denota la constante polinómica de la base de Lagrange para el punto xi.. Tanto xi como LPCi deben mantenerse en secreto. Entonces, capturando dos paquetes:
Figure imgf000003_0001
Para un nodoi dado el resultado será:
Figure imgf000003_0002
donde ^
Figure imgf000003_0003
{ _ CML{11}^ (mod p) denota el valor de LPCi generado respectivamente por el paquete1 y el paquete2. El LPCi debe ser único, pero aún se desconoce el número primo p utilizado para la operación del módulo, lo que dificulta su cálculo. Rastreando once paquetes, se pudieron generar hasta 10! combinaciones de LPC{y,z}y, de todas ellas, sólo los valores de LPC)y,z ^ e % son elegibles.
Si l,2<l<10! es el número de LPC^y,z^ e % entonces (1 -1 )! combinaciones de LPC{y,z}pueden calcularse como:
Figure imgf000003_0004
{
Y a continuación se calcula el siguiente conjunto, del que podría derivarse el número primo p:
Figure imgf000003_0005
Supongamos que el número primo p se obtiene a partir del conjunto calculado anteriormente. Los valores de CML] y RNDi son públicos (están encapsulados abiertamente en los metadatos del paquete). Por lo tanto, suponiendo que el tráfico pueda ser manipulado en cualquier punto (y que se haya obtenido p), para una configuración dada de la Prueba de Tránsito (PoT), el conjunto {LPC1,...,LPC^n_1}} podría calcularse rastreando dos paquetes diferentes (y sus metadatos PoT).
Supongamos ahora que un tercer paquete3 atraviesa la red. Comprobemos si, conociendo RNDs, se pueden calcular los valores CML]3 . En primer lugar, aunque no se pueda hacer lógicamente (el cálculo de la constante aleatoria se hace internamente en el primer nodo), CML\ se calcula de la siguiente manera:
Figure imgf000003_0006
Para un nodoi dado el resultado será:
Figure imgf000004_0001
Entonces, rastreando los paquetes antes y después de un único nodoi de la red, se podría evitar ese nodo "i" de la ruta PoT obteniendo el paquete, y calculando el correspondiente CMi{new_pacfcet). Si la información se recopila en cada salto de la ruta, el secreto también podría crecer hasta el n-1 salto obteniendo el paquete en el primer nodo, eludiendo toda la ruta.
Por ejemplo, para el segundo nodo, el nodo2, después de recuperar el paquete en el primer salto:
Figure imgf000004_0002
donde se conocen todos los valores, y puede ser generado CML\ y, por lo tanto, el tercer nodo, el nodos , puede evitarse.
Esta demostración podría entonces cultivarse para cualquier nodo "i" de la ruta. Estas operaciones se hacen mod (p) y esto supone que el número primo p puede ser revelado como se muestra inicialmente. También se podría hacer un análisis estadístico para comprobar cuántos paquetes hay que reunir para conseguir ese conjunto lo suficientemente grande para el ataque.
En resumen, hay varios problemas en las soluciones anteriores:
- Las soluciones actuales validan que cierto tráfico ha atravesado un conjunto de nodos, pero no en qué orden. - La solución basada en SSS (el mencionado borrador del IETF) aún no ha demostrado ser segura, como ya se ha explicado.
- Las soluciones basadas en el cifrado (documentos US2016/0315921A1 y US2016/0315819A1) pueden ser costosas desde el punto de vista informático. Además, requieren un servidor central de claves y un nodo de verificación que aloje cada una de las claves de los nodos implicados (intermedios y de entrada), lo que convierte a ambas entidades en puntos únicos de fallo y en un riesgo potencial para la seguridad.
Por lo tanto, existe la necesidad en el estado de la técnica de proporcionar pruebas de tránsito computacionalmente más ligeras para validar que ciertos paquetes atraviesan una ruta especificada de nodos en un orden requerido. Sumario de la invención
La presente invención resuelve los problemas mencionados y supera las limitaciones de los trabajos del estado de la técnica explicados anteriormente, proporcionando una prueba de tránsito ordenada (OPoT) para los paquetes que atraviesan una ruta específica a través de una infraestructura de red.
Además, la presente invención puede utilizar diferentes tecnologías de intercambio de claves junto con algoritmos de cifrado simétrico para asegurar y proporcionar orden a los esquemas de compartición de secretos.
Los ámbitos de aplicación de la presente invención incluyen la seguridad, la calidad de servicio (QoS), la garantía de servicio y la gestión de redes en los segmentos de acceso y transporte, así como en los centros de datos.
Un aspecto de la presente invención se refiere a un procedimiento para validar la prueba de tránsito ordenada (OPoT) de paquetes de tráfico en una red, que comprende las siguientes etapas:
- recibir al menos un paquete a través de una ruta, la ruta comprende múltiples nodos de red que comienzan en un nodo de entrada y terminan en un nodo de salida, el paquete comprende una cabecera que contiene metadatos y se envía desde un nodo de red anterior dentro de la ruta;
- identificar una ruta coincidente para el paquete recibido con una tabla de enrutamiento e identificar metadatos de prueba de tránsito en la cabecera del paquete recibido;
- si se identifica la ruta coincidente para el paquete recibido y, si la ruta coincidente identificada está asociada con metadatos de prueba de tránsito y los metadatos de prueba de tránsito se identifican en la cabecera del paquete recibido, proporcionar una primera clave privada asociada con el nodo de red y el nodo de red anterior de la ruta coincidente en la ruta y descifrar los metadatos de prueba de tránsito utilizando la primera clave privada proporcionada.
En el nodo de entrada de la ruta, el procedimiento comprende además la generación de los metadatos de prueba de tránsito que se incluirán en la cabecera del paquete recibido. Según una realización de la invención, los metadatos de prueba de tránsito son actualizados por cada nodo de red de la ruta hasta alcanzar el nodo de salida.
En el nodo de salida, si el paquete ha atravesado la ruta, el procedimiento comprende además la verificación de los metadatos de prueba de tránsito y, si es así, la eliminación de todos los metadatos de prueba de tránsito de la cabecera antes de reenviar el paquete por el nodo de salida; de lo contrario, el paquete es descartado por el nodo de salida.
En otro nodo de red de la ruta, que no es ni el nodo de entrada ni el nodo de salida, el procedimiento comprende además volver a cifrar los metadatos de prueba de tránsito utilizando una segunda clave privada, antes de reenviar el paquete con la cabecera (la cabecera incluye los metadatos de prueba de tránsito vueltos a cifrar) desde el nodo de red a un nodo de red posterior de la ruta coincidente en la ruta.
Otro aspecto de la presente invención se refiere a un sistema configurado para implementar el procedimiento de validación OPoT descrito anteriormente que comprende una pluralidad de nodos de red asignables a una ruta, la ruta comienza en un nodo de entrada y termina en un nodo de salida, cada nodo de red comprende los siguientes componentes o módulos:
- un primer módulo configurado para identificar una ruta coincidente para el paquete recibido con una tabla de enrutamiento y para identificar metadatos de prueba de tránsito en la cabecera del paquete recibido;
- un segundo módulo conectado al primer módulo y configurado para, si se identifica la ruta coincidente para el paquete recibido y la ruta coincidente identificada se asocia con metadatos de prueba de tránsito y los metadatos de prueba de tránsito se identifican en la cabecera del paquete recibido, descifrar los metadatos de prueba de tránsito utilizando una primera clave privada; la primera clave privada se asocia con el nodo de red y el nodo de red anterior de la ruta coincidente en la ruta y se proporciona mediante medios de almacenamiento del nodo de red
Además, según una realización de la invención, un nodo de red del sistema comprende además un tercer módulo conectado al segundo módulo y configurado, si el nodo de red es el nodo de entrada de la ruta, para generar metadatos de prueba de tránsito que se incluirán en la cabecera del paquete recibido; y, para cualquier nodo, para actualizar los metadatos de prueba de tránsito utilizando información única alojada por cada nodo.
Cada nodo de red del sistema distinto del nodo de salida comprende además un cuarto módulo conectado al tercer módulo y configurado para volver a cifrar los metadatos de prueba de tránsito utilizando una segunda clave privada, antes de reenviar el paquete a un nodo de red posterior de la ruta coincidente en la ruta. El paquete se reenvía a través de un conjunto de interfaces de salida del nodo, y el paquete contiene una cabecera que incluye los metadatos de prueba de tránsito recodificados. La segunda clave privada asociada a dicho nodo de red y al nodo de red posterior de la ruta coincidente es proporcionada por los medios de almacenamiento del nodo de red.
El procedimiento y el sistema de acuerdo con los aspectos de la invención descritos anteriormente tienen una serie de ventajas con respecto a la técnica anterior, que pueden resumirse como sigue:
La presente invención respeta el orden, ya que cualquier redistribución en los nodos atravesados causará valores acumulativos inválidos, lo que conducirá a una fácil identificación por parte del nodo de salida.
La presente invención es computacionalmente más ligera que cualquier encriptación anidada, ya que sólo implica operaciones XOR, sumas, multiplicaciones y módulos.
Aumenta la seguridad de la solución basada en SSS propuesta por el IETF, ya que cifra/secuestra los valores que pueden utilizarse para adjuntar el esquema de números aleatorios (RND) y acumulativos (CML).
Suponiendo que el número aleatorio generado en el nodo de entrada sea realmente aleatorio, la clave asociada a cada salto podría reutilizarse para un gran número de paquetes, ya que el valor aleatorio (y el valor acumulativo generado) actuará virtualmente como una clave privada.
- El valor de actualización de la clave (número de paquetes por clave) también se asocia a los niveles de garantía (LoA) de la ruta, pasando del tamaño del número primo hasta una clave por paquete u One Time Pad (OTP).
- Cada enlace de la ruta genera de forma independiente (y en modo offline) un almacén de claves que se rellena utilizando diferentes técnicas, asociadas a diferentes LoA, como la criptografía post-cuántica (PQC), la distribución cuántica de claves (QKD) o técnicas convencionales de intercambio de claves. No es necesario un servidor central de claves (a diferencia de los documentos US2016/0315921A1 y US2016/0315819A1) y la presente invención se integra con paradigmas de red, como SDN (Software-Defined Network).
- Se pueden definir diferentes técnicas que proporcionen múltiples LoA por ruta (servicio) o incluso por enlace en una ruta, teniendo en cuenta las zonas de seguridad que debe atravesar el tráfico.
- El esquema propuesto también podría formar parte de un servicio más largo, en el que un subconjunto de los nodos incluidos requiere la verificación OPoT (mientras que otros nodos intermedios ignoran y no manipulan ningún metadato OPoT).
Estas y otras ventajas serán evidentes a la luz de la descripción detallada de la invención.
Descripción de los dibujos
Con el fin de ayudar a la comprensión de las características de la invención, según una realización práctica preferente de la misma y para complementar esta descripción, se adjuntan como parte integrante de la misma las siguientes Figuras, que tienen carácter ilustrativo y no limitativo:
La figura 1 muestra un conjunto de nodos que componen una red en la que se configura OPoT, según un posible escenario de aplicación de la invención.
La figura 2 muestra una arquitectura de canalización interna de un nodo de red que realiza OPoT, según una realización preferente de la invención.
La figura 3 muestra un diagrama de la ejecución de OPoT para un paquete dado a través de los nodos de red de una ruta, según una posible realización de la invención.
Realización preferente de la invención
Las materias definidas en esta descripción detallada se proporcionan para ayudar a una comprensión completa de la invención. Por consiguiente, los expertos en la materia reconocerán que pueden introducirse cambios y modificaciones en las realizaciones aquí descritas.
Asimismo, la descripción de funciones y elementos bien conocidos se omite en aras de la claridad y la concisión. Por supuesto, las realizaciones de la invención pueden implementarse en una variedad de plataformas arquitectónicas, sistemas operativos y de servidor, dispositivos, sistemas o aplicaciones. Cualquier disposición arquitectónica o implementación particular presentada en este documento se proporciona únicamente con fines ilustrativos y de comprensión y no pretende limitar aspectos de la invención.
Diferentes realizaciones o características adicionales para la presente invención se definen para proporcionar diferentes niveles de garantía, LoA, ya que diferentes parámetros de seguridad afectan a la calidad de la Prueba de Tránsito, PoT, cuando se despliega una sesión/servicio/ruta. Estos parámetros son:
- Longitud de la clave: La longitud de la clave utilizada (también descrita como el tamaño del número primo utilizado para el esquema SSS) influye en la cantidad de paquetes que pueden ser validados por el esquema SSS. Cuanto mayor sea la longitud, más paquetes podrán comprobarse con un único esquema SSS. Pero este tamaño también afecta a la carga útil de los paquetes asociados, por lo que esta penalización debe considerarse junto con el ancho de banda del servicio.
- Tecnología de intercambio de claves: La calidad de las claves utilizadas para asegurar los valores de SLV depende de la tecnología utilizada para su generación. La presente invención es válida para cualquier cambio en los estándares actuales (por ejemplo, depreciación de las técnicas convencionales de intercambio de claves, adopción de nuevas tecnologías en este ámbito), y capaz de alternar entre diferentes tecnologías bajo demanda. Podría elegirse cualquier tecnología para toda la ruta, o incluso definirse por enlace, en función de la LoA predefinida (pueden considerarse distintos niveles de LoA por enlace/ruta). Actualmente, se consideran aquí tres grupos principales de fuentes clave:
o Algoritmos convencionales: Ya sea para la generación de claves (por ejemplo, Diffie-Hellman) o para el transporte de claves (por ejemplo, RSA), los algoritmos convencionales son la base para el acuerdo de claves de cada enlace.
o Algoritmos post-cuánticos: Gracias a los avances de la informática cuántica, se han desarrollado algoritmos para hacer frente a las actuales amenazas a la seguridad. Estos algoritmos (denominados poscuánticos) aún no han demostrado ser suficientemente seguros contra este tipo de ataques, pero siguen siendo una fuente adecuada para proteger el PdT.
o Distribución cuántica de claves, QKD: Al igual que las técnicas post-cuánticas, esta solución se desarrolló para resolver las amenazas a la seguridad asociadas a los avances de la informática cuántica (por ejemplo, el algoritmo de Shor).
- Tasa de actualización: El número de paquetes en los que se utiliza una clave para asegurar el esquema SSS.
Esta tasa (en paquetes por clave, ppk) se configura desde el valor máximo (el tamaño del prime en el esquema SSS) hasta el mínimo (un paquete por clave u One Time Pad: OTP). La tasa también podría especificarse por enlace de una ruta determinada, o tener una tasa única definida para toda la ruta, en función de consideraciones de seguridad.
- Información cifrada: La cantidad de información que debe mantenerse en secreto. Permite especificar si la CML está cifrada, o si RND y CML están ambos cifrados. Cifrar ambos valores permitirá reutilizar el mismo esquema de SLV, si las claves se actualizan adecuadamente.
- Marca de tiempo: En otra realización, se establece una marca de tiempo que es comprobada por los nodos de la ruta, para verificar que un paquete no se retrasa (no es redirigido) entre dos nodos de la ruta.
La figura 1 presenta un sistema compuesto por múltiples nodos de red (N1, N2,..., N9), en el que una ruta de red, asociada a un servicio de red, está compuesta por un conjunto de nodos conectados (N1, N2, N3, N4, N5) y sus enlaces asociados, representados por líneas discontinuas en la figura 1. El sistema valida los paquetes de tráfico de red que atraviesan una pluralidad de nodos de red formando una ruta mediante un mecanismo propuesto de prueba de tránsito ordenada, OPoT, que combina una técnica acumulativa con técnicas de cifrado de baja sobrecarga computacional para proporcionar un esquema seguro de compartición de secretos. A pesar de que la Figura 1 muestra conexiones directas entre cada par de nodos dentro de la ruta, cualquier enlace podría encerrar otros nodos de la red no incluidos en el esquema OPoT, siendo la ruta OPoT un subconjunto de un servicio más largo. El primer nodo (N1) de la ruta actúa como nodo de entrada, que inicia el proceso OPoT; mientras que el último nodo (N5) es el nodo de salida y el validador final del mecanismo OPoT. El primer nodo (N1) y el último (N5) están conectados a través de nodos intermedios (N2, N3, N4) a lo largo de la ruta.
Cada nodo implicado en el proceso OPoT es capaz de:
- Generar de forma segura conjuntos de claves simétricas con otros pares de la red y almacenar las claves privadas generadas asociadas a cada nodo con el que exista una conexión directa, lógica o física, dentro de la red.
- Leer paquetes de red y acceder a sus metadatos.
- Realizar operaciones XOR de los parámetros de cabecera del paquete -metadatos- y claves privadas del almacén de claves del nodo para asegurar/sellar y descifrar los metadatos OPoT.
- Realizar operaciones rápidas de suma, multiplicación y módulo sobre parámetros numéricos extraídos de la cabecera del paquete con fines de crecimiento secreto.
- Generar números aleatorios seguros para cada paquete a verificar (en el nodo de entrada).
- Modificar, en base a la salida de las diferentes operaciones descritas anteriormente, cada metadato de paquete con un valor actualizado para la verificación OPoT.
- Reenviar los paquetes procesados a otros nodos de la red.
- Comunicarse con el plano de control de la red para permitir la configuración de OPoT (datos SSS necesarios, nodos anteriores y siguientes en la ruta, otra información de correspondencia de flujo).
- Proporcionar canales de configuración seguros para la configuración del servicio OPoT, ya sea con una entidad central, por ejemplo, un controlador SDN, o con un administrador del sistema.
Cada nodo implicado en el proceso OPoT se comunica con una instancia central de gestión capaz de:
- Configurar cada nodo dentro de la ruta OPoT
- Aceptar solicitudes de nuevos servicios OPoT.
- Calcular los esquemas de SSS y actualizar el esquema, cuando sea necesario.
Más concretamente, la Figura 2 muestra un ejemplo de canalización interna de un nodo (N) implicado en el OPoT, representado como una caja de estado. En la etapa inicial, el nodo (N) comprende un conjunto de interfaces de entrada (20) que reciben paquetes entrantes. Las cabeceras de los paquetes entrantes son procesadas inicialmente por un módulo de entrada, un primer módulo (A) con el fin de identificar un flujo/ruta coincidente dentro de una tabla de flujo/enrutamiento (23). Si el paquete coincide y la acción, o los metadatos del paquete, incluyen información OPoT, se proporcionan dos claves privadas desde los medios de almacenamiento (22) del nodo (N) a los siguientes módulos: un segundo módulo (B) para descifrar los metadatos OPoT y un cuarto módulo (D), el último -de salida-, para volver a cifrar los metadatos OPoT antes del reenvío del paquete al nodo siguiente/subsiguiente de la ruta. Los metadatos OPoT de los paquetes entrantes son descifrados por el segundo módulo (B) utilizando la primera clave privada, asociada al enlace del nodo del que se reciben los paquetes entrantes. El nodo (N) dispone de metadatos SSS que serán procesados por un tercer módulo (C) para la correcta generación de los parámetros de validación acumulativa. Una vez finalizado el proceso SSS por el tercer módulo (C), el cuarto módulo (D) asegura los metadatos mediante re-cifrado utilizando la segunda clave privada proporcionada para el enlace siguiente/subsiguiente al nodo subsiguiente en la ruta OpoT. El nodo (N) reenvía el paquete con los metadatos OPoT recifrados a través de su conjunto de interfaces de salida (21).
Los nodos de entrada y salida actúan de forma ligeramente distinta:
- En el nodo de entrada, el primer y último módulo (A, D) funcionan de forma similar a lo descrito anteriormente; mientras que el segundo módulo (B) no existe, y el tercer módulo (C) se encarga de crear los metadatos SSS en las cabeceras OPoT y de generar aleatoriamente el secreto polinómico aleatorio para cada paquete, así como de producir los datos necesarios para la verificación inicial tal y como se ha explicado anteriormente.
- En el nodo de salida, los módulos primero y segundo (A, B) se utilizan respectivamente para identificar y descifrar los datos OPoT, mientras que el tercer módulo (C) actualiza y también verifica los metadatos. Este tercer módulo (C) comprueba los datos generados acumulativamente para verificar si el paquete ha atravesado la ruta especificada. Antes de salir, el tercer módulo (C) elimina cualquier metadato OPoT de las cabeceras de los paquetes, ya que no se volverán a utilizar metadatos OPoT una vez que el paquete haya atravesado la ruta. El cuarto módulo (D) no es necesario en el nodo de salida, ya que el paquete abandona la ruta OPoT.
En la Figura 2, incluso cuando esto no es imprescindible, la representación lógica de la entidad encargada del OPoT es la tabla de encaminamiento (23). Esta tabla de enrutamiento (23) puede implementarse dentro del nodo de red como un núcleo interno, un agente integrado o incluso puede ser una entidad externa (con las penalizaciones de rendimiento y latencia asociadas que esto puede implicar).
El primer módulo (A) realiza la etapa de entrada con la identificación de paquetes requerida, pero las etapas fundamentales implicadas en la OPoT propuesta son las implementadas por los módulos restantes (B, C, D), que implican dos técnicas diferentes: i) un esquema acumulativo de compartición de secretos, basado en un SSS modificado, que permite verificar que todos los nodos han "firmado" el paquete, y ii) cifrado simétrico de los parámetros del SSS para garantizar la seguridad/secreto de la solución (ningún atacante intermedio podría aprender de los paquetes sin conocer las claves privadas) y para dotar de orden a la solución (podría verificar que todos los nodos han sido atravesados y en qué orden). A continuación se explican ambas técnicas, junto con sus antecedentes, puntos fuertes y vulnerabilidades.
i) Esquema de reparto de secretos: Shamir's Secret Sharing
Un esquema de compartición de secretos consiste en un secreto principal que se divide y comparte entre diferentes partes y que sólo puede reconstruirse si todas las partes utilizan sus partes. Si sólo una de las partes no participa en el proceso de reconstrucción/creación, el secreto final obtenido no será el original y, por tanto, el proceso fracasará. Aplicado a las redes y, más concretamente, para validar el tránsito de paquetes a través de la infraestructura, el secreto es algo alojado en el verificador, mientras que las partes, únicas, del secreto se distribuyen entre los nodos implicados. Tras la recepción del paquete, cada nodo debe reconstruir con su parte una parte del secreto que finalmente llegará al nodo -de salida- de verificación. Si algún nodo intermedio es eludido u otra entidad modifica el valor de verificación acumulativo, el secreto final no se reconstruirá como debería y, en consecuencia, el paquete se marcará como fallido.
Un esquema popular de compartición de secretos es el Shamir's Secret Sharing (SSS), que se basa en el esquema de umbral de Adi Shamir. Su idea matemática es que para construir un polinomio de grado n se necesitan n+1 puntos. En este sentido, el secreto a compartir entre "n+1" partes es el polinomio de grado "n", y "n+1" puntos necesarios para reconstruir el polinomio son las partes del secreto a distribuir entre los nodos implicados. Más concretamente, el secreto que deben reconstruir los nodos es el término constante del polinomio. Es importante señalar que el secreto en sí (coeficiente constante del polinomio: pcc) no tiene significado y, como tal, puede definirse dinámicamente según se requiera. Lo que tiene sentido en el esquema, y más concretamente para el caso de la prueba de tránsito, es el proceso de reconstrucción realizado por los nodos de la ruta. Esto hace que el secreto polinómico sea lo suficientemente flexible como para ser actualizado o cambiado a demanda, en función de las restricciones de tráfico.
En este sentido, una entidad de gestión (por ejemplo, un controlador SDN, NMS, administrador del sistema), que también se encarga de configurar la ruta/trayectoria, puede:
a) Elegir un número primo: p
b) Generar un polinomio (sobre un campo finito del tamaño del número primo) basado en el número de saltos a validar.
c) Asignar un punto xi a cada nodo "i" de la ruta
d) Calcular el resultado de cada punto xi utilizando el polinomio yi = Pol (xi ), donde Pol () es la función polinómica e yi denota el resultado calculado para el punto xi
e) Calcular y proporcionar el coeficiente constante de cada reconstrucción parcial del polinomio utilizando el coeficiente constante del polinomio de Lagrange, lcc, para cada punto x i:
Figure imgf000009_0001
f) Distribuir los datos SSS a cada punto xi, esta información incluye: xi, yi, lcci, y p. Además, el nodo de salida de verificación también aloja el secreto, es decir, el coeficiente constante del polinomio pcc, para verificar el correcto tránsito de los datos.
Cada nodo de la red recibe un valor de verificación acumulado, cmv, que es creado inicialmente y puesto a 0 por el nodo de entrada, y actualiza el valor para la reconstrucción del coeficiente constante del polinomio pcc. Este valor actualizado se calcula en cada nodo, utilizando el coeficiente constante del polinomio de Lagrange lcc y el polinomio yi = Pol (xi), siguiendo la interpolación polinómica de Lagrange. De esta forma, cada valor calculado en cada nodo se representa por cmvi = yl x lcct + cmvi-isiendo la comprobación final de verificación:
Figure imgf000009_0002
Si esta comprobación final es verdadera, el esquema SSS ha tenido éxito y el paquete ha pasado por todos los nodos dentro de la ruta.
Un ejemplo de ejecución para una ruta de cuatro nodos n1-n2-n3-n4 es el siguiente:
- Elegir el número primo, p = 71, y un polinomio, por ejemplo, 61x3 55x2 10x 63
- Asignar a los nodos los valores { xi , yi, lcci, p }
o n1: { 39 , 59, 45, 71 }
o n2: { 96 , 61, 10, 71 }
o n3: { 36 , 45, 30, 71 }
o n4: { 68 , 17, 58, 71 }
más el valor de verificación adicional: pcc = 63.
Con estos valores, un paquete específico de la red se recibe en el nodo de entrada. Incluye metadatos adicionales al paquete, inicialmente establecidos como cero. Cuando este paquete atraviesa cada nodo, el valor cmv se actualiza de la siguiente manera:
o cmv1 = 59 x 45 mod(71) = 28
o cmv2 = 61 x 10 28 mod(71) = 70
o cmv3 = 45 x 30 70 mod(71) = 0
o cmv4 = 17 x 58 63 mod(71) = 63
Como el valor calculado en el nodo de salida de verificación es el mismo que el valor de verificación, es decir, cmv4 = pcc = 63, el nodo de salida verifica que todos los nodos han manipulado los metadatos SSS y, por lo tanto, la ruta se verifica correctamente.
No obstante, este proceso de TMCD tiene claras limitaciones:
- La primera está asociada al orden de la ruta. La Compartición Secreta de Shamir simplemente verifica que un conjunto de nodos ha participado en el proceso de reenvío, pero no en qué orden. Esto es clave cuando se habla de cadenas de funciones de servicio de red (debe respetarse el orden en la cadena), así como para verificar cualquier técnica de conmutación/enrutamiento, como las soluciones basadas en sistemas de números residuales, enrutamiento por segmentos u otros enfoques tradicionales.
- La segunda limitación es que este esquema, tal como se ha presentado anteriormente, es útil cuando se utiliza para una sola ejecución (un solo paquete). Si se pretende seguir un segundo paquete, el esquema SSS debería modificarse para cada paquete, lo que no es realista para el rendimiento de los servicios actuales. De lo contrario, los metadatos de los paquetes podrían aprenderse fácilmente y modificarse para el nuevo tráfico entrante.
A diferencia de la solución del estado de la técnica propuesta por el citado borrador del IETF "Proof of Transit" que introduce un segundo polinomio para mejorar el esquema SSS, la presente solución OPoT incluye (pero no se limita a) un único polinomio. Este polinomio y el número primo son generados por el sistema de gestión como se ha descrito anteriormente, pero sin producir el valor secreto o de verificación pcc. Este secreto lo genera el nodo de entrada aleatoriamente y por paquete. Cada nodo dispone de los puntos del polinomio sin coeficiente constante, el número primo p y los valores lcc. Tanto el secreto del polinomio aleatorio, rps, como los valores de verificación acumulativa, cmv, se transmiten juntos en los metadatos del paquete, y se utilizan finalmente para la reconstrucción del secreto. Por tanto, este polinomio se utiliza exactamente igual que en el esquema SSS para la verificación de paquetes, pero se modifica para cada paquete entrante en el flujo de tráfico añadiendo el secreto al punto de los nodos yi, es decir,
cmvt = (y¡ rpsj) x lcct cmvl_í donde rpsj es el valor aleatorio para un paquete "j", paquete*.
Para evitar que un atacante pasivo aprenda información crítica del polinomio y reproduzca el esquema SSS, se incluye además una técnica de encriptación privada para mejorar la seguridad cifrando los metadatos SSS y también para verificar el orden de los nodos a atravesar en la ruta sellando cada paquete en cada host utilizando información o claves privadas, como se describe a continuación.
ii) Cifrado de clave privada para orden y seguridad: XOR y OTP
Como ya se ha mencionado y descrito anteriormente en los antecedentes de la invención, la versión mejorada de SSS presentada en el borrador del IETF tiene vulnerabilidades asociadas que provienen de la exposición de cierta información de forma simple y pública. Esta información, si se almacena y analiza adecuadamente, podría utilizarse para reproducir externamente los polinomios basados en SSS, revelando información clave como el número primo p y los valores lcc. En realidad, se ha demostrado en los antecedentes de la invención que el éxito de dicho ataque no depende del polinomio secreto propuesto por el borrador del IETF, por lo que no aporta ninguna seguridad adicional a la solución del IETF. Si esos valores son conocidos por el atacante, cualquier nodo deseado de la ruta (o incluso toda la ruta, aparte de los nodos de entrada y salida) podría ser eludido, haciendo el esquema completamente inútil. La presente invención propone mantener confidencial la información importante que debe transmitirse entre los nodos, cmv y rps, de modo que puedan evitarse los ataques y el esquema compuesto resulte robusto. Esto se consigue utilizando soluciones y técnicas seguras existentes para el intercambio de claves, sin afectar al rendimiento del flujo de tráfico relacionado. En este sentido, las principales propiedades requeridas son:
- Realizar un cifrado rápido (baja complejidad computacional) dentro de los nodos, para reducir cualquier impacto en el rendimiento del servicio.
- Mantener las capacidades de prueba de tránsito aportadas por el SSS.
- Aumentar la seguridad cifrando los datos críticos de la solución.
- Disponer de un conjunto de claves simétricas generadas y almacenadas de forma segura para los distintos enlaces del nodo dentro de la red.
- Poner orden en la solución.
Asumiendo una estructura interna de módulos para el nodo como la mostrada en la Figura 2, la mejora propuesta al esquema SSS modificado viene dentro de las etapas lógicas realizadas por el segundo y cuarto módulos (B, D). Cualquier paquete que atraviese la ruta OPoT se sella con una clave simétrica mediante una operación XOR. Este proceso lo realiza el último módulo (D). La asociación de claves (técnica de intercambio de claves, consumo de claves, tipo y valor de actualización, etc.) se define durante el despliegue de OPoT, y se utiliza siempre que un paquete entrante es emparejado por el primer módulo (A) del nodo. Esta asociación también podría especificarse para toda la ruta, o incluso definirse por enlace, en función de diferentes consideraciones de seguridad y LoA. Junto con los otros valores OPoT, cualquier asociación clave se establece entre cada dos nodos implicados en cada salto dentro de la ruta. De este modo, los valores cmv y rps se ocultan al salir de cada nodo de la ruta a través del último módulo de salida (D) del nodo, se revelan al entrar en el segundo módulo (B) del siguiente nodo de la ruta y son procesados por el tercer módulo (C) de cada nodo utilizando la técnica SSS. Por lo tanto, cualquier información obtenida de los metadatos del paquete no es significativa para el espía o atacante. Además, si los valores rpsj son realmente aleatorios, las claves podrían reutilizarse en este esquema, ya que podría verse como un nuevo cifrado de claves de los mismos datos (las claves en cada salto). Los valores rpsj cifrados podrían reconstruirse (pero no revelarse) en cada salto escuchando dos paquetes individuales, pero los valores cmv no pueden reconstruirse, ya que no sólo son modificados por el XOR, sino también por la técnica de interpolación polinómica de Lagrange. Por último, el proceso descrito también permite al nodo verificador comprobar si el paquete ha seguido el orden correcto mientras atravesaba la ruta. En particular, el proceso de reconstrucción fallará si no se respeta el orden, ya que el proceso de descifrado producirá valores cmv y rpsj no válidos, y la interpolación (reconstrucción secreta) generará finalmente un valor de verificación erróneo, desechando los paquetes.
Como ejemplo, en la Figura 3, que muestra cuatro nodos (n1, n2, n3, n4) con una configuración similar a la mostrada en la Figura 2 pero adaptada al nuevo esquema, si un paquete que sale del nodo de entrada (n1) se dirige al tercer nodo (n3), saltándose un nodo intermedio (n2), los valores utilizados para el cálculo serán una combinación de cmv y rpsj, ambos XOR con las dos claves intermedias (y diferentes) utilizadas entre el primer y segundo nodos (n1, n2) y el segundo y tercer nodos (n2, n3). En el ejemplo de la Figura 3:
Número primo: p= 71
Polinomio: 61x3 55x2 10x sin coeficiente constante.
- Los nodos reciben los valores { xi , yi, lcci, p }
o n1: { 39 , 59, 45, 71 }
o n2: { 96 , 61, 10, 71 }
o n3: { 36 , 45, 30, 71 }
o n4: { 68 , 17, 58, 71 }
sin valor de verificación, ya que el rps transmitido j se utilizará para la verificación, para un paquete dado j.
En la figura 3 ecmv y erps significan respectivamente cmv y rps. Cualquier nodo muestra las etapas internas implicadas en el OPoT para esta ruta específica. El nodo de entrada (n1) genera el valor aleatorio rps que se utilizará como coeficiente constante del polinomio, que es el secreto. Este valor aleatorio, por ejemplo, rps = 12, se transmite con el paquete y se cifra por salto. Cada nodo de la ruta descifra los metadatos OPoT, reconstruye su parte del secreto utilizando su parte de la acción y los metadatos del paquete OPoT, cifra los nuevos valores y los transmite al nodo siguiente de la ruta. La parte superior de la figura 3 muestra el cifrado de los metadatos OPoT, mientras que la parte inferior muestra la parte de cada nodo y el cmv generado. El nodo de verificación (n4) comprueba finalmente si cmv == rps (en este caso, el éxito es 12==12), permitiendo el reenvío del paquete si la verificación tiene éxito.
Por lo tanto, el proceso OPoT descrito comprende:
- la creación del esquema SSS (evitando el coeficiente constante) por el sistema de gestión central, por ejemplo, el controlador SDN;
- la creación de las sesiones de intercambio de claves n-1 (donde n es el número de nodos incluidos en la ruta OPoT) para cada salto, si aún no están en su lugar;
- para cada paquete, la generación del número aleatorio (coeficiente constante del polinomio) por el nodo de entrada;
- la creación del secreto realizado por cada nodo de la red, junto con el cifrado/descifrado de metadatos realizado después/previo al procesamiento;
- el descifrado final y la verificación del esquema realizados por el nodo de salida (verificador).
Por lo tanto, el proceso OPoT descrito permite:
- Para verificar de forma segura que cierto flujo de tráfico ha atravesado un conjunto de nodos dentro de una ruta.
- Comprobar también que dicho tráfico ha atravesado los nodos mencionados en un determinado orden predefinido.
- Asegurar los metadatos OPoT relacionados mediante el uso de técnicas de cifrado de baja sobrecarga, proporcionando también orden a la solución.
- Proporcionar diferentes LoA para diferentes servicios, ya sea por enlace o por ruta, en función de la fuente de las claves simétricas, el tiempo de actualización de una clave determinada, la cantidad de información que debe cifrarse u otros requisitos de marca de tiempo.
- Integrarse fácilmente en paradigmas de red modernos, como SDN (para la configuración OPoT) o NFV (para la seguridad de la cadena de servicios).
El proceso OPoT es un procedimiento distribuido que es implementado implicando todos los nodos de la red de la ruta o sólo un subconjunto de nodos del conjunto completo de nodos múltiples que definen la ruta en la red.
Nótese que en este texto, el término "comprende" y sus derivaciones (como "que comprende", etc.) no deben entenderse en un sentido excluyente, es decir, estos términos no deben interpretarse como excluyentes de la posibilidad de que lo descrito y definido pueda incluir otros elementos, etapas, etc.

Claims (5)

REIVINDICACIONES
1. Un sistema para validar pruebas ordenadas de tránsito de tráfico de red que comprende una pluralidad de nodos de red asignables a una ruta, comenzando la ruta en un nodo de entrada y terminando en un nodo de salida, en una red, comprendiendo cada nodo de red un conjunto de interfaces de entrada (20) para recibir al menos un paquete con una cabecera que contiene metadatos de un nodo de red anterior dentro de la ruta, comprendiendo además cada nodo de red comprende:
- un primer módulo (A) configurado para identificar una ruta coincidente para el paquete recibido con una tabla de enrutamiento (23) y para identificar metadatos de prueba de tránsito en la cabecera del paquete recibido;
- medios de almacenamiento (22) configurados para, si se identifica la ruta coincidente para el paquete recibido, y el paquete contiene metadatos de prueba de tránsito proporcionar una primera clave privada asociada con el nodo de red y el nodo de red anterior de la ruta coincidente en la trayectoria;
- un segundo módulo (B) conectado al primer módulo (A) y configurado para, si se identifica la ruta coincidente para el paquete recibido y la ruta coincidente identificada se asocia con metadatos de prueba de tránsito y los metadatos de prueba de tránsito se identifican en la cabecera del paquete recibido, descifrar los metadatos de prueba de tránsito utilizando la primera clave privada proporcionada por los medios de almacenamiento (22) del nodo de red;
- Un tercer módulo (C) conectado al segundo módulo (B) t configurado para:
- si el nodo de red es el nodo de entrada, generar metadatos de prueba de tránsito, que se incluyen en la cabecera del paquete recibido, comprendiendo los metadatos de la prueba de tránsito un secreto polinomial aleatorio y un valor de verificación acumulativo, el valor de verificación acumulativo establecido inicialmente en 0; y,
- para cualquier nodo, actualizar los metadatos de la prueba de tránsito utilizando información única alojada por cada nodo.
estando el sistema caracterizado porque:
cada nodo de red diferente del nodo de salida comprende además un cuarto módulo (D) conectado al tercer módulo (C) y configurado para volver a cifrar los metadatos de prueba de tránsito utilizando una operación XOR con una segunda clave privada, antes de pasar el paquete con el encabezamiento, incluyendo el encabezamiento los metadatos de prueba de tránsito vueltos a cifrar, a un conjunto de interfaces de salida (21),
en el que el conjunto de interfaces de salida (21) es proporcionado por el nodo de red para reenviar el paquete a un nodo de red posterior de la ruta coincidente en la ruta y los medios de almacenamiento (22) del nodo de red están configurados además para proporcionar la segunda clave privada asociada con dicho nodo de red y el nodo de red posterior de la ruta coincidente en la ruta; y
en el que, si el nodo de red es el nodo de salida, el tercer módulo (C) está configurado además para validar si el paquete ha atravesado la ruta mediante la verificación de los metadatos de prueba de tránsito,
en el que el tercer módulo (C) del nodo de salida verifica los metadatos de la prueba de tránsito comprobando que el valor de verificación acumulativo es igual al secreto polinomial aleatorio, utilizando Shamir's Secret Sharing; y el tercer módulo (C) de cada nodo de red diferente al nodo de salida actualiza los metadatos de la prueba de tránsito actualizando el valor de verificación acumulado utilizando información única, de acuerdo con la fórmula cmvi = (yi rpsj) x lcc cmv-i donde Icc es el coeficiente constante del polinomio de Lagrange, yi denota el resultado calculado para un punto Xi asignado a un nodo i de la ruta usando el polinomio yi = Pol (Xi) y rpsj es el valor aleatorio para un paquete j, y donde Xi, yi y lcci son distribuidos por una entidad de gestión encargada de configurar la ruta; y, si el paquete se valida como el valor de verificación acumulativo es igual al secreto polinomial aleatorio, el tercer módulo (C) está configurado para eliminar todos los metadatos de prueba de tránsito del encabezado antes de reenviar el paquete a través de un conjunto de interfaces de salida ( 21) proporcionada por el nodo de red; de lo contrario, el tercer módulo (C) está configurado para descartar el paquete.
2. El sistema según cualquier reivindicación anterior, en el que la pluralidad de nodos de red para validar la prueba ordenada de tránsito del tráfico de red es un subconjunto del conjunto completo de nodos de red desde el nodo de entrada hasta el nodo de salida de la ruta.
3. El sistema según cualquier reivindicación anterior, en el que la tabla de encaminamiento (23) está conectada a todos los módulos (A, B, C, D) implicados en la prueba de tránsito del nodo de red.
4. Un procedimiento para validar una prueba ordenada de tránsito de tráfico de red a través de una ruta de múltiples nodos de red que comienza en un nodo de entrada y termina en un nodo de salida, comprendiendo el procedimiento recibir al menos un paquete con una cabecera que contiene metadatos de un nodo de red anterior dentro de la ruta, comprendiendo el procedimiento:
- identificar una ruta coincidente para el paquete recibido con una tabla de enrutamiento (23) e identificar metadatos de prueba de tránsito en la cabecera del paquete recibido,
- si se identifica la ruta coincidente para el paquete recibido y, si la ruta coincidente identificada se asocia con metadatos de prueba de tránsito y los metadatos de prueba de tránsito se identifican en la cabecera del paquete recibido, proporcionar una primera clave privada asociada con el nodo de red y el nodo de red anterior de la ruta coincidente en la ruta y descifrar los metadatos de prueba de tránsito utilizando la primera clave privada proporcionada;
- generar en el nodo de entrada la prueba de metadatos de tránsito a incluir en la cabecera del paquete recibido, comprendiendo la prueba de metadatos de tránsito generada un secreto polinomial aleatorio y un valor de verificación acumulativo, el valor de verificación acumulativo establecido inicialmente en 0;
- actualizar los metadatos de la prueba de tránsito por cada nodo de red;
estando el procedimiento caracterizado porque comprende además:
- volver a cifrar los metadatos de prueba de tránsito en un nodo de red que no es el nodo de salida, utilizando una operación XOR con una segunda clave privada, antes de reenviar el paquete con la cabecera, incluyendo la cabecera los metadatos de prueba de tránsito vueltos a cifrar, desde el nodo de red a un nodo de red posterior de la ruta coincidente en la ruta;
- validar en el nodo de salida si el paquete ha atravesado la ruta mediante la verificación de los metadatos de prueba de tránsito, en el que la verificación de los metadatos de prueba de tránsito comprende:
- comprobar que el valor de verificación acumulativo es igual al secreto polinomial aleatorio, usando Shamir's Secret Sharing
- actualizar el valor de verificación acumulado utilizando información única para actualizar los metadatos de prueba de tránsito siguiendo el esquema de Shamir's Secret Sharing, antes de reenviar el paquete al siguiente nodo de la ruta, de acuerdo con la fórmula cmvi = (yi rpsj) x lcci cmvi-i donde Icc es el coeficiente constante del polinomio de Lagrange, yi denota el resultado calculado para un punto xi asignado a un nodo i de la ruta mediante el polinomio yi = Pol (xi) y rpsj es el valor aleatorio para un paquete j, y donde xi, yi e lcci son distribuidos por una entidad de gestión encargada de configurar la ruta;
5. El procedimiento según la reivindicación 4, en el que los múltiples nodos de red para validar la prueba ordenada de tránsito del tráfico de red es un subconjunto del conjunto completo de nodos de red desde el nodo de entrada hasta el nodo de salida de la ruta.
ES18382095T 2018-02-19 2018-02-19 Procedimiento y sistema para validar la prueba ordenada de tránsito de paquetes de tráfico en una red Active ES2950584T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP18382095.0A EP3528430B1 (en) 2018-02-19 2018-02-19 Method and system for validating ordered proof of transit of traffic packets in a network

Publications (1)

Publication Number Publication Date
ES2950584T3 true ES2950584T3 (es) 2023-10-11

Family

ID=61274214

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18382095T Active ES2950584T3 (es) 2018-02-19 2018-02-19 Procedimiento y sistema para validar la prueba ordenada de tránsito de paquetes de tráfico en una red

Country Status (3)

Country Link
US (1) US11057293B2 (es)
EP (1) EP3528430B1 (es)
ES (1) ES2950584T3 (es)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10992652B2 (en) 2017-08-25 2021-04-27 Keysight Technologies Singapore (Sales) Pte. Ltd. Methods, systems, and computer readable media for monitoring encrypted network traffic flows
US10903985B2 (en) 2017-08-25 2021-01-26 Keysight Technologies Singapore (Sales) Pte. Ltd. Monitoring encrypted network traffic flows in a virtual environment using dynamic session key acquisition techniques
US20190334701A1 (en) * 2018-04-25 2019-10-31 EMC IP Holding Company LLC Lightweight security for internet of things messaging
GB2574597B (en) * 2018-06-08 2021-10-20 Toshiba Kk A Quantum communication network
US10893030B2 (en) 2018-08-10 2021-01-12 Keysight Technologies, Inc. Methods, systems, and computer readable media for implementing bandwidth limitations on specific application traffic at a proxy element
US11558399B2 (en) * 2019-09-30 2023-01-17 International Business Machines Corporation Network transmission path verification
US11190417B2 (en) * 2020-02-04 2021-11-30 Keysight Technologies, Inc. Methods, systems, and computer readable media for processing network flow metadata at a network packet broker
CN114362928B (zh) * 2021-03-23 2023-11-24 长春大学 一种用于多节点间加密的量子密钥分发与重构方法
JP2023042903A (ja) * 2021-09-15 2023-03-28 株式会社東芝 通信装置、通信方法および通信システム
US20230102012A1 (en) * 2021-09-30 2023-03-30 Seagate Technology Llc Polynomial function secret sharing
WO2023056081A1 (en) * 2021-10-01 2023-04-06 Verheyen Henry Secure data exchange network
CN114079562B (zh) * 2021-11-18 2023-11-24 北京京航计算通讯研究所 基于门限秘密共享的软件定义网络数据安全传输方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8700894B2 (en) * 2007-10-17 2014-04-15 Pitney Bowes Inc. Method and system for securing routing information of a communication using identity-based encryption scheme
ES2365887B1 (es) * 2009-05-05 2012-09-03 Scytl Secure Electronic Voting S.A. Metodo de verificacion de procesos de descifrado
KR101640210B1 (ko) * 2013-01-16 2016-07-15 한국전자통신연구원 도메인 내 경로 설정 및 검증을 위한 패킷 처리장치 및 그 방법
US9703965B1 (en) * 2014-06-30 2017-07-11 EMC IP Holding Company LLC Secure containers for flexible credential protection in devices
US10211987B2 (en) 2015-04-27 2019-02-19 Cisco Technology, Inc. Transport mechanism for carrying in-band metadata for network path proof of transit
US9992056B2 (en) * 2015-10-20 2018-06-05 Cisco Technology, Inc. Triggered in-band operations, administration, and maintenance in a network environment
US10361969B2 (en) * 2016-08-30 2019-07-23 Cisco Technology, Inc. System and method for managing chained services in a network environment
US10560354B2 (en) * 2017-03-24 2020-02-11 Cisco Technology, Inc. End-to-end, in situ packet enrichment for network analytics
US10341748B2 (en) * 2017-07-05 2019-07-02 Infinera Corporation Packet-optical in-band telemetry (POINT) framework
US10367735B2 (en) * 2017-08-22 2019-07-30 Cisco Technology, Inc. Cloud provider classification for different service deployment schemes
US10972397B2 (en) * 2017-09-29 2021-04-06 Futurewei Technologies, Inc. Self-driving packets with conditional commands
US10469367B2 (en) * 2017-10-04 2019-11-05 Cisco Technology, Inc. Segment routing network processing of packets including operations signaling and processing of packets in manners providing processing and/or memory efficiencies
US10582027B2 (en) * 2017-11-04 2020-03-03 Cisco Technology, Inc. In-band metadata export and removal at intermediate nodes
US10958506B2 (en) * 2017-12-07 2021-03-23 Cisco Technology, Inc. In-situ OAM (IOAM) network risk flow-based “topo-gram” for predictive flow positioning
US10778464B2 (en) * 2018-04-20 2020-09-15 Futurewei Technologies, Inc. NSH encapsulation for traffic steering establishing a tunnel between virtual extensible local area network (VxLAN) tunnel end points (VTEPS) using a NSH encapsulation header comprising a VxLAN header whose VNI field has been replaced by an NSH shim
US10917340B2 (en) * 2018-09-11 2021-02-09 Cisco Technology, Inc. In-situ passive performance measurement in a network environment

Also Published As

Publication number Publication date
US20190260667A1 (en) 2019-08-22
EP3528430B1 (en) 2023-05-10
EP3528430A1 (en) 2019-08-21
US11057293B2 (en) 2021-07-06

Similar Documents

Publication Publication Date Title
ES2950584T3 (es) Procedimiento y sistema para validar la prueba ordenada de tránsito de paquetes de tráfico en una red
CN107567704B (zh) 使用带内元数据的网络路径通过验证
ES2717999T3 (es) Método criptográfico por bloques para cifrar/descifrar mensajes y dispositivos criptográficos para implementar este método
WO2019214070A1 (zh) 区块链上用户通信加密方法、装置、终端设备及存储介质
US11411722B2 (en) Method of operation of a quantum key controller
US10880100B2 (en) Apparatus and method for certificate enrollment
US20200351087A1 (en) Secure memory tamper detection in a quantum key computer
US11212082B2 (en) Ciphertext based quorum cryptosystem
ES2962566T3 (es) Enrutamiento de contenido seguro con libretas de un solo uso
Datta et al. {spine}: Surveillance protection in the network elements
US11177950B2 (en) Key generation for use in secured communication
US8867747B2 (en) Key generation for networks
US20140044262A1 (en) Low Latency Encryption and Authentication in Optical Transport Networks
JP5672425B2 (ja) 暗号通信システムおよび暗号通信方法
CN115174061A (zh) 基于区块链中继通信网络***的消息传输方法及装置
CN111385090A (zh) 基于多密钥组合量子密钥中继的密钥分发方法及其***
US20220200792A1 (en) Selective data disclosure via a block chain
US11711207B2 (en) Quantum safe key exchange scheme
US20220103355A1 (en) Method and system for key generation
US20230291545A1 (en) Qsl - data at rest
JP5822083B2 (ja) 暗号通信システムおよび暗号通信方法
Trotter Key Permutation Library
CN116527240A (zh) 用于灵活的后量子信任布建和更新的***和方法
CN113722750A (zh) 基于认证加密和组密钥的片上网络安全域构建方法
Koch et al. Thomas Schneider