ES2912050T3 - Sistema de identidad basado en cadenas de bloques - Google Patents

Sistema de identidad basado en cadenas de bloques Download PDF

Info

Publication number
ES2912050T3
ES2912050T3 ES19701762T ES19701762T ES2912050T3 ES 2912050 T3 ES2912050 T3 ES 2912050T3 ES 19701762 T ES19701762 T ES 19701762T ES 19701762 T ES19701762 T ES 19701762T ES 2912050 T3 ES2912050 T3 ES 2912050T3
Authority
ES
Spain
Prior art keywords
identity
instance
attributes
validation
hash values
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
ES19701762T
Other languages
English (en)
Inventor
Frank-Michael Kamm
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.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient Mobile Security GmbH
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 Giesecke and Devrient Mobile Security GmbH filed Critical Giesecke and Devrient Mobile Security GmbH
Application granted granted Critical
Publication of ES2912050T3 publication Critical patent/ES2912050T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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/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
    • 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/3242—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 keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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/3271—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 challenge-response
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Power Engineering (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Procedimiento para comprobar de manera confidencial una identidad empleando una lista encadenada criptográficamente, que presenta las etapas de: - facilitar (100, 1A) atributos de identidad de la identidad junto con una información de clave simétrica mediante una instancia de usuario; - calcular (101, 2A) en cada caso un valor hash para cada atributo de identidad empleando la clave simétrica como hash codificado, de tal modo que, aun conociendo el atributo de identidad, no sea posible deducir la identidad; - registrar (102, 3A) los valores hash calculados (101, 2A) como al menos una entrada de lista en la lista encadenada criptográficamente; - transferir (103, 4A) una dirección de la al menos una entrada de lista junto con la información de clave simétrica desde la instancia de usuario a una instancia de validación; - validar (104, 5A) la al menos una entrada de lista que presenta los valores hash calculados (101, 2A) empleando un documento de identidad que presenta los atributos de identidad, mediante la instancia de validación, comprobándose si los valores hash de los atributos de identidad, facilitados (100, 1A) y guardados en la dirección, coinciden con los atributos de identidad del documento de identidad, y - registrar (105, 6A) una firma de la al menos una entrada de lista en la lista encadenada criptográficamente en el caso de una validación (104, 5A) positiva de los atributos de identidad mediante la instancia de validación, - en donde los valores hash son valores hash codificados.

Description

DESCRIPCIÓN
Sistema de identidad basado en cadenas de bloques
La presente invención está dirigida a un procedimiento para comprobar de manera confidencial una identidad electrónica, en donde se emplea una denominada cadena de bloques. El procedimiento permite que un actor pueda identificar una identidad de cadena de bloques, pero garantizando un nivel de confidencialidad de la identidad respectiva junto con atributos de identidad. La presente invención está dirigida además a un sistema de identidad configurado de manera correspondiente, así como a un producto de programa informático con instrucciones de mando que implementan el procedimiento o hacen funcionar la disposición de sistema propuesta.
El documento CN 106682530 A1 muestra un procedimiento para compartir información médica garantizando la confidencialidad. En este sentido se emplea, entre otras cosas, la denominada tecnología de cadena de bloques. El documento US 9.635.000 B1 muestra un sistema para administrar identidades en una red informática.
El documento US 2017/0149819 A1 muestra una red informática en la que están implementados mecanismos de seguridad que están orientados igualmente a la tecnología de cadena de bloques.
El estado de la técnica trata las más diversas aplicaciones para la tecnología de cadena de bloques. Se conoce la criptomoneda Bitcoin, así como otras muchas criptomonedas. Además, los bancos y aseguradoras están experimentando con cadenas de datos para el tráfico interbancario y para plataformas de comercio. Otras aplicaciones tratadas son registros públicos (por ejemplo: registro de la propiedad), así como plataformas de identidad. En estas últimas se trata de reproducir identidades electrónicas en una cadena de bloques y emplear la cadena de bloques como una especie de memoria para un sistema de administración de identidades.
Además del enfoque con cadena de bloques existen los sistemas clásicos de administración de identidades basados en bases de datos, así como toda una serie de sistemas de identidad móviles, por ejemplo, basados en UICC, otros testigos o basados en tarjetas a través de tarjetas de identidad electrónicas. La ventaja del enfoque de la cadena de bloques es que no se necesita ninguna instancia central que administre una plataforma de identidad.
Un problema hasta ahora no resuelto satisfactoriamente en aplicaciones de identidad basadas en cadenas de bloques es el tema de la privacidad (privacy) versus confianza. Por un lado un consumidor de la identidad de cadena de bloques (relying party, parte de confianza) debe poder identificar el nivel de confianza con el que ha adquirido y confirmado una determinada identidad (o atributos de identidad). Por otro lado, estos atributos de identidad, especialmente en una cadena de bloques pública, no deben ser de acceso libre ni deben poder asociarse entre sí o a una persona real. Además, no debe poder reconocerse con qué partes de confianza está relacionada una determinada identidad. El usuario además debe tener la posibilidad de decidir qué atributos (individuales) presenta frente a una parte de confianza y cuáles no. Los atributos no presentados no deben poder asociarse a este respecto a los atributos presentados.
Por consiguiente, un objetivo de la presente invención es facilitar un procedimiento que permita comprobar una identidad electrónica de tal manera que el procedimiento pueda ejecutarse de manera descentralizada en una red y además se garantice una protección de la confianza lo mayor posible del titular de la identidad. Esto será posible empleando infraestructuras existentes y por consiguiente implicará únicamente un esfuerzo técnico reducido. Además, un objetivo de la presente invención es proponer un sistema de identidad configurado de manera correspondiente, así como un producto de programa informático que presenta instrucciones de mando para llevar a cabo el procedimiento o para hacer funcionar el sistema.
El objetivo se resuelve mediante las características de las reivindicaciones independientes. Otras configuraciones ventajosas están indicadas en las reivindicaciones dependientes.
Según esto se propone un procedimiento para comprobar de manera confidencial una identidad empleando una lista encadenada criptográficamente. En este sentido se trata preferiblemente de una denominada cadena de bloques. El procedimiento comprende las etapas de facilitar atributos de identidad de la identidad junto con una información de clave simétrica mediante una instancia de usuario, calcular en cada caso un valor hash para cada atributo de identidad utilizando la clave simétrica (keyed Hash), de tal modo que, aun conociendo el atributo de identidad, no sea posible deducir el valor hash de la identidad, registrar los valores hash calculados como al menos una entrada de lista en la lista encadenada criptográficamente, transferir una dirección de la al menos una entrada de lista junto con la información de clave simétrica desde la instancia de usuario a una instancia de validación, validar la al menos una entrada de lista que presenta los valores hash calculados empleando un documento de identidad que presenta el atributo de identidad, mediante la instancia de validación, comprobándose si los atributos de identidad, facilitados y guardados en la dirección, coinciden con los atributos de identidad del documento de identidad, y registrar una firma de la al menos una entrada de lista en la lista encadenada criptográficamente en el caso de una validación positiva del atributo de identidad mediante la instancia de validación.
El experto en la técnica reconoce en este sentido que las etapas de procedimiento individuales pueden presentar subetapas. También las etapas individuales pueden ejecutarse iterativamente de tal modo que, por ejemplo, varios datos o atributos pueden transmitirse individualmente o pueden ejecutarse etapas de cálculo secuencialmente o en paralelo.
Mediante el sistema de identidad propuesto se asegurará la privacidad del usuario, mientras que al mismo tiempo una parte de confianza es capaz de valorar el nivel de confianza de atributos de identidad. A este respecto, en una tercera instancia no puede verse con qué parte de confianza está relacionada una identidad determinada. Pueden desvelarse atributos individualmente sin que puedan asociarse a este respecto los atributos no desvelados. Una tercera instancia tampoco puede asociar identidades aunque se conozcan públicamente atributos individuales. Además no es necesario hacer funcionar, adicionalmente a la cadena de bloques, un servicio de nube en el que estén almacenados los atributos propiamente dichos.
Adicionalmente, con el esquema puede crearse una identidad basada en la reputación en la que, por ejemplo, se hayan validado atributos individuales con frecuencia, pero con una confianza más reducida, mientras que otros atributos eventualmente se validaron con menor frecuencia, pero a cambio con un nivel de confianza más alto. El concepto básico se clasifica en las etapas “A. identificación inicial” (enrolment, validation) y “B. uso de la identidad”:
A. Identificación inicial:
Para registrar inicialmente una identidad, según un aspecto de la presente invención se llevan a cabo las siguientes etapas:
1. Un usuario final establece (por ejemplo, en una aplicación móvil o a través de una interfaz web) los atributos que desea validar, incluyendo su contenido (por ejemplo, nombre, fecha de nacimiento, lugar de nacimiento, ...); 2. Se genera una clave simétrica que se emplea para el cálculo de un valor hash codificado de los atributos. Para cada atributo se calcula un valor hash independiente. Mediante el uso de un procedimiento hash codificado no es posible para terceros, en caso de atributos conocidos (por ejemplo, nombre), asociar la identidad sin conocer la clave;
3. El usuario final publica los valores hash codificados de sus atributos en la cadena de bloques. Hasta ahora ha declarado los atributos solo él mismo, pero no han sido validados todavía por terceros;
4. En la siguiente etapa, el usuario se dirige a un servicio de validación que es capaz de verificar identidades (por ejemplo, con un procedimiento VideoIdent, en una sucursal, etc.). El usuario presenta a este servicio su dirección de cadena de bloques en la que están guardados los valores hash codificados de los atributos. Además presenta la clave para el cálculo hash con la cual el servicio puede comprobar que los valores hash son correctos, así como un documento de identidad;
5. El servicio lleva a cabo una identificación mediante la cadena de bloques y compara los atributos declarados por él mismo a partir de esta con los datos del documento de identidad. Si los datos coinciden, el servicio lleva a cabo una transacción de cadena de bloques a la dirección del usuario en la que entrega una firma a través de los valores hash, así como el nivel de confianza de la identificación (por ejemplo, según el nivel eIDAS, electronic Identification, Authentication and trust Service). A continuación se borra la información secreta.
6. Dado que los atributos ahora están validados y se ha introducido una firma a través de los valores hash en la cadena de bloques, si fuera necesario, la clave pública del servicio de validación se introduce como certificado con una infraestructura de clave pública PKI correspondiente. Con ello pueden valorar terceros que los atributos se hayan comprobado mediante una institución reconocida y digna de confianza.
B. El uso de la identidad validada puede llevarse a cabo según la invención de la siguiente manera:
1. El usuario final presenta a una parte de confianza su dirección de cadena de bloques, la clave Hash y el contenido de los atributos necesarios.
2. La parte de confianza calcula a partir del contenido de los atributos el valor hash codificado con ayuda de la clave del usuario y lo compara con los datos introducidos en la cadena de bloques. Por lo demás, la parte de confianza comprueba la o las firmas del servicio o de los servicios de validación a través de los datos.
3. Si fuera necesario, la parte de confianza lleva a cabo un protocolo de desafío-respuesta con el usuario para recibir una prueba de que este posee la clave secreta relativa a la cuenta de cadena de bloques. Con ello la parte de confianza tiene la prueba de que también es realmente el propietario de la cuenta de cadena de bloques que comunica los atributos.
4. Después de finalizar la verificación, la parte de confianza borra la clave de usuario.
En una forma de realización de la invención, cada atributo se representa mediante una dirección de cadena de bloques independiente. Con ello adicionalmente es imposible asociar los atributos individuales a una identidad común. La etapa 3 de la fase de uso B se lleva a cabo entonces de manera independiente para cada atributo.
En una forma de realización adicional está previsto que el usuario no pase la clave para calcular el valor hash codificado a la parte de confianza (desde donde potencialmente podría seguir transmitiéndose), sino a un servicio de confianza de su elección, que se encarga entonces de la resolución de los valores hash y de la comparación con los valores de texto no codificado para la parte de confianza (y tras la autorización por parte del usuario, por ejemplo, a través de un protocolo OAuth 2.0).
El procedimiento propuesto sirve para comprobar de manera confidencial la identidad, dado que según la invención se impide que se revelen de manera innecesaria informaciones del titular de la identidad. Así, por ejemplo, según la invención es posible guardar los atributos de identidad individuales, como, por ejemplo, nombre, dirección o fecha de nacimiento, en diferentes posiciones dentro de la lista encadenada criptográficamente. La lista encadenada criptográficamente es preferiblemente una denominada cadena de bloques.
Una cadena de bloques consta de varias entradas de datos que se conectan entre sí y las piezas de unión representan en cada caso valores hash. Por consiguiente, por lo tanto una lista encadenada criptográficamente es una lista que puede ampliarse continuamente de registros de datos, que también se denominan bloques o, en el presente documento, entradas de lista. En este sentido es posible que cada entrada de lista presente un hash criptográficamente seguro del bloque precedente, una marca de fecha y hora y datos de transacción. Según la invención se obtienen también las ventajas de la cadena de bloques convencional, dado que los atributos de identidad individuales pueden codificarse como entradas de lista o bloques.
Para modelar la identidad electrónica se facilitan atributos de identidad, como por ejemplo el nombre del titular de la identidad. Esto puede realizarse manualmente de tal modo que un usuario, a través de la interfaz, da nombre al atributo de identidad y le proporciona un valor. Dado que el usuario únicamente utiliza el sistema, en el presente documento se habla de una instancia de usuario que está orientada al terminal que usa el usuario para la entrada de datos. La instancia de usuario puede ser, por consiguiente, por ejemplo, un terminal móvil con una interfaz web. Así puede proporcionarse al usuario una máscara de entrada en la que este inserta el atributo de identidad.
Para estos atributos de identidad se calcula en cada caso un valor hash que se presenta preferiblemente como un valor hash codificado. Mediante un valor hash codificado de este tipo no es posible que terceros deduzcan la identidad aunque se les presente el atributo de identidad. Mediante el uso de un procedimiento hash codificado de este tipo no es posible que los atacantes, en caso de atributos conocidos, asocien la identidad sin conocer la clave. Por consiguiente, por lo tanto siempre queda garantizada la confidencialidad de la identidad del usuario, lo que es particularmente ventajoso dado que los datos se guardan criptográficamente en la lista encadenada y deben hacerse accesibles a una instancia interrogadora.
Los valores hash calculados se guardan por lo tanto en la cadena de bloques como un bloque o como una entrada de lista. Es posible crear para cada valor hash una entrada de lista propia o también guardar varios valores hash como una única entrada de lista. Según la tecnología de cadena de bloques conocida, los valores hash se incluyen, por lo tanto, en la lista encadenada criptográficamente y se distribuyen a otros nodos de red en términos de tecnología de redes. La dirección de esta entrada de lista o de estas entradas de lista dentro de la cadena de bloques se transfiere junto con la información de clave simétrica desde el usuario a la instancia de validación. Esto permite que la instancia de validación valide las entradas de lista, es decir, compruebe si son correctas.
El usuario al principio ha creado él mismo el atributo de identidad, y por consiguiente en esta etapa de procedimiento es ventajoso comprobar realmente estos datos. Para ello el usuario puede facilitar un documento de identidad, por ejemplo un pasaporte, y llevar a cabo una identificación remota. Por ello, por lo tanto la instancia de validación puede verificar si las entradas de lista de la cadena de bloques que modelan el atributo de identidad son realmente correctas y coinciden con datos del documento de identidad.
Como una posible comprobación se conoce el procedimiento denominado VideoIdent en el que es posible que un usuario, por ejemplo mediante una cámara web, transfiera un documento de identidad. Por consiguiente, la instancia de validación facilita una interfaz de datos que permite al usuario identificarse y así facilitar, sin gran esfuerzo, los atributos de identidad correctos del documento de identidad. En este sentido se conocen otros procedimientos que permiten leer el documento de identidad de tal manera que los atributos de identidad puedan evaluarse. Así, por ejemplo, de un pasaporte puede leerse el nombre y la dirección.
En consecuencia, por lo tanto, los atributos de identidad facilitados se presentan tal como se indicaron por parte del usuario y se presentan a la instancia de validación los atributos de identidad que se han leído del documento de identidad. En particular, por lo tanto, también es posible comparar ambos atributos y comprobar por consiguiente si son correctos. Esto en el presente documento se denomina validación, que transcurre positivamente en el caso de que los atributos de identidad identificados coincidan con los atributos de identidad leídos del documento de identidad. Si estos atributos no coinciden, entonces el usuario quizá haya indicado valores erróneos y esto se detecta. Después se puede dar lugar a que el procedimiento se repita y el usuario deba facilitar de nuevo su atributo de identidad. Es también posible que el atributo de identidad no se haya indicado erróneamente, sino que por el contrario esté teniendo lugar también un ataque que se detecta en la validación. Por consiguiente, en cualquier caso, ante una validación negativa, el procedimiento o bien se interrumpe o bien se lleva a cabo de nuevo.
Por si tiene lugar una validación positiva, se realiza un registro de una firma de la al menos una entrada de lista en la lista encadenada criptográficamente. Por consiguiente, por lo tanto, la entrada de lista que presenta los atributos de identidad o sus valores hash, se firma y se constata que los atributos de identidad están guardados correctamente en la cadena de bloques.
Según un aspecto adicional de la presente invención se realiza una transferencia de la dirección de la al menos una entrada de lista, de la información de clave simétrica y de los atributos de identidad desde la instancia de usuario a una instancia que interroga acerca de la identidad, con lo cual esta instancia interrogadora mediante los datos transferidos comprueba la al menos una entrada de lista registrada que presenta los valores hash calculados. Esto tiene la ventaja de que la instancia interrogadora, denominada también parte de confianza, puede evaluar todos los datos que son necesarios para constatar una identidad, pero una tercera parte no ve con qué parte de confianza está relacionada una determinada identidad. Con los datos transferidos, la instancia interrogadora, es decir, la parte de confianza, puede comprobar los datos guardados en la cadena de bloques, lo cual se lleva a cabo mediante una comparación. La instancia interrogadora puede ser, por ejemplo, una unidad computacional que se comunica a través de una red con la instancia de usuario. Por consiguiente, la instancia interrogadora tiene todas las posibilidades de comprobar una identidad mediante la tecnología de cadena de bloques.
Según un aspecto adicional de la presente invención, la comprobación de la al menos una entrada de lista también comprende una comprobación de la firma registrada. Esto tiene la ventaja de que también pueden tenerse en cuenta las transacciones de la instancia de validación y la firma facilitada por la instancia de validación puede emplearse asimismo para la comprobación. En este sentido, el experto en la técnica conoce procedimientos que muestran cómo debe evaluarse una firma. La denominada parte de confianza puede leer la firma desde la cadena de bloques.
Según un aspecto adicional de la presente invención, entre la instancia de usuario y la instancia interrogadora se lleva a cabo una autenticación de desafío-respuesta. Esto tiene la ventaja de que realmente los datos transmitidos desde la instancia de usuario a la parte de confianza fueron transferidos por el usuario correcto. Esto asegura la comunicación entre la instancia de usuario y la parte de confianza de modo que se impiden escenarios de ataque. El procedimiento desafío-respuesta se inicia normalmente por la parte de confianza y comienza con un mensaje de desafío a la instancia de usuario, que responde con un mensaje de respuesta que, entre otras cosas, contiene una firma del desafío con la clave privada de la instancia de usuario.
Según un aspecto adicional de la presente invención, los valores hash son los denominados valores hash codificados. Esto tiene la ventaja de que mediante este procedimiento no es posible deducir una identidad de atributos de identidad conocidos y, por consiguiente, la identidad siempre permanece oculta aunque puedan leerse los atributos de identidad o sus valores hash a partir de la cadena de bloques.
Según un aspecto adicional de la presente invención, la lista encadenada criptográficamente se presenta como una cadena de bloques. Esto tiene la ventaja de que pueden emplearse mecanismos de seguridad, que se implementaron en el marco de la denominada tecnología de cadena de bloques, aunque según la invención sea posible proteger la información de un acceso no autorizado. Por consiguiente, la tecnología de cadena de bloques se amplía con reglas que garantizan la privacidad del usuario. Por tanto, de este modo puede integrarse el procedimiento propuesto en una infraestructura existente.
Según un aspecto adicional de la presente invención, la validación empleando el documento de identidad comprende un procedimiento de identificación por vídeo. Esto tiene la ventaja de que un usuario puede facilitar sus datos a través de una interfaz basada en red y, por consiguiente, puede asegurarse que realmente también se presentan los datos o atributos de identidad correctos del usuario. Un procedimiento de identificación por vídeo es, por ejemplo, el denominado procedimiento VideoIdent en el que el usuario sostiene un documento de identidad delante de una cámara. A continuación, el documento puede leerse y los datos de usuario se comparan con los atributos de identidad indicados. Alternativas a un procedimiento de identificación por vídeo de este tipo son el procedimiento convencional, en el que el cliente se dirige por ejemplo a una sucursal bancaria y se identifica, o el uso de una tarjeta de identidad electrónica como, por ejemplo, el documento de identidad electrónico. También esto puede combinarse con el presente procedimiento, y los atributos de identidad correctos pueden crearse de este modo.
Según un aspecto adicional de la presente invención, el registro de la firma comprende un registro de un nivel de confianza (Level of Assurance). Esto tiene la ventaja de que puede guardarse un nivel de confianza en la cadena de bloques que describa el grado de confianza en la corrección de la identificación. En este contexto puede emplearse también el reglamento UE sobre identificación electrónica y servicios de confianza para transacciones electrónicas. En particular puede emplearse el nivel de confianza denominado eIDAS. eIDAS significa en este sentido el reglamento europeo sobre identificación electrónica, autenticación y servicios de confianza (IDentification, Authentication and trust Services). Por consiguiente, por lo tanto puede guardarse un valor que indica con qué probabilidad los datos adquiridos desde el documento de identidad son correctos.
Según un aspecto adicional de la presente invención, el registro de los valores hash calculados se realiza en cada caso en diferentes direcciones de la lista encadenada criptográficamente. Esto tiene la ventaja de que los valores hash pueden guardarse en diferentes bloques o entradas de lista y, por consiguiente, un tercero no puede ver que estos valores hash o los atributos de identidad correspondientes están asociados a un perfil o una identidad determinados. Por consiguiente, por lo tanto estos se guardan de manera independiente unos de otros, e inicialmente no existe ninguna relación visible entre estos datos. Por consiguiente se protege de nuevo la privacidad del usuario, y los valores hash no pueden correlacionarse.
Según un aspecto adicional de la presente invención, en una comunicación entre la instancia de usuario, la instancia interrogadora y/o la instancia de validación se intercala una instancia de total confianza. Esto tiene la ventaja de que pueden llevarse a cabo etapas de procedimiento individuales también por parte de una instancia intermedia de este tipo y, por consiguiente, no siempre tienen que transferirse tampoco todos los datos a las instancias respectivas. Por consiguiente, los datos sensibles se distribuyen adicionalmente a través de la red, y no se forman puntos de recopilación de los datos, que pudieran leerse en caso de un acceso no autorizado. Por ejemplo, la clave para el cálculo del valor hash codificado puede no emitirse a la parte de confianza, sino que puede transferirse a un servicio intermedio que se hace cargo entonces de la resolución de los valores hash y de la comparación con los valores de texto no codificado para la parte de confianza.
Según un aspecto adicional de la presente invención, la instancia de usuario, la instancia interrogadora y la instancia de validación están conectadas en términos de tecnología de la comunicación. Esto tiene la ventaja de que la presente invención puede implementarse en el ordenador y todas las instancias implicadas pueden presentarse como unidades computacionales. También la cadena de bloques se enlaza con las instancias en términos de transmisión de datos, para lo cual han de estar previstos componentes de red. Por ejemplo, las instancias individuales pueden ser un servidor o un cliente.
Según un aspecto adicional de la presente invención, la instancia de validación se facilita mediante un servicio basado en red. Esto tiene la ventaja de que puede preverse una interfaz de usuario convencional que lleva a cabo el procedimiento de identificación y lee el documento de identificación. Por consiguiente puede llevarse a cabo una denominada identificación remota.
Según un aspecto adicional de la presente invención, el procedimiento se ejecuta de manera descentralizada en una red de transmisión de datos. Esto tiene la ventaja de que no están previstas instancias centrales que lleven a cabo la administración de identidades, sino que más bien se aplicará la tecnología de cadena de bloques que se basa en una conservación y gestión de datos descentralizadas. Por consiguiente, únicamente los componentes de red, es decir, la infraestructura subyacente, son centrales, lo que significa que en términos de tecnología de redes puede emplearse un servidor, sin embargo las etapas de procedimiento individuales se ejecutan de manera descentralizada. En particular, partes de la cadena de bloques pueden mantenerse de manera redundante y distribuida en la red.
El objetivo se resuelve también mediante un sistema de identidad para comprobar de manera confidencial una identidad empleando una lista encadenada criptográficamente que presenta una instancia de usuario configurada para facilitar atributos de identidad de la identidad junto con una información de clave simétrica, una unidad criptográfica configurada para calcular en cada caso un valor hash para cada atributo de identidad, de tal modo que, aun conociendo el atributo de identidad, no sea posible deducir la identidad, una interfaz de datos configurada para registrar los valores hash calculados como al menos una entrada de lista en la lista encadenada criptográficamente, un componente de red configurado para transferir una dirección de la al menos una entrada de lista junto con la información de clave simétrica de la instancia de usuario a una instancia de validación, la instancia de validación configurada para validar la al menos una entrada de lista que presenta los valores hash calculados empleando un documento de identidad que presenta el atributo de identidad, mediante la instancia de validación, comprobándose si los atributos de identidad, facilitados y guardados en la dirección, coinciden con los atributos de identidad del documento de identidad, y una interfaz de datos adicional configurada para registrar una firma de la al menos una entrada de lista en la lista encadenada criptográficamente en el caso de una validación positiva del atributo de identidad mediante la instancia de validación.
El experto en la técnica reconoce en este sentido que la unidad criptográfica puede estar integrada, por ejemplo, en la instancia de usuario. La interfaz de datos puede presentarse de manera unitaria, siendo también posible implementar diferentes interfaces de datos. Las instancias individuales pueden facilitarse temporalmente en términos físicos o también en términos de tecnología de software.
El objetivo también se resuelve mediante un producto de programa informático con instrucciones de mando que implementan el procedimiento o hacen funcionar el sistema propuesto.
Según la invención es especialmente ventajoso que el procedimiento propuesto presente etapas de procedimiento que faciliten la funcionalidad que puede reproducirse estructuralmente por el sistema. Además, el sistema comprende características estructurales que también pueden reproducirse mediante las etapas de procedimiento. El producto de programa informático sirve tanto para llevar a cabo el procedimiento propuesto como para hacer funcionar el sistema de identidad. Por ejemplo, el producto de programa informático puede comprender también un protocolo de red.
Otros diseños ventajosos se explican con más detalle mediante las figuras adjuntas. Muestran:
la Fig. 1: el sistema de identidad según la invención y rutas de comunicación correspondientes; y
la Fig. 2: un diagrama de flujo esquemático de un procedimiento para comprobar de manera confidencial una identidad según un aspecto de la presente invención.
La figura 1 muestra una estructura esquemática del sistema de identidad, en donde en el lado izquierdo se ofrece una instancia de usuario que sirve para que el usuario final indique 1A el atributo de identidad, con lo que se genera una clave simétrica S que se emplea 2A para el cálculo de los valores hash codificados. Las funcionalidades que se designan con una A sirven para la identificación inicial, y las funcionalidades 1A, 2A, ... 6A corresponden a los puntos, como se han expuesto ya en “A. Identificación inicial” . Las funcionalidades con una B añadida se refieren a la utilización de la identidad validada y las funcionalidades 1B, 2B y 3B correspondientes se corresponden asimismo con los puntos expuestos.
La funcionalidad 3A se refiere a la publicación de los valores hash codificados de los atributos de identidad en la cadena de bloques. Los parámetros, tal como se indican en la presente figura 1, tienen el siguiente significado: Atributos: texto no codificado de los atributos (por ejemplo, nombre, dirección...)
S: Clave simétrica para el cálculo hash codificado
PrivKU / PubKU: “par de claves de usuario” de la cuenta de cadena de bloques
PrivKI, PubKI: par de claves (certificado incluido) del servicio de validación ID
LoA: nivel de seguridad de la verificación ID (por ejemplo, según eIDAS, ISO, NIST,...)
En la figura 1 aparece “Validación ID” para la instancia de validación y “parte de confianza” para la instancia interrogadora, es decir, la unidad que debe fiarse de una identidad de usuario.
Si la instancia de usuario ha guardado los valores hash de los atributos en la cadena de bloques 3A, entonces los atributos junto con la clave S y la dirección de cadena de bloques de los valores hash se envían 4A a la instancia de validación. La instancia de validación ejecuta entonces una denominada identificación remota, que puede realizarse, por ejemplo, empleando un procedimiento VideoIdent. La instancia de validación proporciona 5a , por consiguiente, una funcionalidad para llevar a cabo la identificación, y compara los atributos declarados por el usuario a partir de la cadena de bloques con los datos del documento de identificación. En caso de una validación positiva, el servicio o la instancia de validación lleva a cabo 5A una transacción de cadena de bloques, y los atributos de identificación están por lo tanto validados y una firma correspondiente se guarda 6A en la cadena de bloques.
Después se emplea la identidad introducida, en donde una parte de confianza interrogará acerca de una identidad de un usuario. Para ello el usuario final presenta a la parte de confianza la dirección de cadena de bloques correspondiente, la clave Hash y el contenido de los atributos 1B necesarios. La parte de confianza, es decir, la instancia interrogadora, tiene ante sí ahora todos los datos que necesita para comprobar 2B los datos introducidos en la cadena de bloques y compararlos con los datos facilitados por el usuario. Por consiguiente puede comprobarse por lo tanto si la identidad introducida en la cadena de bloques es realmente correcta. Para ello puede comprobarse 2B por ejemplo una firma de la instancia de validación.
Para comprobar si la clave secreta pertenece a la cuenta de la cadena de bloques del usuario, puede llevarse a cabo 3B un protocolo denominado de desafío-respuesta, que protege la comunicación de datos entre la instancia de usuario y la parte de confianza.
La figura 2 muestra un diagrama de flujo esquemático de un procedimiento para comprobar de manera confidencial una identidad empleando una lista encadenada criptográficamente que presenta las etapas de facilitar 100 atributos de identidad de la identidad junto con una información de clave simétrica mediante una instancia de usuario, calcular 101 en cada caso un valor hash para cada atributo de identidad, de tal modo que, aun conociendo el atributo de identidad, no sea posible deducir la identidad, registrar 102 los valores hash calculados 101 como al menos una entrada de lista en la lista encadenada criptográficamente, transferir 103 una dirección de la al menos una entrada de lista junto con la información de clave simétrica desde la instancia de usuario a una instancia de validación, validar 104 la al menos una entrada de lista que presenta los valores hash calculados 101 empleando un documento de identidad que presenta los atributos de identidad, mediante la instancia de validación, comprobándose si los atributos de identidad, facilitados 100 y guardados en la dirección, coinciden con los atributos de identidad del documento de identidad, y registrar 105 una firma de la al menos una entrada de lista en la lista encadenada criptográficamente en el caso de una validación positiva de los atributos de identidad mediante la instancia de validación.
Además se realiza una transferencia 106 de la dirección de la al menos una entrada de lista, de la información de clave simétrica y de los atributos de identidad desde la instancia de usuario a una instancia que interroga acerca de la identidad, con lo cual esta instancia interrogadora mediante los datos 106 transferidos comprueba 107 la al menos una entrada de lista 102 registrada que presenta los valores hash 101 calculados.
Mediante el procedimiento propuesto se cubren, entre otras cosas, los requisitos comentados:
En una tercera instancia no puede verse con qué parte de confianza está relacionada una identidad determinada: La parte de confianza no lleva a cabo activamente ninguna transacción de cadena de bloques, de modo que la relación no es identificable para terceros.
Pueden desvelarse atributos individualmente sin que puedan asociarse a este respecto los atributos no desvelados: mediante el empleo de una dirección de cadena de bloques propia por cada atributo no es posible una asociación entre ellos.
Una tercera instancia tampoco puede asociar identidades, aunque se conozcan públicamente los atributos individuales: sin la clave de usuario un tercero no autorizado no puede asociar datos de cadena de bloques a atributos conocidos públicamente. Incluso con la clave de usuario solo la puede asociar a atributos que conoce de por sí. A pesar de ello, no puede personificar al usuario dado que no posee ninguna clave privada de la cuenta de cadena de bloques.
Además, tampoco es necesario hacer funcionar, adicionalmente a la cadena de bloques, también un servicio de nube en el que estén guardados los atributos propiamente dichos: no son necesarias referencias adicionales a un servicio de nube, dado que solo se guardan valores hash codificados en la cadena de bloques. El contenido de los atributos es intercambiado directamente entre usuario y parte de confianza. Adicionalmente, con el esquema puede crearse una identidad basada en la reputación: mediante el número de validaciones de un atributo, la parte de confianza puede identificar con qué frecuencia se ha validado la identidad.

Claims (14)

  1. REIVINDICACIONES
    i. Procedimiento para comprobar de manera confidencial una identidad empleando una lista encadenada criptográficamente, que presenta las etapas de:
    - facilitar (100, 1A) atributos de identidad de la identidad junto con una información de clave simétrica mediante una instancia de usuario;
    - calcular (101,2A) en cada caso un valor hash para cada atributo de identidad empleando la clave simétrica como hash codificado, de tal modo que, aun conociendo el atributo de identidad, no sea posible deducir la identidad;
    - registrar (102, 3A) los valores hash calculados (101, 2A) como al menos una entrada de lista en la lista encadenada criptográficamente;
    - transferir (103, 4A) una dirección de la al menos una entrada de lista junto con la información de clave simétrica desde la instancia de usuario a una instancia de validación;
    - validar (104, 5A) la al menos una entrada de lista que presenta los valores hash calculados (101, 2A) empleando un documento de identidad que presenta los atributos de identidad, mediante la instancia de validación, comprobándose si los valores hash de los atributos de identidad, facilitados (100, 1A) y guardados en la dirección, coinciden con los atributos de identidad del documento de identidad, y
    - registrar (105, 6A) una firma de la al menos una entrada de lista en la lista encadenada criptográficamente en el caso de una validación (104, 5A) positiva de los atributos de identidad mediante la instancia de validación,
    - en donde los valores hash son valores hash codificados.
  2. 2. Procedimiento según la reivindicación 1, caracterizado por que se realiza una transferencia (106, 1B) de la dirección de la al menos una entrada de lista, de la información de clave simétrica y de los atributos de identidad desde la instancia de usuario a una instancia que interroga acerca de la identidad, con lo cual esta instancia interrogadora mediante los datos transferidos (106, 1B) comprueba (107, 2B) la al menos una entrada de lista registrada (102, 3A) que presenta los valores hash calculados (101,2A).
  3. 3. Procedimiento según la reivindicación 2, caracterizado por que la comprobación de la al menos una entrada de lista (107, 2B) también comprende una comprobación de la firma registrada (105, 6A).
  4. 4. Procedimiento según una de las reivindicaciones 2 o 3, caracterizado por que entre la instancia de usuario y la instancia interrogadora se lleva a cabo una autenticación desafío-respuesta.
  5. 5. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que la lista encadenada criptográficamente se presenta como una cadena de datos.
  6. 6. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que la validación (104, 5A) empleando el documento de identidad comprende un procedimiento de identificación por vídeo.
  7. 7. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que el registro (105, 6A) de la firma comprende un registro de un nivel de confianza que indica el grado de confianza en la corrección de la identidad.
  8. 8. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que el registro (102, 3A) de los valores hash calculados (101, 2A) se realiza en cada caso en diferentes direcciones de la lista encadenada criptográficamente.
  9. 9. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que en una comunicación entre la instancia de usuario, la instancia interrogadora y/o la instancia de validación se intercala una instancia de total confianza.
  10. 10. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que la instancia de usuario, la instancia interrogadora y la instancia de validación están conectadas en términos de tecnología de comunicación.
  11. 11. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que la instancia de validación se facilita mediante un servicio basado en red.
  12. 12. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que el procedimiento se ejecuta de manera descentralizada en una red de transmisión de datos.
  13. 13. Sistema de identidad para comprobar de manera confidencial una identidad empleando una lista encadenada criptográficamente, que presenta:
    - una instancia de usuario configurada para facilitar (100, 1A) atributos de identidad de la identidad junto con una información de clave simétrica;
    - una unidad criptográfica configurada para calcular (101, 2A) en cada caso un valor hash para cada atributo de identidad empleando la clave simétrica como hash codificado, de tal modo que, aun conociendo el atributo de identidad, no sea posible deducir la identidad;
    - una interfaz de datos configurada para registrar (102, 3A) los valores hash calculados (101, 2A) como al menos una entrada de lista en la lista encadenada criptográficamente;
    - un componente de red configurado para transferir (103, 4A) una dirección de la al menos una entrada de lista junto con la información de clave simétrica desde la instancia de usuario a una instancia de validación;
    - la instancia de validación configurada para validar (104, 5A) la al menos una entrada de lista que presenta los valores hash calculados (101, 2A) empleando un documento de identidad que presenta los atributos de identidad, mediante la instancia de validación, comprobándose si los valores hash de los atributos de identidad, facilitados (100, 1A) y guardados en la dirección, coinciden con los atributos de identidad del documento de identidad, en donde los valores hash son valores hash codificados; y
    - una interfaz de datos adicional configurada para registrar (105, 6A) una firma de la al menos una entrada de lista en la lista encadenada criptográficamente en el caso de una validación (104, 5A) positiva de los atributos de identidad mediante la instancia de validación.
  14. 14. Producto de programa informático con instrucciones de mando que llevan a cabo el procedimiento según una de las reivindicaciones 1 a 12, cuando se ejecutan en un ordenador.
ES19701762T 2018-01-22 2019-01-15 Sistema de identidad basado en cadenas de bloques Active ES2912050T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018000471.7A DE102018000471A1 (de) 2018-01-22 2018-01-22 Blockchain-basiertes Identitätssystem
PCT/EP2019/000014 WO2019141505A1 (de) 2018-01-22 2019-01-15 Blockchain-basiertes identitätssystem

Publications (1)

Publication Number Publication Date
ES2912050T3 true ES2912050T3 (es) 2022-05-24

Family

ID=65234509

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19701762T Active ES2912050T3 (es) 2018-01-22 2019-01-15 Sistema de identidad basado en cadenas de bloques

Country Status (8)

Country Link
US (1) US11343074B2 (es)
EP (1) EP3743844B1 (es)
KR (1) KR102396824B1 (es)
CN (1) CN111566647B (es)
CA (1) CA3088040C (es)
DE (1) DE102018000471A1 (es)
ES (1) ES2912050T3 (es)
WO (1) WO2019141505A1 (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220263668A1 (en) * 2019-05-09 2022-08-18 Aalto University Foundation Sr Certification of a measurement result of a measuring device
US11558379B2 (en) * 2019-07-15 2023-01-17 Hewlett Packard Enterprise Development Lp Network access authentication and authorization using a blockchain network
US11507943B1 (en) * 2020-02-21 2022-11-22 Anonyome Labs, Inc. Digital wallet for digital identities and interactions with a digital identity services platform
US11621858B2 (en) 2020-12-12 2023-04-04 International Business Machines Corporation Anonymity mechanisms in permissioned blockchain networks

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1536606A1 (fr) * 2003-11-27 2005-06-01 Nagracard S.A. Méthode d'authentification d'applications
GB0622149D0 (en) * 2006-11-07 2006-12-20 Singlepoint Holdings Ltd System and method to validate and authenticate digital data
JP2015122620A (ja) * 2013-12-24 2015-07-02 富士通セミコンダクター株式会社 認証システム、認証方法、認証装置、及び、被認証装置
US20150356523A1 (en) * 2014-06-07 2015-12-10 ChainID LLC Decentralized identity verification systems and methods
RU2635271C2 (ru) * 2015-03-31 2017-11-09 Закрытое акционерное общество "Лаборатория Касперского" Способ категоризации сборок и зависимых образов
EP3292484B1 (en) * 2015-05-05 2021-07-07 Ping Identity Corporation Identity management service using a block chain
US10666423B2 (en) * 2015-09-11 2020-05-26 Aware, Inc. Biometric verification of a blockchain database transaction contributor
US10230756B2 (en) 2015-11-25 2019-03-12 International Business Machines Corporation Resisting replay attacks efficiently in a permissioned and privacy-preserving blockchain network
DE102015225778A1 (de) 2015-12-17 2017-06-22 Deutsche Post Ag Vorrichtung und Verfahren für die personalisierte Bereitstellung eines Schlüssels
EP3424177B1 (en) * 2016-02-29 2021-10-13 SecureKey Technologies Inc. Systems and methods for distributed identity verification
US10333705B2 (en) * 2016-04-30 2019-06-25 Civic Technologies, Inc. Methods and apparatus for providing attestation of information using a centralized or distributed ledger
US9635000B1 (en) 2016-05-25 2017-04-25 Sead Muftic Blockchain identity management system based on public identities ledger
AU2017100968A4 (en) * 2016-07-18 2017-09-07 Brontech Pty Ltd System for issuance, verification and use of digital identities on a public or private ledger.
US10999250B1 (en) * 2016-08-17 2021-05-04 Infersight Llc System and method for validating a message conveyed via a network
CN106682530A (zh) 2017-01-10 2017-05-17 杭州电子科技大学 一种基于区块链技术的医疗信息共享隐私保护方法及装置
US10330784B2 (en) * 2017-04-07 2019-06-25 Qualcomm Incorporated Secure range determination protocol
CN107196966B (zh) * 2017-07-05 2020-04-14 北京信任度科技有限公司 基于区块链的多方信任的身份认证方法和系统
CN107181765A (zh) * 2017-07-25 2017-09-19 光载无限（北京）科技有限公司 基于区块链技术的网络数字身份认证方法
US20210037009A1 (en) * 2018-01-27 2021-02-04 Redrock Biometrics Inc Biometric data sub-sampling during decentralized biometric authentication

Also Published As

Publication number Publication date
CA3088040A1 (en) 2019-07-25
KR102396824B1 (ko) 2022-05-10
CN111566647A (zh) 2020-08-21
EP3743844A1 (de) 2020-12-02
EP3743844B1 (de) 2022-03-23
CN111566647B (zh) 2023-05-30
US20200374140A1 (en) 2020-11-26
CA3088040C (en) 2023-06-20
KR20200097773A (ko) 2020-08-19
DE102018000471A1 (de) 2019-07-25
WO2019141505A1 (de) 2019-07-25
US11343074B2 (en) 2022-05-24

Similar Documents

Publication Publication Date Title
ES2912050T3 (es) Sistema de identidad basado en cadenas de bloques
US11200340B2 (en) Method and system for managing personal information within independent computer systems and digital networks
US10887098B2 (en) System for digital identity authentication and methods of use
US11151260B2 (en) Providing and checking the validity of a virtual document
ES2935164T3 (es) Método para registrar y compartir una identidad digital de un usuario usando contabilidad distribuida
US20220215355A1 (en) Method for directly transmitting electronic coin data records between terminals and payment system
KR101829729B1 (ko) 블록체인 및 이와 연동하는 머클 트리 구조를 통해 모바일 아이디를 이용하여 사용자를 인증하는 방법, 단말 및 이를 이용한 서버
JP5147673B2 (ja) 生体認証システムおよびその方法
CN109637637A (zh) 基于区块链的医疗管理系统
US20030115467A1 (en) Public key infrastructure token issuance and binding
CN108701136A (zh) 用于提供基于区块链的多因素个人身份验证的系统和方法
RU2017134723A (ru) Системы и способы персональной идентификации и верификации
Brunner et al. SPROOF: A Platform for Issuing and Verifying Documents in a Public Blockchain.
CN109753817A (zh) 基于区块链的医疗信息安全存储方案
Bergquist Blockchain technology and smart contracts: privacy-preserving tools
US11985125B2 (en) Biometrically-enhanced verifiable credentials
Tahlil et al. AlgoCert: Adopt Non-transferable NFT for the Issuance and Verification of Educational Certificates using Algorand Blockchain
Reece et al. Self-Sovereign Identity in a World of Authentication: Architecture and Domain Usecases
WO2018014103A1 (pt) Sistema de provisionamento, assinatura e verificação de documento eletrônico, método de provisionamento e assinatura de documento eletrônico e método de verificação de autenticidade de documento eletrônico
Brunner et al. SPROOF: A decentralized platform for attribute-based authentication
Dewangan et al. Enhanced Privacy and Security of Voters' Identity in an Interplanetary File System-Based E-Voting Process
KR20200057985A (ko) 하이브리드 블록체인과 기업형 하드웨어 키보관 시스템을 결합한 솔루션
US20210126793A1 (en) Method, system and non-transitory computer-readable recording medium for supporting non-face-to-face authentication in a blockchain network
Palaiyan et al. Verification of passport system based on blockchain
Kuznetsov et al. A Comprehensive Decentralized Digital Identity System: Blockchain, Artificial Intelligence, Fuzzy Extractors, and NFTs for Secure Identity Management.