ES2264203T3 - Sistema generalizado de identificacion y autenticacion de usuario. - Google Patents
Sistema generalizado de identificacion y autenticacion de usuario.Info
- Publication number
- ES2264203T3 ES2264203T3 ES98922218T ES98922218T ES2264203T3 ES 2264203 T3 ES2264203 T3 ES 2264203T3 ES 98922218 T ES98922218 T ES 98922218T ES 98922218 T ES98922218 T ES 98922218T ES 2264203 T3 ES2264203 T3 ES 2264203T3
- Authority
- ES
- Spain
- Prior art keywords
- authentication
- user
- stages
- demonstrator
- secure application
- 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.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/82—Protecting input, output or interconnection devices
- G06F21/83—Protecting input, output or interconnection devices input devices, e.g. keyboards, mice or controllers thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/36—User authentication by graphic or iconic representation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2107—File encryption
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Storage Device Security (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Radar Systems Or Details Thereof (AREA)
- Eye Examination Apparatus (AREA)
Abstract
Un procedimiento destinado a proporcionar a un usuario acceso a una aplicación segura, que comprende las etapas de: a) proporcionar una petición de autenticación al usuario para acceder a la aplicación segura, comprendiendo la petición de autenticación visualizar ante el usuario al menos un símbolo; b) recibir manipulaciones por el usuario de al menos una parte del símbolo visualizado; c) generar una clave de código sobre la base de la manipulación por el usuario de al menos una parte del símbolo visualizado; d) usar la clave de código en relación con información de autenticación almacenada necesaria para cumplir las exigencias de autenticación de la aplicación segura, para producir un resultado; e) proporcionar el resultado a la aplicación segura; y f) otorgar al usuario acceso a la aplicación segura si el resultado soporta las exigencias de autenticación de la aplicación segura.
Description
Sistema generalizado de identificación y
autenticación de usuario.
La invención se refiere en general a
procedimientos de comprobación de la identidad de un usuario de una
aplicación segura. Más particularmente, la invención se refiere a
un procedimiento de comprobación de la identidad de un usuario que
accede a una o más aplicaciones o sistemas seguros, tales como un
ordenador, servicio en línea, mecanismo de transacción automatizado
y similares.
Existen muchos sistemas electrónicos en uso que
requieren que un usuario se identifique a sí mismo antes de
otorgarle acceso al sistema. Estos sistemas incluyen redes de
ordenadores, cajeros automáticos (ATM), bases de datos
automatizadas tales como LEXIS™, sistemas bancarios, sistemas de
correo electrónico, proveedores en línea tales como America
On-Line (AOL)™, sistemas de comercio de valores,
instituciones educativas, cuentas de la nómina de haberes y una
gran variedad de aplicaciones suplementarias. Para garantizar que la
información de estos sistemas esté protegida de la manipulación,
destrucción o uso indebido, la mayoría de estos sistemas emplean
algún tipo de seguridad. La seguridad es especialmente importante
cuando la información se hace fácilmente disponible para una
extensa comunidad de potenciales usuarios en multitud de ubicaciones
en las redes.
La seguridad de los sistemas puede incluir
típicamente mecanismos físicos, de procedimiento y técnicos. Sin
embargo, la mayoría de los sistemas dependen de uno o más de tres
procedimientos básicos de identificación y autenticación, cada uno
de los cuales requiere algo del Demostrante (los términos
"Demostrante" y "usuario" se usan en forma intercambiable
durante toda la memoria descriptiva):
- Algo que el Demostrante conoce (por ejemplo, nombre y contraseña);
- algo que el Demostrante tiene (por ejemplo, tarjeta de identidad); o
- algo que el Demostrante es (por ejemplo, huella dactilar).
Los sistemas de seguridad dependen
corrientemente de algo que el Demostrante conoce incluso al aplicar
algo que el Demostrante tiene. El enfoque más ampliamente aplicado
a "algo conocido" es el uso de nombre y contraseña en sistemas
de ordenadores. Incluso recientes mejoras de seguridad (por ejemplo
tarjetas inteligentes, cortafuegos, firmas digitales) dependen de
contraseñas e identificadores de usuario tradicionales para
identificar y autenticar usuarios al otorgar acceso.
La mayoría de las metodologías de autenticación
dependen de la presencia de un conjunto completo de información de
autenticación en cada estadio del proceso (por ejemplo nombre y
contraseña). El proceso típico es que el usuario conoce el conjunto
completo de información de autenticación y entra el conjunto
completo en un ordenador o terminal. El conjunto completo se
transmite a una aplicación segura y en ella se compara a un conjunto
de información de autenticación almacenada. En cada estadio del
proceso, el conjunto completo de datos de autenticación necesario
está expuesto a la interceptación y a un posible uso no autorizado.
Esto es especialmente cierto en el caso de entornos de ordenadores
conectados en red.
A fin de garantizar una buena seguridad, las
contraseñas deben ser difíciles de adivinar o desencriptar. Así, se
aconseja a los usuarios evitar contraseñas "débiles" tales como
nombres (por ejemplo el de su cónyuge, animal de compañía);
informaciones que se obtienen fácilmente (por ejemplo, número de
teléfono, cumpleaños); palabras del diccionario; la misma
contraseña para múltiples sistemas, etc. A fin de reducir la amenaza
de acceso no autorizado, los expertos en seguridad informática
suelen recomendar que una contraseña de usuario contenga solamente
letras y números mezclados en cadenas aparentemente aleatorias (por
ejemplo 87SFs81R9) y cambiarla con frecuencia. El acceso no
autorizado no detectado podría producirse fácilmente cuando se
descubre, intercepta o adivina una contraseña.
Tal enfoque plantea un doble problema. En primer
lugar, a causa de que los usuarios humanos típicamente encuentran
más fácil recordar contraseñas que tienen un contexto para el
usuario (por ejemplo una palabra o fecha), las contraseñas que
eligen típicamente no son difíciles de adivinar. Un estudio del
intervalo de contraseñas elegidas por operadores de ordenador halló
que un tercio de todas las contraseñas de usuario podrían
encontrarse en el diccionario. Tales contraseñas son vulnerables al
soporte lógico disponible corrientemente que puede probar cada
palabra del diccionario como contraseña.
En segundo lugar, el problema de la
"sobrecarga de contraseñas" está dando como resultado muchas
violaciones de técnicas de seguridad cuidadosamente planificadas.
Un número en aumento de aplicaciones requieren que los usuarios
sigan un proceso de autenticación que incluye típicamente presentar
alguna forma de un nombre y contraseña para conseguir el acceso. Si
los usuarios cumplen las normas de seguridad, deben memorizar una
cadena aparentemente aleatoria de letras y números para cada
aplicación. Además, la mayoría de las aplicaciones seguras tienen
sus propias interfaces y pueden requerir algo único del usuario.
Algunas revisan las contraseñas de usuarios y restringen el tipo de
contraseña que puede usar el usuario y el tiempo durante el que
puede ser válida la contraseña. Sin embargo, la gran mayoría de las
aplicaciones no hacen nada para simplificar el proceso a los
usuarios y, en lugar de eso, lo hacen más complejo.
Por último, la dificultad de recordar una
multitud de contraseñas para una multitud de aplicaciones promueve
los malos hábitos en los usuarios. Los usuarios seleccionan
contraseñas débiles, las comparten y mantienen listas de
contraseñas vulnerables, a menudo pegando directamente contraseñas
sobre sus ordenadores. De hecho, los propios usuarios son el
eslabón más débil en las aplicaciones y los sistemas más seguros,
haciendo vulnerables los sistemas a fáciles violaciones de
seguridad y accesos no autorizados.
Así, existe la necesidad de un tipo de sistema
de autenticación de contraseñas que pueda cumplir los dos objetivos
aparentemente contradictorios de ser fácil de recordar para el
usuario y difícil de averiguar para cualquier otra persona.
Una solución de la técnica anterior para
resolver este problema es la técnica conocida como "entrada única
al sistema" o "apertura única de sesión", tipificada por el
documento US-A-5.241.594. En esta
técnica, un usuario entra en su ordenador de usuario sólo una vez,
usando un identificador de usuario y una contraseña convencionales.
Cuando el usuario necesita acceder a un ordenador o aplicación
remota, el identificador y la contraseña que acaba de introducir el
usuario se cifran y se transmiten al ordenador remoto, usando un
protocolo de nivel de transporte seguro entre el ordenador del
usuario y el ordenador remoto. El protocolo de nivel de transporte
seguro se establece bien usando un soporte lógico especial en el
ordenador del usuario, o bien usando un servidor distinto. La
contraseña cifrada se compara entonces con una base de datos de
contraseñas cifradas almacenadas en una ubicación central,
típicamente sobre el servidor o el ordenador remoto. Asimismo,
todos los sistemas a los que el usuario quiere acceder deben usar la
misma contraseña.
Sin embargo, la exigencia de que todo ordenador
o aplicación en el sistema (es decir, el ordenador de usuario y
todos los ordenadores remotos) tengan la misma contraseña implica
que esta técnica puede no funcionar para todos los sistemas. Este
procedimiento puede ser inútil para el uso con ordenadores o
aplicaciones remotos que tienen exigencias de autenticación
complicadas o atípicas. Así, muchas aplicaciones de apertura única
de sesión son compatibles con un número de aplicaciones limitado.
Además, la mayoría de las versiones que pueden adquirirse en el
mercado de sistemas de apertura única de sesión utilizan el
procedimiento de servidor distinto, lo que complica el proceso de
autenticación y añade gasto al mismo. Adicionalmente, muchos
sistemas que pueden adquirirse en el mercado requieren que todas
las aplicaciones conformes usen los mismos protocolos de seguridad,
interfaces de soporte físico, etc., limitando la aplicabilidad de
tales sistemas. Por consiguiente, existe la necesidad de un sistema
de autenticación simple, pero seguro, que no requiera soporte físico
suplementario y funcione con sistemas que tienen técnicas y
exigencias de autenticación variadas.
De acuerdo con la invención, se proporciona un
proceso para proporcionar a un usuario acceso a una aplicación
segura, que comprende las etapas de:
a) proporcionar una petición de autenticación
al usuario para acceder a la aplicación segura, comprendiendo la
petición de autenticación visualizar ante el usuario al menos un
símbolo;
b) recibir manipulaciones por el usuario de al
menos una parte del símbolo visualizado;
c) generar una clave de código sobre la base
de la manipulación por el usuario de al menos una parte del símbolo
visualizado;
d) usar la clave de código en relación con
información de autenticación almacenada necesaria para cumplir las
exigencias de autenticación de la aplicación segura, para producir
un resultado;
e) proporcionar el resultado a la aplicación
segura; y
f) otorgar al usuario acceso a la aplicación
segura si el resultado soporta las exigencias de autenticación de
la aplicación segura.
Las formas de realización de la invención
proporcionan a los usuarios un procedimiento de autenticación único,
sencillo que sustituye enfoques de nombre y contraseña
tradicionales y es compatible con exigencias de autenticación
variadas. Éstas posibilitan a los Verificadores ("Verificador"
y "aplicación segura" se usan en forma intercambiable durante
toda la memoria descriptiva) autenticar en forma segura a los
Demostrantes y posibilitan la autenticación de los Demostrantes por
múltiples Verificadores. Éstas aplican un proceso que requiere que
el Demostrante complete sólo un conjunto de rutinas o etapas del
Demostrante fáciles de recordar. Estas etapas del Demostrante dan
comienzo al proceso de autenticación apropiado para cada Verificador
sin más intervención o entrada por parte del Demostrante. Así, los
Demostrantes tienen un proceso simple, unificado para todas sus
exigencias de autenticación, dado que la invención maneja los
matices asociados a cada aplicación segura.
Desde un punto de vista, las formas de
realización de la invención se pone de relieve un procedimiento para
proporcionar a un usuario acceso a una aplicación segura. El
procedimiento incluye almacenar en forma cifrada la información de
autenticación necesaria para cumplir las exigencias de autenticación
de la aplicación segura. Únicamente con carácter de ejemplo, esta
información puede almacenarse en un ordenador de usuario. Cuando el
usuario solicita acceder a la aplicación segura, se presenta al
usuario en su unidad de visualización una petición de
autenticación. Sin embargo, a diferencia de los enfoques de nombre y
contraseña tradicionales, la petición de autenticación presentada
al usuario comprende al menos un símbolo. El usuario debe manipular
al menos una parte del símbolo para responder apropiadamente a la
petición de autenticación. Únicamente con carácter de ejemplo, la
invención podría visualizar al usuario una visualización de una
mesa, un plato y una pluralidad de elementos comestibles. El
usuario selecciona varios elementos comestibles (para hacer una
"comida") y los mueve hasta el plato. Estas manipulaciones,
que pueden ser o no sensibles al orden, son las únicas etapas que
necesita recordar el usuario. La "comida secreta" es fácil de
recordar para el usuario, pero difícil de adivinar para otro.
Además, la "comida secreta" es la misma independientemente de
la aplicación segura a la que se acceda.
Las formas de realización incluyen la etapa de
usar la o las manipulaciones del usuario del o de los símbolos para
generar una Clave de código. Esta Clave de código se usa para
descifrar en un resultado la información de autenticación cifrada
almacenada. Cada aplicación segura o sesión de entrada al sistema
puede exigir un resultado esperado diferente, pero sólo el usuario
conocerá sus etapas de Demostrante. El usuario nunca conoce (y de
hecho no necesita conocer) ninguno de los resultados esperados o el
modo de obtenerlos. Asimismo, la aplicación segura nunca conoce (y
no necesita conocer) las Etapas del Demostrante (es decir,
manipulación o serie de manipulaciones) o el modo de
obtenerlas.
Después de crearse el resultado, éste se
proporciona a la aplicación segura. Si el resultado soporta las
exigencias de autenticación de la aplicación segura (es decir, si
la Clave de código ha descifrado apropiadamente la información de
autenticación cifrada almacenada), se otorga al usuario acceso a la
aplicación segura.
La invención proporciona un procedimiento
sencillo, seguro y efectivo para que un usuario consiga acceso a
una multitud de aplicaciones seguras sin tener que recordar una
serie de complicadas contraseñas. A diferencia de los sistemas de
apertura única de sesión de la técnica anterior, la invención
elimina la entrada, transmisión o almacenamiento de un conjunto
estático, completo de datos de autenticación en cualquier estadio
del proceso de autenticación. La invención no requiere ningún
soporte físico suplementario y no requiere que todas las
aplicaciones seguras a las que se accede usen las mismas exigencias
de autenticación.
A continuación se describirá una forma de
realización de la invención con carácter de ejemplo y en referencia
a los dibujos que se adjuntan, que ilustran un procedimiento para
proporcionar a un usuario acceso a una aplicación segura, y en los
que:
La Fig. 1 es un diagrama de bloques que
ilustra que la invención soporta múltiples Verificadores para cada
Demostrante.
La Fig. 2 es un diagrama de bloques que
ilustra la secuencia entre una ejecución del Demostrante de Etapas
del Demostrante y la activación de los subprocesos apropiados
específicos del Verificador.
Las Figs. 3A-B ilustran
ejemplos de una serie de Etapas del Demostrante no sensible al orden
que podría usarse como una Prueba de identificación.
Las Figs. 4A-D ilustran un
ejemplo de una serie de Etapas del Demostrante, no sensible al
orden, que podría usarse como Prueba de identificación.
La Fig. 5 es un diagrama de flujo que
ilustra las etapas de aceptación de las Etapas del Demostrante que
un usuario ha seleccionado y de conversión en una Cadena.
La Fig. 6 es un diagrama de flujo que
ilustra las etapas para designar un Verificador y su información de
autenticación.
La Fig. 7 es un diagrama de flujo que
ilustra la secuencia de subprocesos implicados en el Proceso desde
la iniciación del Demostrante a la autenticación del
Verificador.
La Fig. 8 es un diagrama de flujo que
ilustra el arranque del Proceso y las etapas para la iniciación del
Proceso de Prueba de identificación subsiguiente.
La Fig. 9 es un diagrama de flujo que
ilustra la configuración de la Interfaz del Demostrante y la
preparación para aceptar respuestas del Demostrante a Pruebas de
identificación.
La Fig. 10 es un diagrama de flujo que
ilustra las etapas de presentación y tratamiento de Pruebas de
identificación del Demostrante.
La Fig. 11 es un diagrama de flujo que
ilustra las etapas que se producen al convertir Etapas del
Demostrante en una Clave de código.
La Fig. 12 es un diagrama de flujo que
ilustra las etapas que se producen automáticamente una vez que se
ha generado una Clave de código sobre la base de la entrada del
Demostrante.
La Fig. 13 es un diagrama de flujo que
ilustra el modo en que el Proceso de correlación selecciona y crea
un subproceso específico de la aplicación para completar la
autenticación.
La Fig. 14 es un diagrama de flujo que
ilustra el subproceso de correlación para aplicaciones que dependen
del nombre y la contraseña para la autenticación.
La Fig. 15 es un diagrama de flujo que
ilustra el subproceso de correlación para aplicaciones que dependen
de certificados y firmas digitales y claves públicas para la
autenticación.
La Fig. 16 es un diagrama de flujo que
ilustra el subproceso de correlación para aplicaciones que dependen
del conocimiento nulo para la autenticación.
La Fig. 17 es un diagrama de flujo que
ilustra el subproceso de correlación para aplicaciones que dependen
de procesos externos para la autenticación.
La Fig. 18 es un diagrama de flujo que
ilustra las etapas en la comunicación de los resultados del Proceso
de correlación al Verificador último.
La Fig. 19 es un diagrama de flujo que
ilustra el subproceso de comunicación para la autenticación
heredada.
La Fig. 20 es un diagrama de flujo que
ilustra el subproceso de comunicación para la autenticación
heredada.
La Fig. 21 es un diagrama de flujo que
ilustra las etapas finales en el Proceso para completar la
autenticación.
En la descripción detallada siguiente de una
forma de realización de la invención, se hace referencia a los
siguientes términos. Cuando se señale, ciertos de estos términos se
usan en forma intercambiable con ciertos otros durante toda la
memoria descriptiva.
Demostrante se define como un individuo que
trata de conseguir acceso a una aplicación segura o Verificador. Un
Demostrante también se denomina "usuario". Las Etapas del
Demostrante se definen como la secuencia personal de etapas
elegidas por un Demostrante. Las Etapas del Demostrante se basan en
uno o más símbolos visualizados ante el usuario y una secuencia de
movimientos o manipulaciones de estos símbolos, ejecutados por el
Demostrante. Un Símbolo se define como un objeto gráfico o visual,
pero conviene entender que podría usarse como símbolo a los efectos
de la invención cualquier cosa que pueda visualizarse visualmente y
que pueda seleccionarse, moverse o manipularse de cualquier modo.
Un Verificador se define como la aplicación, sistema, ordenador,
servidor, etc., al que un Demostrante intenta conseguir acceso.
Cualquier entidad que sea segura y requiera autenticación para que
un usuario consiga acceso a la misma puede ser un Verificador.
Verificador se usa en forma intercambiable con "aplicación
segura" durante toda la memoria descriptiva. Autenticación se
define como el proceso de validación de una identidad reclamada,
tal como la identidad de un Demostrante. Información de
autenticación se define como la información que un Demostrante debe
proporcionar a un Verificador para conseguir acceso. Información de
autenticación puede ser cualquier cosa desde uno o más nombres de
usuario y contraseñas hasta una multitud de rutinas complejas,
procedimientos e información. Una Prueba de identificación se
define como una visualización que requiere que el Demostrante entre
y complete las acciones que comprenden sus Etapas de Demostrante.
Una Prueba de identificación también se denomina "petición de
autenticación". Una Clave de código se define como una clave que
puede usarse para descifrar información de autenticación que se ha
cifrado.
La Fig. 1 es un diagrama de bloques que
proporciona una vista general del soporte de la invención para
múltiples Verificadores para cada Demostrante. Cuando un usuario
selecciona uno de los Verificadores de la Fig. 1, comienzan las
etapas mostradas en forma general en la Fig. 2 y más particularmente
en las Figs. 7-21.
La Fig. 2 es un diagrama de bloques que ilustra
en forma general la secuencia de etapas requeridas para que un
Demostrante consiga acceso a un Verificador. Cada uno de los
Verificadores 1 a N requiere un proceso distinto y único, ilustrado
en la Fig. 2 como subproceso_{1}, a subproceso_{N},
respectivamente, para que un Demostrante consiga acceso. Un
subproceso puede ser tan simple como proporcionar un nombre de
usuario y una contraseña, como es común con muchos sistemas en
línea. Sin embargo, un subproceso también puede comprender una serie
de contraseñas o códigos, u otras exigencias específicas de la
aplicación. Independientemente de la complejidad del subproceso
requerido para un Verificador particular, cuando un Demostrante
quiere acceder al Verificador, el Demostrante sólo necesita
ejecutar sus Etapas de Demostrante para dar comienzo al proceso
apropiado para un Verificador particular, como se muestra en la
Fig. 2.
Como acción preliminar, el Demostrante indica al
sistema que implementa la invención: (a) las Etapas del Demostrante
que el Demostrante usará para acceder a todas las aplicaciones
seguras (que corresponden a grandes rasgos a una "contraseña
simbólica" que debe recordar el usuario); y (b) el Verificador e
información de autenticación asociada (que corresponden a grandes
rasgos a la aplicación segura y su contraseña asociada).
Para designar Etapas del Demostrante, se
presenta ante un usuario una visualización de objetos o símbolos.
Las etapas del Demostrante se completan disponiendo, moviendo u
ordenando en secuencia los objetos o símbolos. Preferentemente, el
objeto o símbolos son familiares para el usuario. Por ejemplo, un
usuario que es químico puede elegir que se le presente una
visualización de la tabla periódica de los elementos. El químico
puede seleccionar entonces varios elementos, o reunir elementos
para crear una fórmula o molécula, o crear otra combinación que
sería fácil de recordar para el químico sin anotarla. La selección
puede ser o no sensible al orden.
Otras posibilidades podrían ser elementos de
comida para un chef de cocina, valores para un analista financiero,
una baraja para un jugador de cartas, etc. Puede apreciarse que
podría contemplarse dentro del alcance de la invención una
innumerable variedad de visualizaciones de objetos y combinaciones
de las mismas, y las sugerencias anteriormente mencionadas no son
en absoluto exhaustivas.
Las Figs. 3A y 3B muestran una vista
simplificada de un esquema de disposición no sensible al orden
creado a partir de una serie de tres Etapas del Demostrante. En la
Fig. 3A, se visualizan ante el usuario dos objetos "X" e
"Y", a lo largo de una cuadrícula similar a un tres en raya
hasta la que pueden moverse uno cualquiera o ambos objetos. Las
tres Etapas del Demostrante están indicadas por las tres líneas
discontinuas que surgen del objeto "X". Dado que este conjunto
particular de Etapas del Demostrante es no sensible al orden,
cualquier serie de Etapas del Demostrante que dé como resultado un
esquema de disposición que se asemeje a 3B podría cumplir una
Prueba de identificación (es decir, Fig. 3A) basada en estas etapas
del Demostrante.
En cambio, las Figs. 4A-4C
muestran una vista simplificada de una serie de Etapas del
Demostrante sensible al orden. La Fig. 4A muestra una Etapa del
Demostrante 1, la Fig. 4B muestra una Etapa del Demostrante 2 y la
Fig. 4C muestra una Etapa del Demostrante 3. La Fig. 4D proporciona
una tabla que compara los esquemas de disposición que resultan de
las Etapas del Demostrante no sensibles al orden de las Figs.
3A-3B y las Etapas del Demostrante sensibles al
orden de las FIGS. 4A-4C. Para las Etapas del
Demostrante sensibles al orden, cada Etapa del Demostrante
corresponderá a un esquema de disposición, como se muestra en las
Figs. 4A-4C. Para las Etapas del Demostrante no
sensibles al orden, el esquema de disposición, como se muestra en la
Fig. 3B, corresponde al resultado final de todas las Etapas del
Demostrante.
En una forma de realización de la invención, las
series de Etapas del Demostrante se usan solas como una contraseña
fácil de recordar para acceder a una aplicación segura. El esquema
de disposición o serie de esquemas de disposición se almacenan en
una ubicación accesible para la aplicación segura, de modo que,
cuando un Demostrante pretende acceder a la aplicación segura,
podría presentarse una prueba de identificación que visualice ante
el usuario los símbolos y exija que el usuario reproduzca
exactamente la contraseña designada previamente por el usuario. La
información de esquema de disposición de la contraseña podría
cifrarse adicionalmente de modo que sólo la aplicación segura pueda
descifrarla con fines de comparación con la respuesta a la prueba de
identificación del usuario. Sin embargo, se prefiere que, en lugar
de eso, la serie de Etapas del Demostrante y el esquema de
disposición correspondiente se usen para formar una Clave de código
destinada a descifrar información de autenticación necesaria para
acceder a una aplicación segura, como se describirá de forma más
completa en este documento.
Después de generarse el esquema de disposición o
la serie de esquemas de disposición, el sistema que implementa la
invención usa el esquema o los esquemas de disposición resultantes
para generar una Cadena que se usará más tarde para construir una
Clave de código. La Fig. 5 ilustra el Proceso de construcción de
Etapas del Demostrante. Después de proporcionar el usuario una
serie de Etapas del Demostrante, como se ilustra en las Figs. 3 y
4, el Proceso de construcción de Etapas del Demostrante de la Fig. 5
genera un esquema de disposición sobre la base de las Etapas del
Demostrante. El esquema de disposición contiene generalmente el tipo
de información mostrado en la Fig. 4D. A continuación, este proceso
combina matemáticamente las selecciones, objetos y acciones
representados por el esquema de disposición para producir una Cadena
correspondiente a la serie de Etapas del Demostrante. Típicamente,
esta cadena está en forma de cadena binaria. La Cadena generada es
específica de la sensibilidad al orden de las Etapas del
Demostrante, la disposición de los símbolos u objetos usados y la
secuencia de etapas del Demostrante. La Cadena se almacena de modo
que pueda usarse más tarde (véase la Fig. 9) para producir una
Clave de código. Nótese igualmente que un Demostrante tiene la
opción de cambiar en cualquier momento sus Etapas de Demostrante
repitiendo el Proceso de construcción de Etapas del Demostrante de
la Fig. 5.
En una forma de realización preferida, la Cadena
se almacena en el ordenador del usuario en una ubicación y manera
tales que la Cadena es inaccesible para las aplicaciones seguras a
las que el usuario pretende acceder. Esto ayuda a garantizar que no
se transmita a las aplicaciones seguras un conjunto completo de
información de autenticación. Sin embargo, en otras formas de
realización, es posible almacenar la Cadena en una ubicación,
inaccesible todavía a las aplicaciones seguras, que no sea el
ordenador del usuario, tal como un ordenador remoto o un servidor.
También es posible almacenar la Cadena en un soporte de
almacenamiento portátil, tal como un disquete, para permitir al
usuario disfrutar de las ventajas de la invención en cualquier
ordenador que use. Otra posibilidad es almacenar la Cadena en una
red de ordenadores en una ubicación "escondida" de otros
usuarios.
La Fig. 6 ilustra otro proceso preliminar de uso
de la invención, que implica la designación una sola vez de las
exigencias de autenticación asociadas a una aplicación particular.
Para adaptar las exigencias de autenticación particulares de un
Verificador, la invención posibilita que los usuarios designen antes
de tiempo el Verificador y sus exigencias de autenticación. Esto se
hace típicamente después de que el usuario haya elegido sus Etapas
de Demostrante, como se ha ilustrado en las Figs. 3, 4 y 5. Sin
embargo, como muestra la Fig. 6, un Demostrante tiene la
posibilidad de interrumpir el proceso de designación de Verificador
y de elegir las Etapas de Demostrante en el momento de designar un
Verificador, si el usuario no lo ha hecho ya.
Un ejemplo puede ayudar a ilustrar las
operaciones del proceso mostrado en la Fig. 6. Supongamos que se ha
emitido a un usuario un nombre de usuario y una contraseña para el
servicio en línea LEXIS™. El usuario quiere añadir esta aplicación
segura al sistema que implementa la invención, habiendo completado
ya las etapas de la Fig. 5. En primer lugar, el usuario designa la
aplicación segura particular (es decir, "LEXIS™"). Esto se
hace de modo que el sistema que implementa la invención pueda
configurar en forma apropiada la información de autenticación que
proporcionará el usuario, a fin de garantizar que la información de
autenticación será compatible con las exigencias de la aplicación
segura. Preferentemente, esta designación se realiza a través de
una interfaz sencilla, fácil de usar por el usuario, tal como un
menú desplegable o la selección a partir de una lista de
aplicaciones. Sin embargo, se contempla que son posibles muchos
procesos de designación de aplicaciones, incluyendo introducir
manualmente el nombre de las aplicaciones o recibir información de
aplicaciones desde una fuente externa. Se contempla además que, en
formas de realización futuras, un sistema que implemente la
invención puede ser capaz de detectar y determinar automáticamente
la aplicación que el usuario quiere designar.
A continuación, como se muestra en la Fig. 6, el
usuario suministra la información de autenticación apropiada para
la aplicación segura. En este ejemplo, el usuario podría
proporcionar un nombre de usuario y una contraseña de LEXIS™, tal
como "Jsmith, ab2dc3e." Ésta es la única vez en que el usuario
necesita recordar la información de autenticación para esta
aplicación. Tras proporcionar el usuario esta información de
autenticación, la invención usa la Cadena (desde la Fig. 5) para
generar una Clave de código usada para cifrar la información de
autenticación. La propia Clave de código nunca se almacena; todo
cuanto se almacena es la Cadena (como se ha indicado previamente) y
la información de autenticación del Verificador cifrada. En una
forma de realización preferida, la información de autenticación del
Verificador cifrada se almacena en una ubicación inaccesible para
el Verificador, tal como en el ordenador del usuario. Sin embargo,
las alternativas disponibles para el almacenamiento de la Cadena
también son aplicables al almacenamiento de la información de
autenticación cifrada del Verificador.
El proceso de cifrado usado con la Clave de
código es, preferentemente, una función unívoca no reversible, tal
como una función unívoca de verificación de errores. Sin embargo,
conviene entender que un experto en la materia contemplaría
técnicas de cifrado explotables suplementarias.
El proceso de generación de una Cadena y una
Clave de código a partir de la Cadena, y de cifrado de la
información de autenticación, ayuda a garantizar que no puedan
deducirse fácilmente las Etapas del Demostrante, los esquemas de
configuración y la información de autenticación. Asimismo, con este
proceso, la Clave de Código puede ser única para cada aplicación y
sesión de entrada al sistema.
La Fig. 7 proporciona una vista global de las
etapas implicadas en una forma de realización preferida de la
invención. Estas etapas refieren cronológicamente los eventos que se
producen cuando un usuario que ya ha completado las etapas de
selección de las Etapas del Demostrante (Fig. 5) y Designación del
Verificador (Fig. 6) pretende conseguir acceso al Verificador.
Por lo general, la forma de realización de la
invención proporciona a los Demostrantes un proceso de autenticación
único, sencillo que sustituye los enfoques de nombre y contraseña
tradicionales. Esta posibilita que los Verificadores autentiquen a
los Demostrantes en forma segura y posibilita que los Demostrantes
sean autenticados por múltiples Verificadores. La mayoría de los
Verificadores requieren un proceso distinto y único (es decir, la
mayoría de los Verificadores tienen exigencias de autenticación
únicas). Para otorgar acceso al Verificador, la invención requiere
al Demostrante que complete un conjunto de rutinas o Etapas del
Demostrante. Los Demostrantes sólo necesitan ejecutar sus Etapas
del Demostrante para dar comienzo al proceso apropiado para cada
Verificador.
La forma de realización de la invención soporta
cierto número de procesos de autenticación diferentes. La
autenticación del Demostrante se logra sobre la base de los
resultados combinados de las Etapas del Demostrante y el proceso o
subproceso apropiado para la aplicación a la que se accede. La forma
de realización sigue una única secuencia, mostrada en general en la
Fig. 7, que da comienzo al subproceso apropiado para cada una de
las exigencias específicas del Verificador. La serie de etapas para
la invención, una vez iniciada, no requiere ninguna intervención
más o entrada por parte del Demostrante. De hecho, el Demostrante
sólo necesita seleccionar el Verificador o aplicación segura a la
que acceder y completar sus Etapas de Demostrante. Se proporciona
al Demostrante un proceso simple unificado para todas sus exigencias
de autenticación. El Proceso maneja los matices asociados a cada
aplicación o sistema.
Las etapas mostradas en la Fig. 7 se aplican a
todas las aplicaciones seguras a las que un usuario pretende
acceder y se inician para cada aplicación o sistema basado en una
autenticación única. Generalmente, la entrada del Demostrante en el
Proceso de conexión del Demostrante y Proceso de Prueba de
identificación se usaría para construir una clave ("Clave de
código") en el Proceso de construcción de Clave de código. Esta
Clave de código corresponde a la misma Clave de código que se ha
obtenido en la Fig. 6 del Proceso de construcción de Etapas del
Demostrante de la Fig. 5. Entonces la invención "establece
correlaciones" con el subproceso específico del Verificador
sobre la base de la aplicación a la que accede el Demostrante. Este
Proceso de correlación debería examinar la Clave de código y
generar resultados apropiados para su transmisión al Verificador en
el Proceso de comunicación. El Proceso de comunicación puede ser un
intercambio único, o una serie de intercambios iterativos. A
continuación se proporciona un mayor detalle de cada etapa de la
Fig. 7.
Las etapas de la forma de realización, como se
muestra en la Fig. 7, comprenden dos conjuntos mayores de etapas:
Procesos que implican al Demostrante y Procesos automáticos. Los
Procesos que implican al Demostrante se inician mediante la entrada
del Demostrante y requieren la misma. Los Procesos automáticos se
inician mediante la conclusión de los Procesos que implican al
Demostrante y no requieren ninguna entrada más por parte del
Demostrante.
Las etapas que implican al Demostrante se
inician mediante una petición de autenticación al Demostrante y
requieren la entrada del Demostrante para completarse. La secuencia
incluye el Proceso de conexión del Demostrante, el Proceso de
Prueba de identificación y el Proceso de construcción de Clave de
código.
Como se muestra en la Fig. 8, el Proceso de
conexión del Demostrante es la etapa inicial en el Proceso global y
abarca las etapas necesarias para establecer el Proceso de Prueba de
identificación. El Proceso de conexión del Demostrante se inicia
mediante una petición de autenticación al Demostrante. Esta petición
puede provenir de varias fuentes que incluyen, pero sin limitarse
a, controladores de recursos, proveedores de acceso y procesos
manuales y automáticos. El Proceso de conexión del Demostrante
presenta y contiene pruebas de identificación del Demostrante.
Una vez iniciado, en cualquier punto durante el
Proceso de conexión del Demostrante, el Demostrante puede
cancelar/suspender el proceso de autenticación. El proceso de
cancelación está sujeto a una acción explícita por parte del
Demostrante. La cancelación suspende el Proceso y la autenticación
falla. En cualquier punto durante el Proceso de conexión del
Demostrante, el Demostrante puede indicar que todas las respuestas
de la Prueba de identificación están completas y debería continuar
la autenticación. Esto no indica autenticación satisfactoria. Esto
indica solamente que el Demostrante cree que se ha suministrado a
las Pruebas de identificación un conjunto completo de
respuestas.
respuestas.
La Fig. 9 ilustra adicionalmente que, una vez
iniciado, el Proceso de conexión del Demostrante contiene y
presenta al Demostrante una Prueba o Pruebas de identificación de
carácter significativo sobre la base del entorno y las experiencias
seleccionados por el Demostrante, de modo que el Demostrante pueda
responder con confianza. Como se ha tratado con el Proceso de
construcción de Etapas del Demostrante, una Prueba de identificación
podría reproducir exactamente la visualización de objetos
familiares que se solicita que manipule un usuario. Como
alternativa, puede presentarse ante el Demostrante una presentación
genérica como el proceso estándar, más simple de presentar la
Prueba de identificación (enfoque del mínimo denominador común) o un
proceso predefinido por el Demostrante que se corresponda más
estrechamente con el entorno y las experiencias del Demostrante
seleccionados.
Por ejemplo, si el usuario no ha seleccionado un
conjunto particular de símbolos que corresponda con su entorno y
sus experiencias, entonces puede presentarse la visualización de un
símbolo o conjunto de símbolos genérico, familiar, tal como una
baraja de cartas. El Proceso de presentación realiza la
determinación sobre la base del entorno elegido por el Demostrante
y de si éste está soportado. La etapa final es la de crear los
subprocesos que definan las Pruebas de identificación individuales
que deben presentarse al Demostrante. Estas Pruebas de
identificación individuales ayudan a cumplir las exigencias de
autenticación de una aplicación segura particular. Si cualquiera de
los subprocesos no puede crearse, el Proceso falla y se suspende el
Proceso. De lo contrario, se inicia el Proceso de Prueba de
identificación.
La Fig. 10 representa las etapas iniciales que
se producen cuando se presenta ante el Demostrante una Prueba de
identificación. La Prueba de identificación podría ser una única
Prueba de identificación o una serie de Pruebas de identificación.
La Prueba de identificación requiere una respuesta o respuestas del
Demostrante a fin de continuar el Proceso. La propia Prueba de
identificación puede sembrarse con un valor aleatorio a fin de
aleatorizar la salida de la Prueba de identificación y proporcionar
un conjunto de datos específico de la sesión.
La Prueba de identificación se presenta como un
conjunto familiar de objetos o símbolos, similar a la visualización
mostrada para elegir las Etapas iniciales del Demostrante. Las
acciones del Demostrante o Etapas del Demostrante se completan
disponiendo, moviendo u ordenando en secuencia los objetos y
símbolos. La Prueba de identificación también podría ser sensible
al orden, lo que indica que se construiría una lista de acciones
(por ejemplo, Etapas del Demostrante) y se almacenaría durante la
vida efectiva de una Prueba de identificación específica. El orden
de las Etapas del Demostrante influiría directamente en el resultado
del Proceso de Prueba de identificación.
En cualquier punto durante el Proceso de Prueba
de identificación, el Demostrante puede cancelar/suspender el
Proceso. La cancelación está sujeta a una acción explícita por parte
del Demostrante. La cancelación suspende el Proceso y la
autenticación falla. Igualmente, en cualquier punto durante el
Proceso de Prueba de identificación, el Demostrante puede
reinicializar la Prueba de identificación. Esto posibilita que el
Demostrante reinicialice el proceso cuando el Demostrante comete un
error mientras completa sus Etapas de Demostrante. Esto devuelve al
Demostrante al inicio del Proceso de Prueba de identificación.
Cuando el Demostrante indica la conclusión del
Proceso de Prueba de identificación, comienza el Proceso de
construcción de Clave de código de la Fig. 11. La conclusión no
equivale ni indica una autenticación con éxito. Una Clave de código
se genera sobre la base del tratamiento de los esquemas de
disposición generados por las Etapas del Demostrante en los
Procesos de Prueba de identificación. Como muestra la Fig. 11, cada
Etapa del Demostrante genera un esquema de disposición que se trata
en el Proceso de construcción de Clave de código. Pueden generarse
esquemas de configuración tanto sensibles al orden como no sensibles
al orden. La conversión es específica del tipo de Prueba de
identificación, sensibilidad al orden, disposición de objetos y
secuencia de las Etapas del Demostrante.
Para Etapas del Demostrante no sensibles al
orden, el Proceso de construcción de Clave de código genera un
Compendio de esquemas de disposición (similar a la Tabla de la Fig.
4C) correspondiente a las Etapas del Demostrante. El esquema de
disposición final se trata en un resultado, tal como una Cadena, que
se usa para construir la Clave de código. Típicamente, para
producir la Clave de código, se trata el resultado o Cadena con una
función unívoca no reversible, tal como una función unívoca de
verificación de errores. Esta Clave de código se usará para
descifrar la información de autenticación almacenada.
Para Etapas del Demostrante sensibles al orden,
se sigue un proceso de construcción de Clave de código sensible al
orden, como se muestra en la Fig. 11. Este proceso selecciona el
primero en la serie de esquemas de disposición resultantes de las
Etapas del Demostrante en el proceso de prueba de identificación. A
continuación, el proceso de construcción de Clave de código
sensible al orden convierte el esquema de disposición seleccionado
en un resultado, tal como una Cadena. Entonces, se selecciona el
siguiente esquema de disposición en la secuencia sensible al orden.
Se trata el resultado anterior con una función unívoca no reversible
(por ejemplo, una función unívoca de verificación de errores) con
el esquema de disposición recién seleccionado y se pasa al proceso
de construcción de Clave de código. Este proceso continúa hasta que
se trate el esquema de disposición final en la secuencia
(convertido en la Clave de código efectiva aplicando una función
unívoca no reversible). La Clave de código resultante se usa del
mismo modo que la Clave de código generada por el proceso de
construcción de Clave de código no sensible al orden.
Conviene entender que el proceso de construcción
de Clave de código descrito anteriormente no está limitado a
funciones unívocas no reversibles, sino que en lugar de ello, un
experto en la materia contemplará metodologías de cifrado
suplementarias que puedan usarse en la invención.
Nótese también que la Cadena generada durante el
proceso de construcción de Clave de código puede ser o no la misma
que la Cadena almacenada en el ordenador del usuario. Sin embargo,
es más seguro que la Cadena que se tiene generada durante el
proceso de construcción de Clave de código sea diferente de la
Cadena almacenada en el ordenador del usuario. El resultado más
importante es el hecho de que la información de autenticación, tras
ser cifrada por la Clave de código resultante de esta Cadena, cumpla
las exigencias de la aplicación segura a la que debe accederse. Si
la Prueba de identificación no es sensible al orden, entonces sólo
el resultado o esquema de disposición final es importante en la
determinación del resultado del Proceso de Prueba de identificación
(véase la Fig. 8). El Proceso de Prueba de identificación continúa
hasta que el Demostrante indique la conclusión o suspenda el
proceso.
El Proceso de Clave de código garantiza que las
Etapas del Demostrante y los esquemas de disposición no puedan
deducirse fácilmente. La Clave de código nunca se almacena y podría
ser única para cada aplicación y sesión de autenticación. Una vez
completado el Proceso de construcción de Clave de código, los
resultados se alimentan a los Procesos automáticos. La conclusión
del Proceso de construcción de Clave de código no indica en ningún
caso autenticación con éxito. Ésta indica simplemente que se ha
generado una Clave de código específica a partir del o de los
esquemas de disposición que han resultado de las Etapas del
Demostrante durante el proceso de Prueba de identificación.
Las etapas restantes en el Proceso se producen
automáticamente y no requieren ninguna otra implicación del
Demostrante. Las Figs. 7 y 12 representan una vista general de alto
nivel de las etapas que están implicadas.
Los resultados del Proceso de construcción de
Clave de código dan comienzo a los Procesos automáticos. El
protocolo de autenticación apropiado y los subprocesos
correspondientes se seleccionan sobre la base de la aplicación a la
que se accede. El Proceso de correlación da comienzo al Proceso de
comunicación con el Verificador y al Proceso de comprobación
subsiguiente. Si no puede correlacionarse la Clave de código,
entonces falla la autenticación y se suspende el proceso
global.
Como se muestra en la Fig. 13, el Proceso de
correlación se inicia mediante los resultados del Proceso de
construcción de Clave de código. Un subproceso de correlación
apropiado se selecciona sobre la base de la aplicación a la que
accede el Demostrante y el tipo de autenticación necesaria para esta
aplicación. Con la creación con éxito de un subproceso de
correlación específico, se alimentan al mismo la o las Claves de
código con fines de tratamiento. Si se requieren correlaciones
suplementarias, en una secuencia de correlaciones, entonces se
realimentan los resultados del subproceso de correlación al Proceso
de correlación. Si falla la creación de un subproceso de
correlación específico o si no puede descubrirse ningún subproceso
de correlación apropiado, entonces falla la autenticación y se
suspende el Proceso global. De lo contrario, los resultados del
Proceso de correlación dan comienzo al Proceso de comunicación.
Siguen descripciones para algunos posibles
subprocesos de correlación asociados a protocolos de autenticación
específicos. Estos incluyen Nombre y Contraseña heredados (Fig. 14),
Firma/Certificado digital (Fig. 15), Conocimiento nulo (Fig. 16) y
Autenticación externa (Fig. 17). Podrán añadirse otros subprocesos a
medida que estén disponibles o se desarrollen protocolos de
autenticación alternativos.
La Fig. 14 representa las etapas que están
implicadas en el subproceso que soporta aplicaciones de nombre y
contraseña heredadas tradicionales. El resultado del Proceso de
construcción de Clave de código y/u otro subproceso de correlación
da comienzo al subproceso. Las etapas previas en el Proceso de
correlación también pueden suministrar información suplementaria
necesaria para la iniciación de este subproceso. Los resultados de
este subproceso de correlación se suministran en retorno al Proceso
de correlación para uso en el Proceso de comunicación. En este caso
particular, los resultados son un par específico de nombre y
contraseña que puede usarse en la autenticación. Si falla la
creación de este subproceso de correlación específico o si por
cualquier razón la propia correlación es incapaz de completarse,
entonces falla la autenticación y se suspende el Proceso.
La Fig. 15 representa las etapas que están
implicadas en el subproceso que podría soportar el uso de firmas
digitales o certificados digitales. El resultado del Proceso de
construcción de Clave de código y/u otro subproceso de correlación
da comienzo al subproceso. Las etapas previas en el Proceso de
correlación también pueden suministrar información suplementaria
necesaria para la iniciación de este subproceso. Los resultados de
este subproceso de correlación se suministran en retorno al Proceso
de correlación. En este caso particular, los resultados del
subproceso son un certificado digital, firma digital, clave pública
y/o privada específicos que puedan usarse en la autenticación. Si
falla la creación de este subproceso de correlación específico o si
por cualquier razón la propia correlación es incapaz de
completarse, entonces falla la autenticación y se suspende el
Proceso.
La Fig. 16 representa las etapas que están
implicadas en el subproceso que podría soportar la autenticación de
tipo conocimiento nulo. Los resultados del Proceso de construcción
de Clave de código y/u otro u otros subprocesos de correlación dan
comienzo al subproceso. Las etapas previas en el Proceso de
correlación también pueden suministrar información suplementaria
necesaria para la iniciación de este subproceso. Los resultados de
este subproceso de correlación se suministran en retorno al Proceso
de correlación. En este caso particular, los resultados del
subproceso son claves e información de conocimiento nulo que pueden
usarse en la autenticación. Si falla la creación de este subproceso
de correlación específico o si por cualquier razón la propia
correlación es incapaz de completarse, entonces falla la
autenticación y se suspende el Proceso.
La Fig. 17 representa el subproceso que soporta
aplicaciones basadas en autenticación externa. Los resultados del
Proceso de construcción de Clave de código y/u otro u otros
subprocesos de correlación dan comienzo al proceso. Las etapas
previas en el Proceso de correlación también pueden suministrar
información suplementaria necesaria para la iniciación de este
subproceso. Los resultados de este subproceso de correlación se
suministran a un Proceso de autenticación externo. El control de la
tarea de autenticación se pasa a este proceso externo para su
conclusión. Si falla la creación de un subproceso de correlación
específico o si por cualquier razón la propia correlación es
incapaz de completarse, entonces falla la autenticación y se
suspende el Proceso.
El Proceso de comunicación de la Fig. 18 es el
enlace entre el Demostrante y el Verificador.
Los resultados del Proceso de correlación dan
comienzo al Proceso de comunicaciones. Este proceso conduce al
Proceso de comprobación final y a las consecuencias finales de la
autenticación.
Debe seleccionarse y crearse un subproceso de
comunicaciones apropiado sobre la base de la aplicación seleccionada
por el Demostrante en la iniciación, el tipo de autenticación que
debe producirse y las exigencias de comunicaciones asociadas. A
continuación se describen ejemplos de estos subprocesos de
comunicaciones. Al crear con éxito un subproceso de comunicaciones
específico, se inicia la comunicación y los resultados de la
correlación se alimentan al mismo con fines de tratamiento. Si se
requieren correlaciones suplementarias en una secuencia de
correlaciones, entonces se realimentan los resultados del subproceso
de correlación actual al Bucle del Proceso de comunicaciones. De lo
contrario, los resultados del Proceso de comunicaciones dan comienzo
al Proceso de comprobación y los resultados de aquel proceso
conducen a la conclusión o al fallo final de la autenticación.
En cualquier punto durante el Proceso de
comunicaciones, el Proceso de comprobación puede indicar fallo. En
tal caso, falla la autenticación y el Proceso se suspende. Siempre
que el Proceso de comprobación indique éxito, el o los subprocesos
pueden continuar según sea necesario. Si falla la creación de un
subproceso de comunicaciones específico o si no puede descubrirse
ningún subproceso de comunicaciones apropiado, entonces falla la
autenticación y se suspende el Proceso.
La Fig. 19 representa las etapas que están
implicadas en el subproceso de comunicaciones heredado/simétrico.
Los resultados del Proceso de correlación y/u otro u otros
subprocesos de comunicaciones dan comienzo al proceso. Las etapas
previas en el Proceso de comunicaciones también pueden suministrar
información suplementaria necesaria para la iniciación de este
subproceso. Los resultados de este subproceso de comunicaciones se
suministran en el Proceso de comunicaciones después de que el
Demostrante y el Verificador realicen un proceso exhaustivo de
comprobación simétrica a través del canal proporcionado por este
subproceso. La tarea de completar el proceso de autenticación puede
concederse a un proceso de autenticación externo y todo el control
se cede a este proceso. Si falla la creación de este subproceso de
comunicaciones específico o si la propia comunicación es incapaz de
completarse por cualquier razón (tal como un fallo para lograr un
canal de comunicaciones válido), entonces falla la autenticación y
se suspende el Proceso global.
La Fig. 20 representa las etapas que están
implicadas en el subproceso de comunicaciones por
certificado/
asimétrico. Los resultados del Proceso de correlación y/u otro u otros subprocesos de comunicaciones dan comienzo al proceso. Las etapas previas en el Proceso de comunicaciones también pueden suministrar información suplementaria necesaria para la iniciación de este subproceso. Los resultados de este subproceso de comunicaciones se suministran al Proceso de comunicaciones después de que el Demostrante y el Verificador realicen un proceso exhaustivo de comprobación asimétrica a través del canal proporcionado por este subproceso. La tarea de completar el proceso de autenticación puede concederse a un proceso de autenticación externo y todo el control se cede a este proceso. Si falla la creación de este subproceso de comunicaciones específico o si la propia comunicación es incapaz de completarse por cualquier razón (tal como un fallo para lograr un canal de comunicaciones válido), entonces falla la autenticación y se suspende el Proceso global.
asimétrico. Los resultados del Proceso de correlación y/u otro u otros subprocesos de comunicaciones dan comienzo al proceso. Las etapas previas en el Proceso de comunicaciones también pueden suministrar información suplementaria necesaria para la iniciación de este subproceso. Los resultados de este subproceso de comunicaciones se suministran al Proceso de comunicaciones después de que el Demostrante y el Verificador realicen un proceso exhaustivo de comprobación asimétrica a través del canal proporcionado por este subproceso. La tarea de completar el proceso de autenticación puede concederse a un proceso de autenticación externo y todo el control se cede a este proceso. Si falla la creación de este subproceso de comunicaciones específico o si la propia comunicación es incapaz de completarse por cualquier razón (tal como un fallo para lograr un canal de comunicaciones válido), entonces falla la autenticación y se suspende el Proceso global.
La Fig. 21 representa las etapas del Proceso de
comprobación final y su relación con la prueba de identificación de
autenticación. Entre el Proceso de comunicación/correlación anterior
y el Proceso de comprobación se inicia un proceso automático de
prueba de identificación/respuesta. En el Proceso de
comunicación/correlación se presenta una prueba de identificación
particular. Generalmente, la prueba de identificación requiere una
respuesta a fin de continuar el Proceso. El Verificador indica si
la respuesta del Proceso de comunicación/correlación actual es o no
correcta y el Proceso avanza en consecuencia. Los procesos de manejo
de prueba de identificación/respuesta del Proceso de comprobación
continúan hasta que el Verificador indique la conclusión o suspenda
el proceso de autenticación. Cuando el Verificador indica la
conclusión final del proceso de prueba de identificación/respuesta,
la autenticación tiene éxito o falla en función de si el Verificador
ha recibido suficientes respuestas para generar el Resultado
esperado.
En cualquier punto durante un Proceso de
comprobación particular, el Demostrante puede reinicializar la
prueba de identificación. Esto posibilita que el Proceso de
comunicación/correlación reinicialice el proceso en los casos en
los que el Demostrante cometa un error. Esto devuelve al inicio de
este proceso. En cualquier punto durante el Proceso de
comprobación, el Verificador (así como el Proceso de
comunicación/correlación) puede cancelar/suspender el proceso de
autenticación. El proceso de cancelación se inicia por acción
explícita por parte del Verificador y/o del Proceso de
comunicación/correlación. La cancelación suspende el proceso de
autenticación y el Proceso falla.
Claims (20)
1. Un procedimiento destinado a proporcionar a
un usuario acceso a una aplicación segura, que comprende las etapas
de:
a) proporcionar una petición de autenticación
al usuario para acceder a la aplicación segura, comprendiendo la
petición de autenticación visualizar ante el usuario al menos un
símbolo;
b) recibir manipulaciones por el usuario de al
menos una parte del símbolo visualizado;
c) generar una clave de código sobre la base
de la manipulación por el usuario de al menos una parte del símbolo
visualizado;
d) usar la clave de código en relación con
información de autenticación almacenada necesaria para cumplir las
exigencias de autenticación de la aplicación segura, para producir
un resultado;
e) proporcionar el resultado a la aplicación
segura; y
f) otorgar al usuario acceso a la aplicación
segura si el resultado soporta las exigencias de autenticación de
la aplicación segura.
2. Un procedimiento según la reivindicación 1,
en el que la información de autenticación necesaria para cumplir
las exigencias de autenticación de la aplicación segura se almacena
en forma cifrada, y la clave de código se usa para descifrar la
información de autenticación para producir el resultado.
3. Un procedimiento según la reivindicación 2,
en el que la etapa de generar la clave de código comprende además
las etapas de generar un esquema de disposición sobre la base de la
manipulación por el usuario de al menos una parte del símbolo
visualizado; y tratar el esquema de disposición con una función
unívoca no reversible para generar la clave de código destinada a
descifrar la información de autenticación.
4. Un procedimiento según la reivindicación 1,
2 ó 3, en el que la información de autenticación está ajustada en
formato para ser compatible con las exigencias de autenticación de
la aplicación segura.
5. Un procedimiento según cualquiera de las
reivindicaciones precedentes, en el que la información de
autenticación se almacena en una ubicación accesible para la
aplicación segura.
6. Un procedimiento según cualquiera de las
reivindicaciones 1 a 4, en el que la información de autenticación
se almacena en la ubicación del usuario.
7. Un procedimiento según la reivindicación 2,
en el que la etapa de descifrar la información de autenticación
usando la clave de código comprende además la etapa de establecer
correlaciones de la información de autenticación con un formato
especificado por la aplicación segura.
8. Un procedimiento según cualquiera de las
reivindicaciones precedentes, que comprende además la etapa de
permitir que el usuario repita etapas previo recibo de una petición
de reinicialización.
9. Un procedimiento según cualquiera de las
reivindicaciones precedentes, en el que la etapa de proporcionar
una petición de autenticación comprende proporcionar una pluralidad
de peticiones de autenticación al usuario para acceder a la
aplicación segura.
10. Un procedimiento según la reivindicación 1
ó 2, que incluye una etapa de almacenar información de autenticación
que comprende sembrar la información de autenticación con un valor
aleatorio; y en el que la etapa de propor-
cionar una petición de autenticación al usuario comprende sembrar la petición de autenticación con el valor aleatorio.
cionar una petición de autenticación al usuario comprende sembrar la petición de autenticación con el valor aleatorio.
11. Un procedimiento según la reivindicación 1,
que incluye una etapa de almacenar información de autenticación que
comprende almacenar en forma cifrada información de autenticación
necesaria para acceder a una pluralidad de aplicaciones
seguras.
12. Un procedimiento según la reivindicación
11, en el que cada una de la pluralidad de aplicaciones requiere la
misma información de autenticación.
13. Un procedimiento según la reivindicación
11, en el que al menos una de la pluralidad de aplicaciones no
requiere la misma información de autenticación que las demás
aplicaciones.
14. Un procedimiento según cualquiera de las
reivindicaciones precedentes, que comprende la etapa de determinar
el usuario el tipo de símbolo de visualización para el usuario, que
corresponde a una experiencia familiar para el usuario.
15. Un procedimiento según cualquiera de las
reivindicaciones precedentes, en el que el símbolo es un símbolo
gráfico.
16. Un procedimiento según la reivindicación 2,
que incluye las etapas de generar un esquema de disposición en
respuesta a la manipulación por el usuario de al menos una parte del
símbolo visualizado; convertir el esquema de disposición en una
deducción matemática; y tratar la deducción matemática con una
función unívoca no reversible para generar la clave de código.
17. Un procedimiento según la reivindicación
16, en el que el resultado del desciframiento de la información de
autenticación cifrada usando la clave de código se correlaciona con
un formato compatible con la aplicación, y el resultado
correlacionado se usa para realizar acciones a fin de cumplir las
exigencias de autenticación de la aplicación segura, en respuesta a
una petición por parte de la aplicación segura.
18. Un procedimiento según la reivindicación 16
ó 17, en el que se convierte el esquema de disposición en una
cadena binaria sobre la base de las manipulaciones por el
usuario.
19. Un procedimiento según la reivindicación 16
ó 17, en el que la etapa de convertir el esquema de disposición
comprende además tratar el resultado con una función unívoca de
verificación de errores.
20. Un procedimiento según la reivindicación
17, en el que la etapa de correlacionar el resultado comprende
además las etapas de determinar la aplicación segura particular, y
usar la clave de código para generar la autenticación necesaria
para acceder a la aplicación segura.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US4628997P | 1997-05-13 | 1997-05-13 | |
| US46289P | 1997-05-13 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2264203T3 true ES2264203T3 (es) | 2006-12-16 |
Family
ID=21942650
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES98922218T Expired - Lifetime ES2264203T3 (es) | 1997-05-13 | 1998-05-12 | Sistema generalizado de identificacion y autenticacion de usuario. |
Country Status (10)
| Country | Link |
|---|---|
| US (2) | US6332192B1 (es) |
| EP (1) | EP1010049B1 (es) |
| JP (3) | JP2001525961A (es) |
| AT (1) | ATE325375T1 (es) |
| AU (1) | AU749130B2 (es) |
| CA (1) | CA2290434C (es) |
| DE (1) | DE69834406T2 (es) |
| ES (1) | ES2264203T3 (es) |
| IL (1) | IL132877A (es) |
| WO (1) | WO1998052115A1 (es) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2574029A1 (es) * | 2015-07-03 | 2016-06-14 | Francisco ANDRÉS MARTÍNEZ | Sistema y método para la recuperación de objetos perdidos |
Families Citing this family (114)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7743248B2 (en) | 1995-01-17 | 2010-06-22 | Eoriginal, Inc. | System and method for a remote access service enabling trust and interoperability when retrieving certificate status from multiple certification authority reporting components |
| EP0881557B1 (en) * | 1997-05-28 | 2003-04-16 | Siemens Aktiengesellschaft | Computer system for protecting software and a method for protecting software |
| US6772336B1 (en) * | 1998-10-16 | 2004-08-03 | Alfred R. Dixon, Jr. | Computer access authentication method |
| US7219368B2 (en) | 1999-02-11 | 2007-05-15 | Rsa Security Inc. | Robust visual passwords |
| WO2000070838A2 (en) * | 1999-05-14 | 2000-11-23 | Pivia, Inc. | Client-server independent intermediary mechanism |
| US7058817B1 (en) | 1999-07-02 | 2006-06-06 | The Chase Manhattan Bank | System and method for single sign on process for websites with multiple applications and services |
| AU3438401A (en) | 1999-11-04 | 2001-05-14 | Jp Morgan Chase Bank | System and method for automated financial project management |
| US8571975B1 (en) | 1999-11-24 | 2013-10-29 | Jpmorgan Chase Bank, N.A. | System and method for sending money via E-mail over the internet |
| US10275780B1 (en) | 1999-11-24 | 2019-04-30 | Jpmorgan Chase Bank, N.A. | Method and apparatus for sending a rebate via electronic mail over the internet |
| AU2294001A (en) * | 1999-12-22 | 2001-07-03 | Accenture Llp | A method for a virtual trade financial framework |
| IL150728A0 (en) * | 2000-01-14 | 2003-02-12 | Catavault | Method and system for secure registration, storage, management and linkage of personal authentication credentials data over a network |
| IL135150A0 (en) * | 2000-03-17 | 2001-05-20 | Avner Geller | A method and a system for secured identification of user's identity |
| US7426530B1 (en) | 2000-06-12 | 2008-09-16 | Jpmorgan Chase Bank, N.A. | System and method for providing customers with seamless entry to a remote server |
| US10185936B2 (en) | 2000-06-22 | 2019-01-22 | Jpmorgan Chase Bank, N.A. | Method and system for processing internet payments |
| US7392388B2 (en) * | 2000-09-07 | 2008-06-24 | Swivel Secure Limited | Systems and methods for identity verification for secure transactions |
| US8335855B2 (en) | 2001-09-19 | 2012-12-18 | Jpmorgan Chase Bank, N.A. | System and method for portal infrastructure tracking |
| DE10050734A1 (de) * | 2000-09-29 | 2002-04-11 | Reinhold Rohrbach | Verfahren und Vorrichtung zur Zugangscodeermittlung |
| AU2002218644A1 (en) * | 2000-11-29 | 2002-06-11 | Temasek Polytechnic | Enhance authorization system and method for computer security |
| US6883095B2 (en) * | 2000-12-19 | 2005-04-19 | Singlesigon. Net Inc. | System and method for password throttling |
| US7020645B2 (en) * | 2001-04-19 | 2006-03-28 | Eoriginal, Inc. | Systems and methods for state-less authentication |
| US8849716B1 (en) | 2001-04-20 | 2014-09-30 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
| US7689506B2 (en) | 2001-06-07 | 2010-03-30 | Jpmorgan Chase Bank, N.A. | System and method for rapid updating of credit information |
| US6834795B1 (en) * | 2001-06-29 | 2004-12-28 | Sun Microsystems, Inc. | Secure user authentication to computing resource via smart card |
| US7266839B2 (en) | 2001-07-12 | 2007-09-04 | J P Morgan Chase Bank | System and method for providing discriminated content to network users |
| US7103576B2 (en) | 2001-09-21 | 2006-09-05 | First Usa Bank, Na | System for providing cardless payment |
| WO2003038561A2 (en) | 2001-11-01 | 2003-05-08 | First Usa Bank, N.A. | System and method for establishing or modifying an account with user selectable terms |
| US7412720B1 (en) * | 2001-11-02 | 2008-08-12 | Bea Systems, Inc. | Delegated authentication using a generic application-layer network protocol |
| GB0126426D0 (en) | 2001-11-03 | 2002-01-02 | Royal Holloway University Of L | Authentication of a remote user to a host in a data communication system |
| US20030093699A1 (en) * | 2001-11-15 | 2003-05-15 | International Business Machines Corporation | Graphical passwords for use in a data processing network |
| JP2003157332A (ja) * | 2001-11-21 | 2003-05-30 | Oki Electric Ind Co Ltd | 本人確認装置、本人確認システム、カード発行装置及びカード発行システム |
| US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
| US7246230B2 (en) | 2002-01-29 | 2007-07-17 | Bea Systems, Inc. | Single sign-on over the internet using public-key cryptography |
| US7219231B2 (en) * | 2002-01-30 | 2007-05-15 | Hewlett-Packard Development Company, L.P. | Extensible authentication system and method |
| US7941533B2 (en) | 2002-02-19 | 2011-05-10 | Jpmorgan Chase Bank, N.A. | System and method for single sign-on session management without central server |
| KR20020077838A (ko) * | 2002-08-09 | 2002-10-14 | 박승배 | 타인의 관찰에 의한 패스워드의 노출 문제를 해결한 패스워드 시스템 |
| US6954862B2 (en) * | 2002-08-27 | 2005-10-11 | Michael Lawrence Serpa | System and method for user authentication with enhanced passwords |
| US7058660B2 (en) | 2002-10-02 | 2006-06-06 | Bank One Corporation | System and method for network-based project management |
| US8239917B2 (en) * | 2002-10-16 | 2012-08-07 | Enterprise Information Management, Inc. | Systems and methods for enterprise security with collaborative peer to peer architecture |
| US20040193923A1 (en) * | 2003-01-16 | 2004-09-30 | Hammond Frank J. | Systems and methods for enterprise security with collaborative peer to peer architecture |
| US7840806B2 (en) * | 2002-10-16 | 2010-11-23 | Enterprise Information Management, Inc. | System and method of non-centralized zero knowledge authentication for a computer network |
| US8301493B2 (en) | 2002-11-05 | 2012-10-30 | Jpmorgan Chase Bank, N.A. | System and method for providing incentives to consumers to share information |
| US7577987B2 (en) * | 2002-12-23 | 2009-08-18 | Authernative, Inc. | Operation modes for user authentication system based on random partial pattern recognition |
| US7644433B2 (en) * | 2002-12-23 | 2010-01-05 | Authernative, Inc. | Authentication system and method based upon random partial pattern recognition |
| US20040163087A1 (en) * | 2003-02-14 | 2004-08-19 | Carl Sandland | Computer program code and method for delivering external data to a process running on a virtual machine |
| US7496953B2 (en) * | 2003-04-29 | 2009-02-24 | International Business Machines Corporation | Single sign-on method for web-based applications |
| US7073067B2 (en) * | 2003-05-07 | 2006-07-04 | Authernative, Inc. | Authentication system and method based upon random partial digitized path recognition |
| US20040225880A1 (en) * | 2003-05-07 | 2004-11-11 | Authenture, Inc. | Strong authentication systems built on combinations of "what user knows" authentication factors |
| US7478433B2 (en) * | 2003-06-19 | 2009-01-13 | Panasonic Corporation | Program execution system having authentication function |
| US20040267870A1 (en) * | 2003-06-26 | 2004-12-30 | Rozmus John Michael | Method of single sign-on emphasizing privacy and minimal user maintenance |
| US7305705B2 (en) * | 2003-06-30 | 2007-12-04 | Microsoft Corporation | Reducing network configuration complexity with transparent virtual private networks |
| CA2434276A1 (en) | 2003-07-03 | 2005-01-03 | Ibm Canada Limited - Ibm Canada Limitee | Password management |
| US8190893B2 (en) | 2003-10-27 | 2012-05-29 | Jp Morgan Chase Bank | Portable security transaction protocol |
| US7552327B2 (en) | 2003-11-13 | 2009-06-23 | International Business Machines Corporation | Method and apparatus for conducting a confidential search |
| US7698734B2 (en) * | 2004-08-23 | 2010-04-13 | International Business Machines Corporation | Single sign-on (SSO) for non-SSO-compliant applications |
| US7941671B2 (en) * | 2004-10-14 | 2011-05-10 | Oracle International Corporation | Method and apparatus for accommodating multiple verifier types with limited storage space |
| US7669057B2 (en) * | 2005-01-24 | 2010-02-23 | International Business Machines Corporation | Secure computer password system and method |
| US20060185004A1 (en) * | 2005-02-11 | 2006-08-17 | Samsung Electronics Co., Ltd. | Method and system for single sign-on in a network |
| US7363492B2 (en) * | 2005-02-25 | 2008-04-22 | Motorola, Inc. | Method for zero-knowledge authentication of a prover by a verifier providing a user-selectable confidence level and associated application devices |
| US8185877B1 (en) | 2005-06-22 | 2012-05-22 | Jpmorgan Chase Bank, N.A. | System and method for testing applications |
| US7577994B1 (en) * | 2005-08-25 | 2009-08-18 | Symantec Corporation | Detecting local graphic password deciphering attacks |
| US8583926B1 (en) | 2005-09-19 | 2013-11-12 | Jpmorgan Chase Bank, N.A. | System and method for anti-phishing authentication |
| US8230487B2 (en) | 2005-12-21 | 2012-07-24 | International Business Machines Corporation | Method and system for controlling access to a secondary system |
| WO2007089503A2 (en) * | 2006-01-26 | 2007-08-09 | Imprivata, Inc. | Systems and methods for multi-factor authentication |
| US8078990B2 (en) | 2006-02-01 | 2011-12-13 | Research In Motion Limited | Secure device sharing |
| US20080276309A1 (en) * | 2006-07-06 | 2008-11-06 | Edelman Lance F | System and Method for Securing Software Applications |
| US8793490B1 (en) | 2006-07-14 | 2014-07-29 | Jpmorgan Chase Bank, N.A. | Systems and methods for multifactor authentication |
| US8925052B2 (en) * | 2006-07-26 | 2014-12-30 | At&T Intellectual Property I, L.P. | Application integration |
| US7849321B2 (en) * | 2006-08-23 | 2010-12-07 | Authernative, Inc. | Authentication method of random partial digitized path recognition with a challenge built into the path |
| US8521857B2 (en) | 2006-08-24 | 2013-08-27 | Bby Solutions, Inc. | Systems and methods for widget rendering and sharing on a personal electronic device |
| US7945776B1 (en) * | 2006-09-29 | 2011-05-17 | Emc Corporation | Securing a passphrase |
| US8046823B1 (en) | 2006-10-03 | 2011-10-25 | Stamps.Com Inc. | Secure application bridge server |
| US8201217B1 (en) * | 2006-10-03 | 2012-06-12 | Stamps.Com Inc. | Systems and methods for single sign-in for multiple accounts |
| JP4888057B2 (ja) * | 2006-11-01 | 2012-02-29 | 富士通セミコンダクター株式会社 | 情報処理装置 |
| US8176427B2 (en) * | 2006-12-21 | 2012-05-08 | Canon Kabushiki Kaisha | Method for configuring a device using simple pictograms |
| US8042159B2 (en) * | 2007-03-15 | 2011-10-18 | Glynntech, Inc. | Website log in system with user friendly combination lock |
| US7904947B2 (en) * | 2007-03-22 | 2011-03-08 | Glynntech, Inc. | Gateway log in system with user friendly combination lock |
| US8473735B1 (en) | 2007-05-17 | 2013-06-25 | Jpmorgan Chase | Systems and methods for managing digital certificates |
| US9607175B2 (en) * | 2007-05-21 | 2017-03-28 | International Business Machines Corporation | Privacy safety manager system |
| WO2009002804A2 (en) * | 2007-06-22 | 2008-12-31 | Chumby Industries, Inc. | Systems and methods for device registration |
| US8156338B1 (en) | 2007-09-25 | 2012-04-10 | United Services Automobile Association | Systems and methods for strong authentication of electronic transactions |
| US7890761B1 (en) | 2007-09-25 | 2011-02-15 | United Services Automobile Association (Usaa) | Systems and methods for strong authentication of electronic transactions |
| US8813200B2 (en) * | 2007-12-21 | 2014-08-19 | Oracle International Corporation | Online password management |
| US8321682B1 (en) | 2008-01-24 | 2012-11-27 | Jpmorgan Chase Bank, N.A. | System and method for generating and managing administrator passwords |
| US8996867B2 (en) | 2008-02-28 | 2015-03-31 | At&T Intellectual Property I, L.P. | Method and device for end-user verification of an electronic transaction |
| DE102008019034A1 (de) | 2008-04-15 | 2009-10-22 | Patev Gmbh & Co. Kg | Verfahren und Vorrichtung zur Ermittlung eines Zugangscodes |
| US20110166916A1 (en) * | 2008-06-12 | 2011-07-07 | Ads Captcha Ltd. | Time-Resolved & User-Spatially-Activated Feedback Entrance and Method Thereof |
| CN101316424A (zh) * | 2008-07-08 | 2008-12-03 | 阿里巴巴集团控股有限公司 | 一种信息传输方法、***及装置 |
| JP5234990B2 (ja) | 2009-05-13 | 2013-07-10 | 住友重機械工業株式会社 | 軸受構造 |
| GB0910545D0 (en) * | 2009-06-18 | 2009-07-29 | Therefore Ltd | Picturesafe |
| US9608826B2 (en) | 2009-06-29 | 2017-03-28 | Jpmorgan Chase Bank, N.A. | System and method for partner key management |
| US8713647B2 (en) * | 2009-08-21 | 2014-04-29 | International Business Machines Corporation | End-of-session authentication |
| DE102009052174B3 (de) * | 2009-11-06 | 2010-10-21 | Christoph Althammer | Verfahren zur Authentifizierung eines Benutzers an einer Rechnereinheit |
| DE102011016150A1 (de) * | 2011-03-28 | 2012-10-04 | Jurij Schilling | Authentifizierungsmethode mittels eines auf dem Algorithmus basierendes Kennwortes |
| US8713703B2 (en) | 2011-07-31 | 2014-04-29 | International Business Machines Corporation | Advanced CAPTCHA using images in sequence |
| US8590058B2 (en) | 2011-07-31 | 2013-11-19 | International Business Machines Corporation | Advanced audio CAPTCHA |
| KR101841039B1 (ko) * | 2011-11-28 | 2018-03-28 | 삼성전자주식회사 | 패스워드 인증 방법 및 이를 이용한 휴대기기 |
| CN102880820B (zh) * | 2012-08-14 | 2017-11-17 | 东莞宇龙通信科技有限公司 | 一种移动终端应用程序访问方法及移动终端 |
| US8868919B2 (en) | 2012-10-23 | 2014-10-21 | Authernative, Inc. | Authentication method of field contents based challenge and enumerated pattern of field positions based response in random partial digitized path recognition system |
| US9215072B1 (en) | 2012-10-23 | 2015-12-15 | Authernative, Inc. | Back-end matching method supporting front-end knowledge-based probabilistic authentication systems for enhanced credential security |
| US8955074B2 (en) | 2012-10-23 | 2015-02-10 | Authernative, Inc. | Authentication method of enumerated pattern of field positions based challenge and enumerated pattern of field positions based response through interaction between two credentials in random partial digitized path recognition system |
| CN103096171A (zh) * | 2012-11-22 | 2013-05-08 | 康佳集团股份有限公司 | 一种基于人脸识别的应用授权方法、***及智能电视 |
| KR101987246B1 (ko) * | 2012-11-26 | 2019-06-12 | 한국전자통신연구원 | 휴대용 단말기의 사용자 인증 장치 |
| US20140157382A1 (en) * | 2012-11-30 | 2014-06-05 | SunStone Information Defense, Inc. | Observable authentication methods and apparatus |
| US9230081B2 (en) * | 2013-03-05 | 2016-01-05 | Intel Corporation | User authorization and presence detection in isolation from interference from and control by host central processing unit and operating system |
| US9419957B1 (en) | 2013-03-15 | 2016-08-16 | Jpmorgan Chase Bank, N.A. | Confidence-based authentication |
| ES2742673T3 (es) | 2013-07-02 | 2020-02-17 | Precise Biometrics Ab | Aplicación de verificación, método, dispositivo electrónico y programa informático |
| JP5659284B1 (ja) * | 2013-11-27 | 2015-01-28 | 株式会社三菱東京Ｕｆｊ銀行 | プログラム、サーバおよび通信端末 |
| JP6298288B2 (ja) * | 2013-12-20 | 2018-03-20 | キヤノン株式会社 | 情報処理装置、情報処理方法、及びプログラム |
| US10148726B1 (en) | 2014-01-24 | 2018-12-04 | Jpmorgan Chase Bank, N.A. | Initiating operating system commands based on browser cookies |
| US9563758B2 (en) * | 2014-05-12 | 2017-02-07 | International Business Machines Corporation | Increasing security of a device and/or system via questioning about a characteristic of the device and/or system |
| CN105095729B (zh) * | 2015-06-19 | 2018-05-25 | 广州密码科技有限公司 | 一种二维码登录方法、服务器及*** |
| DE102015119140A1 (de) * | 2015-11-06 | 2017-05-11 | Océ Printing Systems GmbH & Co. KG | Verfahren zum Steuern des Zugriffs auf verschlüsselte Dateien und Computersystem |
| US10389868B2 (en) * | 2017-06-16 | 2019-08-20 | Intertrust Technologies Corporation | Device authentication systems and methods |
| DE102021125572B9 (de) | 2021-10-01 | 2023-08-03 | Uwe Leibrecht | Verfahren zur Durchführung eines Authentisierungsprozesses durch einen individuellen Systembenutzer |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4652990A (en) | 1983-10-27 | 1987-03-24 | Remote Systems, Inc. | Protected software access control apparatus and method |
| US5168520A (en) | 1984-11-30 | 1992-12-01 | Security Dynamics Technologies, Inc. | Method and apparatus for personal identification |
| US4720860A (en) | 1984-11-30 | 1988-01-19 | Security Dynamics Technologies, Inc. | Method and apparatus for positively identifying an individual |
| US5465084A (en) | 1990-03-27 | 1995-11-07 | Cottrell; Stephen R. | Method to provide security for a computer and a device therefor |
| GB9010603D0 (en) | 1990-05-11 | 1990-07-04 | Int Computers Ltd | Access control in a distributed computer system |
| JPH0430242A (ja) * | 1990-05-25 | 1992-02-03 | Nippon Telegr & Teleph Corp <Ntt> | パスワード管理装置 |
| US5237614A (en) | 1991-06-07 | 1993-08-17 | Security Dynamics Technologies, Inc. | Integrated network security system |
| US5479512A (en) | 1991-06-07 | 1995-12-26 | Security Dynamics Technologies, Inc. | Method and apparatus for performing concryption |
| US5485519A (en) | 1991-06-07 | 1996-01-16 | Security Dynamics Technologies, Inc. | Enhanced security for a secure token code |
| US5657388A (en) | 1993-05-25 | 1997-08-12 | Security Dynamics Technologies, Inc. | Method and apparatus for utilizing a token for resource access |
| JPH0535678A (ja) * | 1991-07-31 | 1993-02-12 | Toshiba Corp | ユーザー認証方式 |
| US5276314A (en) * | 1992-04-03 | 1994-01-04 | International Business Machines Corporation | Identity verification system resistant to compromise by observation of its use |
| US5241594A (en) | 1992-06-02 | 1993-08-31 | Hughes Aircraft Company | One-time logon means and methods for distributed computing systems |
| US5361062A (en) | 1992-11-25 | 1994-11-01 | Security Dynamics Technologies, Inc. | Personal security system |
| US5586260A (en) | 1993-02-12 | 1996-12-17 | Digital Equipment Corporation | Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms |
| US5416840A (en) * | 1993-07-06 | 1995-05-16 | Phoenix Technologies, Ltd. | Software catalog encoding method and system |
| DE69329277T2 (de) | 1993-07-08 | 2001-02-15 | Koninklijke Kpn N.V., Groningen | Rechnersystem das einen Prozessor und ein Speicherfeld hat, das eine Rechnerschnittstelle beinhaltet |
| TW299410B (es) | 1994-04-04 | 1997-03-01 | At & T Corp | |
| US5550968A (en) | 1994-04-12 | 1996-08-27 | International Business Machines Corporation | Method and system for providing access security to controls in a graphical user interface |
| US5999711A (en) * | 1994-07-18 | 1999-12-07 | Microsoft Corporation | Method and system for providing certificates holding authentication and authorization information for users/machines |
| US5604490A (en) | 1994-09-09 | 1997-02-18 | International Business Machines Corporation | Method and system for providing a user access to multiple secured subsystems |
| US5706349A (en) | 1995-03-06 | 1998-01-06 | International Business Machines Corporation | Authenticating remote users in a distributed environment |
| JPH08297638A (ja) * | 1995-04-26 | 1996-11-12 | Nippon Telegr & Teleph Corp <Ntt> | 利用者認証方式 |
| JPH0962596A (ja) * | 1995-08-25 | 1997-03-07 | Hitachi Ltd | 電子メールシステム |
| US5821933A (en) | 1995-09-14 | 1998-10-13 | International Business Machines Corporation | Visual access to restricted functions represented on a graphical user interface |
| JP3624971B2 (ja) * | 1995-10-02 | 2005-03-02 | 松下電器産業株式会社 | ソフトウエア利用制御方法 |
-
1998
- 1998-05-12 DE DE69834406T patent/DE69834406T2/de not_active Expired - Lifetime
- 1998-05-12 CA CA002290434A patent/CA2290434C/en not_active Expired - Lifetime
- 1998-05-12 IL IL13287798A patent/IL132877A/xx not_active IP Right Cessation
- 1998-05-12 ES ES98922218T patent/ES2264203T3/es not_active Expired - Lifetime
- 1998-05-12 AU AU74816/98A patent/AU749130B2/en not_active Expired
- 1998-05-12 WO PCT/US1998/009661 patent/WO1998052115A1/en active IP Right Grant
- 1998-05-12 US US09/076,375 patent/US6332192B1/en not_active Expired - Lifetime
- 1998-05-12 AT AT98922218T patent/ATE325375T1/de not_active IP Right Cessation
- 1998-05-12 JP JP54943198A patent/JP2001525961A/ja not_active Withdrawn
- 1998-05-12 EP EP98922218A patent/EP1010049B1/en not_active Expired - Lifetime
-
2001
- 2001-02-09 US US09/781,062 patent/US6327659B2/en not_active Expired - Lifetime
-
2009
- 2009-01-26 JP JP2009014812A patent/JP4866432B2/ja not_active Expired - Lifetime
-
2010
- 2010-12-13 JP JP2010277482A patent/JP2011070699A/ja not_active Withdrawn
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2574029A1 (es) * | 2015-07-03 | 2016-06-14 | Francisco ANDRÉS MARTÍNEZ | Sistema y método para la recuperación de objetos perdidos |
Also Published As
| Publication number | Publication date |
|---|---|
| IL132877A (en) | 2003-12-10 |
| JP2009116902A (ja) | 2009-05-28 |
| JP4866432B2 (ja) | 2012-02-01 |
| AU749130B2 (en) | 2002-06-20 |
| WO1998052115A1 (en) | 1998-11-19 |
| US6332192B1 (en) | 2001-12-18 |
| IL132877A0 (en) | 2001-03-19 |
| CA2290434A1 (en) | 1998-11-19 |
| EP1010049A1 (en) | 2000-06-21 |
| CA2290434C (en) | 2008-05-06 |
| DE69834406D1 (de) | 2006-06-08 |
| EP1010049B1 (en) | 2006-05-03 |
| ATE325375T1 (de) | 2006-06-15 |
| JP2001525961A (ja) | 2001-12-11 |
| DE69834406T2 (de) | 2006-12-07 |
| JP2011070699A (ja) | 2011-04-07 |
| AU7481698A (en) | 1998-12-08 |
| US6327659B2 (en) | 2001-12-04 |
| US20010005887A1 (en) | 2001-06-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2264203T3 (es) | Sistema generalizado de identificacion y autenticacion de usuario. | |
| US11025616B2 (en) | Limited user authentication by self-recognition | |
| US7921455B2 (en) | Token device that generates and displays one-time passwords and that couples to a computer for inputting or receiving data for generating and outputting one-time passwords and other functions | |
| US8042159B2 (en) | Website log in system with user friendly combination lock | |
| JP5133248B2 (ja) | クライアント／サーバー認証システムにおけるオフライン認証方法 | |
| US8918849B2 (en) | Secure user credential control | |
| US8041954B2 (en) | Method and system for providing a secure login solution using one-time passwords | |
| US8407762B2 (en) | System for three level authentication of a user | |
| US7904947B2 (en) | Gateway log in system with user friendly combination lock | |
| EP2486505A1 (en) | Method and apparatus for using cryptographic mechanisms to provide access to a portable device using integrated authentication using another portable device. | |
| PT2150915E (pt) | Protocolo de login seguro | |
| CN108881116A (zh) | 展现敏感信息的实现方法和装置 | |
| US7347366B2 (en) | Method and apparatus to provide authentication using an authentication card | |
| McCarney | Password managers: Comparative evaluation, design, implementation and empirical analysis | |
| Kenneth et al. | Web application authentication using visual cryptography and cued clicked point recall-based graphical password | |
| CA2611549C (en) | Method and system for providing a secure login solution using one-time passwords | |
| KR101699167B1 (ko) | Otp 인증 시스템, 단말 및 이를 이용한 인증 방법 | |
| EP1684208A2 (en) | Generalized user identification and authentification system | |
| EP2523140A1 (en) | Secure user credential control | |
| WO2023073267A1 (es) | Sistema y método de autenticación mutua | |
| Bratli | Document Verification System on iOS with Face ID/Touch ID | |
| Henry | Toward usable, robust memometric authentication: An evaluation of selected password generation assistance | |
| KR20200143182A (ko) | 고유 정보를 이용한 실시간 문자열 변조/복조 장치 및 방법 | |
| KR20210141438A (ko) | 보안성 있는 사용자 인증 시스템 및 방법 |