ES2634024B1 - Método seguro para compartir datos y controlar el acceso a los mismos en la nube - Google Patents

Método seguro para compartir datos y controlar el acceso a los mismos en la nube Download PDF

Info

Publication number
ES2634024B1
ES2634024B1 ES201630357A ES201630357A ES2634024B1 ES 2634024 B1 ES2634024 B1 ES 2634024B1 ES 201630357 A ES201630357 A ES 201630357A ES 201630357 A ES201630357 A ES 201630357A ES 2634024 B1 ES2634024 B1 ES 2634024B1
Authority
ES
Spain
Prior art keywords
data
certificate
partitions
local agent
precedes
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
ES201630357A
Other languages
English (en)
Other versions
ES2634024A1 (es
Inventor
Juan José BERMÚDEZ PÉREZ
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to ES201630357A priority Critical patent/ES2634024B1/es
Priority to US15/465,852 priority patent/US20170279807A1/en
Publication of ES2634024A1 publication Critical patent/ES2634024A1/es
Application granted granted Critical
Publication of ES2634024B1 publication Critical patent/ES2634024B1/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
    • 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
    • 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
    • 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/045—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 hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • 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
    • 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
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity

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)
  • Storage Device Security (AREA)

Abstract

La presente invención tiene por objeto un método de almacenamiento de datos en la nube que permite garantizar la privacidad de dichos datos incluso frente a los administradores de los servidores que conforman la nube, sin que ello impida gestionar de forma práctica y cómoda los permisos de acceso a dichos datos. Dicha garantía se obtiene mediante la encriptación de los datos almacenados y el almacenamiento distribuido y particionado (por ejemplo mediante el método de Shamir) de las claves que permiten desencriptar dichos datos. Al ser implementado dicho método, un atacante que quisiese acceder a los datos de forma no autorizada debería obtener acceso no autorizado a al menos dos servidores distintos, ubicados en lugares físicos distintos y administrados por autoridades distintas.

Description

