ES2828948T3 - Método, sistema y productos de programa informático para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas - Google Patents
Método, sistema y productos de programa informático para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas Download PDFInfo
- Publication number
- ES2828948T3 ES2828948T3 ES15382354T ES15382354T ES2828948T3 ES 2828948 T3 ES2828948 T3 ES 2828948T3 ES 15382354 T ES15382354 T ES 15382354T ES 15382354 T ES15382354 T ES 15382354T ES 2828948 T3 ES2828948 T3 ES 2828948T3
- Authority
- ES
- Spain
- Prior art keywords
- communication
- encrypted
- data
- network element
- ctx
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- 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/0822—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 key encryption key
-
- 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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/105—Multiple levels of security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
Método para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas, comprendiendo el método: - establecer una sesión de datos cifrada entre dos aplicaciones de comunicación, una aplicación de comunicación de cliente (100) y una aplicación de comunicación de servidor (200), a través de una red de comunicación; - recibir y / o transmitir, mediante la aplicación de comunicación de cliente (100), en dicha sesión de datos cifrada establecida, unos datos de comunicación cifrados (D) desde / a dicha aplicación de comunicación de servidor (200) a través de por lo menos un elemento de red de computación (M); y - realizar, mediante dicho por lo menos un elemento de red de computación (M), diferentes acciones que no sean el reenvío de datos de comunicación desde una aplicación de comunicación a la otra sobre dichos datos de comunicación cifrados (D), en el que dichos datos de comunicación cifrados (D) comprenden una pluralidad de porciones de datos, o contextos, (CTX), cifrándose y autenticándose cada uno (CTX_X) por medio de claves de contexto, y siendo dichas diferentes acciones específicas para dicho por lo menos un elemento de red de computación (M) y para uno o más de dicha pluralidad de contextos (CTX_X) de los datos de comunicación cifrados (D). caracterizado porque el método comprende, además: - negociar, mediante el elemento de red de computación (M), con ambas de las dos aplicaciones de comunicación (100, 200), antes de la realización de las diferentes acciones sobre los uno o más contextos (CTX_X), una clave simétrica usando un protocolo de intercambio de claves; - generar, mediante ambas de las dos aplicaciones de comunicación (100, 200), para cada uno de los uno o más contextos (CTX_X) de los datos de comunicación cifrados (D) a los que tiene derecho el elemento de red de computación (M), dichas claves de contexto, en el que cada una de las dos aplicaciones de comunicación (100, 200) genera una mitad de un secreto compartido para generar una función pseudo aleatoria, usándose la función pseudo aleatoria para generar las claves de contexto; - enviar, mediante ambas de las dos aplicaciones de comunicación (100, 200), al elemento de red de computación (M), la mitad correspondiente del secreto compartido en forma cifrada usando dicha clave simétrica negociada con el elemento de red de computación (M); y - computar, mediante el elemento informático (M), las claves de contexto usando la función pseudo aleatoria, usándose las claves de contexto computadas para descifrar los datos de comunicación cifrados (D) para realizar las diferentes acciones.
Description
DESCRIPCIÓN
Método, sistema y productos de programa informático para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas
Campo técnico
La presente invención está orientada, en general, al campo de la seguridad en Internet. En particular, la invención se refiere a métodos y a sistemas para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas.
En la presente invención, los 'middleboxes' son unos elementos de red de computación que se ejecutan “en el interior de” una red, estando ubicados en el plano lógico entre los puntos de extremo (una aplicación de cliente y una aplicación de servidor) de sesiones de comunicación. Una aplicación de cliente (por ejemplo, un navegador web) puede conectar con una aplicación de servidor (por ejemplo, un servidor web) por medio de uno o más middleboxes que añaden valor más allá del transporte básico de datos. Los usuarios poseen / gestionan aplicaciones de cliente y los proveedores de contenidos poseen / gestionan aplicaciones de servidores. La totalidad de la comunicación, entre todas las partes, es una sesión de datos; las conexiones vinculan saltos individuales en la sesión de datos (por ejemplo, una conexión de TCP entre la aplicación de cliente y un middlebox).
La presente invención se centra en los middleboxes de nivel de aplicación, que también se denominan representantes o servicios en el trayecto, que tienen acceso a datos de aplicación. Estos middleboxes pueden realizar funciones como detección de intrusiones, filtrado de contenidos, almacenamiento en memoria intermedia, compresión de datos y control parental, entre otros.
Antecedentes de la invención
Seguridad de la capa de transporte (TLS, Transport Layer Security) es el protocolo convencional para proporcionar autenticidad y confidencialidad sobre las conexiones de TCP. Hoy en día, esta se usa para proporcionar una versión segura de protocolos tradicionales (por ejemplo, IMAP, SMTP, XMPP, etc.); en particular, el uso de HTTP sobre TLS se conoce comúnmente como HTTPs . Cada conexión de TLS comienza con una toma de contacto entre un servidor y un cliente. En esta toma de contacto, se usa la serie de infraestructura de claves públicas (PKI, Public Key Infrastructure) para autenticar el servidor (y, con el tiempo, el cliente) y para generar claves criptográficas para crear un canal seguro a lo largo del cual se transmiten datos.
La TLS ha experimentado una amplia adopción y está soportando en la actualidad una fracción significativa del tráfico global de HTTP (Facebook™, Google™ y Twitter™ la usan por defecto). La TLS realiza la suposición fundamental de que toda la funcionalidad se encuentra únicamente en los puntos de extremo y, por lo tanto, es incapaz de utilizar los muchos servicios en - red que optimizan el uso de recursos de red, mejoran la experiencia del usuario, y protegen a clientes y a servidores frente a amenazas de seguridad. La reintroducción de tal funcionalidad en - red en sesiones de TLS seguras se realiza hoy en día a través de manipulaciones fraudulentas, debilitando en muchos casos la seguridad global.
En la actualidad se conocen cuatro soluciones orientadas a la inserción de middleboxes en sesiones de TLS:
Certificado raíz a medida: Esta solución consiste en la instalación de un certificado raíz a medida en un cliente, permitiendo que el middlebox cree un certificado para sí mismo que afirma ser el servidor previsto. El middlebox a continuación conecta con el servidor y pasa los datos de una conexión a la otra. Al contrario que la presente invención, en esta solución, no existe mecanismo alguno para autenticar el middlebox. Lo que es aún peor, el middlebox es completamente transparente para el servidor. En el cliente, solo una inspección profunda de la cadena de certificados revelaría la presencia de un certificado falsificado. Además, el cliente no tiene garantía alguna más allá del primer salto. Mientras que la conexión al middlebox está cifrada, el cliente no puede verificar que se está usando TLS desde el middlebox al servidor, si se encuentran presentes middleboxes adicionales, o si el punto de extremo de la sesión es siquiera el servidor previsto. Asimismo, los middleboxes obtienen un acceso pleno de lectura / escritura al tren de datos. Por un lado, muchos middleboxes solo necesitan un acceso selectivo al tren de datos. Por otro lado, debería darse a los clientes la capacidad de controlar qué datos compartir o no. Por último, los puntos de extremo (y los middleboxes) no pueden detectar modificaciones en vuelo.
Bandera de certificado “I ’m a proxy” (“Soy un representante”): Un proyecto de IETF de 2014 de Ericsson™ y AT&TTM que propone el uso de la extensión Uso Extendido de Claves (Extended Key Usage) de X.509 para indicar que el certificado pertenece a un representante [1]. Tras la recepción de un certificado de este tipo durante un protocolo de toma de contacto de TLS, el agente del cliente omitiría la comprobación de nombre de dominio (presumiblemente
después de asegurar el permiso de usuario) y establecería una sesión de TLS con el representante, lo que a su vez abriría una conexión con el servidor. Basándose en las preferencias del cliente, el agente del cliente podría aceptar solo certificados de representante para determinadas sesiones. En este caso, el cliente no tiene garantía alguna más allá del primer salto, y los middleboxes obtienen un acceso pleno de lectura / escritura al tren de datos. Además, en esta solución, los puntos de extremo (y los middleboxes) tampoco pueden detectar modificaciones en vuelo.
Pasar clave de sesión fuera de banda: Otro proyecto de IETF, este de Google™, supone que el cliente mantiene una conexión de TLS persistente con el representante y multiplexa múltiples sesiones a lo largo de esa conexión. Después de establecer una conexión de TLS de extremo a extremo con el servidor (que el representante reenvía a ciegas), el cliente pasa la clave de sesión al representante antes de la transmisión de datos por la nueva conexión [2]. Una vez más, el agente del usuario puede conceder de forma selectiva el acceso de representante de una forma en función de la conexión basándose en la preferencia del usuario. Esta solución se resiente ya que los middleboxes también obtienen un acceso pleno de lectura / escritura a una sesión de TLS. En comparación con las soluciones en lo que antecede, este enfoque limita un acceso de middlebox a la sesión de TLS indicada de forma específica por el cliente. No obstante, dentro de una sesión de TLS un middlebox aún obtiene un acceso pleno de lectura / escritura. Además, el servidor no es consciente de que se añaden middleboxes de confianza a una sesión segura con el consentimiento de ambos puntos de extremo, y los puntos de extremo (y los middleboxes) tampoco pueden detectar modificaciones en vuelo.
Remitir un navegador a medida: Esta solución consiste en la modificación del propio navegador para aceptar certificados procedentes de determinados representantes de confianza. Este es el enfoque que está adoptando Viasat™ para sus clientes de Internet por satélite de Exede®. En esta solución, tampoco existe un mecanismo para autenticar el middlebox, siendo el middlebox transparente para el servidor. En el cliente, solo una inspección profunda de la cadena de certificados revelaría la presencia de un certificado falsificado. Además, el cliente tampoco tiene garantía alguna más allá del primer salto. Mientras que la conexión al middlebox está cifrada, el cliente no puede verificar que se está usando t Ls desde el middlebox al servidor, si se encuentran presentes middleboxes adicionales, o si el punto de extremo de la sesión es siquiera el servidor previsto. Los middleboxes también obtienen un acceso pleno de lectura / escritura al tren de datos. Por un lado, muchos middleboxes solo necesitan un acceso selectivo al tren de datos. Por otro lado, debería darse a los clientes la capacidad de controlar qué datos compartir o no. Asimismo, esta solución requiere una instalación de navegador a medida, y los puntos de extremo (y los middleboxes) tampoco pueden detectar modificaciones en vuelo.
El documento US2011289311 divulga un método y un aparato que utiliza el protocolo de IPSEC de capas (LES) como una alternativa a IPSEC para seguridad de capa de red incluyendo una modificación al protocolo de Intercambio de Clave de Internet. Para la seguridad a nivel de aplicación de la navegación web con retraso de extremo a extremo aceptable, se usa el protocolo de SSL de modo dual (DSSL) en lugar de SSL. Los protocolos de LES y de DSSL consiguen la seguridad de comunicación de extremo a extremo deseada mientras permiten que los servidores de representante de TCP y HTTP funcionen correctamente.
El artículo científico 'A multi-layer IPsec protocol' de Yongguang Zhang et.al. se refiere a IPsec [KA98c], que es una serie de protocolos convencionales que proporciona servicios de seguridad para comunicaciones de Internet. Protege todo el datagrama de IP de una manera “de extremo a extremo”; ningún nodo de red intermedio en el Internet público puede acceder a o modificar ninguna información por encima de la capa de IP en un paquete protegido por IPsec. Sin embargo, avances recientes en la tecnología de internet presentan un nuevo conjunto rico de servicios y aplicaciones, como ingeniería de tráfico, mejoras de rendimiento de TCP o almacenamiento en memoria intermedia y representación transparente, todo lo cual requiere que nodos de red intermedios accedan a una determinada parte de un datagrama de IP, normalmente la información de protocolo de capa superior, para realizar clasificación de flujo, encaminamiento basado en restricciones, u otro procesamiento personalizado. Esto está en conflicto directo con los mecanismos de IPsec. En esta investigación, se propone un esquema de protección de seguridad de múltiples capas para IPsec, que usa un control de acceso de grano más fino para permitir que enrutadores intermedios de confianza lean y escriban porciones seleccionadas de datagramas de IP (normalmente, los encabezamientos) de una manera segura y controlada.
El documento científico 'A critical analysis of multilayer IP security protocol' de Sing J. et.al divulga un número de técnicas desarrolladas que pretenden aumentar el rendimiento de protocolos de capa de transporte y aplicación cuando se usan a lo largo de enlaces que muestran tasas de error de bit altas y grandes retrasos de propagación. Sin embargo, muchas de estas técnicas se vuelven inútiles cuando se usa un protocolo de seguridad de capa de red, debido a que la carga útil de la red está protegida de la observación y / o manipulación. El protocolo de seguridad de IP de múltiples capas (ML-IPsec) se ha propuesto como una manera de superar este problema, permitiendo el uso de tecnologías de mejora del rendimiento mientras proporciona seguridad de capa de red. ML-IPsec tiene un número de problemas que reducen su eficacia y provocan complejidades de configuración. Este documento identifica estos problemas y propone modificaciones al ML-IPsec, con el objetivo de rectificar los problemas, mientras engloba las
características y los beneficios clave de este protocolo de seguridad de múltiples capas.
El documento científico 'ML-IKE:A multilayer IKE Protocol for TCP Performance Enhancement in Wireless Networks' de Zhang Y et.al. divulga que para resolver el conflicto entre la tecnología de aceleración de TCP basada en el nodo medio de PEP y el protocolo de IPSec usado en la Red de Satélite, NASA y e1Hughes Research Laboratory (HRL) propusieron cada uno de manera independiente una solución denominada protocolo de IPsec de múltiples capas que puede integrar IPSec con PEP de TCP. El problema es el siguiente: el protocolo de IKE tradicional no puede funcionar con el protocolo de IPSec de múltiples capas. En este estudio, el modo principal de IKE tradicional y el modo rápido se mejoran para el protocolo de IPSec de capas, y se propone un protocolo de distribución de claves de capas mejorado: ML-IKE. Este protocolo de distribución de claves se usa para el intercambio de claves entre pares y nodo medio, de manera que nodos diferentes tienen asociaciones de seguridad (SA) diferentes, y asociaciones de seguridad diferentes corresponden a campos de paquete de IP diferentes, así que nodos de SA diferentes tienen autorización diferente para campos de paquete de Ip diferentes. El protocolo de ML-IKE es adecuado para IPSec de capas, así que IPSec de capas puede usarse para actualización y distribución de claves automática.
Sumario de la invención
De acuerdo con un primer aspecto, realizaciones de la presente invención proporcionan un método para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas, tal como se define en la reivindicación 1. El método comprende: establecer una sesión de datos cifrada entre dos aplicaciones de comunicación, una aplicación de comunicación de cliente y una aplicación de comunicación de servidor, a través de una red de comunicación; recibir y / o transmitir, mediante la aplicación de comunicación de cliente, en dicha sesión de datos cifrada establecida, unos datos de comunicación cifrados desde / a dicha aplicación de comunicación de servidor a través de por lo menos un elemento de red de computación; y realizar, mediante un elemento de red de computación, diferentes acciones que no sean el reenvío de datos desde una aplicación de comunicación a la otra sobre los datos de comunicación cifrados.
De acuerdo con el método propuesto, los datos de comunicación cifrados incluyen una pluralidad de porciones de datos, que también se denominan como contextos, cifrándose y autenticándose cada uno por medio de claves de contexto. Además, las diferentes acciones son específicas para el elemento de red de computación y para uno o más de la pluralidad de contextos de los datos de comunicación cifrados.
Las claves de contexto se computan de acuerdo con una realización por medio de una función pseudo aleatoria (PRF, pseudo random function) a la que ambas aplicaciones de comunicación contribuyen con una mitad de un secreto compartido, o material de clave de contexto, el uso del secreto compartido para generar la PRF. Como alternativa, esta operación puede moverse solo al cliente.
Las diferentes acciones que puede realizar el elemento de red de computación pueden comprender permisos de lectura y / o de escritura sobre los uno o más contextos de los datos de comunicación cifrados.
De acuerdo con una realización, el elemento de red de computación negocia, con ambas aplicaciones de comunicación, antes de la realización de las diferentes acciones sobre los uno o más contextos, una clave simétrica usando cualquier protocolo de intercambio de claves convencional. A continuación, cada aplicación de comunicación genera, para cada uno de los uno o más contextos de los datos de comunicación cifrados a los que tiene derecho el elemento de red de computación, una mitad del secreto compartido para la PRF, y envía al elemento de red de computación la mitad correspondiente del secreto compartido en forma cifrada usando dicha clave simétrica negociada. Por último, el elemento de red de computación computa las claves de contexto usando PRF; las claves de contexto se usan para descifrar datos de comunicación y realizan las diferentes acciones a las que tiene derecho el elemento de red de computación.
Además, el elemento de red de computación puede proporcionar a ambas de las dos aplicaciones de comunicación su propio certificado. En este caso, las dos aplicaciones de comunicación verificarán el certificado recibido del elemento de red de computación antes de contribuir al cómputo de las claves de contexto.
De acuerdo con una realización, la sesión de datos cifrada es una sesión de Transport Layer Security (seguridad de la capa de transporte), TLS. Como alternativa, la sesión de datos cifrada es una sesión de pase de mensaje de OpenStack.
Otras realizaciones de la invención, de acuerdo con otros aspectos, que se divulgan en el presente documento también incluyen un sistema y programas de soporte lógico para realizar las etapas y operaciones de realización de método que se han resumido en lo que antecede y que se divulgan con detalle en lo sucesivo. Más en particular, un producto de programa informático es una realización que tiene un medio legible por ordenador que incluye instrucciones de
programa informático que están codificadas en el mismo que, cuando se ejecutan en por lo menos un procesador en un elemento informático, da lugar a que el procesador realice las operaciones que se indican en el presente documento como realizaciones de la invención.
La presente invención proporciona a los puntos de extremo de una sesión de datos un conocimiento y un control explícitos acerca de qué elementos funcionales son parte de la sesión. Además, la presente invención permite que los usuarios y los proveedores de contenidos elijan de forma dinámica qué porciones de datos de contenidos están expuestas a servicios en - red (por ejemplo, encabezamientos de HTTP frente a contenidos), y protejan la autenticidad y la integridad de los datos a la vez que se sigue posibilitando el acceso a determinados servicios en - red mediante la separación de los permisos de lectura y de escritura. La presente invención puede desplegarse de forma gradual.
Breve descripción de los dibujos
Las anteriores y otras ventajas y características se entenderán de manera más profunda a partir de la siguiente descripción detallada de realizaciones, con referencia a lo adjunto, que ha de considerarse de una forma ilustrativa y no limitante, en lo que:
La figura 1 es una representación gráfica que muestra cómo se usan Klectores, Kescritores y Kpuntos de extremo.
La figura 2 es un ejemplo del protocolo de toma de contacto de mcTLS que propone la presente invención. El sombreado indica una diferencia con respecto al protocolo de toma de contacto de TLS.
La figura 3 es un diagrama de flujo que ilustra un uso y elementos de sistema para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas.
La figura 4 ilustra un ejemplo de estrategia de segmentación de contexto que puede usarse por el método propuesto.
Descripción detallada de la invención y de varias realizaciones
La presente invención proporciona un mecanismo para posibilitar de forma explícita y segura una funcionalidad en -red a lo largo de sesiones de datos cifradas. A pesar de que el mecanismo se presenta en el contexto de TLS, debido a que TLS es el protocolo convencional para sesiones de datos seguras en Internet, el mecanismo propuesto es amplio y podría aplicarse a otras tecnologías como OpenStack, IPsec (capa 3) y tcpcrypt (capa 4). OpenStack es una plataforma de soporte lógico informático en la nube de código abierto; las ideas que se describen en la presente podrían usarse para posibilitar una funcionalidad en nube a la vez que se asegura un pase de mensaje seguro. IPsec representa Internet Protocol Security (seguridad de Protocolo de Internet) y esta es una serie de protocolos para asegurar comunicaciones de Internet Protocol (IP, Protocolo de Internet) mediante la autenticación y el cifrado de cada paquete de IP de una sesión de comunicación. Por consiguiente, las ideas que se describen en la presente podrían adoptarse para introducir funcionalidades en - red. De forma similar, tcpcrypt introduce la misma idea en los paquetes de TCP, y también podría ampliarse con las ideas en lo que antecede.
Por consiguiente, a continuación se describirá mcTLS, una modificación de TLS que incorpora las enseñanzas de la presente invención para posibilitar una funcionalidad en - red explícita y segura a lo largo de sesiones de datos de TLS.
La expresión “claves de contexto” tal como se usa en el presente documento hace referencia a un conjunto de claves de cifrado simétrico y de código de autenticación de mensajes (MAC, message authentication code) para controlar quién puede leer y escribir los datos que se envían en un contexto, o porción de datos, CTX_X, de unos datos de comunicación D. Las aplicaciones de comunicación 100, 200 pueden asociar cada contexto CTX_X con un fin y acceder a permisos para cada middlebox M. Por ejemplo, los navegadores web / servidores podrían usar un contexto CTX_X para encabezamientos de HTTP y otro para contenidos.
Al igual que en TLS, en mcTLS también puede distinguirse entre un registro y un protocolo de toma de contacto. A continuación, ambos de estos protocolos se explicarán con más detalle.
Protocolo de registro
- Control del acceso de lectura:
Cada contexto CTX_X tiene su propia clave de contexto de lector (que se denomina Klectores). La posesión de esta clave de contexto constituye un acceso de lectura de tal modo que mcTLS puede evitar que un middlebox M lea un contexto CTX X mediante la retención de la clave de lector de ese contexto.
- Control del acceso de escritura:
Para controlar el acceso de escritura, mcTLS adopta el siguiente enfoque de “punto de extremo - escritor - lector” para los MAC. Cada registro de mcTLS porta tres MAC con clave, que se generan con las claves de MAC a partir de Kpuntos de extremo, Kescritores (compartida por los puntos de extremo 100, 200 y los escritores (los middleboxes M que tienen acceso de escritura para un contexto CTX_X)), y Klectores (compartida por los puntos de extremo 100, 200, los escritores y los lectores (los middleboxes M que solo tienen acceso de lectura para un contexto CTX_X).
Cada contexto CTX_X tiene su propia Kescritores y Klectores pero existe solo una Kpuntos de extremo para la sesión de datos debido a que los puntos de extremo 100, 200 tienen acceso a todos los contextos CTX.
- Generación de los MAC:
Cuando un punto de extremo 100, 200 ensambla un registro, este genera tres MAC: uno con Klectores, uno con Kescritores y uno con Kpuntos de extremo.
Cuando un escritor modifica un registro, este genera unos MAC con Kescritores y Klectores y simplemente reenvía el MAC de Kpuntos de extremo original.
Cuando un lector reenvía un registro, este deja la totalidad de los tres MAC sin modificar.
- Verificación de los MAC:
Cuando un punto de extremo 100, 200 recibe un registro, este comprueba el MAC de Kescritores para confirmar que no se realizó modificación ilegal alguna y comprueba el MAC de Kpuntos de extremo para descubrir si se hizo cualquier modificación legal (si se importa a la aplicación de comunicación).
Cuando un escritor recibe un registro, este comprueba el MAC de Kescritores para verificar que no se ha realizado modificación ilegal alguna.
Cuando un lector recibe un registro, este usa el MAC de Klectores para comprobar si se ha hecho alguna modificación de terceras partes.
Ha de hacerse notar que, con el esquema de MAC de punto de extremo - escritor - lector, los lectores no pueden detectar cambios ilegales realizados por otros lectores. El problema es que una clave de contexto compartida no puede usarse por una entidad para supervisar otras entidades al mismo nivel de privilegio. Debido a que todos los lectores comparten Klectores (de tal modo que estos pueden detectar modificaciones de terceras partes), todos los lectores son también capaces de generar unos MAC de Klectores válidos.
Existen dos opciones para arreglar esto: (a) los lectores y los escritores / puntos de extremo 100, 200 comparten claves simétricas por pares; los escritores / puntos de extremo 100, 200 computan y adjuntan un MAC para cada lector, o (b) los puntos de extremo 100, 200 y los escritores adjuntan firmas digitales en lugar de los MAC; a diferencia de los MAC de Kescritores, los lectores pueden verificar estas firmas.
Esto es un problema solo cuando existen más de dos lectores para un contexto CTX_X, y que los lectores no detecten modificaciones de lector no debería ser, en general, un problema (las modificaciones de lector aún pueden detectarse en el siguiente escritor o punto de extremo 100, 200). Los beneficios parecen insuficientes para justificar la tara adicional de (a) o (b), pero estos podrían implementarse como modos opcionales que se negocian durante el protocolo de toma de contacto.
La figura 1 ilustra cómo se usan Klectores, Kescritores y Kpuntos de extremo.
Protocolo de toma de contacto
El protocolo de toma de contacto de mcTLS es muy similar al protocolo de toma de contacto de TLS. En primer lugar se explicarán los detalles de la generación de claves de contexto y, a continuación, la propia toma de contacto. - Generación de claves de contexto:
En TLS, los puntos de extremo llegan a un acuerdo acerca de un secreto maestro, que se usa para computar una función pseudo aleatoria (PRF), que genera la clave de sesión. Los puntos de extremo de mcTLS 100, 200 establecen
un secreto maestro y lo usan para generar Kpuntos de extremo al igual que en la TLS clásica; Kpuntos de extremo se usa para los MAC de extremo a extremo, para intercambiar de forma segura un secreto de contexto parcial entre el cliente 100 y el servidor 200, y para autenticar la toma de contacto por medio del cifrado del mensaje Acabado. Adicionalmente, cada punto de extremo 100, 200 genera de forma independiente un secreto de contexto parcial, que se pasa a la PRF para generar KCescritores y KClectores (en el cliente 100) y KSescritores y KSlectores (en el servidor 200) para cada contexto CTX_X. Al final del protocolo de toma de contacto, los middleboxes M computan Kescritores = PRF (KCescritores KSescritores, “claves de escritor”, randc rands) y Klectores = PRF(KClectores KSlectores, “claves de lector”, randc rands), en los que PRF(secreto, etiqueta, semilla) se define en el documento TLS RFC [3], y randc / rands son unos valores aleatorios que se intercambian en el comienzo de la toma de contacto de TLS. Obsérvese que, a pesar de que esta se describe como una clave por simplicidad, Klectores es, en realidad, cuatro claves (al igual que la “clave de sesión” en TLS): una clave de cifrado para datos en cada sentido y una clave de MAC para datos en cada sentido. De forma similar, Kescritores es, en realidad, una clave de MAC para cada sentido.
- Protocolo de toma de contacto:
La figura 2 ilustra las etapas de un protocolo de toma de contacto de mcTLS, resaltando las diferencias con respecto a TLS. Los mensajes que se muestran son registros de mcTLS de tal modo que mcTLS tiene la misma “forma” de 2-RTT que TLS.
1. Saludo inicial de cliente. Al igual que TLS, una sesión de mcTLS comienza con un mensaje ClientHello (la etapa 201). En mcTLS, el ClientHello porta una MiddleboxListExtenstion, que incluye una lista de los middleboxes M1, M2 a incluir en la sesión de datos (mecanismos para construir esta lista se encuentran fuera del ámbito de la presente patente) y una lista de claves de contexto, sus fines (cadenas con significado para la aplicación de comunicación), y los permisos de acceso de cada middlebox M1, M2 para cada uno de los contextos CTX_X. El cliente 100 abre una conexión de TCP con el primer middlebox M1 y envía el ClientHello (la etapa 201); el middlebox M1 abre una conexión de TCP con el siguiente salto en la lista, reenvía el ClientHello, y así sucesivamente.
2. Certificado e intercambio de claves públicas. Al igual que en TLS, el servidor 200 responde con su certificado (la etapa 202), y, si el mensaje de certificado no contiene suficientes datos para la serie de cifras escogida, el servidor 200 envía un mensaje de intercambio de claves adicional (la etapa 203). En esta etapa, los middleboxes M1, M2 hacen lo mismo: estos envían sus certificados (las etapas 205, 206) (y posiblemente un mensaje de intercambio de claves) tanto al cliente 100 como al servidor 200. Esta etapa es necesaria solo si el cliente 100 y el servidor 200 solicitan certificados a partir de los middleboxes M1, M2 y ocurre en paralelo con los mensajes ServerCertificate y ClientKeyExchange.
3. Generación de claves. Los puntos de extremo 100, 200 generan (las etapas 207, 208), un material de pre secreto - maestro y un material de clave de contexto parcial para cada contexto CTX_X. En la etapa 5, los middleboxes M1, M2 combinan estos materiales de clave de contexto parciales para computar las claves de contexto. Este enfoque sirve a dos fines: este proporciona un acuerdo de clave contributiva y asegura que un middlebox M solo obtiene acceso a un contexto CTX_X si tanto el cliente 100 como el servidor 200 llegan a un acuerdo.
4. Intercambio de claves. En primer lugar, el cliente 100 (las etapas 210 - 212) y el servidor 200 (las etapas 214 - 216) intercambian el material de pre-secreto - maestro usando cualquiera de los mecanismos de acuerdo de clave convencionales soportados por TLS. A continuación, para cada contexto CTX_X, los puntos de extremo 100, 200 envían KClectores y KSlectores a los lectores y KCescritores y KSescritores a los escritores. Este material de clave de contexto se envía cifrado bajo una clave simétrica que resulta de cualquier protocolo de intercambio de claves convencional. Estos mensajes se reenvían al punto de extremo opuesto de tal modo que estos pueden incluirse en la función de troceo de los mensajes de toma de contacto que se verifica al final del protocolo de toma de contacto. Los puntos de extremo 100, 200 intercambian todos los materiales de clave de contexto parciales que están cifrados bajo Kpuntos de extremo. El servidor 200 en una realización puede elegir evitar esta tara al pedir al cliente 100 que genere el material de clave de contexto completo.
5. Acabado. El protocolo de toma de contacto de mcTLS concluye con el intercambio de mensajes ChangeCipherSpec y Finished (las etapas 213 y 217), al igual que TLS. La recepción del mensaje ChangeCipherSpec impulsa que los middleboxes M1, M2 computen las claves de contexto. Todos los mensajes de toma de contacto, incluyendo los que se envían a los middleboxes M1, M2, están incluidos en la función de troceo de Finished. La verificación de la función de troceo asegura que ambos puntos de extremo 100, 200 siguen la misma secuencia de mensajes de toma de contacto.
- Claves de contexto contributivas:
Una clave de contexto se computa como Clave = PRF (secreto, etiqueta, semilla) en la que secreto = KC KS, etiqueta = “una cadena”, y semilla = randc rands. Este enfoque tiene varias ventajas; en primer lugar, tanto la aplicación de comunicación de cliente 100 como la aplicación de comunicación de servidor 200 contribuyen en la creación de una clave de contexto lo que comporta que ambos de ellos llegan a un acuerdo acerca de los privilegios que compartir con un middlebox M. En segundo lugar, mediante el uso de una operación de concatenación, en lugar de una operación de XOR por ejemplo, la aplicación de comunicación de servidor 200 no puede forzar Clave = 0 mediante la elección de KS = KC (debido a que una aplicación de comunicación de servidor 200 ve KC antes de la concertación a KS). A pesar de que no resulta claro por qué una aplicación de comunicación de servidor 200 intentaría forzar una clave débil, esto es una protección adicional, por ejemplo, frente a un ataque potencial.
- Modo de distribución de claves de contexto de cliente
Una preocupación acerca del despliegue de TLS es que el protocolo de toma de contacto es demandante desde un punto de vista computacional, limitando el número de nuevas conexiones por segundo que pueden procesar los servidores. De forma similar a TLS, en mcTLS, la autenticación de los puntos de extremo 100, 200 en la sesión de datos es opcional. Otra operación de mcTLS pesada para las aplicaciones 200 de los servidores es la generación y el cifrado del secreto compartido parcial para la distribución a los middleboxes M. Como alternativa, esta operación puede moverse solo al cliente: unas claves de contexto se generan a partir del secreto maestro y la aplicación de comunicación de cliente 100 las cifra y las distribuye a los middleboxes M. Esto reduce la carga de servidor, pero tiene la desventaja de que no se impone el acuerdo acerca de los permisos de middlebox.
Ha de hacerse notar que esto no sacrifica el acuerdo de clave contributiva en el sentido de que ambos puntos de extremo contribuyen a la aleatoriedad. La aplicación de comunicación de cliente 100 genera los secretos de contexto completo a partir del secreto que esta comparte con el servidor; si un intercambio de claves de cliente / servidor fue contributivo, las claves de contexto heredan este beneficio. La elección de un modo de toma de contacto se deja a los proveedores de contenidos, que pueden decidir de forma individual cómo realizar esta compensación recíproca de control - rendimiento; la aplicación de comunicación de servidor 200 indica su elección para la aplicación de comunicación de cliente 100 en el mensaje ServerHello.
Con referencia a continuación a la figura 3, en la misma se ilustra un diagrama de alto nivel de una realización de la presente invención para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas. En primer lugar (la etapa 301), una aplicación de comunicación de cliente 100 que está instalada en un dispositivo informático de cliente (que no se ilustra) entra en contacto con la aplicación de comunicación de servidor 200 que está instalada en un servidor (que no se ilustra), intercambiando una lista de los middleboxes de confianza M que a esta le gustaría insertar en el trayecto de la sesión de datos. Esta lista puede proporcionarse por un operador o hallarse de formas alternativas. La presente invención no restringe mecanismo específico alguno. El servidor 200 responde con su certificado (la etapa 302). Una vez que se ha seleccionado un middlebox M1 (puede seleccionarse más de uno) a partir de dicha lista de los middleboxes de confianza M, el middlebox seleccionado M1 se autentica con ambos (la etapa 305), la aplicación de comunicación de cliente 100 y la aplicación de comunicación de servidor 200, mientras que continúa una autenticación ordinaria entre la aplicación de comunicación de servidor 200 y la aplicación de comunicación de cliente 100. La aplicación de comunicación de cliente 100 y la aplicación de comunicación de servidor 200 entonces llegan a un acuerdo acerca de los privilegios que debería recibir el middlebox M1 mediante la definición de un conjunto de contexto CTX_X y claves de contexto (las etapas 306 - 307). Por último, la aplicación de comunicación de cliente 100 y la aplicación de comunicación de servidor 200 comienza a intercambiar datos (por ejemplo, unos datos de comunicación D) usando los contextos CTX_X apropiados que se han definido en lo que antecede (las etapas 308 - 310). La figura 4 ilustra una posible estrategia de segmentación de contexto que puede usarse por el método propuesto.
Existen dos formas de pensar en los contextos CTX_X: como porciones de los datos de comunicación que van a transferirse o como una configuración de los permisos de middlebox. Por ejemplo, supóngase que una aplicación de comunicación de cliente 100 desea transferir un documento que consiste en tres porciones, CTX_A, CTX_B, y CTX_C por medio de dos middleboxes M1, M2. Por ejemplo, CTX_A y CTX_B podrían ser dos subconjuntos de encabezamientos de HTTP, mientras que CTX_C podría ser el contenido de HTTP que se está transfiriendo. El middlebox M1 debería tener acceso de lectura a la totalidad del documento y el middlebox M2 debería leer CTX_A, escribir CTX_B, y no tener acceso alguno a CTX_C, por ejemplo, por razones de privacidad el middlebox M2 no debería ser capaz de leer el contenido de HTTP que se está transfiriendo. La aplicación de comunicación podría atribuir una clave de contexto para cada contexto CTX_X y asignar los permisos apropiados (a la izquierda en la figura 4), o esta podría crear una clave de contexto para cada combinación de permisos y usar la clave de contexto apropiada cuando se envía cada contexto CTX_X del documento (a la derecha en la figura 4).
La presente invención posibilita la intercepción legal de tráfico cifrado por medio de claves de contexto contributivas.
A pesar de que las claves de contexto contributivas no son un requisito, por ejemplo, un enfoque rival podría posibilitar el control para solo un punto de extremo, se requieren múltiples claves de contextos para posibilitar un acceso de datos selectivo a los middleboxes M. Un inconveniente del uso de múltiples claves de contexto es un aumento en el número de bytes que se transfieren por el cable, en comparación con un enfoque de extremo a extremo clásico. Por consiguiente, el uso no autorizado de tal característica puede detectarse mediante una inspección de tráfico. Una aplicación de comunicación de cliente 100 que ejecuta el protocolo rival bajo inspección puede dotarse de instrumentos para notificar el contenido que se transfiere, junto con la cifra que se usa y el recuento de bytes que se reciben a partir del cable. Si el cifrado de nuevo del contenido recibido con la misma cifra origina un recuento de byte diferente del número de bytes que se reciben a partir del cable, es probable que se detectara el uso de múltiples contextos de cifrado.
La invención propuesta puede implementarse en soporte físico, soporte lógico, soporte lógico inalterable, o cualquier combinación de los mismos. Si se implementan en soporte lógico, las funciones pueden estar almacenadas o codificadas como una o más instrucciones o código en un medio legible por ordenador.
Los medios legibles por ordenador incluyen medios de almacenamiento informático. Los medios de almacenamiento pueden ser cualquier medio disponible al que pueda acceder un ordenador. A modo de ejemplo, y no de limitación, tales medios legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento en disco óptico, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que pueda usarse para portar o almacenar un código de programa deseado en forma de instrucciones o estructuras de datos y al que pueda acceder un ordenador. Disco, tal como se usa en el presente documento, incluye disco compacto (CD, compact disc), disco láser, disco óptico, disco versátil digital (DVD, digital versatile disc), disco flexible y disco Blu-ray en los que los discos magnéticos por lo general reproducen datos por medios magnéticos, mientras que los discos ópticos reproducen datos por medios ópticos con láseres. También deberían estar incluidas dentro del ámbito de los medios legibles por ordenador combinaciones de lo anterior. Cualquier procesador y el medio de almacenamiento pueden encontrarse en un ASIC. El ASIC puede encontrarse en un terminal de usuario. Como alternativa, el procesador y el medio de almacenamiento pueden encontrarse como componentes discretos en un terminal de usuario.
Tal como se usan en el presente documento, los productos de programa informático comprenden unos medios legibles por ordenador, incluyendo todas las formas de medio legible por ordenador excepto en la medida en la que se considere que tales medios son señales de propagación no reglamentarias y transitorias.
El ámbito de la presente invención se define en el siguiente juego de reivindicaciones.
Referencias:
[1] S. Loreto, J. Mattsson, R. Skog, et al. Explicit Trusted Proxy in HTTP/2.0. Proyecto de Internet draft-loreto-httpbistrusted-proxy20-01, Secretaría de IETF, febrero de 2014.
[2] R. Peon. Explicit Proxies for HTTP/2.0. Proyecto de Internet draft-rpeon-httpbis-exproxy-00, Secretaría de IETF, junio de 2012.
[3] https://tools.ietf.org/html/rfc5246
Claims (8)
1. Método para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas, comprendiendo el método:
- establecer una sesión de datos cifrada entre dos aplicaciones de comunicación, una aplicación de comunicación de cliente (100) y una aplicación de comunicación de servidor (200), a través de una red de comunicación;
- recibir y / o transmitir, mediante la aplicación de comunicación de cliente (100), en dicha sesión de datos cifrada establecida, unos datos de comunicación cifrados (D) desde / a dicha aplicación de comunicación de servidor (200) a través de por lo menos un elemento de red de computación (M); y
- realizar, mediante dicho por lo menos un elemento de red de computación (M), diferentes acciones que no sean el reenvío de datos de comunicación desde una aplicación de comunicación a la otra sobre dichos datos de comunicación cifrados (D),
en el que dichos datos de comunicación cifrados (D) comprenden una pluralidad de porciones de datos, o contextos, (CTX), cifrándose y autenticándose cada uno (CTX_X) por medio de claves de contexto, y siendo dichas diferentes acciones específicas para dicho por lo menos un elemento de red de computación (M) y para uno o más de dicha pluralidad de contextos (CTX_X) de los datos de comunicación cifrados (D).
caracterizado porque el método comprende, además:
- negociar, mediante el elemento de red de computación (M), con ambas de las dos aplicaciones de comunicación (100, 200), antes de la realización de las diferentes acciones sobre los uno o más contextos (CTX_X), una clave simétrica usando un protocolo de intercambio de claves; - generar, mediante ambas de las dos aplicaciones de comunicación (100, 200), para cada uno de los uno o más contextos (CTX_X) de los datos de comunicación cifrados (D) a los que tiene derecho el elemento de red de computación (M), dichas claves de contexto, en el que cada una de las dos aplicaciones de comunicación (100, 200) genera una mitad de un secreto compartido para generar una función pseudo aleatoria, usándose la función pseudo aleatoria para generar las claves de contexto;
- enviar, mediante ambas de las dos aplicaciones de comunicación (100, 200), al elemento de red de computación (M), la mitad correspondiente del secreto compartido en forma cifrada usando dicha clave simétrica negociada con el elemento de red de computación (M); y - computar, mediante el elemento informático (M), las claves de contexto usando la función pseudo aleatoria, usándose las claves de contexto computadas para descifrar los datos de comunicación cifrados (D) para realizar las diferentes acciones.
2. Método de la reivindicación 1, en el que el elemento de red de computación (M) además de negociar la clave simétrica proporciona a ambas de las dos aplicaciones de comunicación (100, 200) un certificado propio, verificando las dos aplicaciones de comunicación (100, 200) el certificado recibido del elemento de red de computación (M) antes de generar las claves de contexto.
3. Método de cualquiera de las reivindicaciones anteriores, en el que las diferentes acciones comprenden permisos de lectura y / o de escritura del elemento de red de computación (M) sobre los uno o más contextos (CTX_X) de los datos de comunicación cifrados (D).
4. Método de cualquiera de las reivindicaciones anteriores, en el que la sesión de datos cifrada es una sesión de Transport Layer Security (seguridad de la capa de transporte), TLS.
5. Método de cualquiera de las reivindicaciones anteriores 1 a 3, en el que la sesión de datos cifrada es una sesión de pase de mensaje de OpenStack.
6. Sistema para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas, que comprende:
- dos aplicaciones de comunicación, una aplicación de comunicación de cliente (100) y una aplicación de comunicación de servidor (200), ejecutándose dicha aplicación de comunicación de cliente (100) en un dispositivo informático de cliente y estando configurada para establecer una sesión de datos cifrada con dicha aplicación de comunicación de servidor (200) a través de una red de comunicación y para recibir y / o transmitir por lo menos unos datos de comunicación cifrados (D) desde / a dicha aplicación de comunicación de servidor (200) a través de por lo menos un elemento de red de computación (M); y
- comprendiendo dicho por lo menos un elemento de red de computación (M) uno o más procesadores para realizar diferentes acciones que no sean el reenvío de paquetes de datos desde una aplicación de comunicación a la otra sobre dichos por lo menos unos datos de comunicación cifrados (D),
en el que el sistema está caracterizado por que dichos uno o más procesadores están configurados para realizar para cada sesión de datos cifrada que se establece entre dichas dos aplicaciones de comunicación (100, 200) dichas diferentes acciones sobre una o más de una pluralidad de porciones de datos, o contextos, (CTX) de los datos de comunicación cifrados (D) de acuerdo con un algoritmo que implementa el método de la reivindicación 1.
7. Producto de programa informático incorporado de forma tangible en un medio de almacenamiento legible por máquina no transitorio, que incluye instrucciones que están configuradas para dar lugar a que un elemento de red de computación (M) :
- realice diferentes acciones que no sean el reenvío de paquetes de datos sobre por lo menos unos datos de comunicación cifrados (D) que se transmiten y / o que se reciben por una aplicación de comunicación de cliente (100) a / desde una aplicación de comunicación de servidor (200), a través de una red de comunicación,
en el que dichos por lo menos unos datos de comunicación cifrados (D) comprenden una pluralidad de porciones de datos, o contextos, (CTX), estando cada uno (CTX_X) cifrado mediante una clave de contexto, y
en el que dichas diferentes acciones son específicas para dicho por lo menos un elemento de red de computación (M) y para uno o más de dicha pluralidad de contextos (CTX_X) de los datos de comunicación cifrados (D);
- negociar con ambas de las aplicaciones de comunicación (100, 200), antes de la realización de las diferentes acciones sobre los uno o más contextos (CTX_X), una clave simétrica usando un protocolo de intercambio de claves;
- recibir a partir de ambas de las dos aplicaciones de comunicación (100, 200) la mitad correspondiente de un secreto compartido en forma cifrada usando dicha clave simétrica negociada, generándose dicho secreto compartido por cada una de las dos aplicaciones de comunicación (100, 200) por medio de una función pseudo aleatoria, en el que cada aplicación de comunicación (100, 200) genera una mitad del secreto compartido, y en el que la función pseudo aleatoria se usa para generar las claves de contexto; y
- computar las claves de contexto usando la función pseudo aleatoria, usándose las claves de contexto computadas para descifrar los datos de comunicación cifrados (D) para realizar las diferentes acciones.
8. Producto de programa informático de la reivindicación 7, en el que las diferentes acciones comprenden permisos de lectura y / o de escritura del elemento de red de computación (M) sobre los uno o más contextos (CTX_X) de los datos de comunicación cifrados (D).
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP15382354.7A EP3113443B1 (en) | 2015-07-02 | 2015-07-02 | Method, a system and computer program products for securely enabling in-network functionality over encrypted data sessions |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2828948T3 true ES2828948T3 (es) | 2021-05-28 |
Family
ID=53546560
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES15382354T Active ES2828948T3 (es) | 2015-07-02 | 2015-07-02 | Método, sistema y productos de programa informático para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US10742611B2 (es) |
| EP (1) | EP3113443B1 (es) |
| BR (1) | BR112017028270A2 (es) |
| ES (1) | ES2828948T3 (es) |
| WO (1) | WO2017001133A1 (es) |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9338147B1 (en) | 2015-04-24 | 2016-05-10 | Extrahop Networks, Inc. | Secure communication secret sharing |
| US10476673B2 (en) | 2017-03-22 | 2019-11-12 | Extrahop Networks, Inc. | Managing session secrets for continuous packet capture systems |
| US10958666B1 (en) * | 2017-03-24 | 2021-03-23 | NortonLifeLock Inc. | Systems and methods for verifying connection integrity |
| GB201710168D0 (en) | 2017-06-26 | 2017-08-09 | Microsoft Technology Licensing Llc | Introducing middleboxes into secure communications between a client and a sever |
| US10999318B2 (en) * | 2017-07-07 | 2021-05-04 | Uniken Inc. | Algorithmic packet-based defense against distributed denial of service |
| US9967292B1 (en) * | 2017-10-25 | 2018-05-08 | Extrahop Networks, Inc. | Inline secret sharing |
| US10389574B1 (en) | 2018-02-07 | 2019-08-20 | Extrahop Networks, Inc. | Ranking alerts based on network monitoring |
| US10038611B1 (en) | 2018-02-08 | 2018-07-31 | Extrahop Networks, Inc. | Personalization of alerts based on network monitoring |
| US10270794B1 (en) | 2018-02-09 | 2019-04-23 | Extrahop Networks, Inc. | Detection of denial of service attacks |
| EP3554114A1 (de) * | 2018-04-10 | 2019-10-16 | Siemens Aktiengesellschaft | Verfahren, vorrichtungen und computerprogrammprodukt zur überwachung einer verschlüsselten verbindung in einem netzwerk |
| CN110768933B (zh) * | 2018-07-27 | 2022-08-09 | 深信服科技股份有限公司 | 一种网络流量应用识别方法、系统及设备和存储介质 |
| US10411978B1 (en) | 2018-08-09 | 2019-09-10 | Extrahop Networks, Inc. | Correlating causes and effects associated with network activity |
| US10594718B1 (en) | 2018-08-21 | 2020-03-17 | Extrahop Networks, Inc. | Managing incident response operations based on monitored network activity |
| CN109344632A (zh) * | 2018-09-28 | 2019-02-15 | 山东超越数控电子股份有限公司 | 一种基于硬件加密卡的openstack卷加密方法 |
| US11063921B2 (en) * | 2018-11-06 | 2021-07-13 | International Business Machines Corporation | Extracting data from passively captured web traffic that is encrypted in accordance with an anonymous key agreement protocol |
| KR20200086800A (ko) * | 2019-01-10 | 2020-07-20 | 삼성전자주식회사 | 전자 장치, 전자 장치 제어방법 및 네트워크 시스템 |
| US10965702B2 (en) | 2019-05-28 | 2021-03-30 | Extrahop Networks, Inc. | Detecting injection attacks using passive network monitoring |
| EP3748927A1 (de) * | 2019-06-04 | 2020-12-09 | Siemens Aktiengesellschaft | Verfahren und system zum überwachen von nachrichten einer kommunikationsverbindung |
| US11165814B2 (en) | 2019-07-29 | 2021-11-02 | Extrahop Networks, Inc. | Modifying triage information based on network monitoring |
| US10742530B1 (en) | 2019-08-05 | 2020-08-11 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
| US11388072B2 (en) | 2019-08-05 | 2022-07-12 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
| CN112398800A (zh) * | 2019-08-19 | 2021-02-23 | 华为技术有限公司 | 一种数据处理方法及装置 |
| US10742677B1 (en) | 2019-09-04 | 2020-08-11 | Extrahop Networks, Inc. | Automatic determination of user roles and asset types based on network monitoring |
| CN110661729B (zh) * | 2019-09-17 | 2023-01-10 | 苏州浪潮智能科技有限公司 | 一种基于Openstack系统的创建项目资源的方法和装置 |
| US11165823B2 (en) | 2019-12-17 | 2021-11-02 | Extrahop Networks, Inc. | Automated preemptive polymorphic deception |
| US11658944B2 (en) * | 2020-03-13 | 2023-05-23 | Arm Ip Limited | Methods and apparatus for encrypted communication |
| US11310256B2 (en) | 2020-09-23 | 2022-04-19 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
| US11463466B2 (en) | 2020-09-23 | 2022-10-04 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
| CN112769568B (zh) * | 2021-01-29 | 2022-07-22 | 华中师范大学 | 雾计算环境中的安全认证通信系统、方法、物联网设备 |
| US11349861B1 (en) | 2021-06-18 | 2022-05-31 | Extrahop Networks, Inc. | Identifying network entities based on beaconing activity |
| US11296967B1 (en) | 2021-09-23 | 2022-04-05 | Extrahop Networks, Inc. | Combining passive network analysis and active probing |
| US11843606B2 (en) | 2022-03-30 | 2023-12-12 | Extrahop Networks, Inc. | Detecting abnormal data access based on data similarity |
| CN115174267B (zh) * | 2022-09-02 | 2022-11-18 | 深圳星云智联科技有限公司 | 一种tls协议协商方法、设备及介质 |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5657390A (en) * | 1995-08-25 | 1997-08-12 | Netscape Communications Corporation | Secure socket layer application program apparatus and method |
| CA2267395C (en) * | 1999-03-30 | 2002-07-09 | Ibm Canada Limited-Ibm Canada Limitee | Method and system for managing keys for encrypted data |
| US6711679B1 (en) * | 1999-03-31 | 2004-03-23 | International Business Machines Corporation | Public key infrastructure delegation |
| US7069434B1 (en) * | 2000-06-13 | 2006-06-27 | Hewlett-Packard Development Company, L.P. | Secure data transfer method and system |
| US7111163B1 (en) * | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
| US6931529B2 (en) * | 2001-01-05 | 2005-08-16 | International Business Machines Corporation | Establishing consistent, end-to-end protection for a user datagram |
| US7149892B2 (en) * | 2001-07-06 | 2006-12-12 | Juniper Networks, Inc. | Secure sockets layer proxy architecture |
| US7231663B2 (en) * | 2002-02-04 | 2007-06-12 | General Instrument Corporation | System and method for providing key management protocol with client verification of authorization |
| US7373500B2 (en) * | 2003-04-15 | 2008-05-13 | Sun Microsystems, Inc. | Secure network processing |
| EP1519530A1 (en) * | 2003-09-29 | 2005-03-30 | STMicroelectronics S.r.l. | Method for establishing an encrypted communication by means of keys |
| JP4707992B2 (ja) * | 2004-10-22 | 2011-06-22 | 富士通株式会社 | 暗号化通信システム |
| JP4561671B2 (ja) * | 2006-03-30 | 2010-10-13 | 株式会社日立製作所 | データ通信方法およびシステム |
| US8850554B2 (en) * | 2010-02-17 | 2014-09-30 | Nokia Corporation | Method and apparatus for providing an authentication context-based session |
| US8671273B2 (en) * | 2010-04-15 | 2014-03-11 | The University Of Maryland | Method of performance-aware security of unicast communication in hybrid satellite networks |
| US8855301B2 (en) * | 2011-08-12 | 2014-10-07 | Cisco Technology, Inc. | Coordinating compression information for unreliable encrypted streams through key establishment protocols |
| WO2013110857A1 (en) * | 2012-01-24 | 2013-08-01 | Ssh Communications Security Oyj | Privileged access auditing |
| US9065856B2 (en) * | 2013-02-01 | 2015-06-23 | Vidder, Inc. | Securing communication over a network using client system authorization and dynamically assigned proxy servers |
| WO2014124300A1 (en) * | 2013-02-07 | 2014-08-14 | Schlage Lock Company Llc | A system and method for nfc peer-to-peer authentication and secure data transfer |
| US9148446B2 (en) * | 2013-05-07 | 2015-09-29 | Imperva, Inc. | Selective modification of encrypted application layer data in a transparent security gateway |
| US10432753B2 (en) * | 2013-08-16 | 2019-10-01 | Fujitsu Limited | Demand response event dissemination system and method |
-
2015
- 2015-07-02 ES ES15382354T patent/ES2828948T3/es active Active
- 2015-07-02 EP EP15382354.7A patent/EP3113443B1/en active Active
-
2016
- 2016-06-01 US US15/740,893 patent/US10742611B2/en active Active
- 2016-06-01 WO PCT/EP2016/062340 patent/WO2017001133A1/en active Application Filing
- 2016-06-01 BR BR112017028270A patent/BR112017028270A2/pt active Search and Examination
Also Published As
| Publication number | Publication date |
|---|---|
| EP3113443B1 (en) | 2020-08-26 |
| WO2017001133A1 (en) | 2017-01-05 |
| US20180198761A1 (en) | 2018-07-12 |
| BR112017028270A2 (pt) | 2018-09-04 |
| US10742611B2 (en) | 2020-08-11 |
| EP3113443A1 (en) | 2017-01-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2828948T3 (es) | Método, sistema y productos de programa informático para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas | |
| US9553892B2 (en) | Selective modification of encrypted application layer data in a transparent security gateway | |
| JP2022023942A (ja) | クライアント－クラウドまたはリモートサーバーの安全なデータまたはファイル・オブジェクト暗号化ゲートウェイ | |
| ES2601505T3 (es) | Identificación de teléfono móvil y autenticación de comunicación | |
| US7584505B2 (en) | Inspected secure communication protocol | |
| US7661131B1 (en) | Authentication of tunneled connections | |
| US9154484B2 (en) | Identity propagation | |
| US8468347B2 (en) | Secure network communications | |
| US11777718B2 (en) | Unification of data flows over network links with different internet protocol (IP) addresses | |
| Zamfir et al. | A security analysis on standard IoT protocols | |
| US10277576B1 (en) | Diameter end-to-end security with a multiway handshake | |
| Cho et al. | Securing ethernet-based optical fronthaul for 5g network | |
| Hall-Andersen et al. | nQUIC: Noise-based QUIC packet protection | |
| Baseri et al. | Navigating quantum security risks in networked environments: A comprehensive study of quantum-safe network protocols | |
| Gokulakrishnan et al. | A survey report on VPN security & its technologies | |
| Niemiec et al. | Authentication in virtual private networks based on quantum key distribution methods | |
| Tanveer et al. | Performance analysis of AES-finalists along with SHS in IPSEC VPN over 1Gbps link | |
| Tennekoon et al. | On the effectiveness of IP-routable entire-packet encryption service over public networks (november 2018) | |
| Eronen et al. | An Extension for EAP-Only Authentication in IKEv2 | |
| Thuc et al. | A Sofware Solution for Defending Against Man-in-the-Middle Attacks on Wlan | |
| Heer et al. | End-host Authentication and Authorization for Middleboxes based on a Cryptographic Namespace | |
| Alhaj | Performance Evaluation of Secure Data Transmission Mechanism (SDTM) for Cloud Outsourced Data and Transmission Layer Security (TLS) | |
| Maalavika et al. | A Review on Garlic Routing and Artificial Intelligence Applications in Public Network | |
| Park | VPN: Privacy and Anonymity for All | |
| WO2015022701A2 (en) | Method and system of routing and handover of secure communication without knowledge of private/secret key |