ES2925190T3 - Esquema de cifrado de multidifusión para plataforma de propiedad de datos - Google Patents

Esquema de cifrado de multidifusión para plataforma de propiedad de datos Download PDF

Info

Publication number
ES2925190T3
ES2925190T3 ES20204830T ES20204830T ES2925190T3 ES 2925190 T3 ES2925190 T3 ES 2925190T3 ES 20204830 T ES20204830 T ES 20204830T ES 20204830 T ES20204830 T ES 20204830T ES 2925190 T3 ES2925190 T3 ES 2925190T3
Authority
ES
Spain
Prior art keywords
cryptographic key
key
data
computer processor
subscribers
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
ES20204830T
Other languages
English (en)
Inventor
Elena Pasquali
Daniele Grazioli
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.)
Ecosteer Srl
Original Assignee
Ecosteer Srl
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 Ecosteer Srl filed Critical Ecosteer Srl
Application granted granted Critical
Publication of ES2925190T3 publication Critical patent/ES2925190T3/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/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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • 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)
    • 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/083—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) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Storage Device Security (AREA)

Abstract

En el presente documento se describen realizaciones para implementar la gestión periódica de claves criptográficas. Una realización incluye un procesador configurado para realizar operaciones que comprenden recibir una primera entrada que asocia un primer conjunto de suscriptores con un primer flujo de datos publicado por el primer dispositivo editor y una primera clave criptográfica. El procesador puede transmitir, al primer dispositivo editor, una primera confirmación, indicando que la primera clave criptográfica está lista para usar, por ejemplo. En algunas realizaciones, el procesador puede liberar la primera clave criptográfica a un primer conjunto de suscriptores, recibir una segunda entrada de un usuario de publicación, asociando un segundo conjunto diferente de suscriptores con el primer flujo de datos, y recibir una segunda clave criptográfica después de un cierto tiempo. periodo de tiempo. El procesador puede además transmitir, al primer dispositivo, una segunda confirmación, indicando que la segunda clave criptográfica está lista para usar, y liberar la segunda clave criptográfica al segundo grupo de suscriptores. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Esquema de cifrado de multidifusión para plataforma de propiedad de datos
Antecedentes
En los últimos años, a medida que la tecnología informática y los sensores de telemetría se han vuelto más eficientes, menos costosos y más extendidos, ha habido una proliferación de datos generados por esta nueva tecnología. Se han observado aumentos similares en el volumen de datos con otros tipos de datos personales, desde redes sociales hasta registros médicos. Dado que los datos recopilados de los individuos y sus dispositivos pueden volverse más personales y abundantes, tales datos también pueden parecer menos privados y, a menudo, están controlados por terceros que recopilan datos personales de muchos individuos para vender e intercambiar estos datos. Los terceros que controlan estos datos están, por lo tanto, en posición de beneficiarse inmensamente, a menudo sin consideración o compensación por la privacidad de los individuos o el control al que los individuos renuncian por los motivos de esta monitorización. Dado el control de terceros sobre la recopilación convencional de datos, los individuos rara vez, si alguna, tienen la oportunidad de elegir o dar su consentimiento para que otros terceros específicos accedan a sus datos.
En el campo actual, no se conocen tecnologías capaces de automatizar el procesamiento de datos para conceder y retirar el consentimiento para acceder a datos personales. Algunos proveedores de cadena de bloques existentes han buscado implementar otros tipos de superposiciones técnicas de privacidad. Por ejemplo, Enigma (enigma.co) se centra en la protección de conjuntos de datos dentro de la cadena de bloques. Como otro ejemplo, el protocolo Ocean es un proyecto que tiene como objetivo desarrollar un protocolo y una red, un ecosistema basado en testigos (token), para incentivar la compartición de datos y servicios, tal como para aplicaciones relacionadas con la IA. Sin embargo, cada uno de estos sistemas existentes tiene inconvenientes considerables. Por ejemplo, tanto Enigma como el protocolo Ocean necesitan repositorios de datos con requisitos de almacenamiento masivo para ciertos casos de uso, estas no son soluciones escalables. Además, Enigma y el protocolo Ocean deben propagar datos a sus proveedores de persistencia antes de llevar a cabo su conversión a testigo y control de acceso, lo que crea una posible vulnerabilidad de seguridad. Enigma y el protocolo Ocean también incorporan sus propias capas de acceso a datos en la mezcla, lo que añade una mayor complejidad a los protocolos de comunicación existentes. Por lo tanto, se hace necesario un enfoque diferente para tener una solución escalable, que cumpla con las normativas de privacidad, para restaurar el control a los individuos. El documento de patente US 2018/254892 A1 también representa la técnica anterior relevante.
Breve descripción de los dibujos
Los dibujos adjuntos se incorporan en el presente documento y forman parte de la memoria descriptiva.
La Figura 1 representa una vista a nivel de calle de un caso de uso dado de diversos dispositivos periféricos en una ciudad inteligente, de acuerdo con algunas realizaciones.
La Figura 2 representa una interfaz que muestra una vista general de un caso de uso dado de diversos dispositivos periféricos en una ciudad inteligente, de acuerdo con algunas realizaciones.
La Figura 3 representa una vista de suscriptor de ejemplo de un flujo de datos particular, en el contexto de la vista general de la Figura 2, de acuerdo con algunas realizaciones.
La Figura 4 representa una vista de suscriptor de ejemplo de información detallada sobre un editor del flujo de datos particular de la Figura 3, de acuerdo con algunas realizaciones.
La Figura 5 representa una vista de editor de ejemplo de suscriptores para un flujo de datos particular, de acuerdo con algunas realizaciones.
La Figura 6 representa una vista de editor desplazada de ejemplo de suscriptores para un flujo de datos particular, de acuerdo con algunas realizaciones.
La Figura 7 representa una acción de editor de ejemplo que revoca el acceso de un suscriptor seleccionado para el flujo de datos particular, de acuerdo con algunas realizaciones.
La Figura 8 representa un resultado de ejemplo de la acción del editor de la Figura 7, habiendo revocado el acceso del suscriptor seleccionado para el flujo de datos particular, de acuerdo con algunas realizaciones.
La Figura 9 representa una cuenta de usuario de ejemplo de un editor dado, de acuerdo con algunas realizaciones. La Figura 10 representa una interfaz de usuario móvil de ejemplo para un editor, de acuerdo con algunas realizaciones.
La Figura 11 representa una interfaz de usuario móvil de ejemplo para que un editor decida si concede o deniega el acceso a un suscriptor solicitante, de acuerdo con algunas realizaciones.
La Figura 12 representa una acción del editor de ejemplo que concede acceso al suscriptor solicitante a través de la interfaz de usuario móvil de la Figura 11, de acuerdo con algunas realizaciones.
La Figura 13 representa un resultado de ejemplo de la acción del editor de la Figura 12, habiendo concedido acceso al suscriptor solicitante, de acuerdo con algunas realizaciones.
La Figura 14 representa una relación entre un propietario de datos (editor) y posibles consumidores de datos, de acuerdo con algunas realizaciones.
La Figura 15 representa una conexión inicial entre un intermediario de terceros y dispositivos perimetrales, que pueden corresponder a uno o más editores, de acuerdo con algunas realizaciones.
La Figura 16 representa el acceso al flujo de datos proporcionado a un número de suscriptores, de acuerdo con algunas realizaciones.
La Figura 17 representa una realización en la que se puede revocar el acceso a datos a un flujo de datos dado para un suscriptor particular, de acuerdo con algunas realizaciones.
La Figura 18 representa una implementación de ejemplo con una caja telemática vehicular, de acuerdo con algunas realizaciones.
La Figura 19 representa una implementación de ejemplo con al menos un proveedor de servicios públicos, de acuerdo con algunas realizaciones.
La Figura 20 representa una implementación de ejemplo de empresa a empresa (B2B) con al menos un proveedor de servicios públicos, de acuerdo con algunas realizaciones.
La Figura 21 representa una implementación de ejemplo con al menos una ciudad inteligente, de acuerdo con algunas realizaciones.
La Figura 22 representa un diagrama de ejemplo de la tecnología utilizada para implementar una red superpuesta, de acuerdo con algunas realizaciones.
La Figura 23 representa una consola de ejemplo de un editor de flujo de datos, de acuerdo con algunas realizaciones.
La Figura 24 muestra un ejemplo que muestra datos cifrados enviados por el editor al intermediario. Los datos pueden cifrarse antes de enviarse al intermediario, de acuerdo con algunas realizaciones.
La Figura 25 representa un registro de ejemplo de un servidor intermediario, de acuerdo con algunas realizaciones. La Figura 26 representa un registro de ejemplo de un nodo de Ethereum que puede usarse para ejecutar un contrato inteligente asociado a un flujo de datos referenciado, de acuerdo con algunas realizaciones.
La Figura 27 representa una consola de ejemplo que ejecuta el programa que implementa un suscriptor, de acuerdo con algunas realizaciones.
La Figura 28 muestra una consola de Ethereum de ejemplo con dos cuentas de propiedad externa (EOA), de acuerdo con algunas realizaciones.
La Figura 29 representa una consola de Ethereum de ejemplo que muestra una dirección del contrato inteligente asociado al flujo de datos, de acuerdo con algunas realizaciones.
La Figura 30 muestra una captura de pantalla de ejemplo de un extremo frontal del editor, de acuerdo con algunas realizaciones.
La Figura 31 muestra una captura de pantalla de ejemplo de un extremo frontal del suscriptor, de acuerdo con algunas realizaciones.
La Figura 32 representa una interfaz de extremo frontal de ejemplo para un editor con un suscriptor listado, de acuerdo con algunas realizaciones.
La Figura 33 muestra una captura de pantalla de ejemplo que muestra un estado de suscriptor correspondiente en el extremo frontal del suscriptor, de acuerdo con algunas realizaciones.
La Figura 34 representa la salida de una consola de ejemplo que ejecuta una implementación del proveedor para el suscriptor, de acuerdo con algunas realizaciones.
La Figura 35 representa un diagrama de flujo de proceso de un sistema que implementa un protocolo para implementar DOP como una red superpuesta usando dispositivos perimetrales aptos, de acuerdo con algunas realizaciones.
La Figura 36 representa un diagrama de flujo de proceso de un sistema que implementa un protocolo para implementar DOP como una red superpuesta usando dispositivos perimetrales restringidos, de acuerdo con algunas realizaciones.
Las Figuras 37A-D representan casos de uso de ejemplo de un sistema DOP, de acuerdo con algunas realizaciones.
Las Figuras 38A-H representan casos de uso de revocación de clave de ejemplo de un sistema DOP, de acuerdo con algunas realizaciones.
Las Figuras 39A-E representan casos de uso de revocación de clave de ejemplo de un sistema DOP, de acuerdo con algunas realizaciones.
La Figura 40 es un diagrama de flujo que ilustra un proceso que implementa algunas de las técnicas mejoradas descritas en el presente documento, de acuerdo con algunas realizaciones.
La Figura 41 es un diagrama de bloques de un sistema informático de ejemplo útil para implementar diversas realizaciones.
En los dibujos, los números de referencia similares generalmente indican elementos idénticos o similares. Adicionalmente, en general, el dígito o dígitos más a la izquierda de un número de referencia identifican el dibujo en el que aparece por primera vez el número de referencia.
Descripción detallada
La presente invención se define en las reivindicaciones independientes. Se definen realizaciones preferidas en las reivindicaciones dependientes.
En el presente documento se proporcionan realizaciones de sistemas, aparatos, dispositivos, métodos y/o productos de programas informáticos (dispositivos o medios de almacenamiento legibles por ordenador no transitorios), y/o combinaciones y subcombinaciones de los mismos, para implementar el cifrado de multidifusión para una plataforma de propiedad de datos.
De acuerdo con las técnicas mejoradas desveladas en el presente documento, los aspectos de la presente divulgación incluyen uno o más aparatos o sistemas para controlar el acceso a flujos de datos y puntos de datos en un flujo de datos dado, sin requerir interacción directa entre un suscriptor y un editor (el originador del flujo de datos), ni con un intermediario opcional o una infraestructura de red que transporte los datos.
Como ejemplo, el propietario o conductor de un vehículo puede decidir quiénes son los suscriptores que tienen acceso a cualquier punto de datos que pueda generar una caja telemática a bordo del vehículo, sin reconfigurar, cambiar el estado o incluso comunicarse de otra manera con la caja telemática, en una realización. Por ejemplo, el propietario o conductor del vehículo puede revocar el acceso a uno o más de los suscriptores previamente concedidos sin cambiar el estado, reconfigurar o comunicarse con la caja telemática. Además, es posible que cualesquiera operaciones de concesión y/o revocación no requieran ningún cambio de estado, reconfiguración o comunicación con el intermediario o la infraestructura de red que pueda estar transportando los puntos de datos y entregándolos a los suscriptores concedidos.
La Figura 1 representa una vista a nivel de calle de un caso de uso dado de diversos dispositivos periféricos en una ciudad inteligente, de acuerdo con algunas realizaciones. Por ejemplo, un dispositivo perimetral puede ser un dispositivo de Internet de las cosas (IoT), que incluye, entre otros, un microcontrolador físico, un sistema informático, un medidor de energía, una caja de telemática vehicular, un sensor ambiental, etc., que además puede incluir diversas formas de conectarse a otros dispositivos, incluso a través del encaminamiento del protocolo de Internet (IP), redes de malla, redes superpuestas, cualquier equivalente o cualquier combinación de los mismos. El hardware para implementar dichas conexiones puede incluir redes cableadas o inalámbricas a través de protocolos estándar o protocolos personalizados (no estándar), cualquier equivalente o una combinación de los mismos.
Un dispositivo perimetral puede incluir al menos un sensor que puede usarse para recopilar puntos de datos específicos. Por ejemplo, un dispositivo perimetral puede incluir un sensor ambiental, un monitor de biotelemetría, un dispositivo de geolocalización, un dispositivo de seguimiento de posición, un dispositivo de contabilidad de inventario, un dispositivo de contador de tráfico, un dispositivo de medición de flujo, cualquier equivalente o una combinación de los mismos. Los dispositivos perimetrales y/o puntos de datos pueden incluir identificadores únicos, tipos de puntos de datos, dispositivos perimetrales, otros dispositivos conectados, etc., otros metadatos relacionados, cualquier equivalente o una combinación de los mismos.
La combinación de dispositivos perimetrales y sensores mostrados en la Figura 1 puede servir para ilustrar un ejemplo no limitante de datos que pueden recopilarse en una infraestructura de ciudad inteligente, descrito más ampliamente con respecto a la Figura 21, por ejemplo. Una ciudad inteligente puede implementarse a cualquier escala, mayor o menor que la mostrada en este punto, como resultado de la implementación de la tecnología y las técnicas mejoradas descritas en el presente documento.
La Figura 2 representa una interfaz 200 que muestra una vista general de un caso de uso dado de diversos dispositivos periféricos en una ciudad inteligente, de acuerdo con algunas realizaciones. En este ejemplo no limitante, un mapa 204 puede cargarse en una aplicación web o aplicación nativa, por ejemplo, para ordenadores de propósito general (PC, quiosco, etc.), dispositivos móviles (por ejemplo, tableta, teléfono inteligente, etc.), superpuesta con indicaciones de dispositivos perimetrales (editores o dispositivos de editor) disponibles en una ubicación dada, correspondientes a ubicaciones específicas en el mapa 204. Se pueden proporcionar objetos, botones u otros manejadores de interfaz seleccionables para que un usuario seleccione un editor o dispositivo de editor determinado, para ver, gestionar o suscribirse al flujo o flujos de datos del editor o dispositivo de editor seleccionados para su publicación.
Adicionalmente, o como alternativa, se pueden proporcionar otros objetos de interfaz, por ejemplo, en un área o barra designada 202. Se puede indicar un perfil de usuario actual 222 en un área separada o adyacente, que puede indicar un saldo de testigos y/u otro símbolo de identificación (por ejemplo, fotografía, avatar, etc.) para una referencia rápida de la cuenta de usuario actual que ha iniciado sesión con la interfaz 200. Como se muestra en el ejemplo no limitante del área o barra designada 202 para otros objetos de interfaz, puede incluirse un indicador de búsqueda (por ejemplo, por palabras clave u otros identificadores) para filtrar los editores, dispositivos de editor o flujos de datos disponibles, etc.
Otros objetos, por ejemplo, los botones 212-216, se pueden proporcionar con consultas de búsqueda predeterminadas u otros criterios de identificación, por ejemplo, para filtrar editores, dispositivos de editores o flujos de datos, basándose en las suscripciones, publicaciones o todos los puntos disponibles de un usuario actual en la vista del mapa 204 dado. Adicionalmente, algunos botones, por ejemplo, los botones 214 y 216, pueden configurarse para permitir otras indicaciones, tales como las insignias 214a y 216a, o indicaciones equivalentes, para mostrar una cantidad actual de flujos de datos suscritos y/o publicados, de acuerdo con algunas realizaciones. Los botones de vista 218 se pueden usar para alternar vistas, que incluyen las vistas de mapa, vistas de lista, vistas de superposición de mapa, cualquier equivalente o cualquier combinación de las mismas, de acuerdo con algunos ejemplos no limitantes.
La Figura 3 representa una vista de suscriptor de ejemplo de un flujo de datos particular, en el contexto de la vista general de la Figura 2, de acuerdo con algunas realizaciones. Como se muestra por el objeto puntero con forma de mano en la Figura 2 (que puede representar como alternativa un toque directo en una pantalla táctil o un panel táctil, por ejemplo), un usuario determinado está seleccionando un sensor de partículas. Después de seleccionar un flujo de datos particular del mapa, se puede proporcionar más información, con opciones adicionales, por ejemplo, para vistas más detalladas e ideas sobre la información disponible.
La Figura 4 representa una vista de suscriptor de ejemplo de información detallada sobre un editor del flujo de datos particular de la Figura 3, de acuerdo con algunas realizaciones. Por ejemplo, cuando un suscriptor selecciona una vista más detallada, por ejemplo, desde un aviso como se muestra en la Figura 3, se puede mostrar otra pantalla con información más detallada. En algunas realizaciones, si un suscriptor aún no se ha suscrito al flujo seleccionado, se puede mostrar un aviso para permitir que el suscriptor se suscriba al flujo. En realizaciones adicionales, la solicitud de un suscriptor para suscribirse a un flujo de datos seleccionado, por ejemplo, a través de un aviso mostrado, puede desencadenar una notificación a un editor correspondiente al flujo de datos seleccionado, para que el editor conceda acceso al suscriptor solicitante. En las Figuras 10-13 más adelante, se muestran ejemplos de una interfaz de editor para manejar solicitudes de suscriptor.
La Figura 5 representa una vista de editor de ejemplo de suscriptores para un flujo de datos particular, de acuerdo con algunas realizaciones. Como se muestra para un editor dado (que ha iniciado sesión), la Figura 5 muestra por lo tanto una vista de ejemplo de una consola de gestión para un flujo de datos dado, que incluye el estado de los suscriptores y las suscripciones, así como los derechos de acceso actuales para cada suscriptor y los objetos de la interfaz para alternar el acceso a la suscripción (conceder/revocar).
La Figura 6 representa una vista de editor desplazada de ejemplo de suscriptores para un flujo de datos particular, de acuerdo con algunas realizaciones. En esta vista, puede mostrarse más información del ejemplo de la Figura 5 en una vista dada. En este caso, siguiendo el ejemplo no limitante de la Figura 5, los diez suscriptores actuales se muestran ahora en la vista desplazada de la Figura 6.
La Figura 7 representa una acción de editor de ejemplo que revoca el acceso de un suscriptor seleccionado para el flujo de datos particular, de acuerdo con algunas realizaciones. En este ejemplo no limitante, el usuario de publicación que ha iniciado sesión desea revocar el acceso a un suscriptor particular ("Mantenimiento de coche R") del flujo de datos seleccionado. Por lo tanto, como se muestra por el objeto puntero con forma de mano en la Figura 7 (que puede representar como alternativa un toque directo en una pantalla táctil o panel táctil, por ejemplo), el usuario de publicación puede presionar un botón en una interfaz gráfica de usuario (o equivalente) para revocar el acceso al flujo de datos seleccionado para el suscriptor en particular.
La Figura 8 representa un resultado de ejemplo de la acción del editor de la Figura 7, habiendo revocado el acceso del suscriptor seleccionado para el flujo de datos particular, de acuerdo con algunas realizaciones. Como se muestra, el único suscriptor cuyo estado ha cambiado era el suscriptor en particular que el usuario de publicación buscaba revocar. Los derechos de acceso de los otros suscriptores se dejan intactos, de acuerdo con los controles de acceso granular. En algunas realizaciones, otros objetos de la interfaz de usuario pueden permitir la selección o anulación de la selección de múltiples suscriptores o de todos los suscriptores, para una mayor facilidad de gestión.
La Figura 9 representa una cuenta de usuario de ejemplo de un editor dado, de acuerdo con algunas realizaciones. Dependiendo de la configuración de las cuentas y/o la infraestructura, se pueden mostrar u ocultar diversos campos. Se puede mostrar un recuento total de suscriptores, así como suscriptores a los que se les concede o no acceso. El recuento de suscriptores puede ser por flujo de datos (dispositivo de publicación) o por cuenta de editor (usuario de publicación), de acuerdo con algunas realizaciones de ejemplo. Se puede proporcionar otra gestión de acceso, por ejemplo, para la autenticación de nombre de usuario y contraseña, autenticación de múltiples factores, otra identificación, etc. También se puede almacenar y mostrar el saldo del testigo, por ejemplo, para enviar y/o recibir pagos por acceso a datos. Los testigos pueden, en algunas realizaciones, corresponder al valor de la criptomoneda y/o pueden intercambiarse fácilmente por otra moneda, bienes, servicios, datos, etc.
La Figura 10 representa una interfaz de usuario móvil de ejemplo para un editor, de acuerdo con algunas realizaciones. De forma similar a las interfaces mostradas en las Figuras 2 y 3 anteriores, se puede mostrar un mapa, así como superposiciones que indican editores seleccionados, dispositivos de editores, flujos de datos, etc. Se puede mostrar una notificación, por ejemplo, una notificación de rótulo, con una cuenta de editor que ha iniciado sesión, indicando que un suscriptor ha solicitó acceso a un flujo de datos indicado, por ejemplo, en el mapa mostrado.
La Figura 11 representa una interfaz de usuario móvil de ejemplo para que un editor decida si concede o deniega el acceso a un suscriptor solicitante, de acuerdo con algunas realizaciones. La pantalla de la Figura 11 puede mostrarse, por ejemplo, en respuesta a la selección o activación de otra manera de una acción vinculada a la notificación de la Figura 10, por ejemplo. En otros casos de uso de ejemplo, la pantalla de la Figura 11 puede visualizarse en respuesta a la selección de un suscriptor o solicitud desde una pantalla similar a la de las Figuras 8 o 9 (adaptada para cualquier dispositivo de visualización dado), de acuerdo con algunas realizaciones.
La Figura 12 representa una acción del editor de ejemplo que concede acceso al suscriptor solicitante a través de la interfaz de usuario móvil de la Figura 11, de acuerdo con algunas realizaciones. El círculo mostrado dentro del recuadro del botón "conceder" de la Figura 12 indica un evento táctil en una pantalla táctil, en esta realización de ejemplo. Sin embargo, puede usarse cualquier otro puntero o gesto de selección, equivalente, o cualquier combinación de los mismos, etc., para activar la aceptación de una opción para conceder acceso a un flujo de datos dado para una solicitud de suscriptor dada. Además, o como alternativa, según otros ejemplos de interfaz de usuario descritos en el presente documento, se puede usar una interfaz de voz o una interfaz háptica para la entrada/salida.
La Figura 13 representa un resultado de ejemplo de la acción del editor de la Figura 12, habiendo concedido acceso al suscriptor solicitante, de acuerdo con algunas realizaciones. En este caso, una pantalla de confirmación indica que se ha concedido acceso al suscriptor solicitante, de acuerdo con la acción de la Figura 12. También se proporciona un objeto de interfaz con una opción para revocar el acceso, en esta realización de ejemplo no limitante. En general, como se describe más adelante, el acceso puede concederse o revocarse arbitrariamente en cualquier momento por un usuario de publicación que sea propietario de los flujos de datos publicados por los dispositivos de publicación del usuario de publicación.
Arquitectura basada en intermediario para compartición de datos
En el campo de la compartición de datos, los proveedores de datos (editores) pueden adoptar una arquitectura abierta centrada en intermediario para proporcionar múltiples aplicaciones y suscriptores con acceso casi instantáneo al mismo flujo de datos. Adicionalmente, o como alternativa, algunas realizaciones también pueden incluir un enfoque orientado a multidifusión.
Un intermediario de datos puede ser un software de terceros que se puede alojar utilizando una infraestructura privada, por ejemplo, en las instalaciones, o alojarse por al menos un tercero, por ejemplo, a través de servicios de nube pública. Los intermediarios pueden estar basados en protocolos de comunicación de código abierto, tales como el transporte de telemetría de cola de mensajes (MQTT), el protocolo avanzado de cola de mensajes (AMQP) o Apache Kafka, por nombrar unos pocos ejemplos no limitantes.
En una realización, al menos un alimentador puede enviar o publicar al menos un flujo de datos a cualquier tipo de intermediario o grupo de multidifusión, por ejemplo. El intermediario puede a continuación difundir el mismo flujo de datos a todas las aplicaciones que son suscriptoras de un flujo de datos particular.
Una arquitectura orientada a la multidifusión o centrada en intermediario de terceros puede proporcionar varios beneficios. Un ejemplo es la capacidad de usar el mismo flujo de datos para diferentes objetivos comerciales, compartiendo el flujo de datos entre diferentes suscriptores y diferentes aplicaciones. Otro ejemplo de beneficio es la independencia entre tales aplicaciones diferentes y la tecnología mejorada descrita en la presente divulgación, ya que se puede acceder a los datos a través de interfaces y protocolos convencionales de código abierto, en algunas realizaciones.
Muchas plataformas comerciales del Internet de las cosas (IoT) adoptan un enfoque centrado en intermediario. Por ejemplo, IoT de Amazon Web Services (AWS) o IoT de Microsoft Azure, entre otros, han implementado servicios de mensajería centrados en intermediario para su uso con aplicaciones IoT. La adopción de la cadena de bloques también ha llevado al surgimiento de una nueva categoría de plataformas, por ejemplo, un mercado de flujo de datos, donde los flujos de datos pueden compartirse y/o venderse a cualquier número de suscriptores.
La posibilidad de compartir flujos de datos en tiempo real a través de mercados, así como a través de plataformas de intermediación tradicionales, tales como las de Google, Microsoft o Amazon, entre otras, pone en primer plano la cuestión de la protección de la propiedad de los datos. Los aspectos de la presente divulgación abordan este problema, tal como se describe adicionalmente en el presente documento.
Plataforma de propiedad de datos (DOP)
La posibilidad de utilizar mercados de flujo de datos para vender datos destaca aún más un problema que siempre ha existido con las plataformas tradicionales de difusión de datos. Por ejemplo, ¿cómo pueden los propietarios de datos controlar el acceso de terceros a sus datos una vez que los han enviado a un intermediario de datos? La tecnología mejorada descrita en el presente documento permite a los editores tener control sobre qué suscriptores pueden acceder a sus flujos de datos a medida que se publican nuevos datos.
Usando las técnicas mejoradas desveladas en el presente documento, una solución puede incluir una capa de control de privacidad de datos. En algunas realizaciones, una capa de control de este tipo puede habilitarse mediante contratos inteligentes o aplicaciones descentralizadas similares en un espacio de cadena de bloques, por ejemplo. Adicionalmente, o como alternativa, se puede usar la gestión de bases de datos tradicionales, en lugar de contratos inteligentes, la cadena de bloques, aplicaciones descentralizadas o tecnología de libro mayor distribuido (DLT), para dar cuenta de las relaciones entre un editor y cualquier suscriptor o suscriptores, por ejemplo. Con aplicaciones descentralizadas basadas en cadena de bloques, contratos inteligentes o cualquier combinación de los mismos, con o sin un intermediario externo particular, un DOP puede ser una infraestructura de confianza cero o sin confianza, que no requiere que ningún editor confíe en ninguna parte determinada, tal como un determinado intermediario, proveedor de plataforma, autoridad de certificación, etc. Un modelo de confianza cero puede mejorar aún más la seguridad de las claves criptográficas.
Como se muestra en la Figura 14, se puede establecer una relación entre un propietario de datos 1402 (editor) y posibles consumidores de datos 1404 (suscriptores) celebrando uno o más contratos inteligentes 1408. El flujo de datos que fluye a través del intermediario puede convertirse en testigos y el propietario de los datos puede decidir el tamaño y el valor del testigo. Esto puede ser en criptomoneda u otra moneda virtual o moneda fiduciaria, otros bienes y/o servicios, o una combinación de los mismos, por ejemplo.
La Figura 15 muestra una conexión inicial entre un intermediario de terceros 1510 y los dispositivos perimetrales 1514a-n, que pueden corresponder a uno o más editores, de acuerdo con algunas realizaciones. El intermediario de terceros 1510 puede ser uno de cualquier número de intermediarios de terceros, por ejemplo. En algunas realizaciones, el intermediario de terceros 1510 puede ser opcional, en una arquitectura o ecosistema más descentralizado, de acuerdo con algunas realizaciones. Como se muestra en la Figura 15, los consumidores de datos 1504 (suscriptores) aún no se han conectado a ningún flujo de datos de los dispositivos perimetrales 1514a-n. Los suscriptores pueden solicitar acceso a un editor determinado, tal como en los ejemplos mostrados en las Figuras 3, 4 y 11, por ejemplo, a través de un intermediario de terceros 1510 u otra arquitectura o ecosistema descentralizado.
Como se muestra en la Figura 16, se puede proporcionar acceso al flujo de datos a cualquier número de suscriptores. Por ejemplo, cuando se ha suscrito un contrato inteligente, el propietario de los datos puede conceder acceso a los datos a uno o más consumidores de datos. En algunas realizaciones, el acceso a los datos puede concederse condicionalmente, por ejemplo, a cambio de testigos (por ejemplo, testigos de criptomonedas en una cadena de bloques) u otros bienes o servicios de valor cuantificable.
La Figura 17 muestra una realización en la que se puede revocar el acceso a datos a un flujo de datos dado para un suscriptor particular. Como se muestra en la Figura 16 anterior, uno de los consumidores de datos 1604 no está pagando testigos por los datos recibidos. Por tanto, el propietario de los datos 1602 puede elegir revocar el acceso a los datos a este suscriptor. Cualquier proveedor (editor) puede revocar el acceso a los datos para cualquier flujo de datos dado a cualquier consumidor de datos (suscriptor), en cualquier momento y por cualquier razón. Por ejemplo, esto puede ocurrir cuando no se ha respetado un contrato inteligente o cuando los datos se han utilizado de forma indebida de otra manera, por ejemplo, en violación de cualquier otro acuerdo.
Los procesos de concesión o revocación de acceso a flujos de datos pueden ser independientes tanto del origen de los datos técnicos como de cualquier capa de presentación de datos, por ejemplo, un intermediario de terceros, en algunas realizaciones. Un origen de datos técnicos de este tipo se muestra como un alimentador 1412, 1512, 1612 y 1712, en las realizaciones de ejemplo de las Figuras 14-17, respectivamente, pero un origen de datos técnicos también puede incluir conexiones directas a dispositivos perimetrales 1414a-n, 1514a-n, 1614a-n y 1714a-n, dispositivos perimetrales 1414a-n, 1514a-n, 1614a-n, y 1714an, ellos mismos y/o cualquier sensor o dispositivo de telemetría a bordo de cualquiera de los dispositivos perimetrales 1414a-n, 1514a-n, 1614a-n y 1714a-n, por ejemplo.
En el mundo conectado de hoy en día, la tecnología mejorada de la presente divulgación se puede utilizar en innumerables escenarios, a través de todos los sectores de la industria, dispositivos móviles personales, dispositivos llevables, hogares y vehículos, así como en ciudades inteligentes, por proporcionar algunos ejemplos no limitantes.
Como se demuestra en la Figura 18, un conductor o propietario de un vehículo puede tener la libertad de elegir y cambiar su aseguradora, además de elegir si desea compartir sus datos desde una caja telemática vehicular a bordo (por ejemplo, velocidad del coche en tiempo real, aceleración, posición, eficiencia de combustible, niveles de contaminación, etc.) con otros suscriptores, por ejemplo, su empleador, autoridades municipales, empresas de mantenimiento de carreteras. De esta manera, tal compartición de datos puede llevarse a cabo en total conformidad con el Reglamento General de Protección de Datos (GDPR) de la Unión Europea y el Espacio Económico Europeo, y otras regulaciones similares destinadas a proteger la privacidad de las personas, por ejemplo.
Como se demuestra en la Figura 19, la DOP, utilizando la tecnología mejorada descrita en el presente documento, puede interrumpir los modelos comerciales tradicionales que vinculan una fuente de datos, por ejemplo, un medidor de energía, a una sola aplicación y suscriptor, por ejemplo, un proveedor de servicios públicos. Un ejemplo incluye el desacoplamiento de medidores y proveedores de servicios públicos, lo que permite a los consumidores de servicios públicos (como editores de datos) tener más control sobre la elección y el cambio de proveedores de servicios públicos (como suscriptores de datos). Adicionalmente, o como alternativa, los editores de datos pueden tener opciones para monetizar sus datos y/o elegir qué suscriptores podrán acceder a sus datos, en algunas realizaciones.
Como se muestra en la Figura 20, la tecnología mejorada como se describe en la presente divulgación también puede encontrar aplicaciones en escenarios B2B. Por ejemplo, las energías renovables son un sector que puede implicar a muchos suscriptores, desde proveedores de seguros hasta autoridades gubernamentales. Estos suscriptores pueden requerir los mismos datos, pero para diferentes objetivos, que van desde la contabilidad hasta la gestión de redes inteligentes y/o las normas ambientales o de seguridad.
Tradicionalmente, cada suscriptor puede instalar sus propios medidores y sensores, los cuales, a su vez, pueden enviar datos a su propia aplicación vertical. En contraste, una arquitectura centrada en intermediario, tal como la que se desvela en el presente documento, donde los propietarios de datos pueden compartir flujos de datos con todos los suscriptores a cambio de servicios o dinero en efectivo, puede generar mejoras significativas en coste, eficiencia y conveniencia para todas las partes implicadas. Por lo tanto, como se demuestra en la Figura 20, al monetizar los flujos de datos y controlar su acceso, la tecnología mejorada de la presente divulgación, incluyendo la DOP, puede aprovecharse para permitir que las instituciones, las empresas y los individuos tengan control sobre los datos que generan y reciban una compensación justa en un marco abierto por tales datos.
Como se muestra en la Figura 21, en un ejemplo, una plataforma de ciudad inteligente reúne varios escenarios comerciales potenciales en una infraestructura abierta y descentralizada. Una ciudad puede financiar el desarrollo de un portal de ciudad inteligente, donde los ciudadanos, las empresas y las instituciones podrán publicar y monetizar los flujos de datos generados por sus dispositivos, mientras mantienen un control total sobre el acceso a los datos, como resultado de la DOP.
Al permitir que los flujos de datos del dispositivo se conviertan en testigos y se compartan con los suscriptores de una manera controlada, los alimentadores, por ejemplo, 1412, 1512, 1612 y 1712, pueden iniciar un ciclo comercial, en las realizaciones de ejemplo mostradas en las Figuras 14-17, respectivamente.
Sin embargo, los alimentadores pueden ser independientes de la DOP. En otras palabras, los alimentadores pueden aplicarse a flujos de datos generados por cualquier tecnología. Además, los alimentadores pueden ser independientes de la plataforma que transporta los datos. En otras palabras, los alimentadores se pueden usar con cualquier intermediario de datos, así como con cualquier mercado de flujos de datos. Por estas razones, la presente divulgación puede proporcionar una superposición de tecnología de privacidad universal, que cumple con las regulaciones de privacidad de datos tales como el RGPD, lo que incluye permitir que una parte que controla cualquier plataforma o intermediario de compartición de flujo de datos "demuestre que un sujeto de datos ha dado su consentimiento para el procesamiento de sus datos personales", así como que "el sujeto de datos tendrá derecho a retirar su consentimiento en cualquier momento" y que, para cualquier sujeto de datos (editor), es "tan fácil retirarlo como dar su consentimiento", todo como lo exige actualmente el RGPD.
La tecnología mejorada de la presente divulgación, si bien es compatible con las soluciones orientadas a bases de datos existentes, puede aprovechar adicionalmente o como alternativa la tecnología de contratos inteligentes basada en cadenas de bloques para implementar una capa de control de acceso a datos que puede usarse para regular la compartición de flujos de datos para instituciones, empresas e individuos, de acuerdo con algunas realizaciones.
Ventajas sobre la tecnología relacionada
En comparación con otras tecnologías relevantes en el espacio de la cadena de bloques, la tecnología mejorada de la presente divulgación proporciona, entre otros beneficios, varios factores tecnológicos diferenciadores:
La tecnología mejorada de la presente divulgación puede controlar el acceso a los flujos de datos, no a los conjuntos de datos. Esto elimina la necesidad de almacenamiento de plataforma y repositorios de datos, que es un requisito sustancial tanto para Enigma como para el protocolo Ocean, lo que hace que la tecnología mejorada de la presente divulgación sea una tecnología más ágil y escalable. Reducir o eliminar los requisitos de almacenamiento puede mejorar aún más el rendimiento al reducir la sobrecarga de memoria para gestionar el almacenamiento y puede reducir o eliminar los costes de alquiler u operación de la infraestructura de almacenamiento.
La tecnología mejorada de la presente divulgación convierte en testigos los flujos de datos a medida que fluyen desde su fuente técnica, mientras que tanto Enigma como el protocolo Ocean deben propagar los datos a sus proveedores de persistencia antes de la conversión a testigos y el control de acceso, lo que crea una posible vulnerabilidad de seguridad.
La tecnología mejorada de la presente divulgación controla el acceso a los flujos de datos independientemente de la capa de transporte de datos, mientras que tanto Enigma como el protocolo Ocean proporcionan su propia capa de acceso a datos. Añadir capas de abstracción únicas y personalizadas de esta manera puede plantear riesgos para la seguridad y la pérdida de datos, mientras que controlar el acceso a los flujos de datos independientemente de la capa de transporte de datos puede proporcionar, en su lugar, un sistema más robusto con menos vulnerabilidades y una superficie de ataque más pequeña.
Dentro del alcance de la presente divulgación, no existe un requisito específico para ningún recurso o componente centralizado o compartido que pueda tener alguna responsabilidad para calcular cualquier clave de grupo. En su lugar, en algunas realizaciones, pueden calcularse o producirse las claves criptográficas por los emisores, por ejemplo, dispositivos de publicación como orígenes técnicos de flujos de datos. Puede haber varios beneficios para este enfoque. Por un lado, los emisores pueden evitar ser también receptores, lo que puede mejorar especialmente la seguridad y el rendimiento para escenarios de loT, por ejemplo. Si los emisores también tienen que ser receptores (agentes que esperan el tráfico entrante), entonces puede que no sea posible adoptar un paradigma sólido de solo inserción (diodo de datos) desde el perímetro hasta la nube. Por lo tanto, en contraste a ciertos métodos existentes, tales como el presentado en la Patente de Estados Unidos N.° 5.748.736 ("System and Method for Secure Group Communications via Multicast or Broadcast" emitido el 5 de mayo de 1998), la tecnología mejorada de la presente divulgación puede permitir implementación de cifrado de multidifusión incluso en presencia de diodos de datos en el perímetro.
Adicionalmente, enviar una transmisión de multidifusión que contenga una nueva clave cifrada usando una clave anterior al grupo de multidifusión actual y decirles que ahora usen la nueva clave puede implicar una alta calidad de servicio del canal utilizado para difundir la nueva clave. En este escenario, uno o más miembros del grupo de multidifusión pueden no recibir el mensaje que contiene la nueva clave, lo que, por lo tanto, puede ser problemático.
Droplet (haciendo referencia a Shafagh et al., "Droplet: Decentralized Authorization for IoT Data Streams, "arXiv:1806.02057v1 (6 de junio de 2018)) describe un enfoque diferente de Enigma o el protocolo Ocean, donde "un servicio de control de acceso a datos descentralizado" puede "operar sin entidades de confianza intermedias". Sin embargo, este enfoque, como se describe en su documento de 2018, también se basa en el almacenamiento en línea de los datos generados por los editores, aunque Droplet puede ser independiente del tipo de almacenamiento (por ejemplo, almacenamiento P2P, almacenamiento en las instalaciones, almacenamiento basado en la nube, etc.). El modelo de datos de Droplet incluye flujos continuos de datos de series temporales almacenados en fragmentos durante intervalos definidos (por ejemplo, "Droplet" en la página 8), pero, requiere de esta manera un aprovisionamiento de almacenamiento potencialmente grande.
En contraste, a diferencia de cualquiera de los enfoques anteriores de Enigma, el protocolo Ocean o Droplet, la tecnología mejorada de la presente divulgación no tiene un requisito específico para ninguna calidad de servicio (QoS) particular, que de otro modo podría ser necesario para mantener los costes manejables en gran despliegue de IoT utilizando tecnología anterior. En algunos casos, cuando la confiabilidad es lo suficientemente necesaria como para que la pérdida de cualquier mensaje sea un fallo crítico, requerir tal QoS puede hacer que los sistemas IoT convencionales queden inutilizables, mientras que la tecnología mejorada de la presente divulgación no tiene tales requisitos o limitaciones. En comparación con Droplet, Enigma y el protocolo Ocean, la tecnología mejorada desvelada en el presente documento, en su lugar, puede reducir o eliminar los requisitos de almacenamiento, lo que reduce significativamente los gastos generales de aprovisionamiento y gestión del almacenamiento de datos para cargas útiles cifradas, en las que se basan los sistemas anteriores.
Además, como se demuestra en el diagrama de ejemplo de la Figura 22, la tecnología mejorada de la presente divulgación puede usarse para implementar una red superpuesta, que a su vez puede permitir el uso de varios protocolos de transporte subyacentes diferentes al encapsular paquetes específicos de DOP en paquetes de cualquier protocolo de transporte subyacente.
En general, cualquier red superpuesta puede requerir componentes perimetrales dedicados al encapsulado y desencapsulado de los paquetes que atraviesan la superposición. Puede ser necesario un tercer componente para establecer una fuerte relación entre los suscriptores que producen información y los suscriptores que consumen información. Este tercer componente puede ser responsable de la gestión de la propiedad y de la conversión en testigos de la información.
La red superpuesta de la presente divulgación puede encajar muy bien con diversas topologías de interconexión de red diferentes. Por lo tanto, la red superpuesta se puede usar con un enfoque en topologías centradas en intermediario, aunque la red superpuesta no se limita solo a ese caso de uso. Como las topologías centradas en intermediario pueden ser más adecuadas para la economía de compartición de datos, las topologías centradas en intermediario pueden proporcionar una definición sólida de editor (productor/vendedor) y suscriptor (consumidor/comprador), pero pueden implementarse a través de cualquier red orientada a multidifusión.
Un aspecto de la presente divulgación es la escalabilidad horizontal. La arquitectura desvelada en el presente documento puede lograr escalabilidad horizontal mediante descentralización y distribución. Una implementación del componente responsable de la mediación entre los editores y los suscriptores puede, en algunas realizaciones, basarse en contratos inteligentes, por ejemplo, a través de cadenas de bloques Ethereum o Hyperledger, por nombrar algunos ejemplos no limitantes, mientras que la carga de trabajo dedicada al encapsulado y el desencapsulado de paquetes se distribuye a través de editores y suscriptores. Por lo tanto, se puede lograr una relación lineal entre la carga de trabajo y la capacidad del sistema. La carga de trabajo de encapsulación puede no depender necesariamente del número de suscriptores. La tecnología de cadena de bloques puede permitir la descentralización; en otras palabras, la tecnología cadena de bloques puede proporcionar un medio técnico para controlar la propiedad sin delegar tal control a ningún tercero.
Dado que la tecnología mejorada de la presente divulgación puede implementarse como una red superpuesta, puede implementarse por encima de varios protocolos diferentes disponibles. La capacidad de usar un protocolo principal probado puede permitir la implementación de cualquier DOP o red superpuesta relacionada que pueda ser necesaria en el campo.
Hasta la fecha, la selección de un protocolo específico puede estar impulsada por los siguientes factores: escalabilidad, disponibilidad de enlace de idiomas, disponibilidad y capacidades de encaminamiento de mensajes. Los siguientes protocolos/implementaciones podrían exponer un buen ajuste: MQTT, NATS, Kafka, DSS, Solace, etc. Algunos de ellos, como MQTT, pueden estar obsoletos, mientras que otros, como Kafka y NATS, pueden ofrecer más oportunidades para crear ecosistemas amplios para compartir flujos de datos.
Las capacidades de encaminamiento de mensajes se pueden considerar cuando se selecciona una infraestructura orientada a intermediario para mercados de flujos de datos, por ejemplo. Se puede tener especialmente en cuenta la flexibilidad con la que se pueden encaminar los mensajes de los editores a los suscriptores, junto con la evaluación de otros temas relacionados, tales como el orden temporal y diversos niveles de filtrado.
También puede haber algunas infraestructuras orientadas a intermediario que cumplan con los requisitos de algunos mercados de datos, lo que puede crear la necesidad de formas de establecer relaciones sólidas entre los nodos de la cadena de bloques (por ejemplo, Ethereum, Hyperledger y/u otras plataformas de libro mayor distribuido, etc.) e implementar los nodos que implementan una agrupación, sin importar el tamaño, la infraestructura centrada en intermediario. Una consideración de la descentralización puede ser evitar cualquier componente centralizado de "guardián del zoológico". Incluso un componente centralizado, tal como este, puede volver a implementarse utilizando un libro mayor descentralizado. Sin embargo, un modelo de prueba de participación puede implicar algún nivel de centralización, y tal nivel también puede encajar con un mercado de flujos de datos, de acuerdo con algunas realizaciones.
Si bien no limita ningún requisito mínimo o máximo, la presente divulgación proporciona al menos los siguientes componentes de un ejemplo de implementación de DOP, de acuerdo con algunas realizaciones:
• Uno o más editores: los editores pueden ser propietarios de datos que poseen dispositivos perimetrales (y elementos adjuntos a los mismos) que originan las cargas útiles del flujo de datos.
• Intermediario: los editores pueden enviar sus flujos de datos al menos a un intermediario. Un intermediario puede ser un componente de software convencional de terceros, por ejemplo.
• Uno o más suscriptores: los suscriptores son partes interesadas en acceder a los flujos de datos. Los suscriptores se suscriben a un flujo de datos a través del intermediario.
• La plataforma cadena de bloques: los suscriptores solo pueden acceder a los flujos de datos que atraviesan el intermediario suscribiéndose a un contrato inteligente implementado por la plataforma de cadena de bloques, de acuerdo con algunas realizaciones. Una vez que un suscriptor individual se ha suscrito a un contrato inteligente, el editor puede recibir una notificación y decide si concede al suscriptor acceso a un flujo de datos. La plataforma de cadena de bloques puede ser al menos parte de un componente de software de terceros, por ejemplo. La plataforma de cadena de bloques puede hacer referencia tanto a los editores como a los suscriptores como cuentas de propiedad externa, y cualquier cadena de bloques correspondiente puede no tener permiso y/o estar descentralizada.
La Figura 23 muestra una consola de ejemplo de un editor de flujo de datos. El editor envía flujos de datos al intermediario de terceros. Los datos enviados al intermediario de terceros pueden estar cifrados y pueden ser visibles como datos descifrados solo por los suscriptores del intermediario a quienes el editor les ha concedido acceso a los datos. Los registros mostrados en la Figura 23 pueden descifrarse para que solo puedan ser visibles para un suscriptor al que el editor le haya concedido acceso al flujo de datos. Los registros de datos pueden ser sintéticos. Pueden contener una marca de tiempo variable y una cadena fija, en algunas realizaciones.
El proveedor de presentaciones del editor puede comunicarse con un intermediario de terceros y una plataforma de cadena de bloques que implementa el contrato inteligente asociado al flujo de datos a través de un servidor de intermediario
Un intermediario de terceros puede usar NATS para mensajería, aunque la divulgación no se limita a NATS. Se puede usar cualquier otra tecnología equivalente, como se describe en otra parte del presente documento y que eventualmente reemplace a NATS y soluciones similares en el futuro. Se puede usar Ethereum u otra plataforma como una plataforma de cadena de bloques, por ejemplo, que admita contratos inteligentes y aplicaciones descentralizadas, por ejemplo, pero se puede usar cualquier otra plataforma de cadena de bloques que admita características similares (por ejemplo, Hyperledger) o una solución que no sea de cadena de bloques (por ejemplo, una base de datos), en algunas realizaciones.
La Figura 24 muestra los datos cifrados enviados por el editor al intermediario. Los datos pueden cifrarse antes de enviarse al intermediario. El proveedor de presentaciones del editor puede comunicarse con la plataforma de la cadena de bloques a través de un servidor de intermediario.
La Figura 25 muestra un registro de ejemplo de un servidor de intermediario. Un servidor de intermediario de un ejemplo puede permitir la interacción entre el editor y la plataforma de cadena de bloques que ejecuta los contratos inteligentes asociados a los flujos de datos.
La Figura 26 muestra un registro de ejemplo de un nodo Ethereum que puede usarse para ejecutar un contrato inteligente asociado a un flujo de datos referenciado, de acuerdo con algunas realizaciones.
La Figura 27 muestra una consola de ejemplo que ejecuta el programa que implementa un suscriptor. El suscriptor puede comunicarse con un servicio de extremo trasero, por ejemplo, a través de un proveedor de presentación u otra interfaz. Para acceder al flujo de datos, puede ser necesario que el suscriptor complete varias acciones separadas, tal como suscribirse a un flujo de datos específico a través del intermediario o suscribirse al contrato inteligente asociado al flujo de datos.
En una realización, el suscriptor puede suscribirse al intermediario, pero no al contrato inteligente. El suscriptor puede acceder a nuevos paquetes de datos del flujo, que aún pueden estar cifrados y, por lo tanto, son ilegibles para el suscriptor que, por lo tanto, no tiene acceso a las últimas claves.
Otra realización de la divulgación puede incluir al menos los siguientes elementos: un contrato inteligente ejecutado por uno o más nodos de cadena de bloques, como se muestra en la Figura 26, o un servidor de intermediario que permite la interacción entre el editor y la plataforma cadena de bloques, como en las Figuras 35 y/o 36.
Se pueden crear cuentas de propiedad externa (EOA) (por ejemplo, un editor y varios suscriptores) dentro de la plataforma Ethereum, junto con un contrato inteligente que convierte en testigos un flujo de datos, de acuerdo con una realización.
La Figura 28 muestra un ejemplo de consola Ethereum con dos EOA. En esta realización, la EOA 'ele' es el editor que posee el flujo de datos y la EOA 'graz' es el suscriptor que busca acceder al flujo de datos, por ejemplo.
En la Figura 29, una consola Ethereum de ejemplo muestra la dirección del contrato inteligente asociado al flujo de datos. Estas direcciones se pueden usar en el extremo frontal del prototipo (interfaces de usuario) para el control de acceso al flujo de datos.
La Figura 30 muestra un ejemplo de extremo frontal para una interfaz de gestión del editor. La interfaz de la Figura 30 puede ser un extremo frontal basado en web, por ejemplo. Esta interfaz puede permitir que el editor mantenga la visibilidad sobre cualquiera o todos los suscriptores (que pueden representarse como las EOA), por ejemplo, y también puede iniciar un ciclo de facturación, de acuerdo con algunas realizaciones. En una realización, esta operación puede ejecutarse automáticamente por el extremo trasero. Todavía no hay suscriptores, como se muestra en la Figura 30.
La Figura 31 muestra una captura de pantalla de ejemplo de una interfaz de gestión de extremo frontal del suscriptor, que puede permitirle al suscriptor solicitar acceso o suscribirse a un flujo de datos, renunciar al acceso o cancelar la suscripción al flujo de datos, o depositar testigos si el acceso al flujo de datos tiene un coste asociado a él, de acuerdo con algunas realizaciones de ejemplo. Esta interfaz de la Figura 31 puede ser un extremo frontal basado en web, por ejemplo.
La Figura 32 muestra un ejemplo de haber agregado un suscriptor. La interfaz también puede utilizarse por un editor para conceder y revocar el acceso al flujo de datos a cualquier suscriptor dado, en cualquier momento y por cualquier motivo. Aquí, la EOA del editor corresponde a la dirección "ele" y la dirección del producto corresponde a "dop.address", como se analizó anteriormente. Como se muestra en la Figura 30 anterior, no había suscriptores. En la Figura 32, la captura de pantalla del extremo frontal del editor muestra un suscriptor al que se le ha concedido acceso al flujo de datos y tiene un saldo de crédito positivo (por ejemplo, 5.000.000 testigos).
En la Figura 33, una captura de pantalla de ejemplo muestra un estado de suscriptor correspondiente en el extremo frontal del suscriptor a través de los campos Suscripción, Concedido y Crédito, por nombrar unos pocos ejemplos no limitantes.
La Figura 34 muestra el resultado de una consola de ejemplo que ejecuta una implementación de un proveedor de presentación para el suscriptor, ahora con acceso a las cargas útiles del editor. En el ejemplo, el editor ahora ha concedido acceso al flujo de datos a este suscriptor, y la información en el flujo de datos ahora se puede descifrar en el futuro. De acuerdo con algunas realizaciones, la información mostrada se puede mostrar ahora de la misma manera que la mostrada por el editor, como se describió anteriormente, por ejemplo, como en la Figura 23.
Protocolo que emplea cifrado de multidifusión de extremo a extremo
La Figura 35 muestra un diagrama de flujo de proceso de un sistema que implementa un protocolo para implementar DOP como una red superpuesta utilizando dispositivos perimetrales aptos, por ejemplo, en los que los dispositivos perimetrales incluyen hardware y software aptos para generar claves criptográficas. En una realización, en 3570, el dispositivo perimetral 3510, a una frecuencia dada (por ejemplo, después de un tiempo predeterminado y ciertos intervalos), puede calcular una nueva clave. A continuación, la nueva clave puede enviarse 3512 al intermediario 3520.
El intermediario 3520, a continuación, puede reenviar o almacenar 3522 la nueva clave en la plataforma de cadena de bloques, utilizando una interfaz de contrato inteligente 3530, de acuerdo con algunas realizaciones. Adicionalmente, o como alternativa, un paquete que contiene la solicitud de una nueva clave también puede contener un número entero que representa el número de bytes que se han cifrado hasta ese punto. Este número entero puede almacenarse en un contrato inteligente u otro medio de almacenamiento y puede permitir, por ejemplo, modelos de calificación basados en el volumen de datos.
El dispositivo perimetral 3510 puede, en 3572, repetir la solicitud de si la nueva clave ha sido almacenada y si está lista para usarse. En una realización de ejemplo, en la que el dispositivo perimetral 3510 puede implementarse como un diodo de datos (sin tráfico de carga útil de flujo de datos entrante, solo emitiendo datos), dicha repetición de solicitudes puede mejorar la fiabilidad de los sistemas en su conjunto, en ausencia de otra comunicación síncrona entre nodos. En algunas realizaciones, en 3572, el dispositivo perimetral 3510 puede solicitar si una clave criptográfica está lista para su uso (por ejemplo, usando la solicitud 3514 de CLAVE LISTA), tal como verificar directamente un contrato inteligente 3530 o mediante un intermediario 3520, para comprobar o consultar de otra manera un estado del contrato inteligente 3530. Adicionalmente, o como alternativa, se puede usar una base de datos que admita consultas sobre el estado de la clave en lugar o junto con el contrato inteligente 3530.
Una vez que se ha almacenado la nueva clave y puede estar lista para utilizarse, el dispositivo perimetral 3510 recibe un mensaje 3516 de CLAVE LISTA del intermediario 3520. Cuando el dispositivo perimetral 3510 sabe que la nueva clave está lista, el dispositivo perimetral 3510 puede enviar un mensaje fuera de banda al intermediario 3550 que indica "estate listo, va a utilizarse una nueva clave en breve", de acuerdo con algunas realizaciones. Un ejemplo de caso de uso puede permitir, por medio del mensaje CLAVE LISTA, que las cargas de trabajo causadas por múltiples suscriptores se distribuyan por un factor de tiempo T, donde T puede ser una cantidad de tiempo que transcurre entre el anuncio del mensaje CLAVE LISTA y uso real de la nueva clave. Como resultado, este mensaje fuera de banda (CLAVE LISTA) puede facilitar la escalabilidad horizontal y puede aumentar la calidad del servicio. Además, en una realización, donde las claves criptográficas y/o los anuncios de CLAVE LISTA se envían por separado del canal o los paquetes que contienen la carga útil cifrada, a continuación, las claves pueden entregarse a los suscriptores con éxito incluso cuando el canal de carga útil tiene una baja calidad de servicio, por ejemplo. Sin embargo, un mensaje de este tipo como en 3574, o incluso un intermediario 3550, puede no ser necesario en todos los casos de uso sin el anuncio, los suscriptores que tienen acceso a las nuevas claves pueden adquirir cada nueva clave en o cerca de intervalos de tiempo predeterminados (por ejemplo, establecidos por una frecuencia configurable) para la gestión periódica de claves criptográficas.
En 3562, el suscriptor 3560 puede solicitar al intermediario 3540 la nueva clave (solicitud 3542 de OBTENER CLAVE), que puede almacenarse, pero no estar en uso todavía, por ejemplo, comprobando el contrato inteligente 3530 (solicitud 3532 de OBTENER CLAVE). La nueva clave se puede dar al suscriptor 3560 si el suscriptor 3560, basándose en el estado del contrato inteligente, 1) se le concede y 2) tiene suficiente crédito, de acuerdo con algunas realizaciones. Sin embargo, dicha funcionalidad puede implementarse, en otras realizaciones, utilizando soluciones de bases de datos no necesariamente vinculadas a implementaciones de cadenas de bloques o contratos inteligentes.
Basándose en una configuración dada, en 3576, la carga útil puede enviarse 3526, durante un período de tiempo, por el dispositivo perimetral 3510 al intermediario 3550 y puede cifrarse usando la clave anterior 3552, por ejemplo.
Después de una duración de tiempo (por ejemplo, establecida por una frecuencia configurable), en 3578, el dispositivo perimetral 3510 puede enviar a continuación la carga útil 3528 al intermediario 3550 cifrada usando la nueva clave 3554. En este escenario, si un suscriptor no tuviera acceso a la nueva clave, el suscriptor perdería la visibilidad de las cargas útiles que se habrían cifrado con la nueva clave, lo que permitiría la gestión periódica de las claves criptográficas.
En otra realización, el dispositivo perimetral 3510, a una frecuencia determinada, puede calcular dos nuevas claves: una primera clave (Clave A) para cifrar cargas útiles y una segunda clave (Clave B) para cifrar la Clave A. A continuación, la nueva primera clave (Clave A) puede cifrarse usando la clave B, después de lo cual la clave A cifrada puede enviarse 3512 al intermediario 3520.
El intermediario 3520 puede entonces reenviar y/o almacenar 3522 la nueva clave cifrada en la plataforma de cadena de bloques, por ejemplo, utilizando una interfaz de contrato inteligente, de acuerdo con algunas realizaciones. El dispositivo perimetral 3510 puede a continuación repetir la solicitud de si la nueva clave cifrada se ha almacenado y si está lista para usarse. El dispositivo perimetral 3510 puede repetir la solicitud, porque el dispositivo perimetral 3510 puede implementarse, en algunas realizaciones, como un diodo de datos sin estar configurado o autorizado para manejar el tráfico entrante.
Una vez que se ha almacenado la nueva clave cifrada y está lista para usarse, el dispositivo perimetral 3510 puede recibir a continuación un mensaje 3516 de CLAVE LISTA del intermediario 3520. Una vez que el dispositivo perimetral 3510 sabe que la nueva clave cifrada está lista, el dispositivo perimetral 3510 puede enviar, basándose en una configuración dada, en algunas realizaciones, un mensaje fuera de banda a un asunto correspondiente de una cola de mensajes en un intermediario de datos puede indicar que se utilizará una nueva clave en breve. Este mensaje fuera de banda (CLAVE LISTA) puede facilitar la escalabilidad horizontal y puede aumentar la calidad del servicio, al menos por las razones descritas anteriormente. Sin embargo, un mensaje de este tipo, o incluso un intermediario 3550, puede no ser necesario en todos los casos de uso.
Además, en algunas realizaciones, el anuncio de un mensaje de CLAVE LISTA puede incluir además una clave criptográfica separada para que se use para descifrar una clave criptográfica cifrada necesaria para descifrar una carga útil, por ejemplo. Además, en algunas realizaciones, como una mejora potencial de la calidad del servicio, la clave criptográfica separada que se usará para descifrar la clave criptográfica cifrada puede incluirse en un subconjunto de cargas útiles 3526 o 3528, por ejemplo. La inclusión de claves criptográficas con algunas cargas útiles puede considerarse una forma de mensajería fuera de banda.
Las claves criptográficas necesarias para descifrar las cargas útiles cifradas pueden cifrarse por lo tanto mediante otras claves intercambiadas fuera de banda, de modo que las claves criptográficas necesarias para descifrar las cargas útiles cifradas se pueden almacenar y compartir de forma segura, por ejemplo, mediante bases de datos tradicionales, contratos inteligentes u otros medios que no son completamente privados. A diferencia de las claves cifradas, las claves criptográficas utilizadas para descifrar las claves cifradas pueden, en algunas realizaciones, no almacenarse en ningún otro lugar que no sea el dispositivo perimetral del editor 3510. Las claves criptográficas utilizadas para descifrar las claves cifradas se pueden reenviar a una frecuencia configurable, lo que permite además una entrega más segura y robusta de claves criptográficas a través de canales variados, lo que confiere beneficios y ventajas adicionales sobre las técnicas convencionales.
En este momento, los suscriptores pueden solicitar al intermediario 3520 (o a un nodo de intermediario separado 3540, en algunas realizaciones) la nueva clave cifrada que puede almacenarse, pero que aún no está en uso. El nodo de intermediario 3540 puede ser un nodo opcional separado como parte del mismo servicio de intermediario proporcionado por el intermediario 3520. Para los propósitos de la Figura 35, los elementos 3520 y 3540 pueden usarse de manera intercambiable, y el nodo de intermediario 3540 puede ser igual o equivalente al intermediario 3520. Adicionalmente, o como alternativa, el nodo de intermediario 3540 puede ser parte de un servicio de intermediario separado.
La nueva clave cifrada se puede dar a continuación a los suscriptores si los suscriptores, basándose en el estado del contrato inteligente: 1) se les concede y 2) tienen crédito suficiente, de acuerdo con algunas modalidades. Sin embargo, dicha funcionalidad puede implementarse, en otras realizaciones, utilizando soluciones de bases de datos no necesariamente vinculadas a implementaciones de cadenas de bloques o contratos inteligentes.
Durante una duración de tiempo, el dispositivo perimetral 3510 puede enviar la carga útil al intermediario 3550, cifrada utilizando la clave anterior. Después de la duración del tiempo, la carga útil enviada por el dispositivo perimetral 3510 al intermediario 3550 puede cifrarse a continuación usando la nueva clave.
La Figura 36 muestra un diagrama de flujo de proceso de un sistema que implementa un protocolo para implementar DOP como una red superpuesta utilizando dispositivos perimetrales restringidos, por ejemplo, en los que los dispositivos perimetrales no pueden incluir hardware y software aptos para generar claves criptográficas. En una realización, en 3670, el dispositivo perimetral 3610, a una frecuencia dada, puede enviar 3612 una solicitud de una nueva clave al intermediario 3620. En algunas realizaciones, un paquete que contiene la solicitud de una nueva clave también puede contener un número entero que representa el número de bytes que se han cifrado hasta ese punto; este número entero puede almacenarse en un contrato inteligente u otro medio de almacenamiento y puede permitir, por ejemplo, modelos de calificación basados en el volumen de datos.
El intermediario 3620 puede a continuación calcular una nueva clave. En algunas realizaciones, el intermediario puede almacenar 3622 la nueva clave para la plataforma de cadena de bloques usando, por ejemplo, una interfaz de contrato inteligente 3630, por ejemplo. Esta realización puede ser aplicable en el caso de entornos o dispositivos perimetrales restringidos, en los que los dispositivos perimetrales pueden no ser aptos para generar nuevas claves usando su propio hardware, por ejemplo. Además, como se describe en cualquier otra parte del presente documento, es posible que no se requiera la tecnología de cadena de bloques y contrato inteligente para todos los casos de uso: las soluciones orientadas a bases de datos pueden ser suficientes, en algunas realizaciones, y ofrecen potencialmente una velocidad ventajosa cuando sea necesario.
El dispositivo perimetral 3610 puede, en 3672, repetir la solicitud de si la nueva clave ha sido almacenada y si está lista para usarse. Se puede requerir que el dispositivo perimetral 3610 repita la solicitud para implementar el dispositivo perimetral 3610 como un diodo de datos sin acceso al tráfico entrante. En algunas realizaciones, el dispositivo perimetral 3610 puede solicitar si una clave criptográfica está lista para su uso (por ejemplo, usando la solicitud 3614 de CLAVE LISTA), tal como comprobando directamente un contrato inteligente 3530 o mediante un intermediario 3620, para comprobar o consultar de otra manera el estado de un contrato inteligente 3630. Adicionalmente, o como alternativa, se puede usar una base de datos que admite consultas del estado de la clave en lugar de o junto con el contrato inteligente 3630.
Una vez que se ha almacenado la nueva clave y está lista para utilizarse, el dispositivo perimetral 3610 puede recibir un mensaje 3616 de CLAVE LISTA del intermediario 3620.
Una vez que el dispositivo perimetral 3610 sabe que la nueva clave está lista, el dispositivo perimetral 3610 puede enviar, basándose en una configuración dada, en algunas realizaciones, un mensaje fuera de banda al intermediario 3650, indicando que se va a utilizar una nueva clave en breve. Este mensaje fuera de banda (CLAVE LISTA) puede facilitar la escalabilidad horizontal y puede aumentar la calidad del servicio, al menos por las razones descritas anteriormente. Sin embargo, un mensaje de este tipo como en 3674, o incluso un intermediario 3650, puede no ser necesario en todos los casos de uso.
En 3662, el suscriptor 3660 puede solicitar al intermediario 3640 la nueva clave (solicitud 3642 de OBTENER CLAVE), que puede almacenarse, pero no estar en uso todavía, por ejemplo, comprobando el contrato inteligente 3630 (solicitud 3632 de OBTENER CLAVE). La nueva clave puede proporcionarse al suscriptor 3660 si el suscriptor 3660, basándose en el estado del contrato inteligente: 1) se le concede y 2) tiene suficiente crédito, de acuerdo con algunas realizaciones. Sin embargo, dicha funcionalidad puede implementarse, en otras realizaciones, utilizando soluciones de bases de datos no necesariamente vinculadas a implementaciones de cadenas de bloques o contratos inteligentes.
Basándose en una configuración dada, en 3676, la carga útil puede enviarse 3626, durante un período de tiempo, por el dispositivo perimetral 3610 al intermediario 3650 y puede cifrarse usando la clave anterior 3652, por ejemplo.
Después de una duración de tiempo (por ejemplo, establecida por una frecuencia configurable), en 3678, la carga útil enviada 3628 por el dispositivo perimetral 3610 al intermediario 3650 puede cifrarse usando la nueva clave 3654. Si un suscriptor no tiene acceso a la nueva clave, ese suscriptor puede perder visibilidad en las cargas útiles posteriores que se cifraron usando la nueva clave.
Las Figuras 37A-D representan casos de uso de ejemplo de un sistema DOP, de acuerdo con algunas realizaciones. La Figura 37A proporciona una vista general de un sistema de ejemplo no limitante.
De acuerdo con otros ejemplos descritos en el presente documento, el usuario 3710 (propietario de datos) puede representar a un editor, por ejemplo, un propietario o usuario de al menos un dispositivo perimetral 3718 (dispositivo de editor) que se puede usar para recopilar y publicar puntos de datos, para cifrarse opcionalmente, de acuerdo con algunas realizaciones. El dispositivo perimetral 3718 puede incluir al menos un procesador perimetral 3714 y un dispositivo de comunicación 3716 y, opcionalmente, al menos una fuente de entropía 3712, que puede estar equipada a bordo de un paquete discreto del dispositivo perimetral 3718 (véase, por ejemplo, la parte resaltada de Figura 37B).
Un suscriptor 3750 (usuario de datos) puede buscar suscribirse o anular la suscripción 3740 a un flujo de datos cifrados 3724 publicado por el propietario de datos 3710. El suscriptor 3750 puede recibir el flujo de datos cifrado 3724 (o 3744, opcionalmente a través de un servicio de intermediario de datos 3738) en un dispositivo de comunicación de suscriptor 3754 y/o un procesador de suscriptor 3752 (véase, por ejemplo, la parte resaltada de la Figura 37D). Sin embargo, para descifrar cualquier dato de carga útil en el flujo de datos cifrado 3724 o 3744, el procesador de suscriptor 3752 puede requerir acceso a la clave criptográfica del editor en un momento dado para el que el suscriptor 3750 busca acceso, por ejemplo, mediante una solicitud a través de un extremo frontal 3730 (opcionalmente a través de un navegador web, una aplicación web híbrida o nativa y/o una interfaz de programación de aplicaciones (API), etc.). El editor (usuario 3710) puede conceder o revocar el acceso al flujo de datos 3720 al interactuar con el extremo frontal 3730.
Cualquier solicitud de acceso de un suscriptor 3750 o las acciones para conceder o revocar el acceso de un usuario 3710 puede procesarse por al menos un procesador de extremo trasero 3732, opcionalmente conectándose a un servicio de intermediario de claves 3734 o directamente a dispositivos perimetrales (por ejemplo, el dispositivo perimetral 3718, el procesador perimetral 3714, el procesador de suscriptor 3752, etc.). Opcionalmente, el procesador de extremo trasero 3732 o el servicio de intermediario de claves 3734 pueden tener al menos una fuente de entropía mediante la que proporcionar datos de semilla aleatorios para la generación de claves criptográficas, ya sea en el procesador de extremo trasero 3732 o en el procesador perimetral 3714, de acuerdo con algunas realizaciones.
Esta pila intermedia de componentes 3730-3736, que incluye el extremo frontal 3730, el procesador de extremo trasero 3732, el servicio de intermediario de claves 3734 y la fuente de entropía 3736 (véase, por ejemplo, la parte resaltada de la Figura 37C), opcionalmente, pueden estar centralizada, distribuida o, de otra manera, descentralizada. Cualquier servicio de intermediario de datos 3738 también es opcional, como lo son el servicio de intermediario de claves 3734 y la fuente de entropía 3736, de acuerdo con algunas realizaciones. Por lo tanto, en algunos casos de uso de ejemplo de acuerdo con otras realizaciones, el dispositivo perimetral 3718 del usuario 3710 puede interactuar más directamente con cualquier número de procesadores de suscriptor 3752 o dispositivos de comunicación de suscriptor 3754 para cualquier número de suscriptores, tal como el suscriptor 3750. Los diagramas de flujo representados en las Figuras 35 y 36 pueden implementarse en el sistema mostrado en las Figuras 37A-D, de acuerdo con algunas realizaciones.
Las Figuras 38A-H representan ejemplos de casos de uso de revocación de clave de un sistema DOP, de acuerdo con algunas realizaciones que usan contratos inteligentes, por ejemplo.
Al igual que con las Figuras 37A-D, de acuerdo con otros ejemplos descritos en el presente documento, el usuario 3810 (propietario de datos) puede representar a un editor, por ejemplo, un propietario o usuario de al menos un dispositivo perimetral 3818 (dispositivo de editor) que se puede usar para recopilar y publicar puntos de datos, para cifrarse opcionalmente, de acuerdo con algunas realizaciones. El dispositivo perimetral 3818 puede incluir al menos un procesador perimetral 3814 y un dispositivo de comunicación 3816 y, opcionalmente, al menos una fuente de entropía 3812 a bordo de un paquete discreto del dispositivo perimetral 3818.
Un suscriptor 3850 (usuario de datos) puede buscar suscribirse o anular la suscripción, al igual que 3740, a un flujo de datos cifrados 3824 publicado por el propietario de datos 3810. Adicionalmente, o como alternativa, el suscriptor 3850 puede proporcionar una entrada que asocia el suscriptor 3850 con un primer conjunto de suscriptores en un contrato inteligente 3840, por ejemplo. El suscriptor 3850 puede recibir el flujo de datos cifrados 3824 (o 3844, opcionalmente a través de un servicio de intermediario de datos 3838) en un dispositivo de comunicación de suscriptor 3854 y/o un procesador de suscriptor 3852. Sin embargo, para descifrar cualquier dato de carga útil en el flujo de datos cifrado 3824 o 3844, el procesador de suscriptor 3852 puede requerir acceso a la clave criptográfica del editor en un momento dado para el que el suscriptor 3850 busca acceso, por ejemplo, mediante una solicitud a través de un extremo frontal 3830 (opcionalmente a través de un navegador web, una aplicación web híbrida o nativa y/o una interfaz de programación de aplicaciones (API), etc.). El editor (usuario 3810) puede conceder o revocar el acceso al flujo de datos como con 3720. Adicionalmente, o como alternativa, el usuario 3810 puede proporcionar entrada para cambiar el estado de cualquier número de suscriptores dentro de un conjunto de suscriptores asociados a un producto de flujo de datos 3820 (por ejemplo, a través de un contrato inteligente), interactuando con el extremo frontal 3830.
Cualquier solicitud de acceso de un suscriptor 3850 o las acciones para conceder o revocar el acceso de un usuario 3810 puede procesarse por al menos un procesador de extremo trasero 3832, opcionalmente conectándose a un servicio de intermediario de claves 3834 o directamente a dispositivos perimetrales (por ejemplo, el dispositivo perimetral 3818, el procesador perimetral 3814, el procesador de suscriptor 3852, etc.). Una acción para revocar el permiso de acceso a un suscriptor seleccionado, por ejemplo, puede dar como resultado un segundo conjunto de suscriptores que excluye al suscriptor seleccionado. Opcionalmente, el procesador de extremo trasero 3832 o el servicio de intermediario de claves 3834 pueden tener al menos una fuente de entropía mediante la que proporcionar datos de semilla aleatorios para la generación de claves criptográficas, ya sea en el procesador de extremo trasero 3832 o en el procesador perimetral 3814, de acuerdo con algunas realizaciones.
Esta pila intermedia de componentes 3730-3738, opcionalmente, puede estar centralizada, distribuida o, de otra manera, descentralizada. Cualquier servicio de intermediario de datos 3838 es opcional, como lo son el servicio de intermediario de claves 3834 y la fuente de entropía 3836, de acuerdo con algunas realizaciones. Por lo tanto, en algunos casos de uso de ejemplo de acuerdo con otras realizaciones, el dispositivo perimetral 3818 del usuario 3810 puede interactuar más directamente con cualquier número de procesadores de suscriptor 3852 o dispositivos de comunicación de suscriptor 3854 para cualquier número de suscriptores, tal como el suscriptor 3850. Los diagramas de flujo representados en las Figuras 35 y 36 pueden implementarse en el sistema mostrado en las Figuras 38A-H, de acuerdo con algunas realizaciones.
Las Figuras 39A-E representan casos de uso de revocación de clave de ejemplo de un sistema DOP, de acuerdo con algunas realizaciones.
Al igual que con las Figuras 37A-D, de acuerdo con otros ejemplos descritos en el presente documento, el usuario (propietario de datos) puede representar a un editor, por ejemplo, un propietario o usuario de al menos un dispositivo perimetral 3918 (dispositivo de editor) que se puede usar para recopilar y publicar puntos de datos, para cifrarse opcionalmente, de acuerdo con algunas realizaciones. El dispositivo perimetral 3918 puede incluir al menos un procesador perimetral 3914 y un dispositivo de comunicación 3916 y, opcionalmente, al menos una fuente de entropía 3912 a bordo de un paquete discreto del dispositivo perimetral 3918. Los diagramas de flujo representados en las Figuras 35 y 36 pueden implementarse en el sistema mostrado en las Figuras 39A-E, de acuerdo con algunas realizaciones.
Un suscriptor (usuario de datos) puede buscar suscribirse o anular la suscripción, al igual que 3740, a un flujo de datos cifrados 3924 publicado por el propietario de datos. Adicionalmente, o como alternativa, el suscriptor puede proporcionar una entrada que asocia el suscriptor con un primer conjunto de suscriptores en un contrato inteligente 3940, por ejemplo. El suscriptor puede recibir el flujo de datos cifrados 3924 (o 3944, opcionalmente a través de un servicio de intermediario de datos 3938) en un dispositivo de comunicación de suscriptor 3954 y/o un procesador de suscriptor 3952. Sin embargo, para descifrar cualquier dato de carga útil en el flujo de datos cifrado 3924 o 3944, el procesador de suscriptor 3952 puede requerir acceso a la clave criptográfica del editor en un momento dado para el que el suscriptor busca acceso, por ejemplo, mediante una solicitud a través de un extremo frontal 3930 (opcionalmente a través de un navegador web, una aplicación web híbrida o nativa y/o una interfaz de programación de aplicaciones (API), etc.). El editor (usuario) puede conceder o revocar el acceso al flujo de datos como con 3720. Adicionalmente, o como alternativa, el usuario puede proporcionar entrada para cambiar el estado de cualquier número de suscriptores dentro de un conjunto de suscriptores asociados a un producto de flujo de datos 3920 (por ejemplo, a través de un contrato inteligente), interactuando con un servicio de extremo frontal, por ejemplo.
Cualquier solicitud de acceso de un suscriptor o las acciones para conceder o revocar el acceso de un usuario puede procesarse por al menos un procesador de extremo trasero 3932, opcionalmente conectándose a un servicio de intermediario de claves 3934 o directamente a dispositivos perimetrales (por ejemplo, el dispositivo perimetral 3918, el procesador perimetral 3914, el procesador de suscriptor 3952, etc.). Opcionalmente, el procesador de extremo trasero 3932 o el servicio de intermediario de claves 3934 pueden tener al menos una fuente de entropía mediante la que proporcionar datos de semilla aleatorios para la generación de claves criptográficas, ya sea en el procesador de extremo trasero 3932 o en el procesador perimetral 3914, de acuerdo con algunas realizaciones.
Cualquier servicio de intermediario de datos 3938 es opcional. Por lo tanto, en algunos casos de uso de ejemplo de acuerdo con otras realizaciones, el dispositivo perimetral 3918 del usuario puede interactuar más directamente con cualquier número de procesadores de suscriptor 3952 o dispositivos de comunicación de suscriptor 3954 para cualquier número de suscriptores, tal como el suscriptor.
Como se describe particularmente con respecto a los elementos 3939a-e, la distribución de claves, la notificación, la revocación y el reemplazo de claves puede realizarse por un dispositivo perimetral 3918 a dispositivos de suscriptor (por ejemplo, el procesador de suscriptor 3952 y/o el dispositivo de comunicación de suscriptor 3954), directamente, con o sin ningún servicio intermedio (procesador de extremo trasero, servicio de intermediario de claves, servicio de intermediario de datos, etc.) que gestione tal comunicación de claves o notificaciones. Tal comunicación puede ser una comunicación fuera de banda a través de una red superpuesta separada o un canal secundario, por ejemplo, independientemente de cualquier extremo trasero, servicio de intermediario o intermediario de datos, en algunas realizaciones.
De acuerdo con un caso de uso de ejemplo, los datos y/o imperativos fuera de banda pueden llevarse dentro de un mismo canal utilizado para cualquier otra carga útil. La agrupación o desagregación se puede realizar mediante diversas pilas de comunicación. Se puede insertar una carga útil en una envolvente que contenga cualquier otro imperativo necesario para la DOP. De esta manera, al menos desde un punto de vista operativo, las implementaciones de DOP pueden evitar, además, por lo tanto, la introducción de requisitos especiales relacionados con los canales de comunicación secundarios, por ejemplo.
Por lo tanto, por ejemplo, como se muestra con respecto a 3939a de la Figura 39A, el dispositivo perimetral 3918 puede transmitir o emitir una notificación para dejar de usar una clave criptográfica anterior. Esta notificación puede transmitirse a través del dispositivo de comunicación 3916 o a través de otros medios acoplados con el procesador perimetral 3914, por ejemplo. Una notificación de este tipo de 3939a puede informar a los suscriptores con acceso continuo concedido que una clave criptográfica está cambiando, de modo que se necesitará la nueva clave criptográfica para el acceso continuo a un flujo.
Como se muestra con respecto a 3939b de la Figura 39B, el dispositivo perimetral 3918 puede transmitir, de manera similar a 3939a, una indicación de que una nueva clave criptográfica está disponible, al menos para suscriptores con acceso continuo concedido. Los suscriptores a los que se les revoque el acceso o no se les conceda el acceso pueden o no recibir una notificación de nuevas claves criptográficas, pero, en cualquier caso, no recibirán la siguiente clave criptográfica para reemplazar la clave criptográfica anterior del dispositivo perimetral 3918, tal como se transmite en 3939c, como se muestra en la Figura 39C.
En algunas realizaciones, el dispositivo perimetral 3918 puede no saber quiénes son los suscriptores, gestionándose tal información del suscriptor, por ejemplo, en un contrato inteligente, base de datos, intermediario u otro almacén de datos externo. Como resultado, los anuncios o indicaciones similares desde el dispositivo perimetral 3918 pueden difundirse a cualquiera o todos los suscriptores, independientemente de si un editor ha concedido o revocado el acceso a un suscriptor particular. Por lo tanto, los suscriptores a los que no se les concede acceso aún pueden recibir anuncios del dispositivo perimetral 3918 pero, en ese caso, es posible que los suscriptores sin acceso concedido no puedan recibir nuevas claves criptográficas de un servicio de extremo trasero correspondiente, por lo que tales suscriptores no pueden descifrar cargas útiles de datos cifrados. Los suscriptores a los que se concede acceso pueden acceder a las últimas claves a través de un servicio de intermediario y/o un servicio de intermediario de datos, por ejemplo, donde las mismas claves pueden cifrarse.
Así, como se muestra en la Figura 39C con respecto a 3939c, se puede transmitir una nueva clave criptográfica a los suscriptores. El procesador perimetral 3914 puede estar equipado para permitir que un editor gestione conjuntos de suscriptores a los que se concede o revoca el acceso al flujo de datos, de acuerdo con algunas realizaciones. Cada dispositivo perimetral 3918 puede incluir, en algunas realizaciones, su propia interfaz de extremo frontal o similar. Adicionalmente, o como alternativa, se puede utilizar un servicio de extremo frontal separado para controlar las suscripciones (concesiones/revocaciones de acceso, etc.) por un propietario de datos.
En algunas realizaciones, el dispositivo perimetral 3918 puede no saber quiénes son los suscriptores, gestionándose tal información del suscriptor, por ejemplo, en un contrato inteligente, base de datos, intermediario u otro almacén de datos externo. Como resultado, los anuncios o indicaciones similares desde el dispositivo perimetral 3918 pueden difundirse a cualquiera o todos los suscriptores, independientemente de si un editor ha concedido o revocado el acceso a un suscriptor particular. Por lo tanto, los suscriptores a los que no se les concede acceso aún pueden recibir anuncios del dispositivo perimetral 3918 pero, en ese caso, es posible que los suscriptores sin acceso concedido no puedan recibir nuevas claves criptográficas de un servicio de extremo trasero correspondiente, por lo que tales suscriptores no pueden descifrar cargas útiles de datos cifrados. Los suscriptores a los que se concede acceso pueden acceder a las últimas claves a través de un servicio de intermediario y/o un servicio de intermediario de datos, por ejemplo, donde las mismas claves pueden cifrarse.
Según la Figura 39D, en algunas realizaciones en las que se puede usar un servicio separado (por ejemplo, servicio de intermediario de claves, servicio de intermediario de datos, cadena de bloques, contrato inteligente, etc.) para almacenar y/o controlar el acceso a las claves, las claves se pueden enviar directamente al servicio separado e indexarse, y el dispositivo perimetral 3918 a continuación puede transmitir solo un índice, opcionalmente con una carga útil cifrada, a algunos o todos los suscriptores y/u, opcionalmente, a un servicio de intermediario de datos, por ejemplo, como se muestra con respecto a 3939d. Adicionalmente, en algunas realizaciones, la clave criptográfica también puede incluirse en esta transmisión, como se muestra con respecto a 3939e de la Figura 39E.
Las razones de tales interacciones del sistema se describen a lo largo de la presente divulgación, y los detalles de implementación para tal interacción, desde un dispositivo perimetral, se describen más adelante, tal como con respecto a la Figura 40.
La Figura 40 es un diagrama de flujo que ilustra un método 4000 para la operación de un aparato de ejemplo de acuerdo con las técnicas mejoradas descritas en el presente documento, de acuerdo con algunas realizaciones. El método 4000 puede realizarse mediante lógica de procesamiento que puede comprender hardware (por ejemplo, circuitos, lógica especializada, lógica programable, microcódigo, etc.), software (por ejemplo, instrucciones que se ejecutan en un dispositivo de procesamiento) o una combinación de los mismos. No todas las etapas del método 4000 pueden ser necesarias en todos los casos para realizar las técnicas mejoradas desveladas en el presente documento. Además, algunas etapas del método 4000 se pueden realizar simultáneamente o en un orden diferente al que se muestra en la Figura 40, como se entenderá por un experto en la materia.
El método 4000 se describirá con referencia a las Figuras 1-41. Sin embargo, el método 4000 no se limita solo a esas realizaciones de ejemplo. Las etapas del método 4000 pueden realizarse por al menos un procesador informático acoplado a al menos un dispositivo de memoria. A continuación, se describe un procesador y un dispositivo o dispositivos de memoria ilustrativos con respecto a la Figura 41.
En algunas realizaciones, el método 4000 puede realizarse por al menos un dispositivo perimetral junto con cualquiera de los protocolos y/o sistemas demostrados en cualquiera de las Figuras 35-39E, que puede incluir además al menos un procesador y una memoria tal como aquellos de la Figura 41. Además, se pueden usar procesos similares al método 4000 para operar un dispositivo perimetral de editor que puede estar implicado con cualquiera de los casos de uso que se muestran en las Figuras 1-34, por ejemplo. Si bien este ejemplo, con fines ilustrativos, incluye operaciones para su uso con un servicio de extremo tarsero, por ejemplo, un servicio de intermediario de claves, tales operaciones son opcionales para otras realizaciones que pueden implicar la comunicación directa entre dispositivos editores y dispositivos suscriptores, por ejemplo.
En 4002, al menos un procesador 4104 puede configurarse para cargar una primera clave criptográfica. Para cargar la primera clave criptográfica, el procesador 4104 puede copiar toda o parte de la primera clave criptográfica, en al menos una operación en serie o en paralelo, desde al menos un dispositivo (que puede ser un procesador integrado 4104, en algunas realizaciones) en al menos un dispositivo de memoria, por ejemplo.
Además, con respecto a 4002, la primera clave criptográfica puede cargarse, por ejemplo, desde un dispositivo externo que, en algunas realizaciones, puede incluir hardware acelerado ajustado para un procesamiento criptográfico mejorado. Adicionalmente, o como alternativa, el dispositivo externo puede incluir al menos una fuente de entropía, que puede no estar presente o fácilmente utilizable en el mismo aparato (por ejemplo, el dispositivo perimetral) que el procesador 4104. Tal caso de uso puede denominarse caso de uso de perímetro restringido, tal como el que se muestra con respecto a la Figura 36.
En algunas realizaciones, la clave criptográfica puede cargarse como generada integrada en el mismo aparato (por ejemplo, el dispositivo perimetral) que puede incluir el procesador 4104. En tales realizaciones, al menos una fuente de entropía puede estar equipada a bordo del mismo aparato que el procesador 4104. Adicionalmente, o como alternativa, la entropía puede obtenerse de un dispositivo externo, en algunas realizaciones. Las fuentes de entropía se pueden utilizar para generar generadores de números (pseudo-)aleatorios para su uso con la generación de claves criptográficas. Las fuentes de entropía pueden incluir, pero sin limitación, sensores ambientales (diferentes o iguales a cualquier sensor ambiental utilizado para alimentar una carga útil de flujo de datos para su publicación), señales integradas o cualquier ruido generado o detectado por el mismo aparato que puede incluir el procesador 4104.
En 4004, el procesador 4104 puede configurarse para transmitir la primera clave criptográfica a un servicio de extremo trasero. Adicionalmente, o como alternativa, la primera clave criptográfica puede transmitirse directamente a uno o más dispositivos de suscriptor, esté o no presente o disponible algún servicio de extremo trasero, de acuerdo con algunas realizaciones.
Un servicio de extremo trasero puede ser un servicio de intermediario de claves, por ejemplo. Un servicio de intermediario de claves puede comprender, en algunas realizaciones, una base de datos tradicional, estructurada o no estructurada que, a su vez, puede o no estar respaldada por almacenamiento cifrado, por ejemplo. El servicio de extremo trasero puede estar centralizado o descentralizado, en algunas realizaciones. Adicionalmente, o como alternativa, el servicio de intermediario de claves, o un servicio de extremo trasero comparable, puede implementarse utilizando una cadena de bloques, que puede implementar, además, en algunas realizaciones, al menos un contrato inteligente asociado al servicio de intermediario de claves y/o editores y/o suscriptores específicos directamente, de acuerdo con algunas realizaciones. Otros ejemplos de diversos casos de uso e implementaciones para 4004 se describen en otra parte del presente documento con respecto a la tecnología mejorada de la presente divulgación.
En 4006, el procesador 4104 puede configurarse para confirmar que la primera clave criptográfica está lista para su uso, de acuerdo con algunas realizaciones. En otras realizaciones, donde no se puede utilizar o no está disponible un servicio de extremo trasero o intermediario de clave, los suscriptores pueden sondear o esperar y escuchar los dispositivos de editor, por ejemplo, a intervalos predeterminados o establecidos de otro modo, para obtener claves y/o proporcionar confirmación de que se recibieron las claves y están listas para su uso. En algunas realizaciones, los dispositivos perimetrales pueden confirmar la disponibilidad de claves en los suscriptores y/o servicios de extremo trasero.
En 4008, el procesador 4104 puede configurarse para cifrar al menos una primera carga útil de datos. En algunos ejemplos desvelados en el presente documento, la al menos una primera carga útil de datos, una vez cifrada, requiere la primera clave criptográfica para cualquier descifrado posterior de la al menos una primera carga útil de datos. Se pueden usar diversos tipos de claves criptográficas, algoritmos y/o criptosistemas, incluyendo con claves criptográficas simétricas, claves criptográficas asimétricas (pares de claves), o cualquier combinación de las mismas, incluyendo las realizaciones en las que cualquiera o todas las múltiples claves posibles se pueden usar para descifrar ciertas cargas útiles, por ejemplo.
En 4010, el procesador 4104 puede configurarse para publicar, a través de un flujo de datos, la al menos una primera carga útil de datos como cifrada, de acuerdo con algunas realizaciones. La publicación se puede realizar utilizando cualquier protocolo de comunicación, que puede estar basado, en algunas realizaciones, en protocolos de comunicación de código abierto, tales como el transporte de telemetría de cola de mensajes (MQTT), el protocolo de cola de mensajes avanzado (AMQP) o Apache Kafka, por nombrar unos pocos ejemplos no limitantes. La publicación se puede realizar directamente y/o a través de cualquiera de las diversas plataformas de intermediarios de datos, incluyendo los proveedores de servicios en la nube u otros servicios de alojamiento.
En 4012, el procesador 4104 puede configurarse para cargar una segunda clave criptográfica, en respuesta a al menos un primer factor que incluye una indicación de que ha transcurrido una cantidad de tiempo predeterminada. El tiempo predeterminado puede establecerse mediante un parámetro de frecuencia configurable, de acuerdo con algunas realizaciones. La segunda clave criptográfica se puede cargar para reemplazar la primera clave criptográfica, por ejemplo, al cifrar cargas útiles de datos de un dispositivo perimetral. En algunas realizaciones que usan contratos inteligentes, la segunda clave puede asociarse al contrato inteligente en lugar de la primera clave, tal como cuando se asocian o se vuelven a asociar diferentes conjuntos de suscriptores al contrato inteligente, para permitir la concesión o revocación del acceso a ciertos conjuntos de suscriptores, por ejemplo.
La cantidad de tiempo predeterminada, o la frecuencia configurada, puede estar en cualquier escala y puede determinarse o establecerse de otra manera a través de cualquier medio de configuración, tal como a través de parámetros de configuración en un archivo de configuración, línea de comandos o interfaz de programación de aplicaciones (API), por ejemplo. En algunas realizaciones, tales parámetros de tiempo/frecuencia pueden estar precodificados para una implementación dada de hardware, firmware, software o cualquier combinación de los mismos.
En 4012, el procesador 4014 puede repetir 4002, reemplazando la primera clave criptográfica con una segunda clave criptográfica. En algunas realizaciones, 4012 puede iterarse o reiterarse 4002 como parte de un bucle de software, por ejemplo, que puede ejecutarse sin un punto final predeterminado. Como se indicó anteriormente con respecto a 4002, de manera similar en 4012, la segunda clave criptográfica puede cargarse, por ejemplo, desde un dispositivo externo que, en algunas realizaciones, puede incluir hardware acelerado ajustado para un procesamiento criptográfico mejorado. Adicionalmente, o como alternativa, el dispositivo externo puede incluir al menos una fuente de entropía, que puede no estar presente o fácilmente utilizable en el mismo aparato (por ejemplo, el dispositivo perimetral) que el procesador 4104. Tal caso de uso puede denominarse caso de uso de perímetro restringido, tal como el que se muestra con respecto a la Figura 36.
En algunas realizaciones, la segunda clave criptográfica puede cargarse como generada integrada en el mismo aparato (por ejemplo, el dispositivo perimetral) que puede incluir el procesador 4104. En tales realizaciones, al menos una fuente de entropía puede estar equipada a bordo del mismo aparato que el procesador 4104. Adicionalmente, o como alternativa, la entropía puede obtenerse de un dispositivo externo, en algunas realizaciones. Las fuentes de entropía se pueden utilizar para generar generadores de números (pseudo-)aleatorios para su uso con la generación de claves criptográficas. Las fuentes de entropía pueden incluir, pero sin limitación, sensores ambientales (diferentes o iguales a cualquier sensor ambiental utilizado para alimentar una carga útil de flujo de datos para su publicación), señales integradas o cualquier ruido generado o detectado por el mismo aparato que puede incluir el procesador 4104.
En 4014, el procesador 4104 puede configurarse para transmitir la segunda clave criptográfica al servicio de extremo trasero. Como se indicó anteriormente con respecto a 4004, de manera similar en 4014, el uso de un servicio de extremo trasero puede ser opcional. Por lo tanto, adicionalmente, o como alternativa, la segunda clave criptográfica puede transmitirse directamente a uno o más dispositivos de suscriptor, esté o no presente o disponible algún servicio de extremo trasero, de acuerdo con algunas realizaciones.
En 4016, el procesador 4104 puede configurarse para confirmar que la segunda clave criptográfica está lista para su uso. En otras realizaciones, donde no se puede utilizar o no está disponible un servicio de extremo trasero o intermediario de clave, los suscriptores pueden sondear los dispositivos de editor, por ejemplo, a intervalos predeterminados o establecidos de otro modo, para obtener claves y/o proporcionar confirmación de que se recibieron las claves y están listas para su uso. En algunas realizaciones, los dispositivos perimetrales pueden confirmar la disponibilidad de claves en los suscriptores y/o servicios de extremo trasero.
En 4018, el procesador 4104 puede configurarse para cifrar al menos una segunda carga útil de datos. En algunas realizaciones, la al menos una segunda carga útil de datos, una vez cifrada, requiere la segunda clave criptográfica para cualquier descifrado posterior de la al menos una segunda carga útil de datos, y en donde la primera clave criptográfica es ineficaz para descifrar la al menos una segunda carga útil de datos. Se pueden usar diversos tipos de claves criptográficas, algoritmos y/o criptosistemas, incluyendo con claves criptográficas simétricas, claves criptográficas asimétricas (pares de claves), o cualquier combinación de las mismas, incluyendo las realizaciones en las que cualquiera o todas las múltiples claves posibles se pueden usar para descifrar ciertas cargas útiles, por ejemplo, como se ha descrito de manera similar anteriormente con respecto a 4010.
En 4020, el procesador 4104 puede configurarse para publicar, a través del flujo de datos, la al menos una segunda carga útil de datos como cifrada, de acuerdo con algunas realizaciones. La publicación se puede realizar utilizando cualquier protocolo de comunicación, que puede estar basado, en algunas realizaciones, en protocolos de comunicación de código abierto, tales como el transporte de telemetría de cola de mensajes (MQTT), el protocolo de cola de mensajes avanzado (AMQP) o Apache Kafka, por nombrar unos pocos ejemplos no limitantes. La publicación se puede realizar directamente y/o a través de cualquiera de las diversas plataformas de intermediarios de datos, incluyendo los proveedores de servicios en la nube u otros servicios de alojamiento, como se ha descrito adicionalmente en el presente documento anteriormente.
Se pueden implementar diversas realizaciones, por ejemplo, utilizando uno o más sistemas informáticos, tal como el sistema informático 4100 mostrado en la Figura 41. Se pueden usar uno o más sistemas informáticos 4100, por ejemplo, para implementar cualquiera de las realizaciones analizadas en el presente documento, así como combinaciones y subcombinaciones de las mismas.
El sistema informático 4100 puede incluir uno o más procesadores (también denominados unidades centrales de procesamiento o CPU), tales como un procesador 4104. El procesador 4104 puede estar conectado a un bus o infraestructura de comunicación 4106.
El sistema informático 4100 también puede incluir el dispositivo o dispositivos de entrada/salida de usuario 4103, tales como monitores, teclados, dispositivos apuntadores, etc., que pueden comunicarse con la infraestructura de comunicación 4106 a través de la interfaz o interfaces de entrada/salida de usuario 4102.
Uno o más de los procesadores 4104 pueden ser una unidad de procesamiento de gráficos (GPU). En una realización, una GPU puede ser un procesador que es un circuito electrónico especializado diseñado para procesar aplicaciones matemáticamente intensivas. Con capacidades de computación de propósito general en unidades de procesamiento de gráficos (GPGPU), la GPU puede ser útil en diversas otras aplicaciones. La GPU puede tener una estructura paralela que sea eficiente para el procesamiento paralelo de grandes bloques de datos, tales como datos matemáticamente intensivos comunes a las aplicaciones de gráficos por ordenador, imágenes, videos, procesamiento de vectores, procesamiento de matrices, etc., así como criptografía (que incluye la ruptura por fuerza bruta), generando funciones de troceo criptográficas o secuencias de funciones de troceo, resolviendo problemas de inversión de función de troceo parcial y/o produciendo resultados de otros cálculos de prueba de trabajo para algunas aplicaciones basadas en cadena de bloques, por ejemplo.
El sistema informático 4100 también puede incluir una memoria principal o primaria 4108, tal como una memoria de acceso aleatorio (RAM). La memoria principal 4108 puede incluir uno o más niveles de caché. La memoria principal 4108 puede tener almacenada lógica de control (es decir, software informático) y/o datos.
El sistema informático 4100 también puede incluir uno o más dispositivos de almacenamiento secundario o memoria 4110. La memoria secundaria 4110 puede incluir, por ejemplo, una unidad de disco duro 4112 y/o un dispositivo o unidad de almacenamiento extraíble 4114. La unidad de almacenamiento extraíble 4114 puede ser una unidad de disquete, una unidad de cinta magnética, una unidad de disco compacto, un dispositivo de almacenamiento óptico, un dispositivo de copia de seguridad en cinta y/o cualquier otro dispositivo/unidad de almacenamiento.
La unidad de almacenamiento extraíble 4114 puede interactuar con una unidad de almacenamiento extraíble 4118. La unidad de almacenamiento extraíble 4118 puede incluir un dispositivo de almacenamiento legible o utilizable por ordenador que tiene almacenado software informático (lógica de control) y/o datos. La unidad de almacenamiento extraíble 4118 puede ser un disquete, una cinta magnética, un disco compacto, un DVD, un disco de almacenamiento óptico y/o cualquier otro dispositivo de almacenamiento de datos informáticos. La unidad de almacenamiento extraíble 4114 puede leer y/o escribir en la unidad de almacenamiento extraíble 4118.
La memoria secundaria 4110 puede incluir otros medios, dispositivos, componentes, instrumentos u otros enfoques para permitir que el sistema informático 4100 acceda a los programas informáticos y/u otras instrucciones y/o datos. Tales medios, dispositivos, componentes, instrumentos u otros enfoques pueden incluir, por ejemplo, una unidad de almacenamiento extraíble 4122 y una interfaz 4120. Los ejemplos de la unidad de almacenamiento extraíble 4122 y la interfaz 4120 pueden incluir un cartucho de programa y una interfaz de cartucho (tal como la que se encuentra en los dispositivos de videojuegos), un chip de memoria extraíble (tal como una EPROM o PROM) y un zócalo asociado, una tarjeta de memoria y puerto USB, una tarjeta de memoria y una ranura para tarjeta de memoria asociada, y/o cualquier otra unidad de almacenamiento extraíble e interfaz asociada.
El sistema informático 4100 puede incluir además una interfaz de comunicación o de red 4124. La interfaz de comunicación 4124 puede permitir que el sistema informático 4100 se comunique e interactúe con cualquier combinación de dispositivos externos, redes externas, entidades externas, etc. (referenciados individual y colectivamente por el número de referencia 4128). Por ejemplo, la interfaz de comunicación 4124 puede permitir que el sistema informático 4100 se comunique con dispositivos externos o remotos 4128 a través de la ruta de comunicaciones 4126, que puede ser alámbrica o inalámbrica (o una combinación de las mismas), y que puede incluir cualquier combinación de LAN, WAN, Internet, etc. La lógica de control y/o los datos pueden transmitirse hacia y desde el sistema informático 4100 a través de la ruta de comunicación 4126.
El sistema informático 4100 también puede ser cualquiera de un asistente digital personal (PDA), una estación de trabajo de escritorio, un ordenador portátil o portable, un netbook, una tableta, un teléfono inteligente, un reloj inteligente u otro dispositivo llevable, parte del Internet de las cosas, y/o el sistema embebido, por nombrar unos pocos ejemplos no limitantes, o cualquier combinación de los mismos.
El sistema informático 4100 puede ser un cliente o servidor, que accede o aloja cualquier aplicación y/o datos a través de cualquier paradigma de entrega, que incluye, pero sin limitación, soluciones informáticas en la nube remotas o distribuidas; software local o en las instalaciones (soluciones basadas en la nube "en las instalaciones"); modelos "como servicio" (por ejemplo, contenido como servicio (CaaS), contenido digital como servicio (DCaaS), software como servicio (SaaS), software gestionado como servicio (MSaaS), plataforma como servicio (PaaS), escritorio como servicio (DaaS), estructura como servicio (FaaS), extremo trasero como servicio (BaaS), extremo trasero móvil como servicio (MBaaS), infraestructura como servicio (IaaS), etc.); y/o un modelo híbrido que incluye cualquier combinación de los ejemplos anteriores u otros servicios o paradigmas de entrega.
Cualquier estructura de datos, formatos de archivo y esquemas aplicables en el sistema informático 4100 pueden derivarse de normas que incluyen, pero sin limitación, Notación de Objetos JavaScript (JSON), Lenguaje de Marcado Extensible (XML), Otro Lenguaje de Marcado (YAML), Lenguaje de Marcado de Hipertexto Extensible (XHTML), Lenguaje de Marcado Inalámbrico (WML), Paquete de Mensajes, Lenguaje de Interfaz de Usuario XML (XUL) o cualquier otra representación funcionalmente similar sola o en combinación. Como alternativa, se pueden usar estructuras de datos, formatos o esquemas propietarios, ya sea exclusivamente o en combinación con normas abiertas o conocidas.
En algunas realizaciones, un aparato o artículo de fabricación tangible y no transitorio que comprende un medio tangible, no transitorio utilizable o legible por ordenador que tiene una lógica de control (software) almacenada en el mismo, también puede denominarse en el presente documento un producto de programa informático o un dispositivo de almacenamiento de programa. Esto incluye, pero sin limitación, el sistema informático 4100, la memoria principal 4108, la memoria secundaria 4110 y las unidades de almacenamiento extraíbles 4118 y 4122, así como los artículos de fabricación tangibles que incorporan cualquier combinación de lo anterior. Tal lógica de control, cuando se ejecuta por uno o más dispositivos de procesamiento de datos (tales como el sistema informático 4100), puede hacer que dichos dispositivos de procesamiento de datos operen como se describe en el presente documento.
Basándose en las enseñanzas contenidas en esta divulgación, será evidente para los expertos en la materia o materias relevantes cómo hacer y utilizar realizaciones de esta divulgación utilizando dispositivos de procesamiento de datos, sistemas informáticos y/o arquitecturas informáticas distintas a las mostradas en la Figura 41. En particular, las realizaciones pueden operar con implementaciones de software, hardware y/o sistema operativo distintas a las descritas en el presente documento.
Debe apreciarse que la sección de descripción detallada, y ninguna otra sección, está destinada a ser utilizada para interpretar las reivindicaciones. Otras secciones pueden exponer una o más, pero no todas, las realizaciones de ejemplo contempladas por el inventor o inventores y, por lo tanto, no pretenden limitar esta divulgación o las reivindicaciones adjuntas de ninguna manera.
Si bien esta divulgación describe realizaciones de ejemplo para campos y aplicaciones de ejemplo, debe entenderse que la divulgación no está limitada a lo mismo. Son posibles otras realizaciones y modificaciones a las mismas, y están dentro del alcance de esta divulgación. Por ejemplo, y sin limitar la generalidad de este párrafo, las realizaciones no se limitan al software, hardware, firmware y/o entidades ilustradas en las figuras y/o descritas en el presente documento. Además, las realizaciones (se describan o no explícitamente en el presente documento) tienen una utilidad significativa para campos y aplicaciones más allá de los ejemplos descritos en el presente documento.
Las realizaciones se han descrito en el presente documento con la ayuda de bloques de construcción funcionales que ilustran la implementación de funciones específicas y las relaciones de las mismas. Los límites de estos componentes básicos funcionales se han definido arbitrariamente en el presente documento por conveniencia de la descripción. Pueden definirse límites alternativos siempre que las funciones especificadas y las relaciones (o equivalentes de las mismas) se realicen apropiadamente. También, las realizaciones alternativas pueden realizar bloques funcionales, etapas, operaciones, métodos, etc. usando ordenaciones diferentes a las descritas en el presente documento.
Las referencias en el presente documento a "una realización", "una realización de ejemplo", "algunas realizaciones" u oraciones similares, indican que la realización descrita puede incluir un rasgo, estructura o característica particular, pero cada realización puede no necesariamente incluir el rasgo, estructura o característica particular. Además, tales expresiones no hacen referencia necesariamente a la misma realización. Además, cuando un rasgo, estructura o característica en particular se describe en relación con una realización, los expertos en la materia tendrían conocimiento de ello para incorporar tal rasgo, estructura o característica en otras realizaciones, ya se hayan o no mencionados o descritos explícitamente en el presente documento.
Adicionalmente, algunas realizaciones pueden describirse usando la expresión "acoplado" y "conectado" junto con sus derivadas. Estos términos no necesariamente pretenden ser sinónimos entre sí. Por ejemplo, algunas realizaciones pueden describirse usando los términos "conectado" y/o "acoplado" para indicar que dos o más elementos están en contacto físico o eléctrico directo entre sí. Sin embargo, el término "acoplado" también puede significar que dos o más elementos no están en contacto directo entre sí, pero aún pueden cooperar o interactuar entre sí.
El alcance de esta divulgación no debería limitarse por cualesquiera de las realizaciones de ejemplo anteriormente descritas, sino que debería definirse únicamente de acuerdo con las siguientes reivindicaciones.