Descripción
Método seguro para compartir datos y controlar el acceso a los mismos en la nube.
ANTECEDENTES 5
El almacenamiento de datos en la nube 1 es un servicio ampliamente extendido en la actualidad. Individuos y empresas ven en esta opción una manera de abaratar costes y mejorar la movilidad, ya que no han de preocuparse de establecer una infraestructura informática y pueden acceder a los datos desde cualquier dispositivo en cualquier lugar con una conexión a Internet. Adicionalmente, en especial para usos profesionales y de empresa, resulta útil poder compartir dichos archivos con otros usuarios, 10 por lo que ofrecer un sistema de permisos para gestionar el acceso a ellos resulta de gran utilidad (WO 2015069234 A1).
Más recientemente, a los requisitos de disminución de coste y comodidad se ha añadido el de la seguridad. Noticias sobre espionaje informático a grandes compañías, e incluso desde gobiernos, han sensibilizado el mercado en este sentido. Para satisfacer estas nuevas inquietudes, diferentes servicios 15 ofrecen la posibilidad de encriptar la información almacenada en la nube (US 9027108 B2). Generalmente dicha encriptación se hace por medio de una clave simétrica que solo conoce el usuario que trasmite el fichero a almacenar en la nube. Si el usuario quiere que otro usuario tenga acceso a dicho fichero, ha de transmitirle la clave. A parte de los evidentes inconvenientes prácticos de este sistema, existe el problema de la no revocabilidad de los permisos: una vez se ha enviado una clave, el 20 usuario tiene acceso para siempre al fichero. Igualmente, si el dueño del fichero modificase la clave, debería transmitir la nueva clave a todos los usuarios a los que quisiese mantener el permiso. Otro inconveniente de esta opción de seguridad es que la clave está almacenada en un solo punto, y si alguien tuviese acceso ilegítimo al sistema informático que guarda la o las claves, tendría acceso a todos los ficheros. 25
El almacenamiento de ficheros en la nube es en realidad un problema idéntico al de muchos otros servicios en Internet que consisten en almacenar datos en la nube, y proporcionar permisos de acceso a dichos datos. Son, por ejemplo, servicios equivalentes: la mensajería instantánea, la publicación de mensajes en redes sociales o los foros de debate. En todos estos casos hay un usuario que sube una información y otorga permisos sobre ella. Recientemente ha aumentado también la inquietud de los 30 usuarios de este tipo de servicios por la seguridad y privacidad.
El requisito de seguridad y privacidad es a menudo especialmente importante para corporaciones y entidades asociativas organizadas.
Definiciones:
1. La nube. La computación en la nube, conocida también como servicios en la nube, informática en la nube, nube de cómputo o nube de conceptos (del inglés cloud computing), es un paradigma que 5 permite ofrecer servicios de computación a través de una red, que usualmente es Internet.
BREVE DESCRIPCIÓN DE LA INVENCIÓN
La presente invención tiene por objeto un sistema de protección y control de acceso de datos almacenados en una infraestructura informática remota independiente (lo que habitualmente se denomina “la nube”). 10
El sistema consta de un Terminal, entendiendo en la presente invención bajo el concepto de terminal cualquier dispositivo capaz de mostrar en unos medios de visualización el contenido de una página web o contenido digital, incluyendo en consecuencia ordenadores, móviles, ordenadores de mano, portátiles, relojes inteligentes, gafas inteligentes, televisiones digitales, etc.
(a) Un Agente Local (descargable o preinstalado en el terminal) que incorpora las operativas necesarias 15 para interactuar con los servidores en la nube y administrar localmente los datos. Dicho módulo incluye (de forma no exclusiva) operativas de comunicación, operativas de encriptación y certificación de información y operativas de detección de errores. En caso de que el usuario de la herramienta sea un circuito electrónico o computador, dicho Agente de Control Local puede estar integrado en el mismo circuito, formar parte del software del computador, o formar parte de un dispositivo independiente 20 conectado al circuito o computador.
Habrá (b) un (o más) Servidor de Control de Datos que (entre otras funciones) recopila la información suministrada por los terminales, vigila el cumplimiento de las políticas de control de los datos, almacena particiones de las claves de acceso e implementa políticas de seguridad para minimizar los riesgos de pérdida de datos. 25
Habrá (c) un (o más) Servidor de Verificación de Acceso que supervisará las políticas de acceso implementadas por el Servidor de Control de Datos y guardará una o más particiones de las clave de acceso a los datos.
Optativamente puede haber (d) una (o más) red independiente de Servidores de Almacenamiento interconectados, ofreciendo un sistema de almacenamiento virtual en la nube. 30
Las características de la invención hacen que las claves para acceder a cualquier conjunto de datos no estén almacenadas en un único punto o bajo la supervisión de una misma autoridad. La clave para descifrar los datos almacenados se parte mediante un algoritmo de compartición de secretos en varias particiones. Algunas de dichas particiones se almacenan en el Servidor de Control de Datos, otras en el Servidor de Verificación de Acceso, y otras las guarda el usuario que incorpora los datos al sistema. Para 5 recomponer la clave y descifrar los datos serán necesarias un número mínimo determinado de particiones. De esta manera si hay un robo de particiones a alguna de las autoridades, dichas particiones serán inútiles sin tener acceso al número mínimo de particiones necesario para descifrar los datos y que estarán custodiadas por autoridades distintas. Los permisos de acceso a los datos, por lo tanto, serán custodiados de forma criptográficamente segura por varias autoridades (idealmente independientes). 10
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La figura 1a representa un posible flujo de datos desarrollado durante los pasos iii y iv del procedimiento para guardar datos en la descripción detallada de la presente invención.
La figura 1b representa un posible flujo de datos desarrollado entre los pasos viii y xiii del procedimiento para guardar datos en la descripción detallada de la presente invención. 15
La figura 1c representa un posible flujo de datos desarrollado entre los pasos ii y vii del procedimiento para descargar datos en la descripción detallada de la presente invención.
La figura 1d representa un posible flujo de datos desarrollado en el paso ix del procedimiento para descargar datos en la descripción detallada de la presente invención.
EXPLICACIÓN DETALLADA DE LA INVENCIÓN 20
Notación:
TLS. Transport Layer Security (TLS; en español «seguridad de la capa de transporte») y su antecesor Secure Sockets Layer (SSL; en español «capa de conexión segura») son protocolos criptográficos que proporcionan comunicaciones seguras por una red, comúnmente Internet.
Certificado digital. Un certificado digital o certificado electrónico es un fichero informático generado 25 por una entidad de servicios de certificación que asocia unos datos de identidad a una persona física, organismo o empresa confirmando de esta manera su identidad digital en Internet. El certificado digital es válido principalmente para autenticar a un usuario o sitio web en internet por lo que es necesaria la colaboración de un tercero que sea de confianza para cualquiera de las partes que participe en la
comunicación. El nombre asociado a esta entidad de confianza es Autoridad Certificadora pudiendo ser un organismo público o empresa reconocida en Internet.
Token. Cadena de caracteres aleatoria que obtiene un agente de software una vez se ha autentificado con un servidor y que le permite mantener credenciales con dicho servidor sin tener que autentificarse en cada operación. Normalmente el token tiene una validez limitada en el tiempo. 5
Supuestos previos:
- Cada Agente Local dispone de un par de claves asimétricas (una clave pública y una privada).
- Opcionalmente, cada Servidor de Verificación de Acceso puede disponer de un par de claves asimétricas (una pública y una privada).
- Opcionalmente, el servidor de Control de Datos puede disponer de un par de claves asimétricas. 10
- Las claves públicas de todo par de claves asimétricas son conocidas por todos los elementos que intervienen en esta invención, mientras que las claves privadas solo son conocidas por sus propietarios (salvo indicado lo contrario)
- Existe un protocolo, no especificado en esta invención, para asignar distintos permisos a distintos grupos de datos. Por ejemplo, el Agente Local podría usar HTTP para comunicar tanto a 15 Servidor de Control de Datos como a los Servidores de Verificación de Acceso los permisos de cada unidad de datos, los permisos de cada usuario, los permisos de distintos grupos de usuarios, y los grupos a que pertenece cada usuario.
Procedimiento para guardar datos en la nube 20
Los siguientes pasos no necesariamente han de darse en el orden descrito.
(i) El Agente Local genera una clave aleatoria. Dicha clave usualmente corresponderá a la clave para un algoritmo de encriptación simétrico. Habitualmente será una clave para el algoritmo AES o Triple DES, si bien puede ser cualquier clave que se pueda emplear en cualquier algoritmo de encriptación de características similares a estos. 25
(ii) El Agente Local encripta con la clave anterior los datos que el usuario del Terminal quiere enviar a la nube. Dichos datos pueden ser por ejemplo, sin exclusión:
o Un fichero informático
o Un mensaje dentro de una conversación instantánea
o Una publicación en una red social 30
o Un mensaje en un foro
Opcionalmente, en lugar de encriptar directamente los datos, el Agente Local puede generar particiones de los datos, por medio de cualquier algoritmo de compartición de secretos (por ejemplo el de Shamir), para que cada partición sea guardada en un servidor distinto. Por ejemplo podría generar una partición destinada a ser almacenada en el (o los) Servidor de Verificación de Acceso. Dichas particiones estarían encriptadas, igualmente, por la clave anteriormente mencionada. 5
(iii) El Agente Local envía los datos encriptados al Servidor de Control de Datos. Dicha transmisión puede realizarse por cualquier medio, no siendo el método empleado parte de esta invención. Por ejemplo se puede utilizar el protocolo HTTP.
El Servidor de Control de Datos guardará la totalidad o parte de dichos datos en sus propios recursos de almacenamiento o los transferirá a otros Servidores de Almacenamiento para que realicen dicha 10 función.
Opcionalmente, el Servidor de Control de Datos puede enviar parte de dichos datos, o particiones de los mismos, a uno o más servidores de Verificación de Acceso para que los almacenen.
Opcionalmente, el Agente Local puede enviar directamente parte de dichos datos, o particiones de los mismos, a uno o más Servidores de Verificación de Acceso para que los almacenen. 15
Opcionalmente, el Agente Local puede enviar directamente parte de dichos datos, o particiones de los mismos, a uno o más Servidores de Almacenamiento para ser almacenados.
(iv) El Servidor de Control de Datos confirma la recepción al Agente Local. No constituye parte de esta invención el protocolo empleado para dar dicha confirmación ni el formato de dicha confirmación. Típicamente será la respuesta a un comando GET o POST del protocolo HTTP. Típicamente se usará el 20 protocolo TLS para que el Agente Local tenga certeza de que los datos están siendo dirigidos al Servidor de Control de Datos, el cuál usará un certificado digital de dominio.
(v) El Agente Local genera un número determinado de particiones de la clave por medio de un algoritmo de compartición de secretos (por ejemplo el de Shamir), siendo necesarias un determinado número de dichas particiones (a determinar en cada caso) para recomponer la clave. Un caso típico sería aquél en 25 que se generan tres particiones de la clave y son necesarias dos particiones para recomponer la clave.
(vi) El Agente Local encripta por medio de una clave pública perteneciente al Servidor de Verificación de Acceso un número determinado de particiones de la clave con que se encriptaron los datos (Particiones para el Servidor de Verificación de Acceso). En caso de haber más de un Servidor de Verificación de Acceso se repetirá la operación, pudiendo seleccionar distintas particiones para cada servidor y 30 empleando la clave pública de cada servidor. Típicamente habrá un solo Servidor de Verificación de Acceso, para el cuál se seleccionará una de las tres particiones generadas.
(vii) El Agente Local firma mediante un algoritmo de firma digital un certificado (Certificado A) que identifica o contiene los datos enviados al Servidor de Control de Datos y la encriptación de las Particiones para el Servidor de Verificación de Acceso. Por ejemplo, el certificado podría contener una 35
huella digital de los datos, el identificador de la operación solicitada (en este caso guardar un fichero), y la encriptación de la partición correspondiente.
En caso de haber más de un Servidor de Verificación de Acceso y haber distintas particiones de la clave
para cada uno, se generará y firmará un certificado para cada servidor. 5
Alternativamente, en lugar de firmar, el Agente Local podría emplear cualquier otro método disponible en el estado de la técnica para identificarse, por ejemplo incluir en el Certificado A un token temporal que habría adquirido previamente del Servidor de Verificación de Acceso y que cumpliría la misma función de garantizar la identidad del usuario. En este caso, el token sería un identificador secreto obtenido por un canal seguro y que durante un tiempo determinado permitiría al Agente Local 10 identificarse por medio de las credenciales que previamente envió mediante dicho canal seguro. No forma parte de esta invención el método concreto a usar para identificarse.
Opcionalmente, el Agente Local podría encriptar con una clave pública del Servidor de Control de Datos las particiones enviadas a dicho servidor pasa ser almacenadas por este. Asimismo, en dicho caso, el Agente Local podría generar otro Certificado A, destinado en este caso al Servidor de Control de Datos, 15 que incluiría dichas particiones firmadas digitalmente.
(viii) El Agente Local envía al servidor de Control de Datos el (o los) Certificado A y un número determinado de particiones de la clave con que se encriptaron los datos (Particiones para el Servidor de Control de Datos). En un caso típico, se utilizará el protocolo HTTP para dicha transmisión, haciendo uso del protocolo TLS para garantizar la privacidad del mensaje y verificar la identidad de las partes. 20 Típicamente se enviará el Certificado A, el identificador de sesión, e información que indique el destino de los datos. Por ejemplo, si es un fichero informático incluirá (entre otras posibles opciones) el directorio de destino y el nombre del fichero.
Opcionalmente, el Agente Local puede generar un Certificado A también para el Servidor de Control de Datos, que incluirá los datos a recibir por este, y que estará encriptado con la clave pública de dicho 25 servidor y firmado digitalmente por el agente. Dicho certificado puede reemplazar, o no, los datos anteriormente citados, enviados mediante cualquier otro método seguro.
Como se ha indicado, el orden de los pasos de esta invención no necesariamente ha de ser el indicado. Por ejemplo, los pasos v,vi,vii y viii se podrían realizar perfectamente antes que los pasos ii,iii y iv o incluso en paralelo a estos. 30
(ix) El Servidor de Control de Datos verifica que el usuario tiene permisos para realizar la operación y guarda en un registro las Particiones para el Servidor de Control de Datos, asociándolas a los datos en cuestión. Por ejemplo, si es una petición para publicar un mensaje en un foro, verificará que tenga permiso para publicar en dicho foro, o si es una petición para guardar un fichero en un directorio verificará que tenga permiso de escritura en dicho escritorio. 35
(x) El Servidor de Control de Datos envía al Servidor de Verificación de Acceso el Certificado A que incluye encriptadas las Particiones para el Servidor de Verificación de Acceso. En caso de haber más de un Servidor de Verificación de Acceso, se enviará a cada servidor el certificado correspondiente. No forma parte de esta invención el protocolo de comunicación entre servidores, aunque típicamente será el protocolo HTTP junto a TLS para garantizar un canal seguro. 5
En alguna posible implementación de esta invención, El Agente Local enviaría directamente el Certificado A al (o los) Servidor de Verificación de Acceso.
(xi) El Servidor de Verificación de Acceso comprueba que la firma del certificado es correcta y que el usuario que firma tiene permisos para realizar la operación. Alternativamente, si por ejemplo el usuario no ha firmado pero envía un token temporal, el servidor comprobará que dicho token fuese asignado a 10 dicho usuario.
Si todo es correcto, desencripta las particiones de la clave y las guarda con un vínculo a los datos del certificado.
(xii) El Servidor de Verificación de Acceso opcionalmente genera un certificado (Certificado B) que contiene información que identifica la petición hecha por el usuario (incluida en Certificado A), encripta 15 dicho certificado con la clave pública del usuario que firma el Certificado A, y firma el Certificado B con su propia clave privada. Por ejemplo, si la petición consiste en almacenar un fichero en un directorio el certificado podría contener el identificador del fichero, el identificador del directorio, el id de usuario, una huella digital de las particiones y la fecha (no siendo imprescindible ninguno de estos elementos). El fin de dicho Certificado B es confirmar al Agente Local que se ha realizado la operación que este solicitó. 20
Opcionalmente dicho certificado se puede enviar al Agente Local que envió la solicitud o se puede guardar en una base de datos para su posterior consulta.
Opcionalmente se puede enviar al Agente Local que envió la solicitud una confirmación de la misma por cualquier otro medio, sin necesidad de generar un certificado, por ejemplo mediante un canal seguro TLS sobre protocolo HTTP. 25
(xiii) El Servidor de Verificación de Acceso envía al Servidor de Control de Datos el Certificado B encriptado y firmado u opcionalmente una simple confirmación.
Opcionalmente el Servidor de Verificación de Acceso podría haber enviado en el paso anterior dicha confirmación directamente al Agente Local por cualquier otro medio.
(xiv) El Servidor de Control de Datos envía al Agente Local una confirmación de que la operación se ha 30 procesado y opcionalmente el Certificado B obtenido del Servidor de Verificación de Acceso.
(xv) El Agente Local :
a) comprueba que el Servidor de Control de Datos reporte que la operación se haya realizado correctamente, y opcionalmente
b) comprueba que la firma del Certificado B corresponda al Servidor de Verificación de Acceso, desencripta el certificado con su clave privada, y comprueba que el Certificado B indique que el Servidor de Verificación de Acceso apruebe la operación y la confirme. De esta manera el Agente Local tiene certeza de que el Servidor de Verificación de Acceso ha recibido las particiones de la clave y están efectivamente en dicho servidor. Opcionalmente el Agente Local 5 podría haber obtenido dicha verificación por cualquier otro método, por ejemplo mediante un canal seguro TLS con el Servidor de Verificación de Acceso.
Procedimiento para descargar datos de la nube
(i) El Agente Local, opcionalmente, genera un certificado (Certificado C) con los datos de petición de acceso, encripta el certificado con la clave pública del Servidor de Verificación de Acceso, y lo firma con 10 su clave privada. Si por ejemplo el usuario quiere leer un mensaje del muro de una red social, el certificado incluirá el identificador del mensaje.
Opcionalmente, el Agente Local puede generar también un Certificado C para el Servidor de Control de Datos, encriptado con la clave pública de este.
(ii) El Agente Local envía al Servidor de Control de Datos los datos de petición de acceso contenidos en 15 el Certificado C, así como dicho certificado encriptado y firmado.
Opcionalmente, el Agente Local puede enviar el Certificado C directamente al Servidor de Verificación de Acceso por medio de cualquier canal seguro.
(iii) El Servidor de Control de Datos verifica que la operación cumple con los protocolos de acceso y si es así, envía el Certificado C tal como lo ha recibido del Agente Local al Servidor de Verificación de Acceso. 20 Si por ejemplo el usuario está requiriendo el acceso de lectura a una publicación en el muro de una red social, el Servidor de Control de Datos comprobará que el usuario tenga permiso para ver dicha publicación.
Opcionalmente, el Certificado C podría haber sido enviado al Servidor de Verificación de Acceso por cualquier otro medio. 25
Opcionalmente, los datos contenidos en el Certificado C podrían haber sido enviados al Servidor de Verificación de Acceso por cualquier otro medio que garantice la seguridad y privacidad de la información. Por ejemplo mediante una conexión HTTP y un canal seguro mediante TLS.
(iv) El Servidor de Verificación de Acceso desencripta el Certificado C (si es el caso de haberlo recibido encriptado) con su clave privada, comprueba la firma y comprueba que el firmante tenga los permisos 30 necesarios para ejecutar la operación especificada en dicho certificado siguiendo un procedimiento similar al del Servidor de Control de Datos.
(v) Si los datos del certificado son correctos y el usuario tiene los permisos necesarios, obtiene las particiones de la clave necesarias para desencriptar los datos, incluye dichas particiones en un nuevo
certificado (Certificado D), lo encripta con la clave pública del Agente Local, y lo firma con su propia clave privada.
Opcionalmente, los datos del Certificado D pueden ser enviados al Agente Local por medio de cualquier otro tipo de canal seguro. Por ejemplo, si el Agente Local conectó mediante HTTP y TLS directamente con el Servidor de Verificación de Acceso, este puede usar el mismo canal para devolver de forma 5 segura y privada los datos del Certificado D.
(vi) El Servidor de Verificación de Acceso, opcionalmente, envía al Servidor de Control de Datos el Certificado D.
(vii) El Servidor de Control de Datos devuelve al Agente Local las particiones que tiene guardadas para acceder a los datos solicitados, así como, opcionalmente, el Certificado D. Si por ejemplo en el momento 10 de partir la clave se hizo en tres particiones, requiriendo dos particiones para recomponer la clave, el Servidor de Control de Datos aportará una clave y el Servidor de Verificación de Acceso envía otra partición encriptada en el certificado D (o mediante otro canal seguro) para que solo el Agente Local pueda leerla. Esas dos particiones podrán ser suficientes para desencriptar los datos, pero en caso de pérdida de datos de un servidor, el Agente Local del usuario que subió los datos a la nube puede haber 15 almacenado una tercera partición por cualquier otro medio, y dicha partición, junto a la de uno de los dos servidores, permitiría recuperar los datos.
(viii) El Agente Local desencripta el certificado D (si es el caso de haberlo recibido encriptado) con su clave privada y comprueba la firma del Servidor de Verificación de Acceso.
(ix) Si tanto el Servidor de Control de Datos como el Servidor de Verificación de Acceso han dado el visto 20 bueno a la operación y le han proporcionado las particiones necesarias para recomponer la clave y desencriptar los datos, el Agente Local descarga los datos solicitados de la dirección indicada por el Servidor de Control de Datos. Dicha descarga puede ser contra el mismo Servidor de Control de Datos, contra cualquier Servidor de Almacenamiento, o contra el Servidor de Verificación de Acceso. No forma parte de esta invención la manera de almacenar internamente los datos en la nube, pudiéndose 25 emplear cualquier método disponible en el estado de la técnica. Se puede por ejemplo usar el servicio de almacenamiento en la nube de una tercera parte (otra empresa) sin conocer qué arquitectura interna utilizan.
Opcionalmente, los datos almacenados pueden haber sido divididos en particiones por medio de cualquier método de compartición de secretos, y por lo tanto el Agente Local deberá recomponer dichos 30 datos una vez descargados.
(x) El Agente Local recompone la clave con que fueron encriptados los datos a partir de las particiones de la clave enviadas por el Servidor de Control de Datos y el (o los) Servidor de Verificación de Acceso. Como se dijo anteriormente, el orden de estos pasos no necesariamente ha de ser el aquí expuesto. Por
ejemplo, la recomposición de la clave se puede hacer en cualquier momento desde que se tiene acceso a las particiones de la clave. Podría recomponerse antes de descargar los datos o en paralelo.
(xi) El Agente Local desencripta los datos con la clave obtenida. Si por ejemplo, los datos corresponden a un mensaje en una conversación instantánea, el Agente Local puede mostrar el mensaje al usuario en pantalla o por cualquier otro medio. 5

