ES2881824T3 - Sistema y método para estándares de protocolos biométricos - Google Patents

Sistema y método para estándares de protocolos biométricos Download PDF

Info

Publication number
ES2881824T3
ES2881824T3 ES16839947T ES16839947T ES2881824T3 ES 2881824 T3 ES2881824 T3 ES 2881824T3 ES 16839947 T ES16839947 T ES 16839947T ES 16839947 T ES16839947 T ES 16839947T ES 2881824 T3 ES2881824 T3 ES 2881824T3
Authority
ES
Spain
Prior art keywords
computing device
user
server
certificate
bops
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
ES16839947T
Other languages
English (en)
Inventor
Scott Streit
Jonathan Mather
Asem Othman
Ionut Dumitran
Thomas Wood
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.)
Veridium IP Ltd
Original Assignee
Veridium IP Ltd
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 Veridium IP Ltd filed Critical Veridium IP Ltd
Application granted granted Critical
Publication of ES2881824T3 publication Critical patent/ES2881824T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/602—Providing cryptographic facilities or services

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)
  • Collating Specific Patterns (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Un método para proporcionar una comunicación segura entre un dispositivo informático de usuario (104) y un dispositivo informático servidor (102), el método que comprende: procesar, mediante el dispositivo informático servidor, una solicitud de inscripción que se recibe desde un dispositivo informático de usuario configurado con una aplicación de software cliente distribuida, la solicitud de inscripción que incluye una porción cifrada de un vector biométrico inicial asociado con un usuario del dispositivo informático de usuario, en donde el procesamiento de la solicitud de inscripción, que incluye la porción cifrada del vector biométrico inicial, incluye: registrar el dispositivo informático de usuario con el dispositivo informático servidor; y almacenar la porción cifrada del vector biométrico inicial en un medio legible por procesador no transitorio que sea accesible por o sea parte del dispositivo informático servidor; en donde registrar el dispositivo informático de usuario con el dispositivo informático servidor incluye: generar un par de claves pública-privada en el dispositivo informático de usuario, firmar una clave pública y el nombre de sujeto de un certificado, recibir, mediante el dispositivo informático servidor, una solicitud de firma de certificado de registro que comprende la clave pública firmada y el nombre de sujeto del certificado desde el dispositivo informático de usuario a través de una capa de conexiones seguras bidireccional; firmar, mediante el dispositivo informático servidor, la solicitud con una clave privada de la Autoridad de Certificación, después de verificar el nombre de sujeto del certificado; generar, mediante el dispositivo informático servidor, una contraseña de certificado de cliente para la solicitud firmada; y transmitir, mediante el dispositivo informático servidor al dispositivo informático de usuario, la contraseña del certificado de cliente; procesar, por el dispositivo informático servidor, una solicitud de autenticación que se recibe posteriormente desde el dispositivo informático de usuario e incluye el certificado y una porción cifrada de un segundo vector biométrico y que se asocia con un usuario del dispositivo informático de usuario, en donde el procesamiento de la solicitud de autenticación incluye: determinar que el certificado está vigente y no está revocado; realizar una comparación de la porción cifrada del vector biométrico inicial y la porción cifrada del segundo vector biométrico; y generar un valor que representa la comparación; y transmitir, mediante el dispositivo informático servidor al dispositivo informático de usuario, el valor que representa la comparación, en donde el dispositivo informático de usuario se autentica cuando el valor que representa la comparación está por encima de un umbral mínimo y el dispositivo informático de usuario no se autentica cuando el valor que representa la comparación está por debajo de un umbral mínimo.

Description

DESCRIPCIÓN
Sistema y método para estándares de protocolos biométricos
Campo de la invención
La presente invención se refiere, en general, a la seguridad y, más particularmente, a los sistemas y métodos para identificar o autenticar a un usuario.
Antecedentes de la invención
Se sigue almacenando información de todo tipo y se accede a ella de forma remota, tal como en dispositivos de almacenamiento a los que se puede acceder a través de redes de comunicación de datos. Por ejemplo, muchas personas y empresas almacenan y acceden a información financiera, información médica y de salud, información sobre bienes y servicios, información sobre compras, información sobre entretenimiento, información de multimedia a través de Internet u otra red de comunicación. Además de acceder a la información, los usuarios pueden efectuar transferencias monetarias (por ejemplo, compras, transferencias, ventas o similares). En un escenario típico, un usuario se registra para acceder a la información y, posteriormente, envía un nombre de usuario y una contraseña para "iniciar sesión" y acceder a la información. Asegurar el acceso a (y desde) dicha información y datos que se almacenan en una red de datos/comunicación sigue siendo una preocupación primordial La publicación "Secure transmission of medical information using IRIS recognition and steganography" por Barkathunisha y otros describe el uso de criptografía visual para asegurar las plantillas de características del iris.
Resumen
La invención se define por las reivindicaciones independientes. Las modalidades preferidas se exponen en las reivindicaciones dependientes. En una o más implementaciones de la presente solicitud, se proporcionan comunicaciones seguras entre un dispositivo informático de usuario y un dispositivo informático servidor. Se recibe una solicitud de inscripción desde un dispositivo informático de usuario que se configura con una aplicación de software cliente distribuida y se procesa. La solicitud de inscripción puede usarse para inscribir el dispositivo informático de usuario en una red e incluye un vector biométrico inicial parcial cifrado asociado con un usuario. Se procesa una solicitud de autenticación que se recibe posteriormente que incluye un segundo vector biométrico parcial cifrado y que está asociado con un usuario del dispositivo informático de usuario. Se realiza una comparación del vector biométrico inicial parcial cifrado y el segundo vector biométrico parcial cifrado, y se genera un valor que representa la comparación y se transmite al dispositivo informático de usuario. El dispositivo informático de usuario se autentica cuando el valor está por encima de un umbral mínimo.
En una o más implementaciones, se proporcionan comunicaciones seguras entre un dispositivo informático de usuario y un dispositivo informático servidor. Se procesa una solicitud de inscripción que se recibe de un dispositivo informático de usuario configurado con una aplicación de software cliente distribuida. La solicitud de inscripción puede usarse para inscribir el dispositivo informático de usuario en una red e incluye una primera porción de un primer vector biométrico asociado con un usuario. Se almacena la primera porción del primer vector biométrico y se procesa una solicitud de autenticación que se recibe posteriormente que incluye un segundo vector biométrico y una segunda porción del primer vector biométrico. La primera y la segunda porción se combinan y comparan con el segundo vector biométrico. Se genera un valor que representa la comparación y se transmite al dispositivo informático de usuario. El dispositivo informático de usuario se autentica cuando el valor está por encima de un umbral mínimo.
En una o más implementaciones, se proporciona un certificado que se incluye en la solicitud de inscripción y la solicitud de autenticación, en donde el procesamiento de la solicitud de autenticación incluye determinar que el certificado está vigente y no revocado.
En una o más implementaciones, se proporciona un sistema de detección de intrusos que proporciona una supervisión activa y evita la suplantación del certificado, que incluye la repetición del certificado.
En una o más implementaciones, procesar la solicitud de autenticación incluye realizar al menos una operación de coincidencia en el espacio cifrado en función del cifrado unidireccional. El cifrado unidireccional puede realizarse mediante el uso de un teclado unidireccional aleatorio.
En una o más implementaciones, la recopilación de roles se proporciona y define mediante una o más reglas de acceso a un activo digital, y el dispositivo informático servidor proporciona o deniega el acceso al activo digital por parte del dispositivo informático de usuario en función de la recopilación de roles. El acceso puede proporcionarse en función de al menos uno de control de acceso discrecional y control de acceso obligatorio.
En una o más implementaciones, el dispositivo informático servidor procesa una segunda solicitud de inscripción que se recibe del dispositivo informático de usuario configurado con una aplicación de software cliente distribuida. La segunda solicitud de inscripción puede usarse para inscribir a un segundo usuario del dispositivo informático de usuario en la red y la segunda solicitud de inscripción incluye un segundo vector biométrico inicial parcial cifrado ("IBV") asociado con un usuario del dispositivo informático de usuario. El procesamiento de la segunda solicitud de inscripción incluye almacenar el segundo IBV parcial cifrado en un medio legible por el procesador no transitorio que es accesible por o es parte del dispositivo informático servidor.
En una o más implementaciones, el dispositivo informático servidor puede revocar la inscripción de un usuario. Otras características y ventajas de la presente invención resultarán evidentes a partir de la siguiente descripción de la invención que se refiere a los dibujos adjuntos.
Breve descripción de dibujos/figuras
Otros aspectos de la presente descripción se apreciarán más fácilmente al revisar la descripción detallada de sus diversas modalidades, descritas a continuación, cuando se toman junto con los dibujos adjuntos, de los cuales:
La Figura 1 es un diagrama de bloques que ilustra una pluralidad de dispositivos y componentes con una o más implementaciones de la presente solicitud;
Las Figuras 2-6 ilustran los dispositivos y el flujo de información entre ellos en conexión con un ejemplo de implementación de BOPS;
La Figura 7A ilustra dispositivos y etapas asociadas con un proceso de inscripción de ejemplo con especial énfasis en la confidencialidad de los datos, de acuerdo con una o más implementaciones;
La Figura 7B ilustra un ejemplo de consola administrativa proporcionada en una interfaz de usuario de acuerdo con la presente solicitud;
La Figura 8 ilustra una descripción general, que incluye el acceso y el intercambio de datos, en relación con un proceso de inscripción;
La Figura 9 ilustra componentes de una arquitectura de seguridad de acuerdo con una o más implementaciones de la presente solicitud;
Las Figuras 10A y 10B ilustran dispositivos y etapas asociadas con dos procesos de inscripción respectivos y alternativos, de acuerdo con una o más implementaciones de la presente solicitud;
La Figura 11 es un diagrama de bloques que ilustra los posibles requisitos y ejemplos asociados con diferentes niveles de un proceso Génesis, de acuerdo con la presente solicitud;
La Figura 12 ilustra un flujo de información de ejemplo asociado con un vector biométrico inicial durante los procesos de inscripción y autenticación;
La Figura 13 ilustra un ejemplo de criptografía visual (VC) que se implementa en conexión con la presente solicitud;
La Figura 14 ilustra una superposición de ejemplo de dos partes (2,2) en un esquema de criptografía visual (VCS) en el que cada bit se cifra en partes, en relación con una implementación de BOPS de ejemplo;
La Figura 15 ilustra una instancia de una jerarquía de roles de acuerdo con la presente solicitud;
La Figura 16 es un diagrama de bloques que ilustra los dispositivos y el flujo de transmisión en relación con la prevención de repetición, de acuerdo con una implementación de ejemplo;
La Figura 17 es un flujo de alto nivel que ilustra las etapas asociadas con un testigo de acuerdo con una implementación de ejemplo;
La Figura 18 ilustra dispositivos y características de ejemplo en conexión con un proceso Génesis en una relación de muchos a muchos;
La Figura 19A representa a múltiples usuarios que inician un proceso de inscripción de ejemplo en un solo dispositivo cliente;
La Figura 19B ilustra un ejemplo de usuario que inicia una sesión de autenticación desde un dispositivo cliente, que almacena información relativa a múltiples cuentas de usuario;
La Figura 19C ilustra etapas de ejemplo asociadas con la revocación de la cuenta de un usuario;
La Figura 20A es un diagrama simplificado que demuestra las etapas asociadas con la inicialización, verificación y confirmación de un certificado de cliente entre un dispositivo cliente y un servidor BOPS;
La Figura 20B ilustra un registro de certificado de cliente de ejemplo en conexión con un servidor de terceros y un servidor BOPS; y
La Figura 21 ilustra un ejemplo de flujo de autenticación de código QR, de acuerdo con una implementación de ejemplo de la presente solicitud.
Descripción detallada
De acuerdo con una o más implementaciones de la presente solicitud de patente, se proporciona un nuevo conjunto de estándares denominados en la presente descripción, generalmente, como los Estándares de Protocolo Abierto Biométrico ("BOPS"), que colectivamente o al menos parcialmente incluye un marco para autenticar usuarios. Una o más implementaciones de BOPS pueden proporcionar uno o más módulos para afirmación de identidad, recopilación de roles, control de acceso multinivel, aseguramiento y auditoría.
La Figura 1 ilustra una disposición de hardware de ejemplo 100 y muestra la comunicación de datos en conexión con una o más implementaciones de BOPS. El arreglo 100 puede incluir una o más aplicaciones de software que configuran múltiples dispositivos informáticos, tales como un dispositivo cliente (por ejemplo, un teléfono inteligente o un dispositivo móvil) 104, un dispositivo informático servidor (denominado en la presente descripción, generalmente, como un "servidor BOPS") 102, un servidor de terceros 106, y un sistema de detección de intrusos ("IDS") que puede incluir una pluralidad de dispositivos informáticos 112, para soportar y habilitar la funcionalidad mostrada y descrita en la presente descripción. Además, el servidor BOPS 102 puede estar en comunicación o conectarse con el dispositivo de monitoreo de salud 108 y el dispositivo de motor de análisis 110. Ambos dispositivos 108 y 110 pueden configurarse como parte del servidor BOPS 102 o pueden ser dispositivos individuales.
La siguiente es una lista no limitativa de abreviaturas y acrónimos denominados en la presente descripción: admin = administrador; AOP = programación orientada a aspectos; API = interfaz de programación de aplicaciones; AWS = Servicios web de Amazon; app a = aplicación cliente; BOPS = estándar de protocolo abierto biométrico; CPU = unidad central de procesamiento; CBV = Identificador biométrico actual; CSRF = falsificación de solicitud entre sitios; ID = identificador; IDS = sistema de detección de intrusos; IBV = vector biométrico inicial; IP = protocolo de Internet; JSON = notación de objetos JavaScript; LDAP = Protocolo ligero de acceso a directorios; MAC = control de acceso obligatorio; MCA = Aplicación de cliente móvil; NSA = Agencia de Seguridad Nacional (Estados Unidos); Código QR = código de respuesta rápida; RDBMS = sistema de gestión de bases de datos relacionales; REST = transferencia de estado representacional; SSL = capa de conexión segura; TCSEC = criterios de evaluación del sistema informático de confianza; TLS = seguridad de la capa de transporte; URL = identificador uniforme de recursos; XNTP = protocolo de tiempo de red extendido; XOR = Operación binaria "OR exclusivo"; 1:M = uno a muchos; 4F = Cuatro dedos, una tecnología biométrica patentada; 5-tupla = Cinco parámetros de datos de tupla.
Una ventaja de la presente solicitud es que una o más implementaciones de BOPS respectivas pueden incluir componentes para proporcionar funcionalidad y que pueden funcionar con los componentes existentes de una empresa o sustituirlos, proporcionando así integración con los entornos operativos actuales en un período de tiempo relativamente muy corto. Además, una o más implementaciones de BOPS respectivas proporcionan protección continua de formularios, tal como para adjudicar el acceso a recursos privados y sensibles. Puede proporcionarse seguridad a nivel de servicio en implementaciones de BOPS que cumplen o superan los objetivos aceptados, al menos en parte como una función de una o más interfaces de programación de aplicaciones (API) que admiten implementaciones como una forma de mecanismo de "apuntar y cortar" para agregar la seguridad adecuada a los sistemas de producción, así como también a los sistemas en desarrollo.
Una o más implementaciones de BOPS pueden incluir un servidor BOPS 102 que puede recibir a través de una o más redes de comunicación de datos desde un dispositivo cliente 104 un vector biométrico, denominado en la presente descripción, generalmente, el vector biométrico inicial ("IBV"), y dividir el vector de acuerdo con un algoritmo en una pluralidad de partes asociadas con la identificación. Independientemente del número de piezas, el IBV puede cifrarse, incluso sin llave, y opcionalmente puede ocurrir un proceso de coincidencia biométrica posterior en el dispositivo cliente 104 o en el servidor 102, por ejemplo, como se indica mediante un parámetro de administración.
Se pueden implementar una o más implementaciones de BOPS en varios entornos en línea, tales como en una nube pública (por ejemplo, AMAZON WEB SERVICES) o en una nube privada.
De acuerdo con la estructura organizativa del dispositivo y la funcionalidad que se muestra y describe en la presente descripción, la autenticación del usuario puede proporcionarse en lugar de la autorización y de tal manera que el servidor no retenga la información del cliente, sino que mantenga una cantidad suficiente de información para permitir el reconocimiento de un cliente desde otro cliente. Los componentes de las consideraciones de seguridad de acuerdo con una o más implementaciones de BOPS pueden incluir afirmación de identidad, recopilación de roles, control de acceso, auditoría y aseguramiento. Por lo tanto, una o más implementaciones de BOPS consideran en gran medida el componente del lado del servidor en una solución biométrica de extremo a extremo.
En relación con la afirmación de identidad, una o más implementaciones de BOPS pueden proporcionar protección continua de los recursos y asegurar la ubicación y viabilidad de la adjudicación y otras características clave. Una o más implementaciones de BOPS pueden ayudar aún más en la afirmación de identidad para ayudar a confirmar que los usuarios nombrados son quienes dicen ser, sin una dependencia directa de los datos biométricos humanos. Los estándares que se muestran y describen en la presente descripción incluyen un estándar interoperable que puede incorporar virtualmente cualquier asertor de identidad o varios asertores diferentes que se asocian con el mismo usuario designado. La aplicación de un IDS (por ejemplo, a través de dispositivos cliente 112) puede proporcionar un monitoreo activo para ayudar a prevenir la suplantación de un conjunto de credenciales y/o poner en la lista negra a un sujeto o dispositivo que determinó haber realizado o está intentando realizar uno o más intentos maliciosos.
Además, la recopilación de roles se admite en función de la confidencialidad de los datos y el acceso privilegiado que se basa, por ejemplo, en reglas definidas y/o aplicadas por un sistema conocido. Por ejemplo, para determinar si se permite un modo de acceso específico, puede compararse un privilegio específico asociado con un rol respectivo con una clasificación de un grupo. La estructura de un objeto se puede definir mediante el control de acceso y la recopilación de roles puede ocurrir a nivel del sistema o mediante la llamada cliente/servidor. Por ejemplo, un servidor BOPS 102 puede almacenar información de recopilación de roles para asociar un usuario único con un dispositivo único 104. El control de acceso puede incluir la implementación de una eliminación de un objeto determinado.
Generalmente, el control de acceso puede ser discrecional y también o alternativamente puede incluir un control de acceso obligatorio, que puede ser más granular. El control de acceso discrecional, por ejemplo, se refiere al control del acceso a uno o más objetos en función de los usuarios y objetos con nombre (por ejemplo, archivos y programas). Un mecanismo de adjudicación puede estar, por ejemplo, basado en roles y permitir que los usuarios y administradores especifiquen y controlen el intercambio de objetos por individuos nombrados y/o por grupos definidos de individuos. El mecanismo de control de acceso discrecional proporciona, en una o más implementaciones, que los objetos están protegidos del acceso no autorizado a nivel de grupo o individual a través de un solo objeto o grupo de objetos. Por lo tanto, la granularidad asociada con el acceso discrecional puede variar de un individuo a otro.
Una o más implementaciones de BOPS pueden hacer cumplir una política de control de acceso obligatoria sobre todos los sujetos y objetos de almacenamiento (por ejemplo, procesos, archivos, segmentos, dispositivos) bajo control dentro de una implementación respectiva. A estos sujetos y objetos se les pueden asignar etiquetas de sensibilidad, que pueden ser una combinación de niveles de clasificación jerárquica y categorías no jerárquicas. Las etiquetas pueden usarse en la adjudicación como base para las decisiones de control de acceso obligatorias. Por ejemplo, el software que se ejecuta en un dispositivo cliente 104 hace que el dispositivo mantenga etiquetas o haga que un servidor BOPS 102 mantenga los datos para forzar la adherencia al etiquetado del sujeto y los objetos. El servidor BOPS 102 puede mantener un almacén de confianza como componente de una implementación de BOPS. Como se usa en la presente descripción, un almacén de confianza se refiere, generalmente, a almacenar datos de una manera segura de tal manera que el control de acceso (DAC o MAC) asegura que el sujeto recibe el objeto correcto y además asegura el no repudio y la confidencialidad.
A continuación, se identifican las reglas y opciones de control de acceso que se admiten en una o más implementaciones de BOPS de ejemplo. Un sujeto puede tener acceso para leer un objeto solo en caso de que la clasificación jerárquica en el nivel de seguridad del sujeto sea mayor o igual que la clasificación jerárquica en el nivel de seguridad del objeto. Una o más categorías no jerárquicas en el nivel de seguridad del sujeto pueden incluir todas las categorías no jerárquicas en el nivel de seguridad del objeto. Un sujeto puede escribir y/o ejecutar un objeto solo si la clasificación jerárquica en el nivel de seguridad del sujeto es menor o igual que la clasificación jerárquica en el nivel de seguridad del objeto y todas las categorías no jerárquicas en el nivel de seguridad del sujeto se incluyen en las categorías no jerárquicas en el nivel de seguridad del objeto. Los datos de identificación y autenticación pueden usarse por el dispositivo servidor BOPS 102 para autenticar la identidad de un usuario y asegurar que el nivel de seguridad y la autorización de sujetos externos a la implementación de BOPS que pueden crearse para actuar en nombre del usuario individual están dominados por la credencial y autorización de ese usuario.
La presente solicitud funciona para aumentar la responsabilidad, incluso como una función de uno o más módulos que permiten auditar y verificar que un modelo de seguridad está operativo, lo que se denomina en la presente descripción, generalmente, como aseguramiento. En el caso poco probable de que un dispositivo informático dentro de una implementación de BOPS se vea comprometido, dichos módulos impiden que el sistema comprometido funcione sin ser detectado. Por ejemplo, en implementaciones de BOPS, las solicitudes de auditoría pueden soportarse a nivel de sujeto/objeto o a nivel de grupo, incluso como una función de programación orientada a aspectos, como se conoce en la técnica. Esto aumenta la probabilidad de que las llamadas se escriban de forma segura en una pista de auditoría. Además, una interfaz de servicios web RESTful y notación de objetos JavaScript (JSON) puede proporcionar un mecanismo para leer una pista de auditoría. La auditoría puede ocurrir en el sujeto por acción, el objeto por acción o el grupo por acción. Por ejemplo, un grupo de usuarios puede ser designado por un nombre específico (por ejemplo, "contabilidad") y puede auditar todas las escrituras en un libro mayor. Además, las personas, por ejemplo, un director financiero, pueden recibir información de auditoría para leer el estado de resultados.
Una o más de un conjunto de pruebas JUnit pueden usarse en una o más implementaciones de BOPS para probar y monitorear las condiciones de los límites, que pueden incluir probar los componentes y las condiciones de los límites dentro de un sistema. En una o más implementaciones de BOPS, las disposiciones de seguridad pueden cumplirse al menos en parte en función de las API. El uso de API excluye la necesidad de identificar y/o personalizar las implementaciones de BOPS para que se ajusten a un sistema subyacente, tal como un sistema de gestión de bases de datos relacionales, un motor de búsqueda o prácticamente cualquier otra arquitectura. La funcionalidad proporcionada por una implementación de BOPS respectiva puede ofrecer un mecanismo de "apuntar y cortar" para agregar la seguridad adecuada a los sistemas en producción, así como también a los sistemas en desarrollo. Además, la arquitectura de una o más implementaciones de BOPS es independiente del lenguaje y admite, por ejemplo, REST, JSON y SSL para proporcionar la interfaz de comunicación. En una o más implementaciones, la arquitectura se basa en la especificación de servlet, SSL abierto, Java, JSON, REST y un almacén persistente. Las herramientas pueden adherirse a estándares abiertos, lo que permite la máxima interoperabilidad para los dispositivos, tal como se muestra en la Figura 1.
En una o más implementaciones de BOPS se proporcionan afirmación de identidad, recopilación de roles, control de acceso multinivel, auditoría y aseguramiento. Estos pueden implementarse en función de una combinación de al menos un dispositivo cliente 104 especialmente configurado (por ejemplo, un teléfono inteligente o dispositivo móvil), un servidor BOPS 102 y un sistema de detección de intrusos (IDS) que comprende el dispositivo 112. En una o más implementaciones, un dispositivo cliente 104 ejecuta una aplicación y carga una clave bidireccional de capa de conexión segura ("SSL")/seguridad de capa de transporte ("TLS") de un solo uso para establecer una sesión de comunicación inicial y segura con el servidor BOPS 102. La clave de un solo uso se reemplaza, al menos funcionalmente, por una clave SSL/TLS bidireccional de un sujeto que se genera y/o proporciona durante una fase de identidad (denominada en la presente descripción, generalmente, "Génesis"). Génesis comprende, generalmente, una etapa inicial o temprana en un proceso que fusiona un conjunto de datos biométricos con un sujeto determinado. Otra fase, denominada en la presente descripción generalmente como Inscripción incluye etapas asociadas con el registro de un usuario y/o dispositivo en una implementación de BOPS, y puede incluir emitir un certificado para un dispositivo cliente 104, proteger el certificado del cliente y proteger los datos confidenciales almacenados en el cliente.
En una o más implementaciones de BOPS, se proporciona una infraestructura que maneja el cifrado de datos y comunicaciones seguras cliente/servidor. La infraestructura de BOPS puede apoyar los procesos de desacoplamiento de Génesis e Inscripción y coordinar estos procesos junto con varios elementos de Inscripción. Estas dependencias pueden identificar una infraestructura de servidor BOPS 102 e incluyen: BOPS DNS; Almacén de confianza de BOPS; Almacén de claves de BOPS; y Protocolo de negociación de claves BOPS. Con respecto a la gestión de certificados, puede configurarse una entrada DNS para el nombre de host 102 del servidor BOPS para que tenga una clave en el almacén de claves para SSL unidireccional. El Almacén de confianza en una o más configuraciones de BOPS es un mecanismo SSL bidireccional que define la autoridad de certificación para firmar todos los certificados correspondientes. En el nivel de transporte, una identidad BOPS puede ocurrir a través del certificado bidireccional y un almacén de confianza mediante la realización de un protocolo de enlace. El almacén de claves admite la seguridad de nivel de transporte a través de una clave en el almacén de claves, y la clave en el almacén de claves puede usar una autoridad de certificación bien definida y reconocida, como VERISIGN, GODADDY u otra autoridad, que pueda usarse para identificar un host para el cifrado en SSL/TLS. Como se indica en la presente descripción, una o más implementaciones de BOPS usan un proceso de contraseña de un solo uso (OTP) para que un dispositivo cliente 104 solicite una contraseña que desbloquee el certificado SSL bidireccional. Esto puede realizarse mediante el dispositivo cliente 104 y el servidor 102 sincronizando una OTP para devolver la clave para desbloquear el certificado después de que se inicie una sesión SSL bidireccional.
En una o más implementaciones, varios elementos de inscripción clave soportan la autenticación del certificado del cliente cuando los dispositivos cliente 104 envían solicitudes al servidor BOPS 102. Un testigo, por ejemplo, puede configurarse como un identificador que vincula un perfil en el servidor a una identidad, tal como una función de un elemento de datos, por ejemplo, "Nombre común". El proceso OTP incluye uno o más mecanismos para solicitar la contraseña del servidor que desbloquea el certificado SSL bidireccional (x.509). La contraseña puede cambiarse para cada uso mediante un algoritmo predefinido que se coordina entre el dispositivo informático servidor 102 y el dispositivo informático cliente 104, y el canal usado para la OTP es preferentemente diferente del canal usado para el certificado individual. Por ejemplo, una notificación de inserción puede enviar una contraseña usada para desbloquear el certificado individual. Puede usarse un certificado diferente para obtener la contraseña para desbloquear el certificado individual. En cualquier caso, el mecanismo para desbloquear el certificado puede no implicar el almacenamiento de esa contraseña en el dispositivo cliente 104.
En un ejemplo, una aplicación usa un certificado predeterminado (por ejemplo, Precargado) para Génesis e Inscripción. El procesamiento posterior puede usar el certificado predeterminado con la OTP actual. El resultado (por ejemplo, una respuesta HTTP) puede incluir la contraseña para desbloquear el certificado. Luego, la OTP avanzaría en el cliente y el servidor. En una o más implementaciones de BOPS, una 5-tupla es un valor de entropía alto que se usa para prevenir ataques de repetición. Los valores pueden ocurrir en la Inscripción y formar parte de futuras comunicaciones entre el dispositivo cliente 104 y el servidor 102.
La interacción de la aplicación cliente/servidor en una implementación de BOPS puede considerarse un proceso de tres etapas, y al menos dos posibles variaciones pueden seguir a la primera etapa inicial. En tal caso, en la presente descripción se describe una arquitectura de aplicación cliente/servidor BOPS con referencia a tres componentes: aplicación cliente que se ejecuta en un dispositivo cliente 104, una aplicación que se ejecuta en el servidor BOPS 102 y una aplicación del lado del servidor (denominada como "App Server" en los dibujos). En los ejemplos ilustrados en las Figuras 2-6, la aplicación del lado del servidor no se ejecuta necesariamente a través del servidor BOPS 102, ya que la conexión s Sl/TLS puede terminar en el servidor de aplicaciones. Además, una implantación de la implementación de BOPS respectiva no requiere que la aplicación confíe en el sistema BOPS con el contenido no cifrado. Con referencia a la Figura 2, durante el proceso Génesis, el dispositivo cliente 104 realiza una llamada al servidor BOPS 102 y autentica al usuario y al software de aplicación del lado del cliente. A continuación, el dispositivo cliente 104 recibe un certificado que se asigna mediante el servidor BOPS 102 y que es específico para la identidad del cliente de una aplicación específica.
Durante el siguiente paso (Figura 3), el dispositivo/aplicación cliente llama directamente al servidor de aplicaciones. La conexión SSL/TLS entre la parte del cliente y el servidor de la aplicación comienza y termina en estos puntos. El intercambio de contenido preferentemente no es visible fuera de la aplicación para el servidor BOPS 102 u otros no confiables dentro de esta entidad de aplicación. Durante la sesión del cliente (Figura 4), el servidor de aplicaciones 106 llama al servidor BOPS 102 para obtener detalles de identificación y confirma que el certificado no ha sido revocado previamente.
En una segunda variación (representada parcialmente en la Figura 5), las etapas de Génesis (incluidos los establecidos en las Figuras 2-3) pueden ser las mismas. A continuación, el servidor BOPS 102 se pone en contacto con el componente del servidor de aplicaciones 106 para notificar que se ha registrado y asignado un nuevo cliente 104. El flujo de la segunda variación difiere del flujo de la primera variación en al menos dos formas: los detalles de identidad son diferentes y la verificación de revocación se obtiene en la sesión del cliente (Figura 6). En la tercera etapa, cuando el dispositivo cliente 104 llama al servidor de aplicaciones 106 directamente, el servidor de aplicaciones 106 llama al servidor BOPS 102 para confirmar que el certificado no ha sido revocado previamente. Las características mostradas y descritas en la presente descripción en relación con implementaciones de BOPS de ejemplo pueden usarse por o en conexión con los módulos de control de acceso proporcionados en la presente descripción, o pueden agregarse a un elemento de afirmación de identidad de un marco existente. Por lo tanto, la implementación de BOPS permite un procesamiento confiable al realizar acciones mínimas en el entorno de producción y, por lo tanto, a menudo excluye un requisito de cambio de software de aplicación.
La Figura 7A ilustra dispositivos y etapas 700 asociados con un proceso de inscripción de ejemplo y la confidencialidad de los datos relacionados, de acuerdo con una o más implementaciones de BOPS. La SSL/TLS bidireccional, que en la presente solicitud se construye sobre SSL/TLS unidireccional, proporciona comunicación comenzando en el dispositivo cliente 104. La comunicación inicial (por ejemplo, Génesis) puede definir el origen de la identidad del cliente 104 y pasar un certificado bidireccional compatible con BOPS que el dispositivo cliente 104 puede usar para comunicaciones posteriores, junto con la afirmación de identidad orientada a la sesión. En una o más implementaciones, la aplicación cliente puede tener una clave SSL/TLS bidireccional precargada que permite operaciones posteriores de Génesis.
De acuerdo con una o más implementaciones, un servidor BOPS 102 recibe una comunicación SSL/TLS unidireccional con identidad SSL/TLS bidireccional desde un dispositivo cliente 104. La comunicación se realiza a través de SSL/TLS unidireccional y SSL/TLS bidireccional. En una o más implementaciones, el servidor 102 usa un almacén de datos para tomar información de identidad confiable y recopilar roles para procesar en nombre de una identidad respectiva. Además, la auditoría maximiza los artefactos apropiados para la verificación y validación continuas del acceso confiable. El aseguramiento puede ocurrir como una función de simplificación y documentación de un mecanismo de control de acceso de varios niveles. En una o más implementaciones de BOPS, se proporciona una consola de administración (en adelante "consola de administración") en una interfaz gráfica de usuario después de completar un proceso de registro, que permite la modificación dinámica de usuarios, grupos y roles, y se describe con mayor detalle en la presente descripción. En la Figura 7B se ilustra un ejemplo de consola de administración. Con referencia a la Figura 7A, una solicitud de testigo (RESTful) se transmite desde un dispositivo cliente 104 (1) y se recibe desde el servidor BOPS 102 y se verifica (2). Puede configurarse una entrada DNS para el nombre de host 102 del servidor BOPS para que tenga una clave en el almacén de claves (3), y se formatea una solicitud (4A) y se transmiten m respuestas de testigo al dispositivo cliente 104 a través de SSL/TLS bidireccional (4B). A continuación, se transmite un testigo (por ejemplo, 5-tupla y una marca de tiempo) desde el dispositivo cliente 104 (5), que se verifica, incluso en función de una marca de tiempo m en la solicitud (6, 7). A continuación, se determina (8) la 5-tupla faltante frente a un almacén de confianza y se formatea una solicitud (9) y se transmite un testigo SHA512 al dispositivo cliente 104 (10).
Continuando con la referencia a la Figura 7A, una solicitud de registro que incluye el testigo SHA512 se transmite desde el dispositivo cliente 104 (11) y se recibe para verificación por el servidor BOPS 102 (12) y la solicitud de firma del cliente se procesa para desbloquear la certificación (13), que incluye calcular una contraseña de un solo uso y verificar un recuento de testigos frente a un almacén de claves (14) y enviar una contraseña de certificado de cliente a un servicio de notificación externo (15). Además, la etapa de verificación en 12 bifurca a las etapas asociadas con la analítica, e incluye determinar la información del dispositivo (16), la información del perfil (17) y los datos biométricos (como se muestra y describe en la presente descripción) (18).
Además, la contraseña del certificado del dispositivo cliente se transmite de vuelta al dispositivo cliente 104 (19), así como también una solicitud formateada (2) y un testigo SHA512 (21). A continuación, se transmite una solicitud de seguridad personalizada, que incluye el testigo SHA512, desde el dispositivo cliente 104 (22), que se verifica mediante el servidor BOPS 102 (23). Se formatea una solicitud (24) y se transmite una respuesta de seguridad personalizada (que incluye un testigo SHA512) al dispositivo cliente 104 (25).
En una o más implementaciones de BOPS, se proporciona un sistema de detección de intrusos activo, incluso a través de los dispositivos 112. El sistema de detección de intrusos activo es eficaz para prevenir un ataque de fuerza bruta, denegación de servicio (por ejemplo, denegación de servicio distribuida o única) u otros ataques. Se puede definir y aplicar una regla personalizada que identifique y rastree los intentos de falsificar la suplantación de certificados SSL/TLS bidireccionales, la repetición de sesiones, los paquetes falsificados o una variedad de técnicas de elusión en un esfuerzo por comprometer un dispositivo servidor BOPS 102.
En una o más implementaciones de BOPS, se usa criptografía visual para cifrar un vector biométrico inicial (IBV). Esta técnica ofrece la ventaja de recomponer rápidamente el IBV, por ejemplo, mediante el uso de una operación XOR en un dispositivo en particular que realiza una comparación biométrica. Por ejemplo, pueden usarse técnicas desarrolladas por Moni Naor y Adi Shamir, que proporcionan un esquema de intercambio secreto. En una operación de ejemplo, un vector se divide en N partes y la recomposición del vector inicial requiere todas las N partes. Los dispositivos respectivos incluyen un servidor BOPS 102 y una aplicación de cliente móvil 104, y el vector inscrito puede dividirse en 2 partes, una almacenada en un depósito BOPS accesible por el servidor BOPS 102 y la otra en el dispositivo informático móvil 104.
En una o más implementaciones de la presente solicitud, pueden emplearse otras formas de cifrado y/o mecanismos para asegurar la confidencialidad de los datos. Por ejemplo, la criptografía de curva elíptica puede usarse en lugar de (o potencialmente además de) la criptografía visual.
Durante una acción de autenticación biométrica de ejemplo, un vector recién adquirido y ambas partes de un vector inscrito pueden estar disponibles en una única ubicación (por ejemplo, la aplicación del dispositivo informático móvil 104 o el servidor BOPS 102), o en múltiples ubicaciones. En cualquier caso, mediante el uso de las partes de los vectores inscritos, el vector inicial puede recomponerse en la memoria, lo que respalda la autenticación que se produce en su contra. La Figura 8 ilustra una descripción general, que incluye el acceso y el intercambio de datos, en relación con un proceso de inscripción. Con respecto al servidor BOPS 102, la identificación se proporciona en función de la cuenta y el dispositivo de un sujeto. La cuenta y el dispositivo del sujeto son parte de la información de perfil del sujeto dado. La información del perfil se almacena en un almacén de datos agrupado. Para el partido, el IBV se toma en partes, se reconstituye y se descifra. Si el algoritmo de coincidencia no es compatible con Euclides, la coincidencia se produce como texto sin formato; de lo contrario, la coincidencia se produce en el dominio cifrado. En una implementación alternativa, se utiliza el cifrado homomórfico, que permite realizar cálculos sobre texto cifrado y generar así un resultado cifrado. Las operaciones coincidentes se pueden realizar en un espacio cifrado, lo que aumenta la privacidad y la seguridad. Por ejemplo, la coincidencia puede ocurrir en el espacio cifrado mediante el uso de un cifrado unidireccional, ofreciendo así un alto nivel de privacidad y excluyendo efectivamente la capacidad de obtener el IBV de texto sin formato original.
En una o más implementaciones, un algoritmo realiza un cifrado unidireccional de tal manera que tiene dos partes: una para el cliente y otra para el servidor. Si la coincidencia usa una distancia euclidiana (por ejemplo, una distancia de Hamming), como se conoce en la técnica, la coincidencia se produce en un espacio cifrado. Alternativamente, si la coincidencia no usa una distancia de Hamming, entonces la coincidencia ocurre en el espacio de texto sin formato, como se describe en la presente descripción.
En una o más implementaciones, se usa una almohadilla aleatoria de un solo uso (ROTP) para realizar un cifrado unidireccional que permite la coincidencia en el espacio cifrado. Alternativamente, la criptografía visual se usa para un cifrado reversible en el caso de que coincida en texto sin formato. Por ejemplo, en el caso de no tener una distancia de Hamming, entonces se usa criptografía visual para volver al texto sin formato para que ocurra una coincidencia en la memoria. Preferentemente, el cifrado y el descifrado usan uno de los dos algoritmos de cifrado: 1.
Máscara de bits o 2. Transformación matricial. Idealmente, todos los algoritmos de coincidencia tendrán una distancia de Hamming y, por lo tanto, el servidor nunca tendrá un IBV de texto sin formato.
El siguiente es un algoritmo de ejemplo en relación con el reconocimiento de iris que se realiza en función del cálculo de la distancia de Hamming entre dos vectores binarios. En el algoritmo de ejemplo, la coincidencia puede realizarse directamente en las mitades cifradas del biométrico sin convertirlas en texto sin formato de la siguiente manera (A denota la operación XOR bit a bit):
El servidor almacena: Inscribir vector A ruido.
El teléfono envía: Verificar vector A el mismo ruido.
La comparación se realiza en el servidor: (Inscribir vector a ruido) a (Verificar vector a el mismo ruido).
XOR es conmutativo y asociativo, por lo tanto, esto se puede reorganizar en: (Inscribir vector a Verificar vector) a (ruido A el mismo ruido).
XOR es autoinverso, por lo tanto (ruido a el mismo ruido) = I, donde I es el elemento de identidad para XOR, que es 0.
Por lo tanto, la expresión se simplifica a: (Inscribir vector a Verificar vector) a i = (Inscribir vector a Verificar vector). La distancia de Hamming entre A y B es una función de A a b .
Por lo tanto, la distancia de Hamming entre los vectores con ruido es idéntica a la distancia de Hamming entre los vectores originales.
En una implementación de ejemplo en la inscripción, ocurre lo siguiente:
a) . Vector de inscripción:
00110011
b) . Secuencia aleatoria (primera mitad del vector): almacenar en el servidor
01010101
c) . Segunda mitad del vector (calculado): almacenar en el teléfono
01100110
En la verificación:
e) . vector de verificación: (observe que solo el último bit cambió entre la inscripción y la verificación porque esta es una buena coincidencia).
00110010
Segunda mitad del vector: almacenado en el teléfono
01100110
f) . Calcular la aproximación a la primera mitad del vector (de e y c):
01010100
En la coincidencia:
g) . enviar esta "primera mitad de verificación" (f) al servidor.
h) . el servidor ahora tiene:
1ra mitad del vector de inscripción b):
01010101
1ra mitad del vector de verificación f):
01010100
marcar todos los bits que han cambiado entre b y f con un 1:
00000001
El sistema puede decir que solo el último bit cambió entre el registro y la verificación, lo que representa una buena coincidencia, pero observe que el servidor solo estaba tratando con datos codificados y que el vector real no se conoce en el servidor, solo puede calcularse la diferencia en los vectores.
En una implementación alternativa, el reconocimiento facial se realiza calculando la distancia euclidiana entre los vectores de plantilla, donde la cara no puede someterse a ingeniería inversa del vector. Cuando se hacen coincidir dos imágenes de caras, por ejemplo, mediante el uso de una red neuronal, cada cara se convierte primero en un vector flotante de 128 bytes de tamaño. La representación de este vector flotante es arbitraria y no puede aplicarse ingeniería inversa a la cara original. Para comparar las caras, se calcula la distancia euclidiana de los dos vectores. Dos caras de la misma persona deben tener vectores similares, y las caras de diferentes personas deben estar más separadas en el espacio euclidiano. Puede calcularse un vector de verificación en el dispositivo móvil y transmitirlo a un servidor remoto para que coincida con un vector de inscripción almacenado. En consecuencia, un biométrico original (por ejemplo, la cara) nunca abandonará el dispositivo del usuario, y todas las coincidencias pueden calcularse en el servidor.
En otra implementación más, el reconocimiento de huellas dactilares se realiza calculando la distancia euclidiana entre vectores de plantilla, donde las huellas dactilares no pueden modificarse mediante ingeniería inversa a partir del vector. De manera similar, como se describió anteriormente, puede aplicarse una red neuronal para la comparación de huellas dactilares. En tal caso, la huella dactilar puede convertirse en un vector en el dispositivo y el vector se transmitiría, eliminando así una forma de reconstruir la imagen de la huella dactilar original a partir del vector de salida de la red.
En una o más implementaciones, se genera aleatoriamente una clave de cifrado en el dispositivo, que se usa para ofuscar el vector de salida de la red neuronal. Por ejemplo, el vector biométrico cifrado = matriz de cifrado x vector biométrico de texto sin formato. En tal caso, la transformación de la matriz de cifrado tiene la propiedad especial de que las distancias euclidianas se conservan, por lo que la matriz debe ser una transformación rígida. En tales casos, el vector biométrico no deja el dispositivo en un formato sin cifrar, y el servidor compara dos datos biométricos cifrados y calcula la distancia euclidiana sin conocer el texto sin formato. Cuando el usuario desea verificar desde un nuevo dispositivo, el usuario puede transferir los datos de cifrado al nuevo dispositivo, por ejemplo, a través de un código QR. Esto requiere que el dispositivo antiguo esté disponible. Si el dispositivo antiguo se pierde o no está disponible, el usuario se vuelve a inscribir, como se muestra y describe en la presente descripción.
Por consiguiente, la privacidad mejorada se proporciona en función de un vector biométrico que se divide y almacena cifrado y entre dispositivos. Ninguna parte del vector biométrico existe en el servidor en forma de texto sin formato ni en el disco ni en la memoria. Además, la presente solicitud proporciona análisis mejorados, ya que los usuarios que deseen realizar un análisis "qué pasaría si" en las autenticaciones respectivas y las autenticaciones fallidas pueden hacerlo a través de una interfaz de administración que soporta facetas, búsquedas, análisis y similares.
La Figura 9 ilustra componentes de una arquitectura de seguridad 900 de ejemplo de acuerdo con una o más implementaciones de BOPS. Como se muestra en la Figura 9, un clúster de seguridad BOPS 902 puede configurarse para ejecutar instancias de BOPS en redes privadas virtuales (VPN). Los atributos principales de una entidad de autoridad de certificación, el Almacén de claves de BOPS y el Almacén de confianza de BOPS pueden ubicarse, por ejemplo, en las instancias de BOPS. Las instancias de BOPS también pueden contener datos asociados con y/o que representan DNS, biblioteca OTP, claves de servicios de notificación, adaptadores comerciales, propiedades de configuración de BOPS. El clúster de equilibrador de carga 904 puede incluir uno o más dispositivos que garantizan la confiabilidad y disponibilidad de los servicios BOPS, carga de trabajo distribuida. Un equilibrador de carga BOPS 904 configurado puede funcionar para maximizar el rendimiento, minimizar el tiempo de respuesta y evitar la sobrecarga de cualquier recurso en la arquitectura BOPS 900.
Continuando con la referencia a la Figura 9, un clúster de persistencia 906 puede incluir uno o más grupos de seguridad de base de datos y puede configurarse para el autoescalado de clústeres de datos BOPS. A medida que los servicios de autenticación se ocupan de los grandes objetos de datos, manejan grandes conjuntos de datos, puede emplearse un almacén de datos masivos, tal como NoSQL y una o más particiones horizontales de datos ("fragmentos") de datos para mejorar el rendimiento leyendo de los fragmentos simultáneamente fusionando los resultados. La arquitectura de seguridad de la base de datos 900 implementa una arquitectura BOPS y evita el almacenamiento centralizado de datos confidenciales en una única ubicación. También se ilustra en la Figura 9 el clúster de monitorización 908, que puede incluir dispositivos IDS 112.
Las Figuras 10A y 10B ilustran dispositivos y etapas asociadas con los procesos de inscripción respectivos y alternativos 1000 y 1010, respectivamente, de acuerdo con una o más implementaciones de BOPS. Las implementaciones mostradas en las Figuras 10A y 10B proporcionan mecanismos para almacenar datos biométricos cifrados asociados con la cuenta o dispositivo, para almacenar información sobre todos los cambios de datos biométricos, para cargar y usar servicios de autenticación y sus bibliotecas biométricas correspondientes (por ejemplo, FACE, 4F, IRIS) y proporcionar operaciones de API para admitir nuevos flujos (por ejemplo, inscripción y autenticación).
En la implementación mostrada en la Figura 10A, una aplicación de software ("MCA") que se ejecuta en un dispositivo informático móvil 104 proporciona la adquisición de un vector biométrico inicial (IBV), para realizar una operación de división criptográfica durante el proceso de inscripción y distribuir este proceso para menor carga de CPU en un lado del servidor, para realizar la solicitud de inscripción (registro) con el servidor BOPS 102 y para realizar una operación de coincidencia criptográfica, cuando el método para el flujo de autenticación se configura para que tenga lugar en el lado del cliente 104. El servidor BOPS 102 puede configurarse para guardar los datos de identidad del usuario junto con el vector compartido, por ejemplo, en el almacén de datos masivos de BOPS 1002 durante un proceso de inscripción. Además, el servidor BOPS 102 puede gestionar el flujo de autenticación e integrar el componente de comunicación del servicio de autenticación (1004). Un servicio de autenticación (1006) puede cargar dinámicamente uno o más algoritmos de autenticación, bibliotecas de motores biométricos, proporcionar soporte para el control de versiones del motor de autenticación, normalizar las comunicaciones entre un servidor BOPS 102 y uno o más motores biométricos, proporcionar soporte para el control de versiones de los motores de autenticación, y normalizar la comunicación entre un servidor BOPS 102 y los motores de autenticación. Un servicio de autenticación envuelve un servicio biométrico al realizar una autenticación.
Como se explica en la presente descripción, se proporcionan uno o más mecanismos para servicios de autenticación conectables y sus correspondientes motores biométricos. En consecuencia, las implementaciones de BOPS pueden configurarse (por ejemplo, a través de una ubicación de servicios de autenticación y bibliotecas biométricas) y pueden cargar automáticamente los servicios disponibles y registrarse en el sistema.
Como resultado, una lista de servicios de enunciación está disponible a nivel de sistema, por ejemplo: motor 4F; motor FACIAL; motor de IRIS; motor de VOZ. Una lista de autenticadores incluye un autenticador FIDO o un autenticador BOPS.
La presente solicitud proporciona mejoras a los servicios de autenticación de integración biométrica al admitir las siguientes características. Pueden proporcionarse uno o más mecanismos para almacenar datos biométricos cifrados en una cuenta o dispositivo accesible por el servidor BOPS 102. Además, puede proporcionarse un mecanismo para almacenar información que represente los cambios de datos biométricos que se produzcan. Además, puede proporcionarse un mecanismo "genérico" para acceder y usar servicios de autenticación que incluyen (por ejemplo, en relación con la autenticación biométrica de rostro, cuatro dedos e iris, tal como se muestra y describe en la solicitud de patente de los Estados Unidos con número de serie 14/201,462, la solicitud de patente de los Estados Unidos con número de serie 14/201,499, la solicitud de patente de los Estados Unidos con número de serie 14/988,833, y la solicitud de patente de los Estados Unidos con número de serie 14/819,639 comunmente asignadas.
En una o más implementaciones de la presente solicitud, un dispositivo informático móvil 104 adquiere un vector de inscripción y realiza una operación de división criptográfica durante un proceso de inscripción. Esto proporciona una mejora en la funcionalidad informática al distribuir el proceso y reducir la carga de la CPU en el lado del servidor. Además, el dispositivo móvil 104 puede realizar una solicitud de inscripción (registro) a un servidor BOPS 102 y realizar una operación de coincidencia criptográfica cuando se configura una etapa de "validación biométrica" del flujo de autenticación para que tenga lugar en el móvil.
En una o más implementaciones de la presente solicitud, el servidor BOPS 102 almacena información de identidad del usuario junto con al menos una porción de un vector compartido, por ejemplo, en un repositorio APACHE SOLR durante el proceso de Inscripción. Además, el servidor BOPS 102 puede configurarse para gestionar la información de autenticación y el flujo de proceso e integrar al menos un componente de comunicación de servicios biométricos. Otros componentes proporcionados en una arquitectura de acuerdo con la presente solicitud pueden incluir uno o más servicios de autenticación y uno o más motores biométricos. Los servicios de autenticación pueden configurarse para realizar la carga dinámica de una o más bibliotecas configuradas para admitir el control de versiones de uno o más servicios de autenticación, para normalizar la comunicación entre el servidor BOPS 102 y los servicios de autenticación, y para ofrecer uno o más escenarios de implementación, tales como las máquinas de aplicaciones web donde una o más instancias de BOPS salen o son una nube separada que puede escalar por sí misma.
En una o más implementaciones, los motores biométricos se configuran para comprender bibliotecas biométricas no administradas que están sujetas a una interfaz, y definidas e implementadas por cada biblioteca respectiva para conectarse al sistema implementado por BOPS. Los motores biométricos ofrecen preferentemente un método "Carga" para cargar un motor si es necesario, un método "Descargar Carga" para descargar un motor para liberar recursos (por ejemplo, memoria, archivos temporales), un "Obtener estado" para proporcionar información de estado (por ejemplo, INIT_FAILED, OK, ERROR, OUT_OF_MEMORY), un método "Dividir" para cifrar un vector adquirido durante la Inscripción, un método "Coincidir" para autenticar un vector, por ejemplo, basado en partes compartidas de un vector inicial, un método "Activar/Registrar" y una descripción del motor. La descripción puede incluir, por ejemplo, un identificador de tipo biométrico, un nombre y una descripción, una versión del motor y un formato biométrico. Mediante el uso de esta información, uno o más procesos asociados con la presente solicitud pueden cargar y registrar automáticamente un motor biométrico específico.
En una o más implementaciones, se admite un mecanismo para servicios de autenticación conectables que permiten que el sistema pueda configurarse (ubicación del servicio de autenticación) y cargue las bibliotecas disponibles automáticamente y se registre en el sistema. Cada biblioteca biométrica, llamada por el servicio de autenticación, puede proporcionar información, tal como una cadena constante (tipo biométrico), una versión respectiva, un nombre y una descripción, para describirse a sí misma. Además, la información, tal como el par (Tipo biométrico, Versión biométrica) puede identificar un motor biométrico único.
Los servicios de autenticación de ejemplo y sus motores biométricos correspondientes y de nivel inferior pueden enumerarse y estar disponibles en el nivel del sistema, que incluye, por ejemplo, 4F, FACIAL, IRIS y VOZ, tal como se muestra y describe en la solicitud de patente de los Estados Unidos con número de serie 14/201,462, la solicitud de patente de los Estados Unidos con número de serie 14/201,499, la solicitud de patente de los Estados Unidos con número de serie 14/988,833, y la solicitud de patente de los Estados Unidos con número de serie 14/819,639 comunmente asignadas.
Como se indica en la presente descripción, en una o más implementaciones de BOPS, los procesos de Génesis e Inscripción están efectivamente desacoplados, lo que permite determinar la identidad de un sujeto sin un requisito directo de que un servidor BOPS 102 acceda a un vector biométrico, certificado u otra información confidencial necesaria para procesamiento automatizado. En consecuencia, una solución BOPS puede interpretarse como "abierta" y puede permitir prácticamente cualquier personalización en Génesis e Inscripción. Por ejemplo, Génesis puede incluir el uso de un nombre de usuario y contraseña para acceder a DIRECTORIO ACTivO, un correo electrónico o mensaje de texto de validación, o un funcionario de una organización para verificar físicamente la identidad. El registro previo de una cuenta de usuario, por ejemplo, que puede ocurrir en lotes, puede basarse en los requisitos comerciales. Además, un proceso Génesis puede formar una dependencia total de la gestión de riesgos y puede, además, determinar el procesamiento aguas abajo. Durante un proceso posterior a Génesis de ejemplo, un usuario inscribe sus datos biométricos, que pueden incluir la emisión de un certificado de cliente único para un dispositivo inscrito respectivamente. Además, puede establecerse una contraseña de un solo uso (por ejemplo, una "semilla") entre un dispositivo cliente 104 y un dispositivo servidor 102, y puede usarse un valor semilla adicional para la prevención de ataques de repetición.
Se reconoce en la presente descripción que un solo usuario puede tener muchos dispositivos y/o un solo dispositivo puede tener muchos usuarios (es decir, un solo dispositivo puede tener muchos datos biométricos). Por lo tanto, una forma de relación de muchos a muchos puede ocurrir como una función de separar los procesos de Génesis y de Inscripción. En consecuencia, un sujeto identificado, a través de Génesis, puede inscribirse muchas veces con muchos datos biométricos. En una o más implementaciones de BOPS, el proceso de inscripción usa un certificado bidireccional de capa de conexión segura/seguridad de capa de transporte (SSL/TLS), que puede generarse por el servidor. Dicha generación puede ocurrir después del proceso Génesis, asegurando así que el certificado sea adecuado para el sujeto bien definido.
Además, una o más implementaciones de BOPS pueden tener varios niveles de aprovisionamiento, lo que proporciona flexibilidad para diferentes niveles de seguridad. Por ejemplo, un nivel alto de Génesis incluye a un usuario validado físicamente frente a alguien, tal como un oficial. Un nivel bajo, como alternativa, puede incluir simplemente definir un nombre de usuario y una contraseña junto con un correo electrónico de validación que recibe un usuario. Se pueden implementar varios niveles de Génesis y procesos de verificación en función de una o más decisiones comerciales que pueden ser únicas o específicas para una o más organizaciones respectivas. Además, el procesamiento posterior puede cambiar en base al nivel de Génesis respectivo. Por ejemplo, un sistema permite una transferencia de $ 1000000 en conexión con un nivel alto de Génesis, pero solo una transferencia de $ 100 en conexión con un nivel inferior de Génesis.
La Figura 11 es un diagrama de bloques que ilustra los posibles requisitos y ejemplos 1100 asociados con diferentes niveles de Génesis, de acuerdo con la presente solicitud. Dado que se necesitan requisitos adicionales en los procesos de verificación, los niveles de seguridad respectivos pueden crecer en consecuencia. En los niveles de ejemplo de la Figura 11, el primer y segundo nivel pueden intercambiarse en base a las consideraciones organizativas. Por ejemplo, si un objetivo es verificar y dar acceso a Wi-Fi a los visitantes de negocios, entonces la verificación puede enviarse a través de un dispositivo móvil y se considera en la presente descripción como un nivel de verificación bajo.
Durante una fase de inscripción, una aplicación móvil que se ejecuta, por ejemplo, en un dispositivo informático móvil 104 inscribe datos biométricos en función de las respectivas capacidades integradas. Por ejemplo, una aplicación móvil creada para una integración específica y que ha requerido datos biométricos predeterminados puede tener tales módulos específicamente codificados en la aplicación.
Una o más implementaciones de BOPS aborda la velocidad de la transacción de autenticación biométrica y resuelve el problema de una amenaza virtualizada en un dispositivo móvil. Un ejemplo de tal amenaza es que un intruso descompila el código en una imagen virtual copiada de un dispositivo móvil, usa este código fuente para detener las llamadas de autenticación e intenta obtener el control de un servidor que autentica y otorga permisos.
Para mitigar estos riesgos, el proceso en una implementación de BOPS encripta el valor biométrico inicial (IBV) sin la clave de encriptación, luego la mitad del IBV se almacena en el dispositivo cliente 104 y la otra mitad se almacena en el servidor 102 o es accesible de otro modo. La coincidencia biométrica puede ocurrir en el servidor 102. La Figura 12 ilustra un flujo de información 1200 de ejemplo asociado con un vector biométrico inicial ("IBV") durante los procesos de inscripción y autenticación. En el flujo de ejemplo ilustrado en la Figura 12, durante la inscripción, el IBV se captura y se divide, y una porción (por ejemplo, la mitad) del IBV se almacena en el dispositivo cliente 104. Una porción (por ejemplo, la mitad o 1/2) del IBV se transmite en una solicitud de inscripción al servidor BOPS 102, y la porción se almacena, por ejemplo, en un almacén de datos accesible por el servidor BOPS 102. A continuación, el servidor BOPS 102 transmite la confirmación de Inscripción.
Continuando con la referencia a la Figura 12, se captura un vector biométrico actual ("CBV") durante un proceso de autenticación biométrica posterior y se envía en conexión con una solicitud de autenticación ("Aut") al servidor BOPS 102 que incluye una porción restante (2/2). El servidor BOPS 102 se configura para combinar la porción recibida del IBV en la solicitud de autenticación, y combinar la porción almacenada del IBV para descifrar. El CBV recibido se compara con el IBV completo en texto sin formato y, en función de la determinación durante la comparación, se devuelve un número (por ejemplo, un número flotante) al dispositivo informático cliente 104. Si hay una coincidencia, el usuario puede registrarse como autenticado. Además, los resultados del proceso de autenticación pueden visualizarse en el dispositivo informático cliente 104.
Por tanto, y como se ilustra en las etapas mostradas en la Figura 12 y descritas en la presente descripción, una implementación de BOPS de acuerdo con la presente solicitud aborda la velocidad de una transacción de autenticación biométrica y resuelve problemas asociados con una amenaza virtualizada en un dispositivo cliente. Tal amenaza puede ocurrir, por ejemplo, después de que un intruso descompila software en una imagen virtual copiada de, por ejemplo, un dispositivo móvil, usa el código fuente para detener las llamadas de autenticación e intenta obtener un control del servidor que autentica y otorga permisos.
Para mitigar estos riesgos, las funciones asociadas con una implementación de BOPS pueden funcionar para cifrar el IBV sin una clave de cifrado, almacenar una porción (por ejemplo, la mitad) del IBV en el dispositivo cliente y una porción (por ejemplo, la otra mitad) en el servidor o un dispositivo accesible por él. La coincidencia biométrica puede ocurrir en el servidor. De esta manera, un dispositivo robado no puede eludir la autenticación, al menos en parte porque un dispositivo o servidor comprometido no proporciona información útil al atacante.
De acuerdo con una o más implementaciones, lo siguiente proporciona el establecimiento de un acuerdo de procesamiento para la autenticación biométrica en una o más implementaciones de BOPS. Un vector biométrico se divide al menos entre el cliente y el servidor, y el enfoque para la autenticación es agnóstico de la biometría. Por ejemplo, y en relación con el reconocimiento facial, el tamaño del vector biométrico inicial puede ser de aproximadamente 20 KB, lo que podría minimizarse mediante la subida/bajada de una solicitud HTTP y una respuesta HTTP y, por lo tanto, se acepta. El algoritmo de división para un IBV en relación con el reconocimiento facial puede ser el siguiente: el bit cero es el blanco y el bit uno el negro. En consecuencia, una implementación de BOPS puede corresponder a Criptografía Visual (VC). Como se indica en la presente descripción, la presente solicitud puede usarse con prácticamente cualquier biométrico y proporciona un mecanismo para tomar el IBV y cifrarlo con VC. Con VC, la coincidencia se produce en texto sin formato. Alternativamente con Aleatorio, la coincidencia se produce en el dominio cifrado.
Con referencia específica a la Figura 12, un dispositivo informático cliente 104 que opera mediante el usuario procede con la inscripción biométrica (1) y captura un vector biométrico inicial (IBV) (2). En la etapa (3), el IBV se cifra y se divide, y 2/2 del IBV se almacena localmente en o con el dispositivo informático cliente 104 (4), y se envía una solicitud de inscripción que incluye la mitad del IBV transmitido al servidor BOPS 102 a través de una capa de transporte (a través de SSL/TLS bidireccional) (5). El 1/2 IBV se almacena por el servidor BOPS 102, tal como en datos masivos de BOPS (6) y se transmite una confirmación de Inscripción desde el servidor BOPS 102 de vuelta al dispositivo informático cliente 104 (7).
Continuando con la referencia a la Figura 12, después de la inscripción, se produce la autenticación biométrica en el dispositivo informático cliente 104 (8) y se captura un vector biométrico actual (9). A continuación, se envía una solicitud de autenticación a través de la capa de transporte (10) que recibe el servidor BOPS 102, combinada con el IBV 2/2 y se usa para el descifrado (11). A continuación, el CBV se compara con el IBV de texto sin formato (12) y se transmite un número flotante al cliente 104 (14), y se muestran los resultados (15).
Pasando ahora a la Figura 13, se muestra un ejemplo de criptografía visual (VC) 1300 que se implementa en conexión con la presente solicitud. La VC proporciona una buena sinergia con el cifrado, la división de un IBV y la reconstrucción del IBV sin un requisito de gestión de claves. En el ejemplo de criptografía visual que se muestra en la Figura 13, el negro puede ser igual a 1 y el blanco puede ser igual a 0. En el ejemplo, el IBV es igual a 00100110. Puede usarse una reconstrucción XOR porque la solución es booleana. El proceso de cifrado de vectores biométricos original puede ocurrir mediante el uso de criptografía visual, y los resultados pueden ser dos vectores señalados como hojas, que contienen solo ruido blanco. El almacenamiento móvil (por ejemplo, el dispositivo cliente 104) contiene una de las hojas y el dispositivo servidor 102 contiene o accede a la otra. El proceso de verificación combina las dos hojas mediante una operación booleana simple que da como resultado la reconstrucción completa del vector biométrico original.
Un ejemplo de reconstrucción de un IBV en relación con una operación XOR se muestra a continuación en la Tabla 1.
Tabla 1
Figure imgf000014_0001
Con referencia a la Tabla 1 y en conexión con una implementación de BOPS de ejemplo, el proceso de cifrado de vector biométrico original puede ocurrir mediante el uso de criptografía visual, y los resultados de este cifrado son dos vectores señalados como hojas que contienen solo ruido blanco. Como se indica en la presente descripción, el almacenamiento asociado con el dispositivo cliente 104 incluye una de las hojas y el almacenamiento asociado con el dispositivo servidor 102 contiene la otra. El proceso de verificación combina las dos hojas mediante una operación booleana simple que da como resultado la reconstrucción completa del vector biométrico original.
La Figura 14 ilustra un ejemplo de superposición de dos partes (2,2) en el esquema de criptografía visual (VCS) donde cada bit se cifra en partes en relación con una implementación de BOPS de ejemplo. En el ejemplo que se muestra en la Figura 14, la elección de partes para un bit cero y uno es un proceso aleatorio. Al codificar el bit cero o uno, se toma un valor de la tabla para una parte y el valor adyacente en la tabla para la otra parte. Al final del proceso, ninguna de las partes proporciona ninguna pista sobre el bit original. La superposición de las dos partes (mediante el uso de OR o XOR) determina el valor del bit original.
Continuando con la referencia al ejemplo mostrado en la Figura 14, se muestra una superposición de dos partes (2,2) en un Esquema de Criptografía Visual (VCS), donde cada bit se cifra en partes. Tenga en cuenta que la elección de partes para un bit cero y uno puede implementarse en un proceso aleatorio. Cuando se codifica el bit cero o uno, se toma un valor de una tabla (por ejemplo, Tabla 1) para una parte y el valor adyacente en la tabla para la otra parte. Al final del proceso, ninguna de las partes proporciona ninguna pista sobre el bit original. A partir de entonces, la superposición de las dos partes, por ejemplo, mediante el uso de OR o XOR, determina el valor del bit original. Este es un ejemplo de (2,2) v Cs . El VCS puede extenderse a más de dos partes cambiando la probabilidad del proceso aleatorio. Cambiar la probabilidad del proceso aleatorio de 0,5 a 0,25 da como resultado que los partes tengan 4 bits en lugar de los dos bits presentes en el ejemplo de 0,5. Además, cambiar la probabilidad del proceso aleatorio a 0,125 da como resultado un cifrado de 8 bits para cada bit de entrada.
Con respecto a la detección de una coincidencia, uno o más módulos en una implementación de BOPS de ejemplo emplea múltiples vectores biométricos iniciales. Luego, hay dos llamadas de servicios web RESTful que se comunican a través de SSL/TLS, una para cada biométrico. Una llamada puede incluir mitades de IBV, además de un biométrico actual en una sesión de autenticación, y devolver un valor de punto flotante que representa la fuerza de la coincidencia. Otra llamada puede ofrecer un IBV (la mitad) a la vez y el biométrico actual, y devolver un valor de punto flotante que representa la fuerza de la coincidencia. Para la segunda llamada, puede haber varias llamadas consecutivas: por ejemplo, un IBV a la vez para determinar una coincidencia.
Los cálculos de tamaño según un acuerdo de coincidencia en relación con una implementación de BOPS de ejemplo, pueden ser los siguientes: 20 kb por vector de cara, 5 fotogramas por segundo; durante 10 segundos = 50 vectores; 50 x 20 kb = 1000 kb.
A continuación se describe un ejemplo de la logística correspondiente en relación con la implementación identificada anteriormente. Los 1000 KB se envían al servidor para la coincidencia. Si no hay coincidencia, se envían los segundos 100 KB, y así sucesivamente, hasta que se determina un valor de punto flotante. En una o más implementaciones de BOPS, se define un umbral mínimo y el valor de punto flotante está al menos dentro del umbral mínimo. De acuerdo con un algoritmo de coincidencia de ejemplo, la trama actual requiere 200 milisegundos más un tiempo de subida/bajada de 125 milisegundos para el servidor. Por tanto, la transmisión de tramas lleva la velocidad de transacción a 325 milisegundos por trama, más la coincidencia. Cuando la coincidencia tiene un límite superior en 100 milisegundos, la transmisión de la trama es aproximadamente de 425 milisegundos. En caso de que falle, se puede transmitir un lote de fotogramas (por ejemplo, cinco a la vez) y se puede intentar una coincidencia nuevamente. Preferentemente, la coincidencia se lleva a cabo en menos de un segundo de tiempo, aunque en ciertos casos menos favorables, la coincidencia podría llevar más tiempo, por ejemplo, en segundos.
Como se muestra y describe en la presente descripción, la naturaleza flexible y autenticadora y agnóstica biométrica de la presente solicitud permite a las organizaciones definir un autenticador y biométrico respectivos que puede usarse para la autenticación y que puede definirse como un biométrico predeterminado. En ausencia de una especificación de un biométrico como parte de una transacción aguas abajo, el biométrico predeterminado puede especificarse a través de una o más interfaces de usuario, tal como a nivel organizacional, nivel de usuario de grupo o nivel de transacción.
En una o más implementaciones, puede configurarse una consola de administración en una interfaz gráfica de usuario y ser accesible a los respectivos usuarios autorizados. La consola de administración puede incluir controles gráficos que, cuando se seleccionan, dan como resultado la configuración para un tipo biométrico predeterminado. Por ejemplo, una organización, ACME Plumbing, especifica que para cierto acceso, la cara se usará como biométrico predeterminado para todos los empleados de ACME. Además, ACME Plumbing especifica que en otros contextos se deben usar 4 dedos para la biométrica para todos los clientes, y aún más específica en otros contextos que tanto los 4 dedos como la cara deben usarse para todas las transacciones de los empleados que superen los $ 10000. Estas opciones se presentan en la consola de administración para que las defina un administrador de ACME Plumbing. Por tanto, la presente solicitud proporciona una aplicación flexible y dinámica de uno o más datos biométricos.
Con respecto a la autenticación, puede usarse una pluralidad de fuentes de información para los datos biométricos en una configuración de organización específica tal como, por ejemplo: un motor de condición; un perfil de miembro; y una definición de miembro. El motor de condición puede basarse en reglas dinámicas que se definen en el sistema. Por ejemplo, cualquier transacción de más de $ 1K requiere al menos dos formas de verificación biométrica. El perfil de miembro define los roles de usuario y los privilegios correspondientes. Por ejemplo, el perfil de miembro "Seguridad de la información: primeros respondedores" puede requerir autenticación cada 10 minutos u otra condición, tal como cada transacción de confirmación. La definición de miembro puede definir una autenticación predeterminada a nivel de organización/integración. Por ejemplo, si hay cuatro tipos de datos biométricos disponibles en el sistema (4F, FACIAL, IRIS) y para una implementación de BOPS/Empresa específica, el biométrico predeterminado es "FACIAL", entonces la autenticación facial está disponible de forma predeterminada y puede proporcionarse como tal, por ejemplo, en un tablero proporcionado a través de una interfaz gráfica de usuario y denominado en la presente descripción, generalmente, como un tablero de administración BOPS. Además, las condiciones respectivas, tal como las descritas anteriormente, pueden indicar prioridades. Por ejemplo, la definición de miembro puede considerarse la prioridad más baja y el motor de condición puede considerarse la más alta. La prioridad más alta se convierte en el(los) método(s) de autenticación.
A continuación, se representan etapas de ejemplo asociadas con un proceso de inscripción de acuerdo con la presente solicitud. Un dispositivo informático móvil 104 configurado con una aplicación de cliente móvil adquiere un vector biométrico, realiza el cifrado y luego realiza una llamada API de registro. En particular, después de adquirir un biométrico, la llamada de registro a un servidor BOPS 102 incluye la mitad de un IBV, que se almacena para el acceso del servidor 102. El proceso de registro puede usarse para iniciar una implementación de BOPS dentro de una organización. Aunque muchas de las descripciones y figuras que se muestran en la presente descripción representan una implementación de BOPS que aparece como un clúster, se considera que BOPS puede configurarse como un componente comercial. Antes de que un administrador de BOPS ("administrador de BOPS") configure un entorno, una organización se registra para una clave API respectiva desde un servidor BOPS 102. Los desarrolladores individuales también pueden, en diversas implementaciones, solicitar la clave API.
Una vez finalizado el proceso de inscripción, un administrador del sitio original ("administrador del sitio original") puede crear administradores del sitio adicionales ("administradores del sitio"). La información de inscripción, que incluye la asociada con varios administradores del sitio, puede asociarse con una clave API respectiva asociada con una organización. En una o más implementaciones, el registro de API puede pertenecer a dos dominios: el administrador del sitio original inscrito; y la clave API emitida, que puede basarse en la información de inscripción, la organización y el caso de uso. Una vez que se acuerda el inicio de la solicitud, el proceso de registro se completa. A partir de entonces, un administrador de BOPS crea un administrador del sitio original para una organización, y el administrador del sitio original puede crear un administrador del sitio (consulte, por ejemplo, el cuadro de jerarquía de roles que se muestra en la Figura 15).
Antes de un proceso de desarrollo que utiliza el servicio BOPS, un desarrollador preferentemente se registra, por ejemplo, mediante el uso de opciones en una consola de administración BOPS. Al proporcionar un nombre de aplicación y usar un mecanismo de identificación orientado a preguntas para identificar al desarrollador, puede establecerse una nueva cuenta y crear una clave API, que se identificaría con el nombre de la aplicación y se asociaría con la aplicación.
En una o más implementaciones de BOPS, la comunicación entre una aplicación que opera en un dispositivo cliente 104 y el servidor BOPS 102 se establece en la parte superior del SSL/TLS bidireccional. Los procesos Génesis establecen tal conexión y especifican cómo los usuarios se identifican con el servidor BOPS 102, de manera que el servidor 102 puede generar una clave privada para establecer la comunicación bidireccional SSL/TLS. Proporcionar preguntas secretas es un mecanismo para que los usuarios se identifiquen, que es un enfoque axiomático y que las partes respectivas (por ejemplo, los proveedores) pueden proporcionar un conjunto de preguntas que describen de manera única a un individuo durante la fase "Génesis".
La aplicación cliente que opera en el dispositivo informático de usuario 104 es responsable de proporcionar un identificador (ID) único que identifica el dispositivo 104 del usuario final. La aplicación puede usar el dispositivo 104 y la API asociada para notificar al servidor BOPS 102 sobre el enlace entre el usuario y el dispositivo 104 del usuario.
5-tupla es uno de esos mecanismos que puede usarse para identificar dispositivos 104.
En una o más implementaciones de BOPS, se especifican las respectivas llamadas RESTful y/o comportamiento que puede usarse para que un sistema derrote los ataques y los vectores de ataque. Además, se especifica un formato de solicitudes para proteger datos en tiempo real de ataques conocidos y desconocidos, y puede estar presente en un IDS (a través de, por ejemplo, dispositivos 112). Por ejemplo, la mitigación de repetición puede usarse en un testigo criptográfico de un solo uso para validar el acceso. En tal caso, el IDS es un tercer nivel que verifica que el cliente 104 y el servidor 102 se conozcan entre sí, asegurando así que el servidor 102 está completamente protegido en la capa de aplicación.
La Figura 16 es un diagrama de bloques 1600 que ilustra los dispositivos y el flujo de transmisión en relación con la prevención de repetición. Como se muestra en la Figura 16, los testigos criptográficos de un solo uso validan el acceso y protegen el servidor 102 en la capa de aplicación de los ciberataques de Capa 7 de la Organización Internacional de Normalización (ISO), que incluye la repetición, la denegación de servicio distribuida (DDoS) y otros ataques. La combinación del testigo y el IDS es útil para detectar ciberataques de capa 7 de la Organización Internacional de Normalización (ISO), que incluye la repetición, la denegación de servicio distribuida (DDoS) y ataques similares. El testigo es válido para un uso y normalmente se pasa del cliente 104 al servidor 102 y luego se devuelve a BOPS mediante el uso de llamadas RESTful.
Una premisa en una o más implementaciones de BOPS es que para la detección de DDoS cada testigo debe ser distinto, y al menos un algoritmo empleado entre el cliente y el servidor tiene en cuenta que el tiempo puede variar y que los valores también deben diferir de un cliente a otro, así como también de un acceso a otro. La Figura 17 es un flujo de alto nivel que ilustra las etapas 1700 asociadas con un algoritmo del testigo de acuerdo con una implementación de BOPS de ejemplo. En la etapa 1702, durante la etapa Génesis, un dispositivo web, móvil o integrado (dispositivo cliente 104) emite una llamada RESTful para solicitar un testigo. A continuación, el testigo se recibe y se incorpora en un mensaje cifrado desde el cliente 104 hasta el servidor 102 (1704). El servidor 102 recibe el testigo y verifica la validez del mensaje pasando el testigo al IDS (1706), que luego verifica que el testigo es válido y asegura que la diferencia entre la hora de creación y la hora actual caiga dentro del período de tiempo de 60 segundos especificado (1708).
La Figura 18 ilustra los productos de Génesis/Inscripción y Usuario/Dispositivo en una relación de muchos a muchos. En el cliente móvil 104, se muestran los elementos de identidad que están vinculados con cada cuenta. En el lado del servidor de la Figura 18, el servidor BOPS 102 se ilustra en conexión con atributos de identidad, cuentas y dispositivos en la relevancia de cada identidad. Para cumplir con el cifrado de datos y la comunicación segura entre el cliente y el servidor con un alto nivel de aseguramiento, la información de identidad se conecta con elementos seguros a través de los cuales la cuenta de los usuarios (por ejemplo, las cuentas de Alice o Bob que se muestran en la Figura 18) se autentican adecuadamente como función de sus correspondientes identidades.
Para iniciar la etapa Génesis, el dispositivo cliente 104 puede elegir establecer una tupla de cinco especificando cualquiera o todos los valores respectivos mostrados en la Tabla 2, a continuación. El IDS puede determinar cualquiera de los cinco valores que no establece el cliente y puede devolver un testigo al cliente en un formato RESTful. El cliente 104 y el servidor 102 comparten la misma tupla de cinco, que luego se usan para calcular una marca de tiempo que, a su vez, se codifica en SHA512 y compara por el servidor IDS o BOPS 102. La marca de tiempo calculada retrocede a una hora basada en la tupla de 5 y es única para cada llamada.
En consecuencia, en una o más implementaciones, el testigo no contiene la marca de tiempo en sí, ya que todos los valores del testigo se convierten en una suma SHA512 para comparar. Esto permite que los valores cambien en cada intervalo de valor de minuto para evitar la repetición ciega. Además, el rango de minutos del testigo puede configurarse para que sea 3 (y no 60) para permitir una entropía suficientemente grande (48,771,072) y, por lo tanto, evitar ataques de prueba y error.
Además, puede configurarse un motor semántico para permitir que un administrador de seguridad cree parámetros personalizados adicionales para la detección y prevención de ataques que pueden estar fuera de cualquier estándar internacional y proporcionar más controles y equilibrios contra una amplia variedad de ataques.
En una o más implementaciones, la detección de repetición funciona a partir de una tupla de cinco. Los valores, tales como los representados en la Tabla 1 anterior, pueden proporcionarse al servidor 102. Alternativamente, el servidor 102 puede seleccionar valores aleatoriamente. De acuerdo con la repetición, se determina inicialmente un rango aceptable de valores y la entropía. Si no se especifican valores de la tupla de cinco durante la etapa Génesis, el algoritmo puede usar los siguientes valores.
Tabla 2
Figure imgf000017_0001
De acuerdo con una implementación de ejemplo, se ejecuta un algoritmo que gira hacia atrás. Si un mes respectivo es menor o igual que el mes actual, entonces el año puede ser igual. Alternativamente, si el mes es mayor que el mes actual, entonces el año debe retroceder. Estos dos casos ilustran el algoritmo.
Tabla 3
Figure imgf000017_0002
Dado que el mes actual del Ejemplo 1 es 8 (agosto) y el valor de Génesis para el mes es 11, y 11 > 8, entonces reducimos el año en un intervalo de 5 y el año se convierte en 2011. Los valores restantes son múltiplos del Génesis que son menores que el valor de la fecha real.
En relación con el segundo ejemplo que usa la misma fecha y hora actuales, el mes actual es 8 (agosto) y el valor de Génesis para el mes es 4 y 4 <= 8. El año se reduce a un intervalo de 5, lo que equivale a 2015. Por lo tanto, el año se convierte en 2015 y los valores restantes son múltiplos del Génesis que son menores que el valor de la fecha real.
En una o más implementaciones de BOPS, pueden proporcionarse varios niveles de privacidad de datos y cada uno puede incluir información biométrica cifrada para evitar que alguien reinicie y/o comprometa la información biométrica. Un nivel de privacidad puede definir que todos los datos no biométricos se almacenen (pasiven) en texto sin formato. Esto simplifica los informes y el análisis de los patrones de uso y los registros de autenticación, y puede incluir otros factores, tales como el no repudio, la ubicación, la fecha y la búsqueda por facetas. Por ejemplo, con relativa facilidad se pueden ver varios intentos de autenticación fallidos en Cleveland durante junio de 2016, y puede proporcionarse información relacionada con personas y dispositivos. Este primer nivel de privacidad puede lograrse en función de herramientas sofisticadas que operan con datos pasivados de texto sin formato. Otro nivel de privacidad más alto puede definir que todos los datos no biométricos se almacenen en formato cifrado, pero no requieren una clave de descifrado separada por cliente. Por tanto, los dispositivos cliente 104 pueden configurarse para usar la misma clave de descifrado, que se considera más seguro que el primer nivel de privacidad descrito anteriormente en el sentido de que una persona con información privilegiada puede no tener acceso, o lo más probable es que no tenga, acceso a la clave de descifrado. Sin embargo, un mayor nivel de privacidad puede requerir que todos los datos no biométricos se almacenen en formato cifrado y que la clave de descifrado sea única para cada identidad. Esto proporciona una mayor privacidad y separación, ya que los datos de cada usuario se cifran con una clave asociada con un biométrico. En altos niveles de privacidad, se prevé en la presente descripción que los datos del usuario, que incluye, por ejemplo, información de identificación personal ("PII"), siempre se cifran en los dispositivos cliente 104, excepto quizás en el momento en que la coincidencia se produce en la memoria. En una o más implementaciones de BOPS, un usuario se autentica para autorizar la transacción y autenticarse para descifrar los datos del usuario (por ejemplo, credenciales de inicio de sesión, archivos o similares). Además, los datos en reposo (por ejemplo, datos pasivados) se cifran en el dispositivo informático servidor 102 y en el dispositivo cliente 104 en todo momento. Los datos de texto sin formato existen preferentemente solo en la memoria en el momento en que se produce un proceso de coincidencia.
En una o más implementaciones de BOPS, se proporcionan plataformas abiertas para permitir prácticamente cualquier personalización para el flujo de Génesis. Algunos ejemplos de Génesis pueden incluir un nombre de usuario y contraseña de acceso a DIRECTORIO ACTIVO, un correo electrónico o mensaje de texto de validación, o la identidad de una persona puede verificarse físicamente, tal como una función de una licencia de conducir, un certificado de nacimiento, un pasaporte, un número de seguro social u otra credencial adecuada.
El registro previo de la cuenta de usuario puede ocurrir en un proceso por lotes que implementa reglas comerciales, y las políticas y procedimientos de la organización pueden contribuir a esas reglas comerciales. Las reglas comerciales pueden integrarse con una plataforma de gestión de acceso, que organiza a los usuarios en grupos o directorios determinando el nivel de privilegios y otros atributos que se adaptarían a algunas necesidades particulares en la administración de roles. Esto proporciona flexibilidad para permitir a los desarrolladores construir formulaciones de perfiles de miembros (por ejemplo, un perfil de usuario, perfil de administrador, perfil de gerente y un perfil de superadministrador), que pueden aplicarse como entrada de una definición de miembro a la que accede un servidor BOPS 102. El proceso Génesis de acuerdo con la presente solicitud puede formar una dependencia total de la gestión de riesgos y, en consecuencia, determinar el procesamiento aguas abajo.
La Figura 19A representa dispositivos y etapas 1900 asociadas con múltiples usuarios que inician la inscripción en un único dispositivo cliente 104. La relación entre el usuario y el dispositivo 104 puede ser de "muchos a muchos" (M:M). Se pueden agregar las primeras etapas de inscripción (A1, Iniciar inscripción biométrica, Solicitar inscripción A2 (x, 509), Devolver Requisitos de inscripción A3, Solicitar registro de cuenta A4 (ID de desarrollador, ID de usuario 1^IBV), Devolver Registro A5). Estas etapas pueden repetirse para un segundo usuario (B1-B5). La relación de muchos a muchos puede ocurrir como una función de la separación de Génesis y la Inscripción. Además, el sujeto identificado a través de Génesis puede inscribirse muchas veces con muchos datos biométricos. Para iniciar la comunicación cliente/servidor, los usuarios capturan sus datos biométricos en el dispositivo cliente, lo que lleva a un proceso de inscripción de un certificado de cliente único emitido para el dispositivo cliente. Una vez que se realiza la parte de seguridad de la Inscripción, se realiza el registro de la información biométrica del usuario, lo que concluye el proceso de Inscripción. Un usuario puede tener muchos dispositivos (clientes), un dispositivo (cliente) puede tener muchos usuarios. Un dispositivo (cliente) puede admitir muchos datos biométricos.
La Figura 19B ilustra dispositivos y etapas 1910 en conexión con un usuario de ejemplo, Alice, iniciando una sesión de autenticación desde un dispositivo cliente 104, que almacena información relativa a múltiples cuentas de usuario. En el ejemplo mostrado en la Figura 19B, Alice inicia la sesión de autenticación (1) y la aplicación que opera en el dispositivo cliente 104 solicita autenticación biométrica (2). Una vez completada la autenticación biométrica (3), la aplicación que opera en el dispositivo cliente 104 configura el dispositivo 104 para enviar los atributos de identidad de Alice a través de TLS (4). A continuación, el servidor BOPS 102 procesa la solicitud de autenticación considerando la integridad de todos los elementos de inscripción y devuelve los resultados (5).
Con referencia al ejemplo que se muestra en la Figura 19B, incluso en el caso de que Alice inicie por error la sesión de autenticación usando la cuenta de Bob, el dispositivo cliente 104 no presenta ninguna solicitud al servidor porque CBV sería diferente del IBV que se creó durante la inscripción. y la autenticación no se realizará correctamente.
La Figura 19C ilustra dispositivos de ejemplo y etapas 1920 asociadas con la revocación de la cuenta de un usuario. En el ejemplo que se muestra en la Figura 19C, se muestra la información asociada con tres usuarios (Eve, Bob y Alice). Un usuario puede definir una o más reglas de revocación, por ejemplo, a través de una consola de administración configurada con una interfaz de usuario gráfica administrativa. Los roles asociados con un administrador (que puede ser autenticado biométricamente de manera similar) pueden ser responsables de implementar las reglas. En el ejemplo que se muestra en la Figura 19C, la cuenta de Alice tiene un certificado activo, la cuenta de Bob tiene un certificado caducado que se bloquea en el nivel de seguridad del transporte y la cuenta de Eve se ha revocado mediante el administrador de BOPS. Más particularmente, después de que el certificado de Eve se haya revocado a través del servidor BOPS 102 (1), se recibe una solicitud de autenticación desde un dispositivo cliente 104 asociado con la cuenta de Eve (2). El servidor BOPS 102 devuelve un mensaje u otro contenido adecuado que representa que el acceso de Eve está bloqueado (3). Con respecto al certificado de Bob, se define un período de 90 días, después del cual caduca el certificado de Bob ("TTL") (4). A continuación, se recibe una solicitud de autenticación desde el dispositivo cliente 104 asociado con la cuenta de Bob (5) y, de forma similar al caso de Eve, el servidor BOPS 102 transmite un mensaje u otro contenido adecuado que representa que el acceso de Bob está bloqueado al dispositivo cliente 104 (6). Con respecto a la cuenta de Alice, se proporciona un período de extensión de período adicional de 90 días (7), y se recibe una solicitud de autenticación desde el dispositivo cliente 104 asociado con la cuenta de Alice (8). El servidor BOPS 102 devuelve un mensaje u otro contenido adecuado que represente los resultados de la autenticación, tal como se muestra y describe en la presente descripción, que Alice está autenticada (9).
Uno de los problemas que se resuelve en relación con los módulos que se muestran y describen en la presente descripción es la prevención de ataques de repetición. En una o más implementaciones, para la detección de DDoS, cada testigo, que normalmente es un identificador que vincula el perfil en el servidor a una identidad en el campo Nombre Común (CN), es distinto. Un algoritmo entre un cliente 104 y un servidor 102 tiene en cuenta que los tiempos pueden variar y que los valores deben diferir de cliente 104 a cliente 104, así como también de acceso a acceso.
En una o más implementaciones, la distribución de certificados funciona de la siguiente manera. Un certificado X.509 se carga previamente en un dispositivo cliente 104, incluso como una función del software de aplicación instalado en el dispositivo cliente 104. Antes del proceso de Génesis, el cliente 104 establece un valor de 5-tupla especificando cualquiera o todas las tuplas (como se muestra y describe en la presente descripción). Durante el proceso de inscripción, el cliente 104 emite una llamada RESTful para solicitar el testigo del servidor BOPS 102. Cuando se recibe el testigo, se incorpora en el mensaje cifrado del cliente al servidor. El servidor recibe el testigo y verifica la validez del mensaje asegurándose de que la diferencia entre la hora de creación y la hora actual se encuentre dentro de un período de tiempo especificado de 60 segundos. El servidor 102 determina cuál de los valores de la 5-tupla falta y devuelve el testigo al cliente en un formato RESTful. El cliente 104 y el servidor 102 comparten el mismo valor de 5-tupla, que luego se usa para calcular una marca de tiempo que, a su vez, se codifica en SHA512 y se compara mediante el IDS, por ejemplo, como análisis de funciones. Por ejemplo, y como se describe en la presente descripción, la marca de tiempo calculada se mueve hacia atrás a una hora basada en la 5-tupla y es única para cada llamada.
La presente solicitud puede configurar un período de tiempo para que un certificado de cliente siga siendo válido (Time-to-Live o TTL). Los certificados revocados de usuarios autenticados pueden reemplazarse silenciosamente por nuevos certificados. Por lo tanto, TTL es un enfoque de "cinturón y tirantes", que funciona en conjunto con IBV y CBV para respaldar la autenticación de usuarios. La revocación de testigos también puede condicionarse a un rol de usuario y otros factores para satisfacer las necesidades comerciales particulares de autorización. Por ejemplo, un certificado puede bloquearse después de 1 o x número de intentos de autenticación fallidos para una transacción financiera, tal como en caso de que no se cumplan las condiciones y y/o z.
La Figura 20A es un diagrama simplificado que muestra las etapas 2000 asociadas con la inicialización, verificación y confirmación de un certificado de cliente entre un dispositivo cliente 104 y un servidor BOPS 102. Las etapas asociadas con el procesamiento de una solicitud de firma del cliente ("CSR") pueden incluir generar un par de claves pública-privada en el dispositivo cliente 104, firmar una clave pública y un nombre de sujeto (denominado en la presente descripción, generalmente como realizar una "Prueba de posesión") que se transmite al servidor BOPS 102. Como se indica en la presente descripción, el cliente envía una solicitud de registro de cuenta mediante el uso de SSL bidireccional. Después de verificar el nombre de sujeto del certificado, firmar la solicitud del cliente con la clave privada de la autoridad de certificación (CA) de BOPS y generar la contraseña del certificado del cliente con el mecanismo OTP, el servidor BOPS 102 devuelve una contraseña del certificado del cliente al dispositivo cliente 104. El cliente registrado verifica la firma del certificado y crea un contenedor.p12 para almacenar la clave privada del cliente y el certificado firmado, pero no la contraseña. Preferentemente, las contraseñas nunca se almacenan en los dispositivos cliente, porque el mecanismo OTP genera una contraseña de un solo uso para cada solicitud del cliente.
La Figura 20B ilustra un proceso de registro de certificado de cliente 2010 en el servidor de terceros y el ejemplo de integración de BOPS. El proceso de CSR, por ejemplo, como se muestra en la Figura 20A, se muestra de manera amplia y comienza con la inscripción del usuario. En el ejemplo mostrado en la Figura 20B, "registrar cuenta de usuario" se usa para describir las etapas asociadas con Génesis e Inscripción, y un certificado de cliente representa un atributo de identidad, mientras que una cuenta representa un Componente de Identidad.
En la implementación de ejemplo mostrada en la Figura 20B, después de que un usuario inicia el proceso de inscripción y envía su información biométrica con la solicitud de registro de cuenta a un servidor BOPS 102, se activa una generación de pares de claves/CSR en el cliente 104. Una vez que se recibe una solicitud de perfil de registro, el servidor BOPS 102 la envía a un Adaptador de Gestión de Acceso (que puede ser una solución/plataforma de gestión de acceso utilizada por una empresa de terceros), como se muestra en la Figura 20B que representa la validación del perfil, y luego además a un servidor de terceros para la verificación y validación de inicio de sesión de la cuenta. El servidor de terceros proporciona un testigo de autenticación después de validar los datos de inicio de sesión, luego envía los resultados de verificación al Adaptador de Gestión de Acceso, que devuelve los resultados de autenticación y el testigo de autenticación al servidor BOPS 102 para completar el registro de cuenta/perfil. El servidor BOPS 102 cifra el testigo de autenticación, almacena datos biométricos, firma CSR con BOPS CA, envía el testigo de autenticación cifrado a la aplicación cliente. Esto representa una implementación de ejemplo e integrada con una empresa (por ejemplo, un banco) que ya tiene miles de millones de cuentas acumuladas en su repositorio, para un mayor grado de verificación en función de una autenticación biométrica.
En una o más implementaciones, puede usarse un código de respuesta rápida (código QR) para activar la ejecución de uno o más módulos que se muestran y describen en la presente descripción. Por ejemplo, la página de inicio de sesión de un socio comercial (por ejemplo, un banco) puede configurarse para mostrar una imagen de código QR que contiene un identificador de oportunidad de sesión respectivo. Un MCA que se ejecuta en un dispositivo informático cliente 104 puede ejecutar uno o módulos (por ejemplo, un asistente de autenticación) para escanear el código QR, registrar la sesión para indicar que está adjunta a la sesión y autenticarse con los datos biométricos del usuario de acuerdo con la enseñanzas en la presente descripción. La Figura 21 ilustra un ejemplo de flujo de autenticación de código QR 2100, en el que un servidor de terceros registra una oportunidad de sesión con un servidor BOPS 102 y, en respuesta, el servidor BOPS 102 puede proporcionar información usable para una nueva sesión de autenticación al servidor de terceros y la información puede proporcionarse (por ejemplo, mostrarse) dentro de un código QR. El servidor de terceros puede transmitir una o más solicitudes de información de estado de sesión. Un usuario (designado un "actor") en la Figura 21 escanea el código QR y registra una sesión con el servidor BOPS 102, que puede notificar a un servidor de terceros externo. Tras la autenticación biométrica, tal como se muestra y describe en la presente descripción, una sesión de usuario puede establecerse, que incluye el servidor de terceros.
El asunto descrito anteriormente se proporciona solo a modo de ilustración, y no debe ser interpretado como limitativo. Se pueden realizar diferentes modificaciones y cambios al asunto descrito en la presente descripción, sin seguir las modalidades de ejemplo y las aplicaciones ilustradas y descritas, y sin apartarse del alcance de la presente invención, como se establece en cada una de las reivindicaciones siguientes.

Claims (1)

  1. REIVINDICACIONES
    Un método para proporcionar una comunicación segura entre un dispositivo informático de usuario (104) y un dispositivo informático servidor (102), el método que comprende:
    procesar, mediante el dispositivo informático servidor, una solicitud de inscripción que se recibe desde un dispositivo informático de usuario configurado con una aplicación de software cliente distribuida, la solicitud de inscripción que incluye una porción cifrada de un vector biométrico inicial asociado con un usuario del dispositivo informático de usuario, en donde el procesamiento de la solicitud de inscripción, que incluye la porción cifrada del vector biométrico inicial, incluye:
    registrar el dispositivo informático de usuario con el dispositivo informático servidor; y almacenar la porción cifrada del vector biométrico inicial en un medio legible por procesador no transitorio que sea accesible por o sea parte del dispositivo informático servidor;
    en donde registrar el dispositivo informático de usuario con el dispositivo informático servidor incluye: generar un par de claves pública-privada en el dispositivo informático de usuario, firmar una clave pública y el nombre de sujeto de un certificado,
    recibir, mediante el dispositivo informático servidor, una solicitud de firma de certificado de registro que comprende la clave pública firmada y el nombre de sujeto del certificado desde el dispositivo informático de usuario a través de una capa de conexiones seguras bidireccional;
    firmar, mediante el dispositivo informático servidor, la solicitud con una clave privada de la Autoridad de Certificación, después de verificar el nombre de sujeto del certificado;
    generar, mediante el dispositivo informático servidor, una contraseña de certificado de cliente para la solicitud firmada; y
    transmitir, mediante el dispositivo informático servidor al dispositivo informático de usuario, la contraseña del certificado de cliente;
    procesar, por el dispositivo informático servidor, una solicitud de autenticación que se recibe posteriormente desde el dispositivo informático de usuario e incluye el certificado y una porción cifrada de un segundo vector biométrico y que se asocia con un usuario del dispositivo informático de usuario, en donde el procesamiento de la solicitud de autenticación incluye:
    determinar que el certificado está vigente y no está revocado;
    realizar una comparación de la porción cifrada del vector biométrico inicial y la porción cifrada del segundo vector biométrico; y
    generar un valor que representa la comparación; y
    transmitir, mediante el dispositivo informático servidor al dispositivo informático de usuario, el valor que representa la comparación, en donde el dispositivo informático de usuario se autentica cuando el valor que representa la comparación está por encima de un umbral mínimo y el dispositivo informático de usuario no se autentica cuando el valor que representa la comparación está por debajo de un umbral mínimo.
    El método de la reivindicación 1, en donde la porción cifrada del vector biométrico inicial comprende una primera porción de un primer vector biométrico asociado con un usuario del dispositivo informático de usuario, en donde la solicitud de autenticación incluye además una segunda porción del primer vector biométrico, y en donde procesar la solicitud de autenticación incluye además:
    combinar al menos la primera y la segunda porciones del primer vector biométrico;
    realizar una comparación de la primera y la segunda porciones combinadas con el segundo vector biométrico; y
    generar un valor que representa la comparación; y
    transmitir, mediante el dispositivo informático servidor al dispositivo informático de usuario, el valor que representa la comparación, en donde el dispositivo informático de usuario se autentica cuando el valor está por encima de un umbral mínimo y el dispositivo informático de usuario no se autentica cuando el valor está por debajo de un umbral mínimo.
    El método de acuerdo con la reivindicación 1 o 2, que comprende además proporcionar, mediante el dispositivo informático servidor al dispositivo informático de usuario, el certificado que se incluye en la solicitud de inscripción y la solicitud de autenticación, en donde el procesamiento de la solicitud de autenticación incluye determinar que el certificado está vigente y no revocado.
    4. El método de acuerdo con una cualquiera de las reivindicaciones 1 a 3, que comprende además el empleo de un sistema de detección de intrusos para la supervisión activa y la prevención de la suplantación del certificado.
    5. El método de acuerdo con la reivindicación 4, en donde la suplantación que se evita incluye la repetición del certificado.
    6. El método de acuerdo con la reivindicación 1 o 2, en donde procesar la solicitud de autenticación incluye además:
    realizar al menos una operación de coincidencia en el espacio cifrado en función del cifrado unidireccional. 7. El método de acuerdo con la reivindicación 6, en donde el cifrado unidireccional se realiza mediante el uso de una almohadilla aleatoria de un solo uso.
    8. El método de acuerdo con la reivindicación 1 o 2, que comprende además:
    proporcionar, mediante el dispositivo informático servidor, la recopilación de roles que se define por una o más reglas para el acceso a un activo digital; y
    proporcionar o denegar, mediante el dispositivo informático servidor, el acceso al activo digital por parte del dispositivo informático de usuario en función de la recopilación de roles.
    9. El método de acuerdo con la reivindicación 8, en donde el acceso se proporciona en función de al menos uno de control de acceso discrecional y control de acceso obligatorio.
    10. El método de acuerdo con la reivindicación 1 o 2, que comprende además:
    procesar, mediante el dispositivo informático servidor, una segunda solicitud de inscripción que se recibe desde el dispositivo informático de usuario configurado con una aplicación de software cliente distribuida, la segunda solicitud de inscripción que puede usarse para inscribir a un segundo usuario del dispositivo informático de usuario en la red y la segunda solicitud de inscripción que incluye una segunda porción cifrada del vector biométrico inicial asociado con un usuario del dispositivo informático de usuario, en donde el procesamiento de la segunda solicitud de inscripción incluye almacenar la segunda porción cifrada del vector biométrico inicial en un medio legible por procesador no transitorio que sea accesible por o sea parte del dispositivo informático servidor.
    11. El método de acuerdo con la reivindicación 10, que comprende además:
    revocar, mediante el dispositivo informático servidor, la inscripción del primer usuario asociado con el dispositivo informático de usuario.
    12. El método de acuerdo con la reivindicación 1, en donde la contraseña se genera mediante el uso de un mecanismo de contraseña de un solo uso.
    13. El método de acuerdo con la reivindicación 1, en donde la solicitud se genera en el dispositivo informático de usuario al generar un par de claves pública-privada, firmando una clave pública y un nombre de sujeto.
    14. Un sistema para proporcionar una comunicación segura entre un dispositivo informático de usuario y un dispositivo informático servidor, el sistema que comprende: el dispositivo informático servidor que tiene al menos un procesador acoplado operativamente a uno o más medios legibles por procesadores no transitorios;
    en donde uno o más medios legibles por procesador incluyen instrucciones para permitir que el dispositivo informático servidor lleve a cabo el método de acuerdo con cualquiera de las reivindicaciones 1-13.
ES16839947T 2015-08-21 2016-08-22 Sistema y método para estándares de protocolos biométricos Active ES2881824T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562208328P 2015-08-21 2015-08-21
US201562241392P 2015-10-14 2015-10-14
PCT/US2016/048068 WO2017035085A1 (en) 2015-08-21 2016-08-22 System and method for biometric protocol standards

Publications (1)

Publication Number Publication Date
ES2881824T3 true ES2881824T3 (es) 2021-11-30

Family

ID=58100854

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16839947T Active ES2881824T3 (es) 2015-08-21 2016-08-22 Sistema y método para estándares de protocolos biométricos

Country Status (11)

Country Link
EP (1) EP3338157B1 (es)
JP (1) JP6906521B2 (es)
KR (1) KR102549337B1 (es)
CN (1) CN108475309B (es)
AU (1) AU2016311166B2 (es)
BR (1) BR112018003390A2 (es)
CA (1) CA2996296C (es)
ES (1) ES2881824T3 (es)
MX (1) MX389744B (es)
PL (1) PL3338157T3 (es)
WO (1) WO2017035085A1 (es)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11329980B2 (en) 2015-08-21 2022-05-10 Veridium Ip Limited System and method for biometric protocol standards
CN109684806A (zh) * 2018-08-31 2019-04-26 深圳壹账通智能科技有限公司 基于生理特征信息的身份验证方法、装置、系统和介质
CN112100645A (zh) * 2019-06-18 2020-12-18 中国移动通信集团浙江有限公司 数据处理方法及装置
CN114175079A (zh) * 2019-07-23 2022-03-11 维尔蒂姆知识产权有限公司 用于生物识别协议标准的系统和方法
CN110830449B (zh) * 2019-10-17 2020-11-13 北京三快在线科技有限公司 文件处理方法、装置、电子设备及可读存储介质
CN111062456A (zh) * 2019-12-25 2020-04-24 李蕴光 一种二维码加密算法
NL2025515B1 (en) 2020-05-06 2021-11-23 Microsoft Technology Licensing Llc Access authentication using obfuscated biometrics
US11468587B2 (en) 2020-05-12 2022-10-11 Samsung Electronics Co., Ltd. System and method for depth map recovery
US12425396B2 (en) 2020-06-10 2025-09-23 Beijing Xiaomi Mobile Software Co., Ltd. Biometric feature verification method and apparatus, electronic device, and storage medium
CN115278673B (zh) * 2022-08-08 2024-07-23 西安电子科技大学 基于联合生物识别的轻量级生物认证方法及系统

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020062451A1 (en) * 1998-09-01 2002-05-23 Scheidt Edward M. System and method of providing communication security
WO2001011843A1 (en) * 1999-08-06 2001-02-15 Sudia Frank W Blocked tree authorization and status systems
US6735695B1 (en) * 1999-12-20 2004-05-11 International Business Machines Corporation Methods and apparatus for restricting access of a user using random partial biometrics
US20020174347A1 (en) * 2001-05-18 2002-11-21 Imprivata, Inc. Authentication with variable biometric templates
CZ2005209A3 (cs) * 2002-09-10 2005-12-14 Ivi Smart Technologies, Inc. Bezpečné biometrické ověření identity
JP2005122478A (ja) * 2003-10-16 2005-05-12 Mitsubishi Electric Corp 指紋照合装置
EP1815637B1 (en) * 2004-11-16 2016-04-20 Koninklijke Philips N.V. Securely computing a similarity measure
DE502005002248D1 (de) * 2005-10-20 2008-01-24 Ubs Ag Vorrichtungen und Verfahren zum Durchführen von kryptographischen Operationen in einem Server-Client-Rechnernetzwerksystem
US20070240230A1 (en) * 2006-04-10 2007-10-11 O'connell Brian M User-browser interaction analysis authentication system
CN100542092C (zh) * 2006-09-21 2009-09-16 上海交通大学 分布式多级安全访问控制方法
JP5121681B2 (ja) * 2008-04-30 2013-01-16 株式会社日立製作所 生体認証システム、認証クライアント端末、及び生体認証方法
US20100097178A1 (en) * 2008-10-17 2010-04-22 Pisz James T Vehicle biometric systems and methods
CA2825391A1 (en) * 2011-01-27 2012-08-02 Rick L. Orsini Systems and methods for securing data
JP5673220B2 (ja) * 2011-03-03 2015-02-18 日本電気株式会社 セキュリティ管理システム、セキュリティ管理方法、及びプログラム
CN102457527A (zh) * 2011-12-30 2012-05-16 中国联合网络通信集团有限公司 基于生物密钥的单点登录方法、装置和系统
US9286455B2 (en) * 2012-10-04 2016-03-15 Msi Security, Ltd. Real identity authentication
JP6318588B2 (ja) * 2013-12-04 2018-05-09 富士通株式会社 生体認証装置、生体認証方法及び生体認証用コンピュータプログラム
EP3090525B1 (en) * 2013-12-31 2021-06-16 Veridium IP Limited System and method for biometric protocol standards
CN104765998A (zh) * 2015-04-16 2015-07-08 国家电网公司 一种基于人脸识别用户身份可靠认证系统及其使用方法

Also Published As

Publication number Publication date
WO2017035085A9 (en) 2017-08-17
EP3338157B1 (en) 2021-05-19
HK1255649A1 (en) 2019-08-23
CN108475309B (zh) 2023-02-03
AU2016311166B2 (en) 2022-03-03
KR20180080183A (ko) 2018-07-11
PL3338157T3 (pl) 2021-11-02
MX389744B (es) 2025-03-20
JP2018529299A (ja) 2018-10-04
KR102549337B1 (ko) 2023-06-28
CA2996296C (en) 2023-04-18
MX2018002190A (es) 2018-07-03
JP6906521B2 (ja) 2021-07-21
AU2016311166A1 (en) 2018-04-12
CN108475309A (zh) 2018-08-31
WO2017035085A1 (en) 2017-03-02
EP3338157A1 (en) 2018-06-27
CA2996296A1 (en) 2017-03-02
BR112018003390A2 (pt) 2018-09-25
EP3338157A4 (en) 2019-04-03

Similar Documents

Publication Publication Date Title
US11329980B2 (en) System and method for biometric protocol standards
US10536454B2 (en) System and method for biometric protocol standards
ES2881824T3 (es) Sistema y método para estándares de protocolos biométricos
US11297064B2 (en) Blockchain authentication via hard/soft token verification
AU2020316421B2 (en) System and method for biometric protocol standards
US9219730B2 (en) Securing a secret of a user
US20180183586A1 (en) Assigning user identity awareness to a cryptographic key
US20240121098A1 (en) Scalable Authentication System with Synthesized Signed Challenge
HK1255649B (en) System and method for biometric protocol standards
WO2025122333A1 (en) Scalable authentication system with synthesized signed challenge