Claims (30)

REIVINDICACIONES
1. Un sistema para la gestión periódica de claves criptográficas, comprendiendo el sistema:
una pluralidad de procesadores informáticos, que comprenden un primer procesador informático (3714, 3814, 3914) en un primer dispositivo de editor de flujo de datos (3718, 3818, 3918), un segundo procesador informático (3732, 3832) en un dispositivo de extremo trasero, y un tercer procesador informático (3752, 3852, 3952) en un primer dispositivo de suscriptor (3754, 3854, 3954);
una primera memoria acoplada comunicativamente con el primer procesador informático, una segunda memoria acoplada comunicativamente con el segundo procesador informático (3732, 3832), y una tercera memoria acoplada comunicativamente con el tercer procesador informático (3752, 3852, 3952), almacenando la segunda memoria instrucciones ejecutables por ordenador que, cuando se ejecutan, provocan al menos que:
el segundo procesador informático (3732, 3832) reciba una primera entrada que asocia un primer conjunto de suscriptores con un primer flujo de datos publicado por el primer dispositivo de editor de flujo de datos (3718, 3818, 3918);
el segundo procesador informático (3732, 3832) reciba, a través de un servicio de intermediario de claves (3734, 3834), una primera clave criptográfica;
el segundo procesador informático (3732, 3832) transmita una primera confirmación, que indica que la primera clave criptográfica está lista para su uso;
el segundo procesador informático (3732, 3832) libere, a través del servicio de intermediario de claves (3734, 3834), la primera clave criptográfica a al menos el primer conjunto de suscriptores que comprende el primer dispositivo de suscriptor (3754, 3854, 3954), en donde la primera clave criptográfica es la misma para cada suscriptor en el primer conjunto de suscriptores;
el segundo procesador informático (3732, 3832) reciba una segunda entrada, de un usuario de editor (3710, 3810), asociando un segundo conjunto de suscriptores con el primer flujo de datos publicado por el primer dispositivo de editor de flujo de datos (3718, 3818, 3918), en donde el segundo conjunto de suscriptores excluye el primer dispositivo de suscriptor (3754, 3854, 3954);
el segundo procesador informático (3732, 3832) reciba, a través del servicio de intermediario de claves (3734, 3834), una segunda clave criptográfica después de que haya transcurrido una cantidad de tiempo predeterminada, en donde la segunda clave criptográfica es ineficaz para descifrar datos que pueden descifrarse utilizando la primera clave criptográfica;
el segundo procesador informático (3732, 3832) transmita una segunda confirmación, que indica que la segunda clave criptográfica está lista para su uso; y
el segundo procesador informático (3732, 3832) libere la segunda clave criptográfica a al menos el segundo conjunto de suscriptores, por lo que el primer dispositivo de suscriptor (3754, 3854, 3954), incluido en el primer conjunto de suscriptores pero excluido del segundo conjunto de suscriptores, no puede descifrar, utilizando la primera clave criptográfica, datos cifrados que requieren la segunda clave criptográfica, en lugar de la primera clave criptográfica, para descifrar los datos cifrados, independientemente del acceso al primer flujo de datos por el primer dispositivo de suscriptor (3754, 3854, 3954), y en donde la segunda clave criptográfica es la misma para cada suscriptor en el segundo conjunto de suscriptores.
2. El sistema de la reivindicación 1, en donde el primer procesador informático está configurado además para emitir una señal para dar instrucción al menos a un dispositivo, que comprende el primer dispositivo de editor de flujo de datos (3718, 3818, 3918), para que deje de usar un primer algoritmo de generación de claves.
3. El sistema de la reivindicación 1, en donde, en respuesta a la segunda entrada y después de que haya transcurrido de nuevo la cantidad de tiempo predeterminada, el segundo procesador informático (3732, 3832) está configurado además para reemplazar la segunda clave criptográfica con una tercera clave criptográfica.
4. El sistema de la reivindicación 1, en donde la segunda entrada comprende:
la selección, por el usuario editor (3710, 3810), del primer dispositivo de suscriptor (3754, 3854, 3954), a partir del primer conjunto de suscriptores, y
la revocación de un permiso de acceso concedido previamente al primer dispositivo de suscriptor (3754, 3854, 3954), de modo que el segundo conjunto de suscriptores excluye al primer dispositivo de suscriptor (3754, 3854, 3954).
5. El sistema de la reivindicación 1, en donde el segundo procesador informático (3732, 3832) está configurado además para transmitir una tercera confirmación de que está disponible al menos una de la primera clave criptográfica o la segunda clave criptográfica, después de haber sido cargada por el servicio de intermediario de claves (3734, 3834).
6. El sistema de la reivindicación 1, en donde el primer flujo de datos publicado por el primer dispositivo de editor de flujo de datos (3718, 3818, 3918) está asociado a un contrato inteligente asociado al servicio de intermediario de claves (3734, 3834), y en donde el primer flujo de datos se convierte a testigos a través del contrato inteligente.
7. El sistema de la reivindicación 6, en donde para liberar la primera clave criptográfica, el segundo procesador informático (3732, 3832) está configurado además para asociar la primera clave criptográfica al contrato inteligente; y, en donde para liberar la segunda clave criptográfica, el segundo procesador informático (3732, 3832) está configurado además para reemplazar la primera clave criptográfica con la segunda clave criptográfica como una clave criptográfica actual asociada al contrato inteligente.
8. El sistema de la reivindicación 7, en donde el segundo procesador informático (3732, 3832) está configurado para recibir, a través del servicio de intermediario de claves (3734, 3834), una solicitud del tercer procesador informático (3752, 3852, 3952) para la clave criptográfica actual asociada al contrato inteligente.
9. El sistema de la reivindicación 8, en donde el contrato inteligente se encuentra en una plataforma de cadena de bloques sin permiso descentralizada y asociada al servicio de intermediario de claves (3734, 3834), y en donde el primer flujo de datos se convierte a testigos a través del contrato inteligente.
10. El sistema de la reivindicación 7, en donde para liberar la primera clave criptográfica, el segundo procesador informático (3732, 3832) está configurado además para asociar el primer conjunto de suscriptores al contrato inteligente; y en donde para liberar la segunda clave criptográfica, el segundo procesador informático (3732, 3832) está configurado además para asociar el segundo conjunto de suscriptores al contrato inteligente, en lugar del primer conjunto de suscriptores.
11. El sistema de la reivindicación 1, en donde la primera clave criptográfica y la segunda clave criptográfica son generadas por el primer dispositivo de editor de flujo de datos (3718, 3818, 3918) que incluye el primer procesador informático y son recibidas por el segundo procesador informático (3732, 3832) desde el primer dispositivo de editor de flujo de datos (3718, 3818, 3918).
12. El sistema de la reivindicación 1, en donde el primer procesador informático está configurado además para transmitir un anuncio a al menos un dispositivo de suscriptor, que comprende el tercer procesador informático (3752, 3852, 3952), de que está disponible una nueva clave criptográfica indexada.
13. El sistema de la reivindicación 12, en donde el anuncio se transmite en respuesta a una solicitud del al menos un dispositivo de suscriptor al primer procesador informático.
14. El sistema de la reivindicación 1, en donde la primera clave criptográfica y la segunda clave criptográfica se reciben desde un generador de claves criptográficas en el sistema utilizando al menos una fuente de entropía (3712, 3812, 3912), en donde la primera clave criptográfica es transmitida a través del servicio intermediario de claves (3734, 3834) al segundo procesador informático (3732, 3832) por el primer dispositivo de editor de flujo de datos (3718, 3818, 3918) como la primera confirmación que indica que la primera clave criptográfica está lista para su uso, y en donde la segunda clave criptográfica es transmitida a través del servicio de intermediario de claves (3734, 3834) al segundo procesador informático (3732, 3832) por el primer dispositivo de editor de flujo de datos (3718, 3818, 3918) como la segunda confirmación que indica que la segunda clave criptográfica está lista para su uso.
15. Un aparato para la gestión periódica de claves criptográficas en un editor de flujo de datos, comprendiendo el aparato:
al menos un dispositivo de memoria configurado para almacenar instrucciones ejecutables por ordenador; y al menos un procesador informático acoplado comunicativamente con la al menos una memoria, pudiendo configurarse el al menos un procesador informático, a través de al menos las instrucciones ejecutables por ordenador, para realizar operaciones que comprenden:
cargar una primera clave criptográfica;
transmitir la primera clave criptográfica;
recibir una primera confirmación de que la primera clave criptográfica está lista para su uso;
cifrar al menos una primera carga útil de datos, en donde la al menos una primera carga útil de datos, una vez cifrada, requiere la primera clave criptográfica para cualquier descifrado posterior de la al menos una primera carga útil de datos;
publicar, a través de un flujo de datos, la al menos una primera carga útil de datos como cifrada;
cargar una segunda clave criptográfica, en respuesta a al menos un primer factor que comprende una indicación de que ha transcurrido una cantidad de tiempo periódica predeterminada;
transmitir la segunda clave criptográfica;
emitir una primera notificación de si la segunda clave criptográfica está lista para su uso;
recibir una segunda confirmación de que la segunda clave criptográfica está lista para su uso;
cifrar al menos una segunda carga útil de datos, en donde la al menos una segunda carga útil de datos, una vez cifrada, requiere la segunda clave criptográfica, en lugar de la primera clave criptográfica, para cualquier descifrado posterior de la al menos una segunda carga útil de datos, y en donde la primera clave criptográfica es ineficaz para descifrar la al menos una segunda carga útil de datos; y
publicar, a través del flujo de datos, la al menos una segunda carga útil de datos como cifrada.
16. El aparato de la reivindicación 15, en donde el al menos un procesador informático está configurado además para cargar una tercera clave criptográfica después de que haya transcurrido de nuevo la cantidad de tiempo predeterminada, en respuesta a un segundo factor que comprende un reemplazo de la segunda clave criptográfica con la tercera clave criptográfica.
17. El aparato de la reivindicación 15, en donde para cargar la primera clave criptográfica, el al menos un procesador informático está configurado además para realizar un primer algoritmo de generación de claves.
18. El aparato de la reivindicación 17, en donde para cargar la segunda clave criptográfica, el al menos un procesador informático está configurado además para realizar un segundo algoritmo de generación de claves, en respuesta a una señal para dejar de usar el primer algoritmo de generación de claves.
19. El aparato de la reivindicación 17, en donde para realizar el primer algoritmo de generación de claves, el al menos un procesador informático está configurado además para generar entropía desde al menos una fuente de hardware integrada en el aparato.
20. El aparato de la reivindicación 17, en donde para realizar el primer algoritmo de generación de claves, el al menos un procesador informático está configurado además para generar entropía desde al menos una fuente de hardware remota del aparato y acoplada comunicativamente con el al menos un procesador informático a través de una interfaz de red, en donde la al menos una fuente de hardware comprende otro aparato.
21. El aparato de la reivindicación 15, en donde para cargar la primera clave criptográfica, el al menos un procesador informático está configurado además para recibir la primera clave criptográfica.
22. El aparato de la reivindicación 15, en donde para cifrar la al menos una primera carga útil de datos, el al menos un procesador está configurado para realizar un primer algoritmo de cifrado para su publicación a través del flujo de datos, en donde, antes de que se realice el primer algoritmo de cifrado, se ha cifrado la al menos una primera carga útil de datos usando uno del primer algoritmo de cifrado o un segundo algoritmo de cifrado, y en donde se requiere una tercera clave criptográfica para descifrar la carga útil de datos cifrados.
23. El aparato de la reivindicación 15, en donde la primera clave criptográfica es parte de un primer par de claves asimétricas, y en donde la segunda clave criptográfica es una parte correspondiente de un segundo par de claves asimétricas.
24. El aparato de la reivindicación 15, en donde el al menos un procesador informático está configurado además para anunciar que está disponible al menos una de la primera clave criptográfica o la segunda clave criptográfica.
25. El aparato de la reivindicación 15, en donde el flujo de datos está asociado a un contrato inteligente en una plataforma de cadena de bloques asociada a un servicio de intermediario de claves (3734, 3834), y en donde el flujo de datos se convierte a testigos a través del contrato inteligente.
26. El aparato de la reivindicación 15, que comprende además un sensor ambiental, un monitor de biotelemetría, un dispositivo de geolocalización, un dispositivo de seguimiento de posición, un dispositivo de contabilidad de inventario, un dispositivo contador de tráfico, un dispositivo de medición de flujo o una combinación de los mismos.
27. El aparato de la reivindicación 15, que comprende además las operaciones de:
asociar la primera clave criptográfica a un primer valor de índice;
asociar la segunda clave criptográfica a un segundo valor de índice; y
transmitir, con la segunda clave criptográfica, el segundo valor de índice a un servicio de extremo trasero que comprende un servicio de intermediario de claves (3734, 3834).
28. El aparato de la reivindicación 27, que comprende además las operaciones de:
emitir una segunda notificación, al servicio de extremo trasero, de que la primera clave criptográfica está lista para su uso, en respuesta a una primera solicitud de si la primera clave criptográfica está lista para su uso; y emitir una tercera notificación, al servicio de extremo trasero, de que la primera clave criptográfica está lista para su uso, en respuesta a una segunda solicitud de si la primera clave criptográfica está lista para su uso.
29. Un aparato para la gestión periódica de claves criptográficas en un proveedor de servicios de extremo trasero, comprendiendo el aparato:
al menos un dispositivo de memoria configurado para almacenar instrucciones ejecutables por ordenador; y al menos un procesador informático acoplado comunicativamente con la al menos una memoria, pudiendo configurarse el al menos un procesador informático, a través de al menos las instrucciones ejecutables por ordenador, para realizar operaciones que comprenden:
recibir una primera entrada que asocia un primer conjunto de suscriptores a un primer flujo de datos publicado por un dispositivo de editor de flujos de datos;
recibir, a través de un servicio de intermediario de claves (3734, 3834), una primera clave criptográfica; transmitir una primera confirmación, que indica que la primera clave criptográfica está lista para su uso; liberar, a través del servicio de intermediario de claves (3734, 3834), la primera clave criptográfica a al menos el primer conjunto de suscriptores que comprende un primer dispositivo de suscriptor (3754, 3854, 3954), en donde la primera clave criptográfica es la misma para cada suscriptor en el primer conjunto de suscriptores; recibir una segunda entrada, de un usuario de editor (3710, 3810), que asocia un segundo conjunto de suscriptores al primer flujo de datos publicado por el dispositivo de editor de flujo de datos, en donde el segundo conjunto de suscriptores excluye el primer dispositivo de suscriptor (3754, 3854, 3954);
recibir, a través del servicio de intermediario de claves (3734, 3834), una segunda clave criptográfica después de que haya transcurrido una cantidad de tiempo predeterminada, en donde la segunda clave criptográfica es ineficaz para descifrar datos que pueden descifrarse utilizando la primera clave criptográfica;
transmitir una segunda confirmación, que indica que la segunda clave criptográfica está lista para su uso; y liberar la segunda clave criptográfica a al menos el segundo conjunto de suscriptores, en donde la segunda clave criptográfica es la misma para cada suscriptor en el segundo conjunto de suscriptores.
30. Un dispositivo de almacenamiento legible por ordenador no transitorio que tiene instrucciones almacenadas en el mismo, en donde las instrucciones, cuando son ejecutadas por al menos un procesador informático, hacen que el al menos un procesador informático realice operaciones que comprenden:
cargar una primera clave criptográfica;
transmitir la primera clave criptográfica a un servicio de extremo trasero;
confirmar que la primera clave criptográfica está lista para su uso;
cifrar al menos una primera carga útil de datos, en donde la al menos una primera carga útil de datos, una vez cifrada, requiere la primera clave criptográfica para cualquier descifrado posterior de la al menos una primera carga útil de datos;
publicar, a través de un flujo de datos, la al menos una primera carga útil de datos como cifrada;
cargar una segunda clave criptográfica, en respuesta a al menos un primer factor que comprende una indicación de que ha transcurrido una cantidad de tiempo periódica predeterminada;
transmitir la segunda clave criptográfica al servicio de extremo trasero;
confirmar que la segunda clave criptográfica está lista para su uso;
cifrar al menos una segunda carga útil de datos, en donde la al menos una segunda carga útil de datos, una vez cifrada, requiere la segunda clave criptográfica, en lugar de la primera clave criptográfica, para cualquier descifrado posterior de la al menos una segunda carga útil de datos, y en donde la primera clave criptográfica es ineficaz para descifrar la al menos una segunda carga útil de datos; y
publicar, a través del flujo de datos, la al menos una segunda carga útil de datos como cifrada.
ES20204830T 2020-04-29 2020-10-30 Esquema de cifrado de multidifusión para plataforma de propiedad de datos Active ES2925190T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US16/861,760 US10771243B1 (en) 2020-04-29 2020-04-29 Multicast encryption scheme for data-ownership platform