Claims (1)

  1. Reivindicaciones
    1- Un método para compartir de forma segura datos electrónicos en la nube haciendo uso de al menos un Terminal, un (o más) Agente Local, un Servidor de Control de Datos, un (o más) Terminal de Verificación de Acceso, y uno o más Servidores de Almacenamiento de Datos, componiendo dicho método: 5
    (i) El Agente Local genera una clave aleatoria
    (ii) El Agente Local encripta con la clave anterior los datos que el usuario del Terminal quiere enviar a la nube.
    (iii) El Agente Local envía los datos encriptados al Servidor de Control de Datos.
    (iv) El Servidor de Control de Datos confirma la recepción al Agente Local. 10
    (v) El Agente Local genera un número determinado de particiones de la clave por medio de un algoritmo de compartición de secretos (por ejemplo el de Shamir), siendo necesarias un determinado número de dichas particiones para recomponer la clave.
    (vi) El Agente Local encripta por medio de una clave pública perteneciente al Servidor de Verificación de Acceso un número determinado de particiones de la clave con que se 15 encriptaron los datos (Particiones para el Servidor de Verificación). En caso de haber más de un Servidor de Verificación de Acceso se repetirá la operación, pudiendo seleccionar distintas particiones para cada servidor y empleando la clave pública de cada servidor.
    (vii) El Agente Local firma mediante un algoritmo de firma digital un certificado (Certificado A) que identifica o contiene los datos enviados al Servidor de Control de Datos y la encriptación de 20 las Particiones para el Servidor de Verificación de Acceso. En caso de haber más de un Servidor de Verificación de Acceso y haber seleccionado distintas particiones para cada uno, se generará un certificado para cada servidor. Alternativamente, en lugar de firmar, el Agente Local podría enviar un token temporal que habría adquirido previamente del Servidor de Verificación de Acceso y que cumpliría la misma función de garantizar la identidad del usuario. 25
    (viii) El Agente Local envía al servidor de Control de Datos el Certificado A y un número determinado de particiones de la clave con que se encriptaron los datos (Particiones para el Servidor de Control de Datos).
    (ix) El Servidor de Control de Datos verifica que el usuario tiene permisos para realizar la operación y guarda en un registro las Particiones para el Servidor de Control de Datos, 30 asociándolas a los datos en cuestión.
    (x) El Servidor de Control de Datos envía al Servidor de Verificación de Acceso el Certificado A y las Particiones para el Servidor de Verificación de Acceso. En caso de haber más de un Servidor de Verificación de Acceso, se enviará a cada servidor el Certificado correspondiente y las particiones correspondientes. 35
    (xi) El Servidor de Verificación de Acceso comprueba que la firma del certificado es correcta y que el usuario que firma tiene permisos para realizar la operación. Alternativamente, si el usuario no ha firmado pero envía un token temporal, el servidor comprobará que dicho token fuese asignado a dicho usuario. Si todo es correcto, desencripta las particiones y las guarda con un vínculo a los datos del certificado. 5
    (xii) El Servidor de Verificación de Acceso opcionalmente genera un certificado (Certificado B) que contiene información que identifica la petición hecha por el usuario (incluida en Certificado A), encripta dicho certificado con la clave pública del usuario que firma el Certificado A, y firma el Certificado B con su clave privada.
    (xiii) El Servidor de Verificación de Acceso envía al Servidor de Control de Datos el Certificado B 10 encriptado y firmado u opcionalmente una simple confirmación.
    (xiv) El Servidor de Control de Datos envía al Agente Local una confirmación de que la operación se ha procesado y opcionalmente el Certificado B obtenido del Servidor de Verificación de Acceso.
    (xv) El Agente Local : 15
    a) comprueba que el Servidor de Control de Datos reporte que la operación se haya realizado correctamente, y opcionalmente
    b) comprueba que la firma del Certificado B corresponda al Servidor de Verificación de Acceso, desencripta el certificado con su clave privada, y comprueba que el Certificado B indique que el Servidor de Verificación de Acceso apruebe la operación y la confirme. 20
    Los pasos anteriores pueden darse no estrictamente en dicho orden siempre y cuando se satisfaga que:
    o i precede a ii
    o ii precede a iiii
    o iii precede a iv 25
    o i precede a v
    o v precede a vi
    o vi precede a vii
    o vii precede a viii
    o viii precede a ix 30
    o viii precede a x
    o x precede a xi
    o x precede a xii
    o xi y xii preceden a xiii
    o xiii precede a xiv 35
    o xiv precede a xv.
    Cuando el mismo u otro Agente Local quiere acceder a los datos:
    (i) Genera un certificado (Certificado C) con los datos de petición de acceso, encripta el certificado con la clave pública del Servidor de Verificación de Acceso, y lo firma con su clave privada. 5
    (ii) Envía al Servidor de Control de Datos los datos de petición de acceso contenidos en el certificado C, así como dicho certificado encriptado y firmado.
    (iii) El Servidor de Control de Datos verifica que la operación cumple con los protocolos de acceso y si es así, envía el Certificado C tal como lo ha recibido del Agente Local al Servidor de Verificación de Acceso. 10
    (iv) El Servidor de Verificación de Acceso desencripta el Certificado C con su clave privada, comprueba la firma y comprueba que el firmante tenga los permisos necesarios para ejecutar la operación especificada en dicho certificado.
    (v) Si los datos del certificado son correctos y el usuario tiene los permisos necesarios obtiene las particiones de la clave necesarias para desencriptar los datos, incluye dichas particiones en 15 un nuevo certificado (Certificado D), lo encripta con la clave pública del Agente Local, y lo firma con su clave privada.
    (vi) El Servidor de Verificación de Acceso envía al Servidor de Control de Datos el Certificado D.
    (vii) El Servidor de Control de Datos devuelve al Agente Local las particiones que tiene guardadas para acceder a los datos solicitados, así como el Certificado D. 20
    (viii) El Agente Local desencripta el certificado D con su clave privada y comprueba la firma del Servidor de Verificación de Acceso.
    (ix) Si tanto el Servidor de Control de Datos como el Servidor de Verificación de Acceso han dado el visto bueno a la operación y le han proporcionado las particiones necesarias para recomponer la clave y desencriptar los datos, el Agente Local descarga los datos solicitados de la dirección 25 indicada por el Servidor de Control de Datos.
    (x) El Agente Local recompone la clave con que fueron encriptados los datos a partir de las particiones enviadas por el Servidor de Control de Datos y el (o los) Servidor de Verificación de Acceso.
    (xi) El Agente Local desencripta los datos con la clave obtenida. 30
    Los pasos anteriores pueden darse no estrictamente en dicho orden siempre y cuando se satisfaga que:
    o i precede a ii
    o ii precede a iii
    o iii precede a iv 35
    o iv precede a v
    o v precede a vi
    o vi precede a vii
    o vii precede a viii
    o viii precede a ix 5
    o viii precede a x
    o ix y x preceden a xi
    2- Un método para compartir de forma segura datos electrónicos en la nube haciendo uso de al menos un Terminal, un (o más) Agente Local, un Servidor de Control de Datos, un (o más) Terminal de Verificación de Acceso, y uno o más Servidores de Almacenamiento de Datos, 10 componiendo dicho método:
    (i) El Agente Local genera una clave aleatoria
    (ii) El Agente Local encripta con la clave anterior los datos que el usuario del Terminal quiere enviar a la nube.
    (iii) El Agente Local envía los datos encriptados al Servidor de Control de Datos, el cual a su vez 15 puede, o no, enviarlos a uno o más Servidores de Almacenamiento.
    (iv) El Servidor de Control de Datos confirma la recepción al Agente Local.
    (v) El Agente Local genera un número determinado de particiones de la clave por medio de un algoritmo de compartición de secretos (por ejemplo el de Shamir), siendo necesarias un determinado número de dichas particiones para recomponer la clave. 20
    (vi) El Agente Local envía al Servidor de Verificación de Acceso un número determinado de particiones de la clave con que se encriptaron los datos (Particiones para el Servidor de Verificación de Acceso).
    (vii) El Servidor de Verificación de Acceso verifica que el usuario tiene permisos para realizar la operación y guarda en un registro las Particiones para el Servidor de Verificación de Acceso, 25 asociándolas a los datos en cuestión.
    (viii) El Servidor de Verificación de Acceso envía al Agente Local una confirmación de que la operación se ha procesado.
    (ix) El Agente Local envía al servidor de Control de Datos un número determinado de particiones de la clave con que se encriptaron los datos (Particiones para el Servidor de Control de Datos). 30
    (x) El Servidor de Control de Datos verifica que el usuario tiene permisos para realizar la operación y guarda en un registro las Particiones para el Servidor de Control de Datos, asociándolas a los datos en cuestión.
    (xi) El Servidor de Control de Datos envía al Agente Local una confirmación de que la operación se ha procesado. 35
    (xii) El Agente Local :
    a) comprueba que el Servidor de Control de Datos reporte que la operación se haya realizado correctamente, y
    b) comprueba que el Servidor de Verificación de Acceso reporte que la operación se haya realizado correctamente 5
    Los pasos anteriores pueden darse no estrictamente en dicho orden siempre y cuando se satisfaga que:
    o i precede a ii
    o ii precede a iii
    o iii precede a iv 10
    o i precede a v
    o v precede a vi
    o vi precede a vii
    o vii precede a viii
    o v precede a ix 15
    o ix precede a x
    o x precede a xi
    o xi precede a xii
    Cuando el mismo u otro Agente Local quiere acceder a los datos: 20
    (i) Envía al Servidor de Control de Datos los datos de petición de acceso a unos determinados datos almacenados.
    (ii) El Servidor de Control de Datos verifica que la operación cumple con los protocolos de acceso y si es así, devuelve al Agente Local las particiones que permiten, una vez mezcladas con las particiones del Servidor de Verificación de Acceso, generar la clave que a su vez permite 25 desencriptar los datos.
    (iii) El Agente Local envía al Servidor de Verificación de Acceso los datos de petición de acceso a unos determinados datos almacenados.
    (iv) El Servidor de Verificación de Acceso verifica que la operación cumple con los protocolos de acceso y si es así, devuelve al Agente Local las particiones que permiten, una vez mezcladas con 30 las particiones del Control de Datos, generar la clave que a su vez permite desencriptar los datos.
    (v) El Agente Local descarga los datos solicitados de la dirección indicada por el Servidor de Control de Datos.
    (vi) El Agente Local recompone la clave con que fueron encriptados los datos a partir de las particiones enviadas por el Servidor de Control de Datos y el (o los) Servidor de Verificación de Acceso.
    (vii) El Agente Local desencripta los datos con la clave obtenida.
    5
    Los pasos anteriores pueden darse no estrictamente en dicho orden siempre y cuando se satisfaga que:
    o i precede a ii
    o iii precede a iv
    o ii y iv preceden a vi 10
    o v y vi preceden a vii
    3- Método, según la reivindicación 1, caracterizado porque el Agente Local también genera un certificado encriptado y firmado para el Servidor de Control de Datos.
    4- Método, según la reivindicación 1, 2 o 3, caracterizado porque parte de los datos (o la totalidad) los guarda el Servidor de Verificación de Acceso o Servidores de Almacenamiento a los cuales 15 proporciona los datos el Servidor de Verificación de Acceso.
    5- Método, según la reivindicación 1, 2 o 3, caracterizado porque los datos son partidos mediante un algoritmo de compartición de secretos y un subconjunto de particiones de dichos datos es almacenado por el Servidor de Control de Datos y un subconjunto de las mismas es almacenado por el o los Servidores de Verificación de Acceso. Los Servidores de Verificación de Acceso 20 pueden almacenar el mismo subconjunto de particiones cada uno de ellos o un subconjunto distinto cada uno.
    6- Método, según la reivindicación 1,2,3, 4 o 5 caracterizado porque el (o los) Servidor de Verificación de Acceso es también un Agente Local que en ese momento se encuentre conectado a la red. 25
ES201630357A 2016-03-23 2016-03-23 Método seguro para compartir datos y controlar el acceso a los mismos en la nube Active ES2634024B1 (es)

Priority Applications (2)

Application Number Priority Date Filing Date Title
ES201630357A ES2634024B1 (es) 2016-03-23 2016-03-23 Método seguro para compartir datos y controlar el acceso a los mismos en la nube
US15/465,852 US20170279807A1 (en) 2016-03-23 2017-03-22 Safe method to share data and control the access to these in the cloud

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201630357A ES2634024B1 (es) 2016-03-23 2016-03-23 Método seguro para compartir datos y controlar el acceso a los mismos en la nube

Publications (2)

Publication Number Publication Date
ES2634024A1 ES2634024A1 (es) 2017-09-26
ES2634024B1 true ES2634024B1 (es) 2018-07-10

Family

ID=59895591

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201630357A Active ES2634024B1 (es) 2016-03-23 2016-03-23 Método seguro para compartir datos y controlar el acceso a los mismos en la nube

Country Status (2)

Country Link
US (1) US20170279807A1 (es)
ES (1) ES2634024B1 (es)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3920465B1 (en) * 2010-10-08 2023-12-06 Brian Lee Moffat Private data sharing system
CN109361638B (zh) * 2017-12-27 2021-06-15 深圳Tcl新技术有限公司 智能设备控制权限共享的方法、***及存储介质
US12047501B2 (en) * 2018-06-01 2024-07-23 Roland Tegeder System and method for providing an authorised third party with overt ledger secured key escrow access to a secret
US10970712B2 (en) * 2019-03-21 2021-04-06 Capital One Services, Llc Delegated administration of permissions using a contactless card
US11457010B2 (en) * 2019-04-05 2022-09-27 Comcast Cable Communications, Llc Mutual secure communications
US20210111876A1 (en) * 2019-10-11 2021-04-15 Atakama LLC Secure session for decryption
EP3809660A1 (en) * 2019-10-16 2021-04-21 Roche Diabetes Care GmbH Method for operating a medical system, medical system, and security module
CN112333141B (zh) * 2020-09-06 2023-04-18 于奎 基于远程应用的提供互联网Web应用服务的方法、装置及***
CN113556236B (zh) * 2021-08-13 2023-04-07 国网浙江省电力有限公司杭州供电公司 一种基于代理签名的能源数据中台敏感内容委托授权方法
CN115225387B (zh) * 2022-07-21 2023-04-07 广州市华商小额贷款股份有限公司 一种基于大数据的数据安全防篡改方法、***及云平台
CN117118759B (zh) * 2023-10-24 2024-01-30 四川省数字证书认证管理中心有限公司 用户控制服务器端密钥可靠使用的方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9002018B2 (en) * 2006-05-09 2015-04-07 Sync Up Technologies Corporation Encryption key exchange system and method
US8520855B1 (en) * 2009-03-05 2013-08-27 University Of Washington Encapsulation and decapsulation for data disintegration
US9141458B2 (en) * 2011-05-09 2015-09-22 Cleversafe, Inc. Adjusting a data storage address mapping in a maintenance free storage container
WO2012167094A1 (en) * 2011-06-01 2012-12-06 Security First Corp. Systems and methods for secure distributed storage
US9027108B2 (en) * 2012-05-23 2015-05-05 Box, Inc. Systems and methods for secure file portability between mobile applications on a mobile device
US20140331061A1 (en) * 2013-05-02 2014-11-06 Solidfire, Inc Drive level encryption key management in a distributed storage system
US9954684B2 (en) * 2016-02-29 2018-04-24 PreVeil LLC Secure sharing