Publications (1)

Publication Number Publication Date
ES2925190T3 true ES2925190T3 (es) 2022-10-14

Family

ID=72290178

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20204830T Active ES2925190T3 (es) 2020-04-29 2020-10-30 Esquema de cifrado de multidifusión para plataforma de propiedad de datos

Country Status (12)

Country Link
US (2) US10771243B1 (es)
EP (1) EP3905583B1 (es)
JP (1) JP7159388B2 (es)
KR (1) KR102312857B1 (es)
AU (1) AU2021265575A1 (es)
CA (1) CA3100810C (es)
DK (1) DK3905583T3 (es)
ES (1) ES2925190T3 (es)
IL (1) IL297755A (es)
LT (1) LT3905583T (es)
SG (1) SG10202100396YA (es)
WO (1) WO2021220161A1 (es)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9584492B2 (en) * 2014-06-23 2017-02-28 Vmware, Inc. Cryptographic proxy service
US11354439B2 (en) * 2020-06-03 2022-06-07 International Business Machines Corporation Content control through third-party data aggregation services
CN113141582B (zh) * 2021-04-25 2022-09-20 深圳市元征科技股份有限公司 日志导出方法、装置、计算机设备以及存储介质
KR20240024853A (ko) * 2021-06-22 2024-02-26 리들 & 코드 게엠베하 내장형 데이터 수집
WO2024052319A1 (en) * 2022-09-09 2024-03-14 Nchain Licensing Ag Computer-implemented methods and systems for improved communications across a blockchain network

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748736A (en) 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
JP4574122B2 (ja) * 2003-03-31 2010-11-04 キヤノン株式会社 基地局、および、その制御方法
US7376652B2 (en) 2003-06-17 2008-05-20 The Hayes-Roth Family Trust Personal portal and secure information exchange
US8341427B2 (en) * 2009-02-16 2012-12-25 Microsoft Corporation Trusted cloud computing and services framework
US8625803B1 (en) * 2011-05-31 2014-01-07 Google Inc. Updating shared keys
US9461983B2 (en) * 2014-08-12 2016-10-04 Danal Inc. Multi-dimensional framework for defining criteria that indicate when authentication should be revoked
US9942034B2 (en) * 2015-02-13 2018-04-10 Visa International Service Association Confidential communication management
US10230696B2 (en) * 2015-06-09 2019-03-12 Intel Corporation System, apparatus and method for managing lifecycle of secure publish-subscribe system
US20170116693A1 (en) 2015-10-27 2017-04-27 Verimatrix, Inc. Systems and Methods for Decentralizing Commerce and Rights Management for Digital Assets Using a Blockchain Rights Ledger
US20170134161A1 (en) 2015-11-06 2017-05-11 Cable Television Laboratories, Inc Blockchaining for media distribution
US10574440B2 (en) * 2016-05-06 2020-02-25 ZeroDB, Inc. High-performance access management and data protection for distributed messaging applications
US11276038B2 (en) 2016-08-07 2022-03-15 Verifi Media, Inc. Distributed data store for managing media
US10491378B2 (en) 2016-11-16 2019-11-26 StreamSpace, LLC Decentralized nodal network for providing security of files in distributed filesystems
CA2958668A1 (en) 2017-02-23 2018-08-23 Scenarex Inc. Methods and apparatus for integrating digital rights management into an existing blockchain
EP3422221A1 (en) 2017-06-29 2019-01-02 Nokia Technologies Oy Electronic health data access control
US10938950B2 (en) 2017-11-14 2021-03-02 General Electric Company Hierarchical data exchange management system
US10715323B2 (en) * 2017-12-29 2020-07-14 Ebay Inc. Traceable key block-chain ledger
PL3512228T3 (pl) 2018-01-10 2023-12-27 E.ON Digital Technology GmbH Sposób bezpiecznego dostarczania wyników analizy i urządzenie czujnikowe do ustalania autentycznych danych
JP6936169B2 (ja) * 2018-02-27 2021-09-15 ヤフー株式会社 認証器管理装置、認証器管理方法、認証器管理プログラム及び認証器管理システム
CN108683705B (zh) 2018-04-10 2021-03-16 北京工业大学 基于区块链的物联网数据共享方法
US10740475B2 (en) * 2018-05-03 2020-08-11 Salesforce.Com, Inc. Method and system for enabling log record consumers to comply with regulations and requirements regarding privacy and the handling of personal data
US10944734B2 (en) * 2018-08-17 2021-03-09 Cisco Technology, Inc. Creating secure encrypted broadcast/multicast groups over wireless network
CN108964911A (zh) 2018-09-18 2018-12-07 苏州米特希赛尔人工智能有限公司 一种基于区块链和量子流数据块技术的流媒体服务系统
US12003957B2 (en) * 2018-10-04 2024-06-04 Google Llc Distributed network cellular identity management
CN109547818A (zh) 2018-12-11 2019-03-29 深圳市汇星数字技术有限公司 一种视频内容去中心化保密分发方法
EP3734605A1 (en) * 2019-04-30 2020-11-04 Ypsomed AG Secure drug delivery data transmission