Also Published As

Publication number Publication date
ES2634024A1 (es) 2017-09-26
US20170279807A1 (en) 2017-09-28

Similar Documents

Publication Publication Date Title
ES2634024B1 (es) Método seguro para compartir datos y controlar el acceso a los mismos en la nube
US10673626B2 (en) Threshold secret share authentication proof and secure blockchain voting with hardware security modules
US11909868B2 (en) Orthogonal access control for groups via multi-hop transform encryption
US8281136B2 (en) Techniques for key distribution for use in encrypted communications
US9609024B2 (en) Method and system for policy based authentication
US8059818B2 (en) Accessing protected data on network storage from multiple devices
CN106104562B (zh) 机密数据安全储存和恢复***及方法
ES2554491T3 (es) Aparatos y método de aplicación de una directiva de ordenador
ES2800295T3 (es) Método de transferencia de datos y dispositivos criptográficos
US11457018B1 (en) Federated messaging
CN104662941B (zh) 用于支持密钥使用的方法、设备和***
ES2659580T3 (es) Procedimiento de comprobación de la preservación de privacidad entre tres partes que se comunican entre sí
US11349659B2 (en) Transmitting an encrypted communication to a user in a second secure communication network
US7412059B1 (en) Public-key encryption system
ES2665887T3 (es) Sistema de datos seguro
Arsenault et al. Securely available credentials-requirements
US10791196B2 (en) Directory lookup for federated messaging with a user from a different secure communication network
JPH10336172A (ja) 電子認証用公開鍵の管理方法
US11368442B2 (en) Receiving an encrypted communication from a user in a second secure communication network
Sinnhofer et al. Patterns to establish a secure communication channel
ES2955478T3 (es) Método de transmisión de una información digital cifrada de extremo a extremo y sistema que implementa dicho método
KR100842014B1 (ko) 다수의 장치로부터 네트워크 저장 장치상의 보호 데이터에대한 접근
Jang et al. Trusted Email protocol: Dealing with privacy concerns from malicious email intermediaries
CN115801376A (zh) 基于pki的密码远程协助方法、***及电子设备
GOPAL et al. Secure Cloud Storage using Decentralized Access Control with Anonymous Authentication

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2634024

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20180710