Also Published As

Publication number Publication date
EP3905583B1 (en) 2022-07-06
US20210344484A1 (en) 2021-11-04
AU2021265575A1 (en) 2022-12-22
JP7159388B2 (ja) 2022-10-24
SG10202100396YA (en) 2021-11-29
IL297755A (en) 2022-12-01
CA3100810C (en) 2021-09-28
DK3905583T3 (da) 2022-09-05
EP3905583A1 (en) 2021-11-03
LT3905583T (lt) 2022-10-25
WO2021220161A1 (en) 2021-11-04
KR102312857B1 (ko) 2021-10-13
US10771243B1 (en) 2020-09-08
CA3100810A1 (en) 2021-05-18
JP2021175193A (ja) 2021-11-01

Similar Documents

Publication Publication Date Title
ES2925190T3 (es) Esquema de cifrado de multidifusión para plataforma de propiedad de datos
EP3602952B1 (en) Method and system for identity and access management for blockchain interoperability
US10204339B2 (en) Method and system for blockchain-based combined identity, ownership, integrity and custody management
US11281779B2 (en) Systems and methods for privacy management using a digital ledger
US10469887B2 (en) Technologies for selective content licensing and secure playback
KR101591255B1 (ko) 클라이언트로부터 생성되는 정보에 대한 차동 클라이언트측 암호화
WO2017128870A1 (zh) 信息处理方法、第一终端、第二终端、服务器及系统
EP2661862A2 (en) Systems and methods for providing individual electronic document secure storage, retrieval and use
Htet Hlaing et al. Secure content distribution with access control enforcement in named data networking
US11722470B2 (en) Encrypted data according to a schema
CN115953244A (zh) 基于区块链的交易监管方法、装置、电子设备和存储介质
CN115599959A (zh) 数据共享方法、装置、设备及存储介质
Feng et al. A blockchain-based efficient and verifiable attribute-based proxy re-encryption cloud sharing scheme
Sun et al. An Identity Privacy-Preserving Scheme against Insider Logistics Data Leakage Based on One-Time-Use Accounts
Kaur et al. Enhanced Security Mechanism in Cloud Based on DNA Excess 3 Codes
CN113312637B (zh) 代理服务器及其对加密的订阅与事件进行匹配的方法
Shiny et al. BSSPD: A BLOCKCHAIN-BASED SECURITY SHARING SCHEME FOR PERSONAL DATA WITH FINE-GRAINED ACCESS CONTROL
Gao et al. Blockchain-enabled supervised secure data sharing and delegation scheme in Web3. 0
Ennasraoui et al. Security Analysis in the Internet of Things: State of the Art, Challenges, and Future Research Topics
KR20210063993A (ko) 공급망 공간에서 제품 스토리를 조정하기 위한 프로버넌스 기반 솔루션
Ilakiya et al. Efficient User Revocation Mechanism for Privilege and Anonymity in Control Cloud Data Access