ES2426946T3 - Un método, sistema, servidor y terminal para poner en práctica una autenticación - Google Patents
Un método, sistema, servidor y terminal para poner en práctica una autenticación Download PDFInfo
- Publication number
- ES2426946T3 ES2426946T3 ES08734046T ES08734046T ES2426946T3 ES 2426946 T3 ES2426946 T3 ES 2426946T3 ES 08734046 T ES08734046 T ES 08734046T ES 08734046 T ES08734046 T ES 08734046T ES 2426946 T3 ES2426946 T3 ES 2426946T3
- Authority
- ES
- Spain
- Prior art keywords
- trigger message
- random number
- authentication
- server
- client
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 126
- 239000000284 extract Substances 0.000 claims abstract description 15
- 238000000605 extraction Methods 0.000 claims abstract description 3
- 239000008186 active pharmaceutical agent Substances 0.000 claims abstract 3
- 230000004044 response Effects 0.000 claims description 56
- 230000001174 ascending effect Effects 0.000 claims description 9
- 230000005540 biological transmission Effects 0.000 claims description 6
- 230000008859 change Effects 0.000 claims description 5
- 239000003999 initiator Substances 0.000 claims description 2
- 238000010304 firing Methods 0.000 claims 1
- 230000008569 process Effects 0.000 description 20
- 230000007246 mechanism Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 230000011664 signaling Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Un método de autenticación basado en el protocolo de Sincronización de Datos, DS, o de Gestión de Dispositivo,DM, estando dicho método caracterizado por cuanto que comprende: la recepción (301), por un cliente, de un mensaje de disparo operativo procedente de un servidor que utiliza un númeroaleatorio del mensaje de disparo operativo para generar el mensaje de disparo; la extracción, por el cliente, del número aleatorio de mensaje de disparo operativo; la utilización (302), por el cliente, del número aleatorio de mensaje de disparo operativo con el fin de generar un extractode acceso y la autenticación del mensaje de disparo operativo generado utilizando el número aleatorio de mensaje dedisparo operativo después de determinar que dicho número aleatorio de mensaje de disparo es válido yel envío (302), por el cliente, de una demanda de sesión al servidor indicado por el mensaje de disparo operativodespués de la realización satisfactoria de la autenticación, en donde la demanda de sesión soporta un identificador ID desesión.
Description
Un método, sistema, servidor y terminal para poner en práctica una autenticación
La presente invención se refiere a tecnologías de comunicaciones y en particular, a un método de autenticación basado en un protocolo de Sincronización de Datos (DS) y un protocolo de Gestión de Dispositivo (DM) y a un sistema, a un servidor y un cliente.
ANTECEDENTES DE LA INVENCIÓN
El Lenguaje de Marcado de Sincronización (SyncML) es un protocolo desarrollado para sincronizar información personal y datos intra-empresa entre múltiples plataformas y redes. El protocolo SyncML define una serie de operaciones entre las entidades participantes y define un conjunto de formatos de mensajes para realizar dichas operaciones. Sobre la base de SyncML, la denominada Alianza Móvil Abierta (OMA) desarrolla el protocolo DS y el protocolo DM.
El protocolo DS puede sincronizar información personal y datos intra-empresa entre múltiples plataformas y redes. El protocolo DS se suele aplicar a la sincronización de datos entre un dispositivo móvil o servidor de aplicación y un servidor de red o la sincronización de datos entre dos Ordenadores Personales (PCs).
El protocolo DM es una solución de gestión a distancia rentable que descarga datos de instrucciones de gestión desde la red al cliente y permite al cliente ejecutar la instrucción de gestión automáticamente para actualizar, configurar y diagnosticar el software y hardware del cliente. Además, el DM transfiere la información de servicio requerida por el operador y la información sobre las funciones del cliente desde el cliente al servidor, con lo que se soporta la operación de otros servicios.
Un mecanismo de autenticación de seguridad similar se aplica al protocolo DS y al protocolo DM para la autenticación del servidor y del cliente de forma efectiva, según se ilustra en la Figura 1:
Etapa 101: El servidor envía un mensaje de disparo operativo al cliente para iniciar una sesión;
El mensaje de disparo operativo transmite: un extracto de acceso denominado Digest generado utilizando un número aleatorio del servidor (s_nonce) y la información de disparo operativo (TriggerInfo). El mensaje de disparo operativo puede soportarse en un mensaje corto u otro mensaje de tipo denominado Push.
El s_nonce es un número aleatorio (nonce) generado por el cliente y disponible para el servidor.
Etapa 102: El cliente envía una demanda de sesión al servidor.
Después de recibir el mensaje de disparo operativo, el cliente utiliza el s_nonce memorizado para generar información del extracto de acceso Digest y para autenticar el mensaje Trigger de disparo operativo. Si la autenticación se realiza satisfactoriamente, el cliente envía una demanda de sesión al servidor para iniciar una sesión.
La demanda de sesión transmite: un identificador de sesión SessionID e información de autenticación (Authenticate) del cliente. La información de autenticación es un Digest generado utilizando el número aleatorio del cliente (c_nonce).
El c_nonce se genera por el servidor y está disponible para el cliente.
En esta etapa, se establece una conexión de sesión entre el cliente y el servidor.
Etapa 103: El servidor reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación.
En conformidad con la información de autenticación enviada por el cliente, el servidor realiza la autenticación del cliente y luego, reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación del servidor.
Más concretamente, la respuesta transmite: un resultado de la autenticación por el servidor del cliente, un identificador SessionID y la información de autenticación del servidor (esto es, un Digest generado utilizando el s_nonce).
Etapa 104: El cliente reenvía un mensaje que transmite el resultado de la autenticación al servidor.
En conformidad con la información de autenticación enviada por el servidor, el cliente realiza la autenticación del servidor y luego, reenvía un mensaje que transmite el resultado de la autenticación al servidor.
Más concretamente, este mensaje transmite: un resultado de la autenticación del cliente del servidor y otra información pertinente.
Si el servidor realiza la autenticación del cliente, de forma insatisfactoria, o el cliente realiza la autenticación del servidor también de forma insatisfactoria, a modo de ejemplo, la contraseña es incorrecta o el valor del número aleatorio nonce es incorrecto, el servidor o el cliente puede enviar una demanda a la parte opuesta directamente para realizar la autenticación de nuevo.
Si el servidor conoce que el s_nonce utilizado en el mensaje Trigger es incorrecto, a modo de ejemplo, si el servidor no recibe ninguna respuesta normal desde el cliente después de enviar repetidamente el mensaje Trigger, el servidor cree que el s_nonce es incorrecto y genera el Digest del mensaje Trigger utilizando un número aleatorio por defecto “0x00000000”. Después de la autenticación insatisfactoria del mensaje Trigger, en conformidad con el Digest generado utilizando el s_nonce, el cliente utiliza el número aleatorio por defecto para generar un Digest y para realizar una nueva autenticación del mensaje Trigger. Si la autenticación es satisfactoria, el número aleatorio nonce por defecto se utiliza para la autenticación del servidor y del cliente y luego, se actualizan s_nonce y el c_nonce. El proceso de actualización se ilustra en la Figura 2:
Etapa 201: El servidor envía un mensaje Trigger al cliente para iniciar una sesión.
Después de determinar que el s_nonce anterior es incorrecto, el servidor utiliza el número aleatorio por defecto para generar un mensaje Trigger y envía el mensaje al cliente. El mensaje Trigger transmite: el Digest generado utilizando el número aleatorio por defecto y la información TriggerInfo.
Etapa 202: El cliente realiza la autenticación del mensaje Trigger de forma insatisfactoria y utiliza el número aleatorio nonce por defecto para una nueva autenticación.
Después de recibir el mensaje Trigger, el cliente utiliza el s_nonce memorizado para realizar la autenticación del mensaje Trigger. Si la autenticación falla por cualquier motivo, el cliente utiliza el número aleatorio por defecto para una nueva autenticación del mensaje Trigger.
Si la autenticación es satisfactoria, ello indica que el s_nonce anteriormente utilizado por el servidor es incorrecto y el cliente envía una demanda de sesión al servidor.
Etapa 203: El cliente envía una demanda de sesión al servidor.
Después de la autenticación satisfactoria utilizando el número aleatorio por defecto, el cliente envía una demanda de sesión al servidor para iniciar una sesión.
La demanda de sesión transmite: el identificador SessionID y el Digest generado utilizando el número aleatorio nonce por defecto.
Etapa 204: El servidor reenvía una respuesta que transmite el resultado de la autenticación, la demanda de autenticación y la orden para actualizar c_nonce.
El servidor realiza la autenticación del cliente utilizando el número aleatorio nonce por defecto y luego, reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación al cliente.
Más concretamente, la respuesta transmite: un resultado de la autenticación por el servidor del cliente, una demanda de actualización de c_nonce y un Digest generado utilizando el número aleatorio nonce por defecto.
Etapa 205: El cliente reenvía un mensaje que transmite el resultado de la autenticación y la orden para actualizar s_nonce al servidor.
El cliente realiza la autenticación del servidor utilizando el número aleatorio por defecto. Una vez realizada satisfactoriamente la autenticación, el cliente actualiza el c_nonce y luego, reenvía un mensaje que transmite el resultado de autenticación y la orden para actualizar s_nonce al servidor.
Etapa 206: El servidor reenvía un resultado de actualización de s_nonce al cliente.
En el proceso de desarrollo de la presente invención, el inventor encuentra al menos los siguientes defectos en la técnica anterior:
El número aleatorio nonce por defecto se utiliza para la autenticación en el caso de que s_nonce sea incorrecto. El número aleatorio por defecto es un valor fijo abierto y el servidor, operativamente malicioso, puede interceptar el mensaje que utiliza el número aleatorio por defecto y enviar el mensaje repetidamente para atacar al servidor o al cliente.
En la técnica anterior, dos valores de número aleatorio se utilizan en una sola sesión: s_nonce y c_nonce, que se generan y actualizan por el servidor y el cliente respectivamente, con lo que se impone una carga de gestión importante en el cliente y en el servidor.
El documento WO 02/25899 A da a conocer un sistema en el que un cliente/servidor/red puede poner en práctica una sesión de gestión de claves cuando el servidor inicia la sesión de gestión de claves utilizando un número aleatorio. El número aleatorio permite que se transmita un mensaje de disparo operativo o de salida del estado de latencia al cliente, de modo que pueda evitarse un ataque de servicio sobre el servidor cuando se recibe un número aleatorio falso por el servidor con un mensaje de demanda de AP. De este modo, el servidor puede rechazar los mensajes de demanda de AP que no vayan acompañados por un número aleatorio memorizado por el servidor. El método puede ponerse en práctica mediante circuitos, señales eléctricas y un código para realizar los actos descritos en el método.
SUMARIO DE LA INVENCIÓN
Las formas de realización de la presente invención dan a conocer un método de autenticación, un sistema, un servidor y un cliente en función de un protocolo DS o de un protocolo DM para optimizar el proceso de autenticación que se realiza entre el cliente y el servidor y sobre la base del protocolo DS o DM.
El método de autenticación, basado en el protocolo DS o DM, en una forma de realización de la presente invención, comprende:
la recepción, por un cliente, de un mensaje Trigger desde un servidor que utiliza un número aleatorio de mensaje Trigger para generar el mensaje Trigger; la extracción del número aleatorio del mensaje Trigger;
después de determinar que el número aleatorio del mensaje Trigger es válido, la utilización del número aleatorio del mensaje Trigger para generar un Digest y la autenticación del mensaje Trigger generado utilizando el número aleatorio de mensaje Trigger y
una vez realizada satisfactoriamente la autenticación, el envío de una demanda de sesión al servidor indicada por el mensaje Trigger, en donde la demanda de sesión transmite un identificador ID de sesión.
El cliente dado a conocer en una forma de realización de la presente invención comprende:
una unidad de recepción, adaptada para recibir un mensaje Trigger que se genera por un servidor utilizando un número aleatorio de mensaje Trigger y en conformidad con un protocolo DS o DM y
una primera unidad de autenticación, adaptada para: extraer el número aleatorio del mensaje Trigger; después de la determinación de que el número aleatorio del mensaje Trigger es válido, utilizar el número aleatorio del mensaje Trigger para generar un Digest y realizar la autenticación del mensaje Trigger generado utilizando el número aleatorio del mensaje Trigger; después de la autenticación operativamente satisfactoria, enviar una demanda de sesión al servidor indicada por el mensaje Trigger.
La solución técnica anterior mejora efectivamente la seguridad del sistema.
Mediante la solución técnica anterior, el servidor y el cliente comparten un número aleatorio en el proceso de sesión en lugar del s_nonce y del c_nonce en la técnica anterior para poner en práctica la autenticación entre el cliente y el servidor, con lo que se libera efectivamente parte de la carga del sistema.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La Figura 1 es un diagrama de flujo de un método de autenticación en la técnica anterior;
La Figura 2 es un diagrama de flujo de utilización de un número aleatorio por defecto para la autenticación y actualización de s_nonce y c_nonce en la técnica anterior;
La Figura 3 es un diagrama de flujo de un método de autenticación en la forma de realización 1 de la presente invención;
La Figura 4 ilustra una estructura de un formato de mensaje después de que se añada un número aleatorio nonce;
La Figura 5 es un diagrama de flujo de un método de autenticación cuando el s_nonce es incorrecto en la forma de realización 1 de la presente invención;
La Figura 6 es un diagrama de flujo de un método de autenticación en la forma de realización 2 de la presente invención;
La Figura 7 es un diagrama de flujo de un método de autenticación en la forma de realización 4 de la presente invención;
La Figura 8 es un diagrama de flujo de un método de autenticación en la forma de realización 5 de la presente invención;
La Figura 9 es un diagrama de flujo de un método de autenticación en la forma de realización 6 de la presente invención;
La Figura 10 representa un formato de mensaje de respuesta de estado que transmite un nuevo s_nonce y en un método de autenticación en la forma de realización 7 de la presente invención,
La Figura 11 es un diagrama de flujo de un método de autenticación en la forma de realización 8 de la presente invención;
La Figura 12 es un diagrama de flujo de un método de autenticación en la forma de realización 9 de la presente invención;
La Figura 13 es un diagrama de flujo de un método de autenticación en la forma de realización 10 de la presente invención;
La Figura 14 representa una estructura de un sistema de autenticación en la forma de realización 1 de la presente invención;
La Figura 15 representa una estructura de un cliente en la forma de realización 1 de la presente invención;
La Figura 16 representa una estructura de un cliente en la forma de realización 2 de la presente invención y
La Figura 17 representa una estructura de un sistema de autenticación en la forma de realización 2 de la presente invención.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
Las formas de realización de la presente invención dan a conocer un método de autenticación basado en un protocolo DS o protocolo DM, un sistema, un servidor y un cliente para optimizar el proceso de autenticación que se realiza entre el cliente y el servidor y sobre la base del protocolo DS o protocolo DM.
El mecanismo de seguridad aplicado a la autenticación del mensaje en una sesión aquí mencionada, es un mecanismo de seguridad de capa de aplicación.
En el método de autenticación en la forma de realización 1 de la presente invención, el servidor genera un número aleatorio para el mensaje Trigger, en donde el número aleatorio es diferente del s_nonce y del c_nonce y está disponible para el mensaje Trigger. El número aleatorio puede denominarse un número aleatorio de mensaje Trigger. El servidor utiliza este número aleatorio para generar información de autenticación y envía el nuevo número aleatorio y la información de autenticación, junto con el mensaje Trigger, al cliente. El cliente utiliza el nuevo número aleatorio para la autenticación del mensaje Trigger.
Según se ilustra en la Figura 3, el método de autenticación en la forma de realización 1 de la presente invención comprende las etapas siguientes:
Etapa 301: El servidor envía un mensaje Trigger al cliente. El mensaje transmite un número aleatorio de mensaje Trigger.
Antes de enviar el mensaje Trigger, el servidor genera un número aleatorio de mensaje Trigger y utiliza este número aleatorio para generar un Digest y luego, utiliza el Digest para generar un mensaje Trigger.
En esta forma de realización, existen tres tipos de método de utilizar el número aleatorio del mensaje Trigger.
(1) Cuando se genera el mensaje Trigger, el servidor utiliza su propio tiempo del sistema (Ts) como un número aleatorio de mensaje Trigger y añade el tiempo Ts en el mensaje Trigger. Por lo tanto, después de recibir el mensaje Trigger, el cliente puede determinar la validez del número aleatorio comparando el tiempo local (Tc) con el tiempo del sistema (Ts). Para el número aleatorio, su validez se suele denominar freshness (carácter reciente) del número aleatorio nonce. Un número aleatorio reciente es válido y un número aleatorio no reciente no es válido.
Después de recibir el mensaje Trigger, el cliente calcula la diferencia entre Ts y Tc, esto es, |Ts-Tc|. Si el |Ts-Tc| es menor que un umbral preestablecido “Diff”, el número aleatorio del mensaje Trigger es válido; si el |Ts-Tc| no es menor que un umbral preestablecido “Diff”, el número aleatorio del mensaje Trigger no es válido.
El valor Diff umbral se suele configurar en el cliente y puede ser un valor empírico determinado en función de las condiciones de la red. Puesto que la propia red móvil no es estable y tiende a generar retardos de transmisión del mensaje de disparo Trigger. Umbrales demasiado pequeños tienden a hacer que no sea válido el número aleatorio del mensaje Trigger; si el umbral es demasiado grande, en el caso de un servidor operativamente malicioso intercepte el mensaje Trigger y conserve el mensaje para el cliente de forma repetida, el cliente considera los mensajes como información válida y los gestiona en tanto que el valor |Ts-Tc| caiga dentro del margen del umbral. Umbrales mayores son más vulnerables a los ataques.
(2) Antes de generar un mensaje Trigger, el servidor generar un identificador ID de sesión para el mensaje Trigger, en primer lugar, en conformidad con determinadas reglas. Las reglas le hacen factible para deducir el ID de sesión anterior a partir del ID de sesión actual. El ID de sesión sirve como un número aleatorio de mensaje Trigger. El servidor utiliza el número aleatorio para generar un Digest y utiliza el Digest para generar un mensaje Trigger.
Después de recibir el mensaje Trigger, el cliente extrae el identificador ID de sesión de la sesión a iniciarse por el mensaje Trigger y utiliza este identificador ID de sesión, el ID del servidor, la contraseña del servidor y otros campos del mensaje Trigger para generar un Digest para la autenticación del mensaje. Después de la autenticación operativamente satisfactoria, el cliente envía una demanda de sesión para establecer la sesión correspondiente al ID de sesión. El servidor extrae el ID de sesión desde la demanda de sesión para identificar dicha sesión.
Además, después de que el cliente extraiga el ID de sesión de la sesión a iniciarse por el mensaje Trigger, el cliente puede inferir el carácter reciente del ID de sesión en conformidad con las reglas de codificación del ID de sesión o el cliente memoriza los identificadores IDs de sesión utilizados y compara el ID de sesión del mensaje Trigger con los identificadores IDs de sesión memorizados para determinar sui carácter reciente.
En este método, el ID de sesión puede sustituirse por un ID de mensaje Trigger (NotificationID). Este ID de mensaje Trigger asocia el resultado del procesamiento del mensaje Trigger reenviado por el cliente con el mensaje Trigger.
(3) Cuando se genera el mensaje Trigger, el servidor numera cada mensaje Trigger y utiliza el número como un número aleatorio de mensaje Trigger exclusivo. El servidor utiliza el número aleatorio para generar un Digest y utiliza el Digest para generar un mensaje Trigger.
El número puede estar en orden ascendente o en orden descendente. Después de recibir un mensaje Trigger, el cliente compara el número aleatorio transmitido en el mensaje con el número aleatorio memorizado. En el caso de que el número esté en orden ascendente, si el nuevo número aleatorio es mayor, el número aleatorio es válido; en caso contrario, no es válido. En el caso de que el número esté en orden descendente, si el nuevo número aleatorio es más pequeño, el número aleatorio es válido y en caso contrario, no es válido.
Después de determinar que el nuevo número aleatorio es válido y de la autenticación satisfactoria del servidor, el cliente memoriza el nuevo número aleatorio, que está disponible para la comparación con el siguiente número aleatorio del mensaje Trigger.
En este método, si un servidor, operativamente malicioso, intercepta el mensaje Trigger y ataca al cliente enviando el mensaje al cliente de forma repetida, puesto que el número aleatorio utilizado por este mensaje Trigger ha sido registrado, todos los mensajes operativamente maliciosos se determinan como no válidos con lo que se impiden ataques procedentes de servidores operativamente maliciosos.
Además, debido a la inestabilidad de las redes móviles, el mensaje enviado más tarde puede llegar primero al cliente y los mensajes Trigger enviados por el servidor para diferentes sesiones pueden llegar al cliente en orden cambiado y en consecuencia, el cliente determina los mensajes válidos como mensajes no válidos de forma errónea.
A modo de ejemplo, el servidor envía 3 mensajes Trigger para 3 sesiones diferentes de forma consecutiva. El número aleatorio del mensaje Trigger utilizado por los 3 mensajes Trigger es 30, 31 y 32 respectivamente. Sin embargo, debido a la inestabilidad de las redes móviles, el cliente recibe primero el mensaje Trigger cuyo número aleatorio es 32. Por lo tanto, el cliente determina este mensaje como válido y registra este número aleatorio. Cuando los otros dos mensajes Trigger llegan al cliente, el cliente compara su número aleatorio con el número aleatorio registrado. Puesto que su número aleatorio es más pequeño que el número aleatorio registrado, el cliente determina, de forma errónea, que los mensajes no son válidos.
Para dichos problemas, las formas de realización de la presente invención ofrecen tres soluciones:
Solución 1: El cliente memoriza todos los valores de números aleatorios de mensajes Trigger o el último número aleatorio de mensaje Trigger recibido y compara el número aleatorio de mensaje Trigger determinado como no válido con el número aleatorio memorizado. Si el número aleatorio es diferente del número aleatorio memorizado, el cliente determina al número aleatorio como válido y lo memoriza.
Cuando el espacio de almacenamiento está limitado, se establece un espacio de almacenamiento y se suprime el número aleatorio mínimo memorizado cuando la cantidad de valores de números aleatorios memorizados alcanza el límite superior.
Solución 2: En el caso de que los valores de números aleatorios de mensajes Trigger estén numerados en un orden ascendente, el cliente memoriza el número aleatorio máximo recibido y la totalidad o parte de los valores de números aleatorios que son más pequeños que el valor máximo actual y no han sido recibidos; el cliente compara el número aleatorio de mensaje Trigger determinado como no válido con los valores de números aleatorios memorizados y, si el número aleatorio es diferente de los valores de números aleatorios memorizados, determina el número aleatorio como
válido y lo memoriza. En el caso de que los valores de números aleatorios de mensajes Trigger estén numerados en un orden descendente, el cliente memoriza el número aleatorio mínimo recibido y la totalidad o parte de los valores de números aleatorios que son mayores que el valor mínimo actual y no han sido recibidos; el cliente compara el número aleatorio del mensaje Trigger determinado como no válido con los valores de números aleatorios memorizados y, si el número aleatorio es diferente de los valores de números aleatorios memorizados, determina el número aleatorio como válido y lo memoriza.
A modo de ejemplo, se supone que el valor inicial es 1, el modo de numeración es el orden ascendente y el cliente recibe secuencialmente estos valores de números aleatorios de mensajes Trigger: 1, 2, 4, 5 y 7. En este caso, el cliente registra el número aleatorio máximo “7” y los valores de números aleatorios que son más pequeños que 7 y no han sido recibidos, esto es, “3” y “6”. Cuando el cliente recibe un número aleatorio de mensaje Trigger “6”, el cliente compara “6” con el valor máximo “7”. Puesto que 6 es menor que 7, el número aleatorio no es válido. A continuación, el cliente compara “6” con “3” y “6” y encuentra el mismo valor y por lo tanto, el cliente determina que el número aleatorio del mensaje Trigger es válido y suprime el “6” registrado. En el caso de que el modo de numeración esté en orden descendente, el método de determinación es similar y por ello no se repite en esta descripción.
Solución 3: En el caso de que los valores de números aleatorios de mensajes Trigger estén numerados en orden ascendente, el cliente memoriza el número aleatorio máximo y considera todos los mensajes Trigger cuyo número aleatorio sea menor que el número aleatorio máximo memorizado como no válidos. En el caso de que los valores de números aleatorios de mensajes Trigger estén numerados en orden descendente, el cliente memoriza el número aleatorio mínimo y considera a todos los mensajes Trigger cuyo número aleatorio sea mayor que el número aleatorio mínimo memorizado como no válidos. Si el servidor no recibe ninguna respuesta desde el cliente en un periodo de tiempo, el servidor genera un nuevo número aleatorio en conformidad con las reglas de numeración y envía el mensaje Trigger que transmite el nuevo número aleatorio.
Lo anteriormente descrito se refiere a un método de utilización de un número aleatorio de mensaje Trigger en una forma de realización de la presente invención.
Si el tiempo del sistema o el número de mensaje Trigger se utiliza como el número aleatorio del mensaje Trigger, el número aleatorio del mensaje Trigger puede transmitirse en la cabecera del mensaje o en el cuerpo del mensaje del mensaje Trigger. Tomando, a modo de ejemplo, la cabecera del mensaje, según se representa en la Figura 4, el formato del mensaje con un número aleatorio añadido comprende: un Digest, una cabecera de mensaje Trigger (Trigger-hdr) y un cuerpo de mensaje Trigger (Trigger-body).
La cabecera Trigger-hdr comprende: la versión, el modo de interacción del usuario (ui-mode), el iniciador de sesión, un número aleatorio, un campo reservado (uso-futuro), identificador ID de sesión, longitud del identificador del servidor (length-identifier) y el identificador del servidor.
Además, las formas de realización del a presente invención dan a conocer dos métodos de utilización de un número aleatorio de mensaje Trigger para generar un Digest:
Método 1: Supóngase H = MD5 como función Hashing y b64 = Base64 como función de codificación. El Digest puede expresarse como:
Digest = H(B64(H(identificador-servidor:contraseña)):nonce:B64(H(Trigger)),
en donde el campo del identificador del servidor es un identificador del servidor, el campo de la contraseña es una contraseña de servidor, el campo nonce es un número aleatorio de mensaje Trigger (esto es, el tiempo del sistema (Ts) o el identificador ID de sesión o el número de mensaje Trigger anteriormente citado) y el campo de Trigger incluye la cabecera Trigger-hdr y el cuerpo Trigger-body del mensaje Trigger.
Después de recibir el mensaje Trigger y de determinar que el número aleatorio del mensaje Trigger transmitido en el mensaje Trigger es válido, el cliente busca el árbol de gestión del cliente para la contraseña correspondiente al servidor. El cliente utiliza la contraseña encontrada, el identificador del servidor en el mensaje Trigger, el número aleatorio y el Trigger para generar un Digest y compara el Digest generado con el Digest transmitido en el mensaje. Si el Digest es el mismo, ello significa que la autenticación es operativamente satisfactoria; en caso contrario, falla la autenticación.
Método 2: Supóngase H = MD5 como función Hashing y b64 = Base64 como función de codificación.
Puesto que el número aleatorio de mensaje Trigger se transmite en la cabecera del mensaje o en el cuerpo del mensaje, el número aleatorio se hace parte del campo Trigger-hrd y del campo Trigger-body en el mensaje Trigger. Por lo tanto, para calcular el Digest, solamente necesita utilizarse el campo Trigger-hdr y el campo Trigger-body. El Digest puede expresarse como:
Digest = H(B64(H(identificador-servidor:contraseña)):B64(H(Trigger))),
en donde el campo del identificador del servidor es un identificador del servidor, el campo de contraseña es una contraseña de servidor y el campo de Trigger incluye la cabecera Trigger-hdr y el cuerpo Trigger-body del mensaje Trigger.
Después de recibir el mensaje Trigger y de determinar que el número aleatorio del mensaje Trigger transmitido en el mensaje Trigger es válido, el cliente busca el árbol de gestión del cliente para la contraseña correspondiente al servidor. El cliente utiliza la contraseña encontrada, el identificador del servidor en el mensaje Trigger y el Trigger para generar un Digest y compara el Digest generado con el Digest transmitido en el mensaje. Si el Digest es el mismo, la autenticación es operativamente satisfactoria y en caso contrario, falla la autenticación.
Etapa 302: El cliente determina que la información es válida, realiza la autenticación de la información de forma satisfactoria y luego, envía una demanda de sesión al servidor.
Después de recibir el mensaje Trigger, el cliente determina si el número aleatorio del mensaje Trigger, transmitido en el mensaje Trigger, es válido. El método de determinación es según se describió anteriormente. Si se determina que el número aleatorio del mensaje Trigger es válido, el cliente busca el árbol de gestión del cliente para la contraseña correspondiente al servidor. El cliente utiliza la contraseña encontrada, el identificador del servidor en el mensaje Trigger y el Trigger para generar un Digest y realiza la autenticación del mensaje Trigger. El método de autenticación detallado se describe en la etapa 301. El método de autenticación del cliente varía con el método de generación del Digest.
Después de la realización satisfactoria de la autenticación, el cliente envía una demanda de sesión al servidor para iniciar una sesión.
La demanda de sesión transmite: un identificador de sesión SessionID e información de autenticación (Authenticate) que incluye el Digest generado utilizando el c_nonce.
En esta etapa, se establece una conexión de sesión entre el cliente y el servidor.
Etapa 303: El servidor reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación.
En función de la información de autenticación enviada por el cliente, el servidor realiza la autenticación del cliente y luego, reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación al cliente.
Más concretamente, la respuesta transmite: un resultado de la autenticación por el servidor del cliente, un identificador de sesión SessionID e información de autenticación (Authenticate) que incluye el Digest generado utilizando el s_nonce.
Etapa 304: El cliente reenvía un mensaje que transmite el resultado de la autenticación al servidor.
Según la información de autenticación enviada por el servidor, el cliente realiza la autenticación del servidor y luego, reenvía un mensaje que transmite el resultado de la autenticación al servidor.
Más concretamente, este mensaje transmite: un resultado de la autenticación por el cliente del servidor y otra información pertinente.
Además, en el caso de que los valores de los números aleatorios del mensaje Trigger estén numerados en orden ascendente, con el aumento de los mensajes Trigger, el valor del número aleatorio será cada vez mayor; en el caso de que los valores de números aleatorios de mensajes Trigger estén numerados en orden descendente, con el aumento de los mensajes Trigger, el valor del número aleatorio disminuye hasta 0. En tales casos, necesita ajustarse el número aleatorio, a modo de ejemplo, necesita ajustarse el punto de inicio del conteo. Las formas de realización de la presente invención dan a conocer varios métodos de ajuste del valor del número aleatorio cuando sea necesario:
Método 1: El servidor actualiza su contraseña de cuenta en el cliente a intervalos. El servidor y el cliente pueden efectuar la reposición del valor del número aleatorio automáticamente cuando el servidor actualiza su contraseña de cuenta en el cliente.
Método 2: Cuando necesita ajustarse el número aleatorio (a modo de ejemplo, cuando llega el tiempo preestablecido o el conteo alcanza el valor preestablecido), el servidor emite una orden para la reposición del número aleatorio. La orden puede ser una orden Alert, a modo de ejemplo:
<Alert>
<CmdID>1</CmdID>
<Datos>1227</Datos><!-sustituir conteo número aleatorio->
</Alert>
Después de ajustar el número aleatorio, el servidor emite una orden para cambiar su contraseña de cuenta en el cliente, con lo que se impide la intercepción del mensaje y los ataques por servidores operativamente maliciosos.
Método 3: Puesto que el servidor puede operar directamente con el árbol de gestión del cliente, el servidor puede añadir un nodo en su información de cuenta en el árbol de gestión de cliente y utilizar el nodo para memorizar los valores de números aleatorios recibidos y retenidos por el cliente. El nodo puede ser:
<X>/AppAuth/<X>/SNNAAuthCount
En adelante, cuando necesite ajustarse el número aleatorio (a modo de ejemplo, cuando llegue el tiempo preestablecido
o el conteo alcance el valor preestablecido), el servidor emite una orden Replace (Sustituir) para el nodo. Una instancia operativa de la orden es como sigue:
<Replace>
<CmdID>4</CmdID>
<Item>
<Objetivo>
<LocURI>./DMAcc/servidorA/AppAuth/1/SNAAuthCount</LocURI>
</Objetivo>
<Datos>1</Datos>
</Item>
</Replace>
Después de ajustar el número aleatorio, el servidor emite una orden para cambiar su contraseña de cuenta en el cliente, con lo que se impide la intercepción de mensajes y los ataques por servidores operativamente maliciosos.
Método 4: Cuando necesite ajustarse el número aleatorio (a modo de ejemplo, cuando llegue el tiempo preestablecido o el conteo alcance el valor preestablecido), el cliente envía una demanda de Sustitución Replace al servidor. Después de que el cliente reciba una confirmación del servidor, ambas partes ajustan el número aleatorio. A la terminación del ajuste, el servidor actualiza su contraseña de cuenta en el cliente, con lo que se impide la intercepción de mensajes y los ataques por servidores operativamente maliciosos.
En el método de autenticación dado a conocer en la forma de realización 1 de la presente invención, un número aleatorio diferente del s_nonce y del c_nonce y disponible para el mensaje Trigger se proporciona en este momento. Una vez iniciada una nueva sesión, el servidor genera un número aleatorio para ser exclusivamente utilizado por el mensaje Trigger para iniciar una sesión. El cliente utiliza el número aleatorio para la autenticación del mensaje Trigger. Aún cuando el s_nonce memorizado por el servidor sea incorrecto, el cliente puede iniciar todavía una sesión. En este caso, si el s_nonce o el c_nonce es incorrecto, el s_nonce o el c_nonce puede actualizarse mediante una interacción para poner en práctica la autenticación.
Tomando, a modo de ejemplo, un s_nonce incorrecto, según se representa en la Figura 5, el método de autenticación dado a conocer en la forma de realización 1 de la presente invención, comprende las etapas siguientes:
Etapa 501: El servidor envía un mensaje Trigger al cliente. El mensaje transmite un número aleatorio de mensaje Trigger.
Antes del envío, el servidor genera un número aleatorio de mensaje Trigger y utiliza este número aleatorio para generar un Digest y luego, utiliza el Digest para generar un mensaje Trigger.
Etapa 502: El cliente determina que el número aleatorio del mensaje Trigger transmitido en el mensaje Trigger es válido, realiza la autenticación satisfactoria del mensaje y luego, envía una demanda de sesión al servidor.
Después de recibir el mensaje Trigger, el cliente determina si el número aleatorio del mensaje Trigger, transmitido en el mensaje Trigger, es válido. El método de determinación es según se describió anteriormente. Si se determina que el número aleatorio del mensaje Trigger es válido, el cliente busca el árbol de gestión del cliente para la contraseña correspondiente al servidor. El cliente utiliza la contraseña encontrada, el identificador del servidor en el mensaje Trigger y el Trigger para generar un Digest y realiza la autenticación del mensaje Trigger. El método de autenticación detallado se describe en la etapa 301. El método de autenticación del cliente varía con el método de generación del Digest.
Una vez realizada satisfactoriamente la autenticación, el cliente envía una demanda de sesión al servidor para iniciar una 5 sesión.
La demanda de sesión transmite: un identificador de sesión SessionID e información de autenticación (Authenticate) que incluye el Digest generado utilizando el c_nonce.
10 En esta etapa, se establece una conexión de sesión entre el cliente y el servidor.
Etapa 503: El servidor reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación.
15 En conformidad con la información de autenticación enviada por el cliente, el servidor realiza la autenticación del cliente y luego, reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación al cliente.
Más concretamente, la respuesta transmite: un resultado de la autenticación por el servidor del cliente, un identificador SessionID e información de autenticación (Authenticate) que incluye el Digest generado utilizando el s_nonce. 20 Etapa 504: El cliente utiliza el s_nonce memorizado para la autenticación del servidor, pero falla la autenticación.
Etapa 505: El cliente envía un mensaje Challenge y un mensaje de actualización de s_nonce al servidor.
25 Etapa 506: El servidor utiliza un nuevo s_nonce para generar información de autenticación y envía una demanda de autenticación al cliente de nuevo.
Después de recibir el mensaje de actualización, el servidor actualiza el s_nonce memorizado según se indica por el cliente, utiliza el s_nonce actualizado para generar una nueva demanda de autenticación y envía el resultado de la 30 actualización y la nueva demanda de autenticación al servidor.
Etapa 507: El cliente reenvía un mensaje que transmite el resultado de la autenticación al servidor.
En conformidad con la demanda de autenticación que se envía por el servidor y se genera utilizando el s_nonce 35 actualizado, el cliente realiza la autenticación del servidor y luego, reenvía un mensaje que transmite el resultado de la autenticación al servidor.
Más concretamente, este mensaje transmite: un resultado de la autenticación por el cliente del servidor y otra información pertinente.
40 En el método de autenticación dado a conocer en la forma de realización 1 de la presente invención, una vez que se inicia una nueva sesión, el servidor genera un número aleatorio exclusivamente disponible para el mensaje Trigger para iniciar una sesión. En el método de autenticación dado a conocer en la forma de realización 2 de la presente invención, el número aleatorio exclusivamente disponible para el mensaje Trigger, para iniciar una sesión, se genera solamente
45 cuando el servidor considera el s_nonce como incorrecto.
Según se ilustra en la Figura 6, el método de autenticación dado a conocer en la forma de realización 2 de la presente invención comprende las etapas siguientes:
50 Etapa 601: El servidor envía un mensaje Trigger al cliente. El mensaje transmite un s_nonce.
Etapa 602 El servidor descubre que falla la autenticación.
Si el servidor no recibe ningún mensaje enviado desde el cliente dentro de un periodo específico, el servidor considera 55 que ha fallado la autenticación.
Etapa 603: El servidor envía un nuevo mensaje Trigger al cliente. El mensaje transmite un número aleatorio de mensaje Trigger.
60 Antes del envío, el servidor genera un número aleatorio de mensaje Trigger y utiliza este número aleatorio para generar un Digest y luego, utiliza el Digest para generar un mensaje Trigger.
Etapa 604: El cliente determina que el número aleatorio del mensaje Trigger, transmitido en el mensaje Trigger es válido, realiza la autenticación satisfactoria del mensaje y luego, envía una demanda de sesión al servidor. 65
Después de recibir el mensaje Trigger, el cliente decide si utilizar el s_nonce o el número aleatorio del mensaje Trigger para la autenticación, determinando si el mensaje Trigger utiliza, o no, el número aleatorio de mensaje Trigger.
El método de determinación es: El cliente determina si el mensaje Trigger utiliza el número aleatorio del mensaje Trigger determinando si el mensaje Trigger incluye un campo de número aleatorio. Es decir, si el mensaje Trigger incluye un campo de número aleatorio, el mensaje Trigger utiliza el número aleatorio del mensaje Trigger. Como alternativa, el cliente determina si el mensaje Trigger utiliza el número aleatorio del mensaje Trigger determinando la información del campo de la versión en el mensaje Trigger. Es decir, puesto que la versión del mensaje revela si el mensaje utiliza, o no, el número aleatorio del mensaje Trigger.
Después de recibir el mensaje Trigger, el cliente determina si el número aleatorio del mensaje Trigger, transmitido en el mensaje Trigger, es, o no, válido. El método de determinación es según se describió anteriormente. Si se determina que el número aleatorio del mensaje Trigger es válido, el cliente busca el árbol de gestión del cliente para la contraseña correspondiente al servidor. El cliente utiliza la contraseña encontrada, el identificador del servidor en el mensaje Trigger y el Trigger para generar un Digest y realiza la autenticación del mensaje Trigger. El método de autenticación detallado se describe en la etapa 301. El método de autenticación del cliente varía con el método de generación del Digest.
Después de la autenticación operativamente satisfactoria, el cliente envía una demanda de sesión al servidor para iniciar una sesión.
La demanda de sesión transmite: un identificador SessionID e información de autenticación (Authenticate) que incluye el Digest generado utilizando el c_nonce.
En esta etapa, se establece una conexión de sesión entre el cliente y el servidor.
Etapa 605: El servidor reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación.
Esta etapa es similar a la etapa 503 y por ello no se detalla en esta descripción.
Etapa 606: El cliente utiliza el s_nonce memorizado para la autenticación del servidor, pero falla la autenticación.
Etapa 607: El cliente envía un mensaje que transmite una demanda Challenge y un nuevo s_nonce al servidor.
Etapa 608: El servidor reenvía un resultado de actualización y una nueva demanda de autenticación al cliente.
Esta etapa es similar a la etapa 506 y por ello no se detalla en esta descripción.
Etapa 609: El cliente reenvía un mensaje que transmite el resultado de la autenticación al servidor.
Esta etapa es similar a la etapa 507 y por ello no se detalla en esta descripción.
En el método de autenticación, dado a conocer en la forma de realización 2 de la presente invención, cuando el servidor considera que el s_nonce es incorrecto, el servidor genera un número aleatorio exclusivamente disponible para el mensaje Trigger para iniciar una sesión. El cliente procesa el mensaje Trigger en conformidad con el método de autenticación dado a conocer en la forma de realización 1 de la presente invención. En el método de autenticación dado a conocer en la forma de realización 3 de la presente invención, el cliente puede decidir si actualizar, o no, el s_nonce determinando si el mensaje Trigger utiliza el número aleatorio exclusivamente disponible para el mensaje Trigger. Si el mensaje Trigger utiliza el número aleatorio exclusivamente disponible para el mensaje Trigger, el cliente actualiza el s_nonce directamente, de modo que el servidor pueda utilizar directamente el s_nonce actualizado para la autenticación en la sesión.
En los métodos de autenticación dados a conocer en la primera y segunda formas de realización de la presente invención, cuando falla la autenticación, no se requiere ningún número aleatorio por defecto para poner en práctica la autenticación, con lo que se mejora la seguridad del sistema.
En el método de autenticación dado a conocer en la forma de realización 3 de la presente invención, los valores de s_nonce y el c_nonce se actualizan sobre la base de la técnica anterior y la contraseña del servidor y la contraseña del cliente se actualizan en consecuencia. La contraseña del servidor actualizada da lugar a un Digest del servidor diferente generado utilizando el número aleatorio por defecto e impide que el mensaje sea sensible a los ataques al cliente. La contraseña del cliente actualizada da lugar a un diferente Digest del cliente generado utilizando el número aleatorio por defecto, impide la reproducción de los ataques al servidor y mejora la seguridad del sistema.
En el método de autenticación dado a conocer en la forma de realización 4 de la presente invención, se refuerza la correlación entre etapas y la etapa anterior se utiliza como una base de autenticación de la siguiente etapa, con miras a
mejorar la seguridad del sistema. Según se ilustra en la Figura 7, el método de autenticación comprende las etapas siguientes:
Etapa 701: El cliente recibe un mensaje Trigger para iniciar una sesión y realiza la autenticación del mensaje.
Etapa 702: El cliente realiza la autenticación del mensaje Trigger de forma operativamente insatisfactoria y utiliza el número aleatorio por defecto para realizar una nueva autenticación.
Etapa 703: El cliente envía una demanda de sesión a un servidor, en donde la demanda de sesión se genera utilizando un número aleatorio por defecto.
Si la autenticación realizada utilizando el número aleatorio por defecto es satisfactoria, el cliente envía una demanda de sesión al servidor que se indica por el mensaje Trigger. Si la sesión utiliza el mecanismo de seguridad de capa de aplicación, el mensaje transmite la información de autenticación generada utilizando el número aleatorio por defecto y el proceso prosigue con la etapa 704. Si la autenticación realizada utilizando el número aleatorio por defecto falla operativamente, el cliente ignora el mensaje Trigger sin iniciar ninguna sesión y se finaliza el proceso.
Etapa 704: El servidor realiza la autenticación de la demanda de sesión enviada por el cliente.
El servidor realiza la autenticación de la demanda de sesión en dos métodos:
Método 1: El servidor utiliza un c_nonce para generar información de autenticación para la autenticación y, si la autenticación es satisfactoria, realiza el proceso normal según la técnica anterior. Si falla la autenticación, el servidor utiliza el número aleatorio por defecto para generar información de autenticación y realiza de nuevo la autenticación. Si la autenticación es satisfactoria, el servidor utiliza el número aleatorio por defecto para generar una demanda de autenticación del servidor y el proceso prosigue con la etapa 705.
Método 2: Si el servidor determina que la sesión utiliza el mecanismo de seguridad de la capa de aplicación, el servidor ha enviado el mensaje Trigger generado utilizando el número aleatorio por defecto al cliente y el mensaje Trigger es un mensaje Trigger para iniciar la demanda de sesión, el servidor utiliza el número aleatorio por defecto para realizar la autenticación de la demanda de sesión. Después de la autenticación operativamente satisfactoria, el proceso prosigue con la etapa 705.
El método de determinación de si una demanda de sesión se inicia, o no, por un mensaje Trigger es: Cada demanda de sesión tiene un identificador ID de sesión único. El identificador ID de sesión, transmitido en la demanda de sesión, se compara con el identificador ID de sesión transmitido en el mensaje Trigger. Si el identificador ID de sesión es el mismo, ello indica que la sesión se inicia por el mensaje Trigger.
La etapa de determinación de si el servidor ha enviado, o no, el mensaje Trigger generado utilizando el número aleatorio por defecto al cliente y si el mensaje Trigger es un mensaje Trigger para iniciar la demanda de sesión que puede producirse después de la demanda de sesión, es objeto de autenticación satisfactoria utilizando el número aleatorio por defecto. Después de la determinación satisfactoria, el proceso prosigue con la etapa 705.
La finalidad de esta etapa es: Si el servidor no ha enviado el mensaje Trigger que se genera utilizando el número aleatorio por defecto y diseñado para iniciar la sesión al cliente, pero recibe la demanda de sesión que se envía por el cliente y que se genera utilizando el número aleatorio por defecto, ello indica que el mensaje no es normal ni seguro y probablemente, es un mensaje fraudulento enviado por una tercera parte operativamente maliciosa y se puede rechazar. Por lo tanto, esta etapa mejora la seguridad del sistema.
Etapa 705: El servidor reenvía un mensaje de respuesta al cliente.
El servidor reenvía una respuesta que transmite el resultado de la autenticación, la demanda de autenticación y la orden para actualizar c_nonce al cliente.
Etapa 706: El cliente realiza la autenticación de respuesta enviada por el servidor.
Si la sesión utiliza el mecanismo de seguridad de capa de aplicación, el cliente utiliza un número aleatorio por defecto para la autenticación del servidor. El método de autenticación es: El cliente utiliza un s_nonce para generar información de autenticación para realizar la autenticación y, si la autenticación es satisfactoria, realiza el proceso normal según la técnica anterior. Si falla la autenticación, el cliente utiliza el número aleatorio por defecto para generar información de autenticación y realiza de nuevo la autenticación. Si la autenticación es satisfactoria, el cliente actualiza el c_nonce y el proceso prosigue con la etapa 707.
Una alternativa a esta etapa es: Si la sesión utiliza el mecanismo de seguridad de la capa de aplicación y el cliente ha enviado la demanda de sesión generada utilizando el número aleatorio por defecto al servidor, el cliente utiliza el número
aleatorio por defecto para la autenticación de la respuesta enviada por el servidor. Después de la autenticación operativamente satisfactoria, el cliente actualiza el c_nonce y el proceso prosigue con la etapa 707.
La etapa de determinación de si el cliente ha enviado, o no, la demanda de sesión generada utilizando el número aleatorio por defecto al servidor puede ocurrir después de que se realice la autenticación utilizando el número aleatorio por defecto. Después de la autenticación operativamente satisfactoria, se realiza la determinación. Después de la determinación satisfactoria, el proceso prosigue con la etapa 707.
Etapa 707: El cliente reenvía una respuesta al servidor.
El cliente reenvía una respuesta que transmite el resultado de la autenticación, el resultado de la actualización de c_nonce y la orden para actualizar s_nonce al servidor.
Etapa 708: El servidor reenvía un resultado de actualización de s_nonce al cliente.
Una vez terminada la etapa anterior, para impedir nuevos ataques, puede actualizarse la contraseña del servidor o, al mismo tiempo la contraseña del servidor y la contraseña del cliente se actualizan.
En la etapa anterior, el identificador ID de sesión puede servir como un número aleatorio o el identificador ID del mensaje Trigger puede servir como un número aleatorio en lugar del número aleatorio por defecto, con lo que se evita un número aleatorio público invariable y se consigue una mayor seguridad.
Los métodos de autenticación dados a conocer en la tercera y cuarta formas de realización de la presente invención, mejoran efectivamente la seguridad del sistema.
En la técnica anterior, cuando el s_nonce es incorrecto y necesita actualizarse, la orden necesita intercambiarse, por cuatro veces, para realizar la actualización, según se indica en las etapas 203-204 en la Figura 2. Puesto que el número aleatorio por defecto necesita utilizarse antes de que se actualice, el riesgo es alto. Con el mensaje intercambiándose en la red móvil numerosas veces, la carga de la red es más elevada.
Una solución técnica para añadir un nuevo s_nonce a la demanda de sesión enviada por el cliente se da a conocer en las formas de realización del método de autenticación aquí descrito. De este modo, el servidor puede actualizar directamente el s_nonce y utilizar el nuevo s_nonce para la autenticación, con lo que se reduce la frecuencia de interacción de señalización y la frecuencia de utilizar el número aleatorio por defecto, con lo que se mejora la seguridad del sistema y se reduce la carga de la red.
Según se representa en la Figura 8, un método de autenticación dado a conocer en la forma de realización 5 de la presente invención, comprende las etapas siguientes:
Etapa 801: El cliente conoce que necesita actualizarse un s_nonce.
El cliente determina que el s_nonce ha caducado o encuentra que el s_nonce memorizado en el servidor es diferente del memorizado en el cliente y por lo tanto, conoce que el s_nonce necesita actualizarse.
El cliente descubre una incoherencia entre el s_nonce memorizado en el servidor y el memorizado en el cliente en la forma siguiente:
Después de recibir el mensaje Trigger, el cliente utiliza el s_nonce memorizado para realizar la autenticación del mensaje Trigger. Si la autenticación falla por cualquier motivo, el cliente utiliza el número aleatorio por defecto o utiliza el identificador ID de sesión o el ID de mensaje Trigger como un número aleatorio para generar un Digest y se realiza la nueva autenticación del mensaje Trigger.
Si la autenticación es satisfactoria, ello indica que el s_nonce anteriormente utilizado por el servidor es incorrecto y el s_nonce memorizado en el servidor es diferente del memorizado en el cliente.
Etapa 802: El cliente envía una demanda de sesión que transmite información de actualización al servidor.
Después de conocer que el s_nonce necesita actualizarse, el cliente genera un nuevo s_nonce, añade el s_nonce a la demanda de sesión y envía la demanda de sesión al servidor, demandando al servidor que inicie una sesión y actualice el s_nonce.
La demanda de sesión transmite: un identificador SessionID, un s_nonce recientemente generado e información de autenticación (Authenticate) que incluye el Digest generado utilizando el c_nonce. En esta demanda de sesión, el número aleatorio por defecto o el identificador ID de sesión o el identificador ID de mensaje Trigger pueden utilizarse como un número aleatorio para generar el Digest.
El s_nonce recientemente generado puede transmitirse en una cabecera SyncHdr o cuerpo SyncBody de la demanda de sesión (SyncML). El método de transmisión se describe a continuación, suponiendo que el s_nonce recientemente generado se transmite 5 en un SyncHdr. Para la transmisión de s_nonce, el SyncHdr se modifica como sigue: SyncHdr (VerDTD, VerProto, SessionID, MsgID, Target, Source, RespURI?, NoResp?, Cred?, Chal?, Meta?)> El mensaje SyncML que transmite el s_nonce es: <SyncML xmlns =’SYNCML:SYNCML1.2’> 15 <SyncHdr> … <Chal> <Meta> <NextNonce xmlns= ‘syncml:metinf’> LG3iZQhhdmKNHg==</siguiente número aleatorio> 25 </Meta> </Chal> </SyncHdr> <SyncBody> … 35 </SyncBody>
</SyncML> Etapa 803: El servidor reenvía una respuesta que transmite el resultado de la autenticación, el resultado de la actualización y la demanda de autenticación.
Después de recibir la demanda de sesión, el servidor utiliza el c_nonce para la autenticación del cliente y utiliza el s_nonce actualizado, transmitido en la demanda de sesión, para actualizar el s_nonce memorizado. Después de la autenticación satisfactoria y de que se concluya la actualización, el servidor utiliza el s_nonce actualizado para generar
45 una demanda de autenticación y reenvía una respuesta que transmite el resultado de la autenticación, la orden de actualización y la demanda de autenticación al cliente. En una forma de realización preferida, el servidor utiliza un c_nonce para la autenticación de la demanda de sesión. Después de la autenticación satisfactoria, el servidor actualiza el s_nonce, con lo que se mantiene la sincronización entre el s_nonce memorizado en el servidor y el memorizado en el cliente.
Más concretamente, la respuesta transmite: un resultado de la autenticación por el servidor del cliente, un resultado de actualización de s_nonce e información de autenticación (Authenticate) que incluye el Digest generado utilizando el s_nonce actualizado.
55 Etapa 804: El cliente reenvía un mensaje que transmite el resultado de la autenticación al servidor.
El cliente utiliza el s_nonce actualizado para realizar la autenticación del servidor. Después de la autenticación operativamente satisfactoria, el cliente reenvía un resultado de autenticación al servidor. Además, el método de autenticación dado a conocer en la forma de realización 5 de la presente invención, puede
aplicarse al método de autenticación dado a conocer en la forma de realización 2 de la presente invención para reducir la frecuencia de interacción de señalización. Según se representa en la Figura 9, el método de autenticación dado a conocer en la forma de realización 6 de la 65 presente invención comprende las etapas siguientes:
Etapa 901: El servidor envía un mensaje Trigger al cliente. El mensaje transmite un s_nonce.
Etapa 902: El servidor descubre que falla la autenticación.
A modo de ejemplo, si el servidor no recibe ninguna demanda de sesión desde el cliente dentro de un periodo de tiempo específico, el servidor considera que ha fallado la autenticación.
Etapa 903: El servidor envía un mensaje Trigger al cliente. El mensaje transmite un número aleatorio de mensaje Trigger.
Antes del envío, el servidor genera un número aleatorio de mensaje Trigger y utiliza este número aleatorio para generar un Digest y luego, utiliza el Digest para generar un mensaje Trigger.
Etapa 904: El cliente descubre que necesita actualizarse un s_nonce.
Después de recibir el mensaje Trigger, el cliente determina si el mensaje Trigger utiliza el número aleatorio exclusivamente disponible para el mensaje Trigger y decide si necesita actualizarse el s_nonce. Como resultado, el cliente descubre que el mensaje Trigger utiliza el número aleatorio exclusivamente disponible para el mensaje Trigger y necesita actualizarse el s_nonce.
El método de determinación de si el mensaje Trigger utiliza, o no, el número aleatorio exclusivamente disponible para el mensaje Trigger es: El cliente determina si el mensaje Trigger utiliza el número aleatorio de mensaje Trigger determinando si el mensaje Trigger incluye, o no, un campo de número aleatorio. Es decir, si el mensaje Trigger incluye un campo de número aleatorio, el mensaje Trigger utiliza el número aleatorio del mensaje Trigger. Como alternativa, el cliente determina si el mensaje Trigger utiliza el número aleatorio de mensaje Trigger determinando la información del campo de la versión en el mensaje Trigger. Es decir, puesto que el campo de la versión revela si el mensaje utiliza, o no, el número aleatorio de mensaje Trigger.
Si el cliente descubre que el mensaje Trigger no utiliza el número aleatorio del mensaje Trigger, lo que indica que no necesita actualizarse el s_nonce y se realiza el proceso ordinario.
Etapa 905: El cliente envía una demanda de sesión que transmite información de actualización al servidor.
Después de recibir el mensaje Trigger y de determinar que el mensaje Trigger utiliza el número aleatorio de mensaje Trigger exclusivamente disponible para dicho mensaje Trigger, el cliente determina si el número aleatorio del mensaje Trigger, transmitido en el mensaje Trigger, es válido. El método de determinación se describió anteriormente. Si se determina que el número aleatorio de mensaje Trigger es válido, el cliente busca el árbol de gestión del cliente para la contraseña correspondiente al servidor. El cliente utiliza la contraseña encontrada, el identificador del servidor y el Trigger para generar un Digest y realiza la autenticación del mensaje Trigger. El método de autenticación detallado se describe en la etapa 301. El método de autenticación del cliente varía con el método de generación del Digest.
Después de la autenticación satisfactoria del mensaje Trigger, el cliente genera un nuevo s_nonce, añade el s_nonce a una demanda de sesión y envía la demanda de sesión que transmite información de actualización al servidor, demandando al servidor que inicie una sesión y actualice el s_nonce.
La demanda de sesión transmite: un identificador SessionID, un s_nonce actualizado e información de autenticación (Authenticate) que incluye el Digest generado utilizando el c_nonce.
El s_nonce recientemente generado puede transmitirse en el SyncHdr o SyncBoby de la demanda de sesión.
Etapa 906: El servidor reenvía una respuesta que transmite el resultado de la autenticación, el resultado de la actualización y la demanda de autenticación.
Después de recibir la demanda de sesión, el servidor utiliza el c_nonce para la autenticación del cliente y utiliza el s_nonce actualizado transmitido en la demanda de sesión, para actualizar el s_nonce memorizado. Después de la autenticación satisfactoria y de concluirse la actualización, el servidor utiliza el s_nonce actualizado para generar una demanda de autenticación y reenvía una respuesta que transmite el resultado de autenticación, el resultado de la actualización y la demanda de autenticación al cliente.
Más concretamente, la respuesta transmite: un resultado de la autenticación por el servidor para el cliente, un resultado de actualización de s_nonce e información de actualización (Authenticate) que incluye el Digest generado utilizando el s_nonce actualizado.
Etapa 907: El cliente reenvía un mensaje que transmite el resultado de la autenticación al servidor.
El cliente utiliza el s_nonce actualizado para realizar la autenticación del servidor. Después de la autenticación satisfactoria, el cliente reenvía un resultado de la autenticación al servidor.
Más concretamente, este mensaje transmite: un resultado de la autenticación del servidor y otra información pertinente.
En la técnica anterior, a veces, el cliente decide no iniciar la sesión después de la autenticación satisfactoria del servidor. En este caso, si el cliente descubre que el s_nonce caduca o es incorrecto y necesita actualizarse, resulta imposible actualizar el s_nonce o mantener efectivamente el s_nonce.
Por lo tanto, el método de autenticación en la forma de realización 7 de la presente invención da a conocer la solución correspondiente.
En el método de autenticación dado a conocer en la forma de realización 7 de la presente invención, después de que el cliente realice la autenticación del servidor satisfactoriamente y decida no iniciar una sesión, el cliente envía una respuesta de estado al servidor. Si el cliente determina que el s_nonce caduca o es incompatible con el s_nonce memorizado en el servidor, el cliente genera un nuevo s_nonce y añade el nuevo s_nonce en la respuesta del estado. El cliente utiliza el c_nonce, el nombre de usuario del cliente y su contraseña y el cuerpo del mensaje de respuesta para calcular el Digest. Por lo tanto, después de recibir la respuesta de estado, el servidor puede realizar la autenticación de la información en función del Digest calculado utilizando el c_nonce, el nombre de usuario del cliente y su contraseña y el cuerpo del mensaje de respuesta. Después de la autenticación satisfactoria, el servidor actualiza el s_nonce memorizado en función del nuevo s_nonce transmitido en la respuesta de estado.
Según se ilustra en la Figura 10, la respuesta de estado con el nuevo s_nonce comprende: un Digest, una cabecera de notificación (notification-hdr) y un cuerpo de notificación (notification-body).
La cabecera notification-hdr comprende: la versión, el código de estado operativo, el ID de notificación, el nuevo número aleatorio (Next-nonce), reservado (uso futuro>), ID de sesión (la longitud de SessionID del ID de autenticación (lenghtauthname) y el ID de autenticación (authname).
El NextNonce es el nuevo s_nonce.
En la técnica anterior, después de que el s_nonce sea incorrecto, el s_nonce y el c_nonce nunca se utilizarán de nuevo y el cliente y el servidor utilizan el número aleatorio por defecto para generar información de autenticación. En consecuencia, el servidor operativamente malicioso puede atacar al servidor o al cliente interceptando cualquier mensaje.
El s_nonce es diferente del c_nonce y se generan por el servidor y el cliente respectivamente y están disponibles en la parte opuesta. Por lo tanto, cuando uno de ellos es erróneo, el otro no resulta afectado. En los métodos de autenticación dados a conocer en la octava y novena forma de realización de la presente invención, se da a conocer una solución para actualizar el s_nonce por separado cuando el s_nonce es erróneo.
El s_nonce es erróneo si el cliente determina que ha caducado el s_nonce o descubre que el s_nonce memorizado en el servidor es erróneo, a modo de ejemplo, el cliente determina que el s_nonce memorizado en el servidor es incompatible
o asíncrono con el s_nonce memorizado en el cliente.
El método de determinación de la coherencia y sincronización entre el s_nonce memorizado en el servidor y el s_nonce memorizado en el cliente puede ser: El servidor no recibe ninguna respuesta del cliente dentro de un periodo de tiempo específico después de utilizar el s_nonce para enviar un mensaje Trigger o el cliente descubre que el mensaje Trigger enviado por el servidor transmite un Digest generado utilizando el número aleatorio por defecto o el cliente descubre que no se utiliza ningún número aleatorio en el mensaje Trigger enviado por el servidor.
Después de descubrir el error del s_nonce y la autenticación satisfactoria del servidor, el cliente inicia una demanda de sesión. En la demanda de sesión, la información de autenticación para la autenticación del cliente se genera utilizando el c_nonce o el modo de autenticación básico (esto es, nombre de usuario más contraseña) se aplica y el s_nonce se actualiza de nuevo.
Dos métodos de autenticación del s_nonce se dan a conocer en la forma de realización 7 y la forma de realización 8 del método de autenticación, respectivamente.
En la forma de realización 8, el servidor utiliza un número aleatorio por defecto para generar un mensaje Trigger. Según se representa en la Figura 11, el método de autenticación comprende las etapas siguientes:
Etapa 1101: El servidor envía un mensaje Trigger al cliente para iniciar una sesión.
Después de determinar que el s_nonce anterior es incorrecto, el servidor utiliza el número aleatorio por defecto para generar un mensaje Trigger y envía el mensaje al cliente. El mensaje Trigger transmite: el Digest generado utilizando el número aleatorio por defecto, la información TriggerInfo y otra información pertinente.
Etapa 1102: El cliente realiza la autenticación insatisfactoria del mensaje Trigger y utiliza el número aleatorio por defecto para realizar una nueva autenticación.
Después de recibir el mensaje Trigger, el cliente utiliza el s_nonce memorizado para generar un Digest y para la autenticación del mensaje Trigger. Si falla la autenticación por algún motivo, el cliente utiliza el nonce por defecto para generar un Digest y volver a realizar la autenticación del mensaje Trigger.
Si la autenticación es operativamente satisfactoria, ello indica que el s_nonce anteriormente utilizado por el servidor es incorrecto y el s_nonce memorizado en el servidor es diferente del memorizado en el cliente.
Etapa 1103: El cliente envía una demanda de sesión que transmite información de actualización al servidor.
Después de la autenticación satisfactoria del mensaje Trigger utilizando el número aleatorio por defecto, el cliente genera un nuevo s_nonce, añade el s_nonce a una demanda de sesión y envía la demanda de sesión que transmite información de actualización al servidor, demandando al servidor para que inicie una sesión y actualice el s_nonce.
La demanda de sesión transmite: un identificador SessionID, un s_nonce actualizado e información de autenticación (Authenticate) que incluye el Digest generado utilizando el c_nonce.
En la etapa anterior, el ID de sesión puede servir como un número aleatorio o el ID del mensaje Trigger puede servir como un número aleatorio en lugar del número aleatorio por defecto, con lo que se evita un número aleatorio público invariable y se consigue una mayor seguridad.
El método de añadir el s_nonce actualizado a la demanda de sesión es esencialmente el mismo que el descrito en la forma de realización 3 y la forma de realización 4 y por ello, no se repite con detalle en esta descripción.
Etapa 1104: El servidor reenvía una respuesta que transmite el resultado de la autenticación, el resultado de la actualización y la demanda de autenticación.
Después de recibir la demanda de sesión, el servidor utiliza el c_nonce para la autenticación del cliente y utiliza el s_nonce actualizado, transmitido en la demanda de sesión, para actualizar el s_nonce memorizado. Después de la autenticación satisfactoria y de concluirse la actualización, el servidor utiliza el s_nonce actualizado para generar una demanda de autenticación y reenvía una respuesta que transmite el resultado de la autenticación, el resultado de la actualización y la demanda de autenticación al cliente.
Más concretamente, la respuesta transmite: un resultado de la autenticación del servidor para el cliente, un resultado de actualización de s_nonce y la información de autenticación (Authenticate) que incluye el Digest generado utilizando el s_nonce actualizado.
Etapa 1105: El cliente reenvía un mensaje que transmite el resultado de la autenticación al servidor.
El cliente el s_nonce actualizado para la autenticación del servidor. Después de la autenticación satisfactoria, el cliente reenvía un resultado de la autenticación al servidor.
En la forma de realización 9, el servidor utiliza un número aleatorio por defecto para generar un mensaje Trigger, pero la demanda de sesión no transmite ninguna información de actualización. Según se ilustra en la Figura 12, el método de autenticación comprende las etapas siguientes:
Etapa 1201: El servidor envía un mensaje Trigger al cliente para iniciar una sesión.
Después de la determinación de que el s_nonce anterior es incorrecto, el servidor utiliza el número aleatorio por defecto para generar un mensaje Trigger y envía el mensaje al cliente. El mensaje Trigger transmite: el Digest generado utilizando el número aleatorio por defecto, la información TriggerInfo y otra información pertinente.
Etapa 1202: El cliente realiza la autenticación insatisfactoria del mensaje Trigger y utiliza el número aleatorio por defecto para una nueva autenticación.
Después de recibir el mensaje Trigger, el cliente utiliza el s_nonce memorizado para generar un Digest y para la autenticación del mensaje Trigger. Si falla la autenticación por cualquier motivo, el cliente utiliza el número aleatorio por defecto para generar un Digest y para una nueva autenticación del mensaje Trigger.
Si la autenticación es satisfactoria, ello indica que el s_nonce anteriormente utilizado por el servidor es incorrecto y el s_nonce memorizado en el servidor es diferente del memorizado en el cliente.
Etapa 1203: El cliente realiza la autenticación satisfactoria de la información y luego, envía una demanda de sesión al servidor.
Después de la autenticación satisfactoria, el cliente envía una demanda de sesión al servidor para iniciar una sesión.
La demanda de sesión transmite: un identificador SessionID y la información de autenticación (Authenticate) que incluye el Digest generado utilizando el c_nonce.
En esta etapa, se establece una conexión de sesión entre el cliente y el servidor.
Etapa 1204: El servidor reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación.
En conformidad con la información de autenticación enviada por el cliente, el servidor realiza la autenticación del cliente. Después de la autenticación satisfactoria, el cliente utiliza un número aleatorio por defecto para generar información de autenticación (Authenticate) y luego, reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación al cliente.
Más concretamente, la respuesta transmite: un resultado de la autenticación del servidor para el cliente, un identificador SessionID y la información de autenticación (Authenticate) que incluye el Digest generado utilizando el número aleatorio por defecto.
Etapa 1205: El cliente reenvía una orden de actualización y un resultado de la autenticación al servidor.
El cliente realiza la autenticación del servidor utilizando el número aleatorio por defecto. Después de la autenticación satisfactoria, el cliente genera un nuevo s_nonce y envía una orden para actualizar s_nonce y un resultado de la autenticación del servidor al servidor.
Etapa 1206: El servidor reenvía un resultado de actualización al cliente.
Después de recibir el mensaje de actualización, el servidor actualiza el s_nonce memorizado según se indica por el cliente y reenvía un resultado de la actualización al cliente.
En la etapa anterior, el ID de sesión puede servir como un número aleatorio o el ID del mensaje Trigger puede servir como un número aleatorio en lugar del número aleatorio por defecto, con lo que se evita un número aleatorio público invariable y se consigue una mayor seguridad.
En este caso, la contraseña del servidor puede actualizarse para mejorar la fiabilidad del sistema.
En otra forma de realización, el servidor utiliza un número aleatorio por defecto para generar un mensaje Trigger, pero la demanda de sesión no transmite ningún número aleatorio por defecto. El método de autenticación incluye las etapas siguientes:
Después de determinar que el s_nonce anterior es incorrecto, el servidor utiliza el número aleatorio por defecto o utiliza el identificador ID de sesión o el identificador ID de mensaje Trigger como un número aleatorio para generar un mensaje Trigger y envía el mensaje al cliente. El mensaje Trigger transmite: el Digest generado utilizando el número aleatorio por defecto o el ID de sesión o el dispositivo objetivo del mensaje Trigger, la información TriggerInfo y otra información pertinente.
Después de recibir el mensaje Trigger, el cliente utiliza el s_nonce memorizado para generar un Digest y la autenticación del mensaje Trigger. Si falla la autenticación por cualquier motivo, el cliente utiliza el número aleatorio por defecto o utiliza el ID de sesión o el ID de mensaje Trigger como un número aleatorio para generar un Digest y para una nueva autenticación del mensaje Trigger. Si la autenticación es satisfactoria, el cliente envía una demanda de sesión al servidor para iniciar una sesión. La demanda de sesión transmite: el identificador SessionID y la información de autenticación (Authenticate) que incluye el Digest generado utilizando el c_nonce.
El servidor utiliza el c_nonce para la autenticación de la demanda de sesión. Si falla la autenticación, el servidor envía un mensaje Challenge para actualizar el c_nonce y requerir la nueva autenticación. Después de la autenticación satisfactoria, el servidor envía una demanda de autenticación generada utilizando el s_nonce y el cliente utiliza el s_nonce para la autenticación. Si falla la autenticación, el cliente envía un mensaje Challenge para actualizar el s_nonce y requerir una nueva autenticación. Después de la autenticación satisfactoria, el cliente reenvía un resultado.
Además, en la etapa anterior, el cliente puede añadir el s_nonce actualizado a la demanda de sesión y enviar la demanda al servidor. La demanda de autenticación enviada por el servidor, utiliza el nuevo s_nonce.
Según se describió anteriormente, cuando el s_nonce es erróneo, solamente se actualiza s_nonce y no se actualiza el c_nonce. Cuando el sistema gestiona el error de s_nonce, aún cuando el sistema utilice un número aleatorio por defecto
o utilice el ID de sesión o el ID de mensaje Trigger como un número aleatorio para la autenticación, puesto que el c_nonce no necesita actualizarse, el cliente puede utilizar el c_nonce para generar una demanda de sesión, con lo que se reduce la frecuencia de utilización del número aleatorio por defecto o la utilización del ID de sesión o del ID de mensaje Trigger como un número aleatorio y se mejora la seguridad del sistema.
En la técnica anterior, el s_nonce y el c_nonce utilizados en una sesión se generan y actualizan por el cliente y el servidor respectivamente, con lo que se impone una mayor carga de gestión en el cliente y en el servidor.
En la forma de realización 10 de la presente invención, se utiliza un solo número aleatorio en una sesión para sustituir los s_nonce y c_nonce en la técnica anterior y para poner en práctica la autenticación entre el cliente y el servidor. La misma sesión está asegurada por un mecanismo de seguridad de capa de transmisión o un mecanismo de seguridad de aplicación y por lo tanto, el mismo número aleatorio se puede utilizar para poner en práctica la autenticación entre el cliente y el servidor.
El número aleatorio puede generarse por el servidor o el cliente. Suponiendo que el número aleatorio se genere por el servidor, el método de autenticación en la forma de realización 10 de la presente invención se elabora como sigue.
En la forma de realización 10, se dan a conocer dos métodos de actualización del número aleatorio, según se describe a continuación:
Método 1: El servidor actualiza el número aleatorio.
En primer lugar, el servidor emite una orden de actualización de número aleatorio (NextNonce). La orden NextNonce transmite un nuevo número aleatorio.
Después de recibir la orden NextNonce, el cliente utiliza el nuevo número aleatorio transmitido en la orden NextNonce para actualizar el número aleatorio memorizado.
La orden de actualización puede transmitirse en un mensaje de autenticación, esto es, el mensaje transmite la orden de actualización y la información de autenticación del servidor. La orden de actualización puede transmitirse también en otro mensaje de gestión, esto es, el mensaje no transmite la información de autenticación del servidor. Si la orden de actualización se transmite en el mensaje de autenticación, después de que el cliente reciba el mensaje, el cliente actualiza el número aleatorio en conformidad con la orden NextNonce y luego, utiliza el número aleatorio actualizado para generar un Digest y para la autenticación de la información. La autenticación es operativamente satisfactoria. En este caso, si un servidor operativamente malicioso intercepta el mensaje, dicho servidor puede iniciar ataques sobre el cliente en cualquier momento. Para impedir dichos ataques, cuando la orden NextNonce se transmite en el mensaje de autenticación, el cliente utiliza el Digest generado empleando el número aleatorio no actualizado para la autenticación de la información. Después de recibir el mensaje, el cliente utiliza el Digest generado empleando el número aleatorio no actualizado para la autenticación en primer lugar. Después de la autenticación satisfactoria, el cliente actualiza el número aleatorio memorizado en conformidad con la orden NextNonce. Si otro mensaje de gestión transmite la orden de actualización del número aleatorio, puesto que un mensaje que transmite el nuevo número aleatorio y otro mensaje que transmite la información de autenticación se envían a la parte opuesta por separado, no existe ningún riesgo de ataques para la reproducción.
Según se indica en la Figura 13, suponiendo que la respuesta se transmite en la orden NextNonce, el proceso es como sigue:
Etapa 1301: El servidor envía un mensaje Trigger al cliente para iniciar una sesión.
El mensaje Trigger transmite: un Digest generado utilizando el número aleatorio compartido y la información TriggerInfo.
El número aleatorio compartido se genera por el servidor y está disponible para el servidor y el cliente.
En la práctica, el número aleatorio compartido, en esta etapa, puede ser un número aleatorio de mensaje Trigger o número aleatorio por defecto. A veces, el servidor no puede utilizar un número aleatorio, sino que utiliza el ID del servidor y la contraseña para generar el mensaje Trigger para iniciar una sesión y el cliente utiliza el ID del servidor y su contraseña para generar un Digest para la autenticación del mensaje Trigger.
Etapa 1302: El cliente envía una demanda de sesión al servidor.
Después de recibir el mensaje Trigger, el cliente utiliza el s_nonce memorizado para generar un Digest y para la autenticación del mensaje Trigger. Si la autenticación es operativamente satisfactoria, el cliente envía una demanda de sesión al servidor para iniciar una sesión,.
La demanda de sesión transmite: un identificador SessionID y la información de autenticación (Authenticate) que incluye el Digest generado utilizando el número aleatorio compartido.
En esta etapa, se establece una conexión de sesión entre el cliente y el servidor.
Etapa 1303: El servidor envía una respuesta que transmite el resultado de autenticación y la demanda de autenticación y la respuesta transmite la orden NextNonce.
En conformidad con la información de autenticación enviada por el cliente, el servidor realiza la autenticación del cliente. Después de la autenticación satisfactoria, si el servidor descubre que necesita actualizarse el número aleatorio compartido, el servidor genera un nuevo número aleatorio compartido y luego, reenvía una respuesta que transmite el resultado de la autenticación y la demanda de autenticación al cliente. La respuesta transmite la orden NextNonce.
Más concretamente, la respuesta transmite: un resultado de la autenticación del servidor para el cliente, un identificador SessionID, información de autenticación (Authenticate) que incluye el Digest generado utilizando el número aleatorio no actualizado y una orden NextNonce que incluye el nuevo número aleatorio.
Etapa 1304: Después de recibir la respuesta, el cliente utiliza el número aleatorio no actualizado para la autenticación del
mensaje.
Etapa 1305: La autenticación es operativamente satisfactoria y el cliente utiliza el nuevo número aleatorio transmitido en
la orden NextNonce para actualizar el número aleatorio compartido memorizado según se indica por la orden NextNonce.
Etapa 1306: El cliente reenvía un mensaje que transmite el resultado de la autenticación y el resultado de la actualización
al servidor.
Más concretamente, este mensaje transmite: un resultado de la autenticación del cliente para el servidor, un resultado de
la actualización del número aleatorio compartido y otra información pertinente.
El servidor y el cliente pueden definir el periodo de validez del número aleatorio compartido de forma diferente. Cuando el servidor determina que el número aleatorio compartido es válido, el periodo de validez del número aleatorio compartido puede haber finalizado para el cliente. Por lo tanto, para mantener la validez del número aleatorio compartido para el cliente, la forma de realización 10 de la presente invención da a conocer una solución técnica en la que el cliente demanda al servidor para actualizar el número aleatorio compartido.
El cliente puede utilizar la orden Alert entre las órdenes DM para demandar al servidor que actualice el número aleatorio compartido. Para hacer que el servidor entienda la orden, se añade un tipo de alerta en la orden. El tipo de Alerta es una indicación de solicitar al servidor la actualización del número aleatorio.
Cuando el cliente cree que necesita actualizarse el número aleatorio, el cliente envía una demanda de actualización del número aleatorio compartido al servidor a través de la orden Alert. La demanda puede transmitirse en el mensaje de autenticación u otro mensaje de gestión. Después de recibir la demanda, el servidor decide si actualizar, o no, el número aleatorio según las condiciones específicas.
El tipo de Alerta puede definirse como: org.openmobilealliance.NextNonce.
A continuación, se proporciona una instancia operativa de un mensaje del tipo Alerta:
<Alert>
<CmdID>2</CmdID>
<Datos>1226</Datos><!-- Alerta genérica -->
<Item>
<Meta>
<Type xmlns= “syncml:metinf”>
org.openmobilealliance.NextNonce
</Tipo>
</Meta>
<Datos/>
</Item>
</Alerta> El método de la actualización del cliente del número aleatorio es similar al método del servidor para actualizar el número aleatorio y por ello no se repite en esta descripción.
Método 2: El servidor y el cliente actualizan conjuntamente el número aleatorio.
El servidor y el cliente pueden generar un nuevo número aleatorio para su actualización cuando determinen que necesita actualizarse el número aleatorio compartido.
El número aleatorio puede actualizarse mediante una orden NextNonce. A continuación se proporciona una instancia operativa de actualización:
<Chal>
<Meta>
<NextNonce xmlns= ‘syncml:metinf’>LG3iZQhhdmKNHg==</NextNonce>
</Meta>
</Chal>
La orden NextNonce puede transmitirse en un mensaje en el proceso de sesión. A modo de ejemplo, el cliente puede añadir la orden NextNonce a una demanda de sesión y enviar la demanda de sesión al servidor, solicitando al servidor que actualice el número aleatorio compartido o que añade la orden NextNonce en otro mensaje.
Sin importar que el servidor o el cliente actualice, o no, el número aleatorio compartido, si la orden de actualización se transmite en el mensaje de autenticación, después de que la parte opuesta reciba el mensaje, la parte opuesta actualiza primero el número aleatorio y luego, utiliza el número aleatorio actualizado para generar un Digest y para la autenticación de la información. La autenticación es así operativamente satisfactoria. En este caso, si un servidor operativamente malicioso intercepta el mensaje, dicho servidor puede iniciar ataques de reproducción sobre el cliente en cualquier momento. Para evitar dichos ataques, cuando la orden NextNonce se transmita en el mensaje de autenticación, la parte opuesta puede utilizar el Digest generado utilizando el número aleatorio no actualizado para la autenticación de la información. Después de la autenticación operativamente satisfactoria, la parte opuesta actualiza el número aleatorio memorizado en conformidad con la orden NextNonce. Si otro mensaje de gestión transmite la orden de actualización de número aleatorio, puesto que un mensaje que transmite el nuevo número aleatorio y otro mensaje que transmite la información de autenticación se envían por separado a la parte opuesta, no existe ningún riesgo de ataques.
En la forma de realización 10 de la presente invención, el servidor y el cliente utilizan un número aleatorio compartido para la autenticación. En este caso, si el número aleatorio compartido es erróneo, el error puede gestionarse mediante cualquiera de los métodos anteriormente descritos. En la etapa 803, en la forma de realización 5 de la presente invención, el mensaje transmite un nuevo número aleatorio, un Digest generado utilizando el nuevo número aleatorio. En este caso, si un servidor, operativamente malicioso, intercepta el mensaje, dicho servidor puede iniciar un ataque enviando el mensaje al servidor o al cliente, de forma repetida. El servidor o el cliente es incapaz de identificar el mensaje, cree que el mensaje es válido y realiza las operaciones correspondientes. Para evitar dichos ataques, el número aleatorio no actualizado puede utilizarse para generar un Digest. De este modo, después de recibir el mensaje, el servidor utiliza el número aleatorio no actualizado para calcular el Digest y para la autenticación del remitente del mensaje, esto es, el cliente y luego, actualiza el número aleatorio memorizado en conformidad con la orden NextNonce.
La forma de realización 10 de la presente invención libera efectivamente la carga de trabajo del sistema.
Según se indica en la Figura 14, un sistema de autenticación dado a conocer en la forma de realización 1 de la presente invención comprende:
un servidor 1410, adaptado para: utilizar el número aleatorio del mensaje Trigger para generar un mensaje Trigger y para enviar el mensaje Trigger generado y
un cliente 1420, adaptado para: recibir el mensaje Trigger generado utilizando el número aleatorio de mensaje Trigger y para utilizar el número aleatorio del mensaje Trigger para efectuar la autenticación del mensaje Trigger generado, esto es, verificar la validez del mensaje Trigger.
El servidor 1410 comprende, además:
una primera unidad de generación 1412, adaptada para generar un mensaje Trigger utilizando un número aleatorio de mensaje Trigger;
una unidad de envío 1411, adaptada para enviar el mensaje Trigger generado utilizando el número aleatorio del mensaje Trigger;
una segunda unidad de generación 1417, adaptada para: generar un mensaje Trigger utilizando un número aleatorio de servidor y para enviar el mensaje Trigger generado al cliente;
una unidad de determinación 1413, adaptada para controlar la primera unidad de generación 1412 para utilizar el número aleatorio de mensaje Trigger para generar un mensaje Trigger después de determinar que el mensaje Trigger generado utilizando el número aleatorio del servidor tiene una autenticación operativamente insatisfactoria;
una unidad de tiempo 1414, adaptada para: determinar el tiempo del sistema del servidor cuando la primera unidad de generación 1412 utiliza el número aleatorio de mensaje Trigger para generar un mensaje Trigger y para añadir el tiempo del sistema en el mensaje Trigger generado utilizando el número aleatorio del mensaje Trigger;
una unidad de codificación 1415, adaptada para: numerar los mensajes Trigger generados por la primera unidad de generación 1412 utilizando el número aleatorio de mensaje Trigger y empleando el número como el número aleatorio de mensaje Trigger;
una unidad de restablecimiento de número aleatorio 1416, adaptada para el restablecimiento del número aleatorio de mensaje Trigger generado por la unidad de codificación 1415 cuando sea necesario y
una unidad de ID de sesión para número aleatorio 1418 adaptada para: utilizar el ID de sesión de la sesión iniciada por el mensaje Trigger como un número aleatorio de mensaje Trigger, de modo que el cliente realice la autenticación del mensaje Trigger utilizando el número aleatorio de mensaje Trigger después de recibir el mensaje Trigger y envía una demanda de sesión para demandar el establecimiento de una sesión correspondiente al ID de sesión después de la autenticación operativamente satisfactoria.
La unidad de codificación 1415 comprende, además:
una unidad de numeración en orden ascendente 14151, adaptada para numerar los mensajes Trigger generados utilizando el número aleatorio de mensaje Trigger en orden ascendente y
una unidad de numeración en orden descendente 14152, adaptada para numerar los mensajes Trigger generados utilizando el número aleatorio de mensaje Trigger en orden descendente.
El cliente 1420 comprende, además:
una unidad de recepción 1421, adaptada para recibir el mensaje Trigger generado utilizando el número aleatorio de mensaje Trigger;
una primera unidad de autenticación 1422, adaptada para: utilizar el número aleatorio de mensaje Trigger para la autenticación del mensaje Trigger generado empleando el número aleatorio de mensaje Trigger, esto es, verificar la validez del mensaje Trigger generado utilizando el número aleatorio de mensaje Trigger;
una segunda unidad de ate 1425, adaptada para utilizar el número aleatorio del servidor para la autenticación del mensaje Trigger después de recibir el mensaje Trigger y, si falla la autenticación, emplear el número aleatorio de mensaje Trigger para una nueva autenticación del mensaje Trigger;
una primera unidad de determinación de la validez 1423, adaptada para: determinar el tiempo local del cliente cuando la unidad de recepción 1421 recibe el mensaje Trigger generado utilizando el número aleatorio de mensaje Trigger y para comparar el valor absoluto de la diferencia entre el tiempo local y el tiempo del sistema con un umbral preestablecido; si el valor absoluto es menor que el umbral preestablecido, para determinar que el número aleatorio de mensaje Trigger es válido y para controlar la primera unidad de autenticación 1422 para utilizar el número aleatorio de mensaje Trigger para la autenticación del mensaje Trigger generado utilizando el número aleatorio de mensaje Trigger;
una segunda unidad de determinación de la validez 1424, adaptada para: memorizar el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger si se determina que el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger es válido en conformidad con el mensaje Trigger memorizado después de que la unidad de recepción 1421 reciba el mensaje generado utilizando el número aleatorio de mensaje Trigger y para controlar la primera unidad de autenticación 1422 para utilizar el número aleatorio de mensaje Trigger para la autenticación del mensaje Trigger generado empleando el número aleatorio de mensaje Trigger y
una unidad de identificador ID de sesión para número aleatorio 1428, adaptada para: utilizar el ID de sesión de la sesión iniciada por el mensaje Trigger como un número aleatorio de mensaje Trigger para la autenticación del mensaje Trigger empleando el número aleatorio de mensaje Trigger y para enviar una demanda de sesión para solicitar el establecimiento de una sesión correspondiente al ID de sesión después de la autenticación operativamente satisfactoria.
La segunda unidad de determinación de la validez 1424 comprende:
una primera unidad de determinación de la numeración 14241, adaptada para: comparar el número aleatorio de mensaje Trigger memorizado en el cliente con el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger y para determinar que el número aleatorio de mensaje Trigger, transmitido en el mensaje Trigger, es válido, si el número aleatorio de mensaje Trigger, transmitido en el mensaje Trigger, es mayor que el número aleatorio de mensaje Trigger máximo memorizado en el cliente o si los valores del número aleatorio de mensaje Trigger que han sido recibidos y memorizados por el cliente no incluyen el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger o si los valores de los números aleatorios que no se han recibido por el cliente incluyen el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger y
una segunda unidad de determinación de la numeración 14242, adaptada para: comparar el número aleatorio de mensaje Trigger memorizado en el cliente con el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger y para determinar que el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger es válido si el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger es menor que el número aleatorio de mensaje Trigger mínimo memorizado en el cliente o si los valores de los números aleatorios de mensajes Trigger que se han recibido y memorizado por el cliente no incluyen el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger o si los valores de números aleatorios que no se han recibido por el cliente incluyen el número aleatorio de mensaje Trigger transmitido en el mensaje Trigger.
El modo de funcionamiento del sistema de autenticación en la forma de realización 1, es similar al modo operativo del método de autenticación en la forma de realización 1 y en la forma de realización 2 de la presente invención y no se repite por ello en esta descripción.
Por intermedio del sistema de autenticación dado a conocer en la forma de realización 1 de la presente invención, cuando falla la autenticación, no se requiere ningún número aleatorio por defecto para poner en práctica la autenticación, con lo que se mejora la seguridad del sistema.
El servidor dado a conocer en la forma de realización 1 de la presente invención es básicamente el mismo que el servidor en el sistema de autenticación dado a conocer en la forma de realización 1 de la presente invención y no se repite por ello en esta descripción.
Según se ilustra en la Figura 15, el cliente, dado a conocer en la forma de realización 1 de la presente invención comprende:
una unidad de recepción 1501, adaptada para recibir un mensaje Trigger enviado por el servidor;
una primera unidad de generación 1512, adaptada para: generar un nuevo número aleatorio de servidor si se determina que el número aleatorio del servidor necesita actualizarse después de recibir el mensaje Trigger, para añadir el nuevo número aleatorio de servidor a una demanda de sesión y para enviar la demanda de sesión al servidor, de modo que el servidor pueda utilizar el nuevo número aleatorio de servidor para actualizar el número aleatorio de servidor memorizado después de recibir la demanda de sesión que transmite el nuevo número aleatorio de servidor y
una segunda unidad de generación 1503, adaptada para: generar un nuevo número aleatorio de servidor si se decide no iniciar una sesión y la determinación de que necesita actualizarse el número aleatorio de servidor después de recibir el mensaje Trigger, para añadir el nuevo número aleatorio de servidor en una respuesta de estado y para enviar la respuesta de estado al servidor, de modo que el servidor pueda utilizar el nuevo número aleatorio de servidor para actualizar el número aleatorio de servidor memorizado después de recibir la respuesta de estado que transmite el nuevo número aleatorio de servidor.
El modo operativo del cliente, dado a conocer en la forma de realización 1, es similar al modo operativo del cliente en el método de autenticación dado a conocer en la cuarta, quinta y sexta formas de realización de la presente invención y por ello no se repite en esta descripción.
A través del cliente dado a conocer en la forma de realización 1 de la presente invención, cuando necesita actualizarse el s_nonce, la demanda de sesión transmite directamente una orden de actualización, con lo que se reduce la frecuencia de interacción de señalización, se reduce la carga de trabajo del sistema, se disminuye la frecuencia de utilización del número aleatorio por defecto para realizar la autenticación y se mejora la seguridad del sistema.
Según se ilustra en la Figura 16, el cliente 1600 dado a conocer en la forma de realización 2 de la presente invención comprende:
una unidad de recepción 1601, adaptada para recibir un mensaje Trigger enviado por el servidor;
una unidad de generación 1602, adaptada para: utilizar un número aleatorio de servidor para la autenticación del mensaje Trigger después de recibir el mensaje Trigger; si falla la autenticación, para utilizar el número aleatorio por defecto para la autenticación del mensaje Trigger; después de la autenticación operativamente satisfactoria, para utilizar
un número aleatorio de cliente para generar una demanda de sesión y para enviar la demanda de sesión al servidor, de modo que el servidor pueda utilizar el número aleatorio del cliente para la autenticación del cliente y
una unidad de cambio de contraseña 1603, adaptada para cambiar la contraseña del servidor y la contraseña del cliente después de la actualización del número aleatorio del servidor con el nuevo número aleatorio del servidor.
El modo operativo del cliente dado a conocer en la forma de realización 2 es similar al modo operativo del cliente en el método de autenticación dado a conocer en la séptima y octava formas de realización de la presente invención y por ello, no se repite en esta descripción.
A través del cliente dado a conocer en la forma de realización 2 de la presente invención, cuando necesita actualizarse s_nonce, solamente se actualiza el s_nonce y no se actualiza el c_nonce. Aún cuando el sistema utilice el número aleatorio por defecto para la autenticación cuando se gestiona el error de s_nonce, puesto que el c_nonce no necesita actualizarse, el cliente puede utilizar el c_nonce para generar una demanda de sesión, con lo que se reduce la frecuencia de utilización del número aleatorio por defecto y se mejora la seguridad del sistema.
Según se indica en la Figura 17, un sistema de autenticación dado a conocer en la forma de realización 2 de la presente invención incluye un servidor 1710 y un cliente 1720.
El servidor 1710 comprende, además:
una unidad de disparo operativo 1711, adaptada para: utilizar un número aleatorio compartido por el servidor y el cliente para generar un mensaje Trigger y para enviar el mensaje Trigger al cliente, de modo que el cliente pueda utilizar el número aleatorio compartido para la autenticación del mensaje Trigger después de recibir el mensaje Trigger;
una unidad de recepción 1712, adaptada para recibir la demanda de sesión generada utilizando el número aleatorio compartido desde el cliente;
una unidad de autenticación 1713, adaptada para la autenticación de la demanda de sesión utilizando el número aleatorio compartido;
una unidad de generación 1714, adaptada para: utilizar un número aleatorio compartido para generar una respuesta después de que se realice la autenticación satisfactoria de la demanda de sesión y para enviar la respuesta al cliente, de modo que el cliente puede utilizar el número aleatorio compartido para la autenticación de la respuesta después de recibir dicha respuesta;
una unidad de actualización 1715, adaptada para: generar un número aleatorio compartido; cuando necesite actualizarse el número aleatorio compartido, para generar un nuevo número aleatorio compartido y para enviar un mensaje de actualización de número aleatorio que transmita el nuevo número aleatorio compartido al cliente, de modo que el cliente pueda utilizar el nuevo número aleatorio compartido para actualizar el número aleatorio compartido después de recibir el mensaje de actualización del número aleatorio y
una unidad de demanda 1716, adaptada para: cuando se determine que necesita actualizarse el número aleatorio compartido, para enviar una demanda de actualización de número aleatorio al cliente, de modo que el cliente pueda generar un nuevo número aleatorio compartido después de recibir la demanda de actualización de número aleatorio y para decidir la actualización del número aleatorio y para enviar un mensaje de actualización del número aleatorio que transmite el nuevo número aleatorio compartido.
El cliente 1720 comprende, además:
una unidad de recepción 1721, adaptada para recibir el mensaje Trigger que se envía por el servidor y se genera utilizando el número aleatorio compartido por el servidor y el cliente;
una primera unidad de autenticación 1722, adaptada para la autenticación del mensaje Trigger utilizando el número aleatorio compartido después de la recepción del mensaje Trigger;
una unidad de generación 1723, adaptada para: utilizar un número aleatorio compartido para generar una demanda de sesión después de la autenticación operativamente satisfactoria y para enviar la demanda de sesión al servidor, de modo que el servidor pueda utilizar el número aleatorio compartido para la autenticación de la demanda de sesión después de recibir la demanda de sesión, esto es, para verificar la validez de la demanda de sesión;
una segunda unidad de autenticación 1724, adaptada para utilizar el número aleatorio compartido para la autenticación de la respuesta después de recibir la respuesta generada por el servidor utilizando el número aleatorio compartido;
una unidad de actualización 1725, adaptada para: generar un número aleatorio compartido; cuando necesite actualizarse el número aleatorio compartido, para generar un nuevo número aleatorio compartido y para enviar un mensaje de actualización de número aleatorio que transmita el nuevo número aleatorio compartido al servidor, de modo que el servidor pueda utilizar el nuevo número aleatorio compartido para actualizar el número aleatorio compartido después de recibir el mensaje de actualización del número aleatorio y
5 una unidad de demanda 1726, adaptada para: cuando se determine que necesita actualizarse el número aleatorio, para enviar una demanda de actualización del número aleatorio al servidor, de modo que el servidor pueda generar un nuevo número aleatorio compartido después de recibir la demanda de actualización de número aleatorio y para decidir actualizar el número aleatorio y enviar un mensaje de actualización de número aleatorio que transmita el nuevo número aleatorio compartido.
10 El modo operativo del sistema de autenticación, en la forma de realización 2, es similar al modo operativo del método de autenticación en la forma de realización 9 de la presente invención y por ello, no se repite en esta descripción.
A través del sistema de autenticación dado a conocer en la forma de realización 2 de la presente invención, el servidor y
15 el cliente comparten un número aleatorio en el proceso de sesión en lugar de s_nonce y del c_nonce en la técnica anterior para poner en práctica la autenticación entre el cliente y el servidor, con lo que se libera efectivamente la carga de trabajo del sistema.
El servidor dado a conocer en la forma de realización 2 de la presente invención y el cliente dado a conocer en la forma
20 de realización 3 de la presente invención son esencialmente el mismo que el servidor y el cliente en el sistema de autenticación dado a conocer en la forma de realización 2 de la presente invención y por ello no se repiten en esta descripción.
Es comprensible para los expertos en esta técnica que la totalidad o parte de las etapas de las formas de realización
25 anteriores pueden ponerse en práctica por hardware bajo las instrucciones de un programa informático. El programa puede memorizarse en un medio de almacenamiento legible por ordenador. El medio de memorización puede ser una Memoria de Solamente Lectura (ROM), un disco magnético o un Disco Compacto (CD).
Lo que antecede es un método de autenticación basado en un protocolo DS o un protocolo DM, un sistema, un servidor y
30 un cliente bajo la presente invención. Aunque la invención se describe a través de algunas formas de realización, a modo de ejemplo, la invención no está limitada a dichas formas de realización. Es evidente para los expertos en esta técnica que se pueden realizar modificaciones y variaciones a la invención sin desviarse por ello del alcance de protección de la invención. La invención cubrirá las modificaciones y variaciones a condición de que caigan dentro del alcance de protección definido por las siguientes reivindicaciones o sus equivalentes.
Claims (6)
- REIVINDICACIONES1. Un método de autenticación basado en el protocolo de Sincronización de Datos, DS, o de Gestión de Dispositivo, DM, estando dicho método caracterizado por cuanto que comprende:la recepción (301), por un cliente, de un mensaje de disparo operativo procedente de un servidor que utiliza un número aleatorio del mensaje de disparo operativo para generar el mensaje de disparo;la extracción, por el cliente, del número aleatorio de mensaje de disparo operativo;la utilización (302), por el cliente, del número aleatorio de mensaje de disparo operativo con el fin de generar un extracto de acceso y la autenticación del mensaje de disparo operativo generado utilizando el número aleatorio de mensaje de disparo operativo después de determinar que dicho número aleatorio de mensaje de disparo es válido yel envío (302), por el cliente, de una demanda de sesión al servidor indicado por el mensaje de disparo operativo después de la realización satisfactoria de la autenticación, en donde la demanda de sesión soporta un identificador ID de sesión.
- 2. El método según la reivindicación 1, caracterizado por cuanto que, antes de utilizar el número aleatorio de mensaje de disparo operativo para generar un mensaje de disparo, el método comprende, además:la utilización, por el servidor, de un número aleatorio de servidor para generar un mensaje de disparo operativo;el envío, por el servidor, del mensaje de disparo operativo generado utilizando el número aleatorio del servidor al cliente yla utilización, por el servidor, del número aleatorio de mensaje de disparo operativo para generar el mensaje de disparo después de determinar que el mensaje de disparo generado mediante el uso del número aleatorio del servidor es objeto de autenticación insatisfactoria.
- 3. El método según la reivindicación 1 o 2, caracterizado por cuanto que un tiempo de sistema del servidor se utiliza por el servidor como el número aleatorio de mensaje de disparo operativo y se transmite en el mensaje de disparo;el cliente determina si el número aleatorio de mensaje de disparo operativo es válido comparando un tiempo local del cliente con el número aleatorio de mensaje de disparo operativo después de recibir el mensaje de disparo generado utilizando el número aleatorio de mensaje de disparo operativo yel cliente utiliza el número aleatorio de mensaje de disparo operativo para generar un extracto de acceso y autenticar el mensaje de disparo generado utilizando el número aleatorio de mensaje de disparo operativo con el empleo del extracto de acceso después de determinar que el número aleatorio del mensaje de disparo es válido.
- 4. El método según la reivindicación 1 o 2, caracterizado por cuanto que la utilización del número aleatorio del mensaje de disparo operativo para generar un mensaje de disparo por el servidor comprende:la transmisión, por el servidor, del número aleatorio del mensaje de disparo operativo en una cabecera de mensaje o un cuerpo de mensaje del mensaje de disparo; la generación del extracto de acceso utilizando el número aleatorio del mensaje de disparo operativo, la cabecera del mensaje y el cuerpo del mensaje del mensaje de disparo y generando un mensaje de disparo utilizando el extracto de acceso ola transmisión, por el servidor, del número aleatorio del mensaje de disparo operativo en una cabecera de mensaje o un cuerpo de mensaje del mensaje de disparo operativo; la generación del extracto de acceso utilizando la cabecera de mensaje y el cuerpo de mensaje del mensaje de disparo operativo y la generación del mensaje de disparo utilizando el extracto de acceso.
- 5. Un cliente, caracterizado por cuanto que comprende:una unidad de recepción (1421), adaptada para recibir un mensaje de disparo operativo que se genera por un servidor utilizando un número aleatorio del mensaje de disparo operativo y en cumplimiento de un protocolo de Sincronización de Datos, DS o de Gestión de Dispositivo, DM yuna primera unidad de autenticación (1422), adaptada para extraer el número aleatorio del mensaje de disparo operativo; para generar un extracto de acceso utilizando el número aleatorio del mensaje de disparo operativo para autenticar el mensaje de disparo generado usando el número aleatorio del mensaje de disparo operativo después de determinar que el número aleatorio del mensaje de disparo operativo es válido; para enviar una demanda de sesión al servidor indicado por el mensaje de disparo operativo después de que se realice satisfactoriamente la autenticación.
- 6. El cliente según la reivindicación 5, caracterizado por cuanto que el cliente comprende, además: una segunda unidad de autenticación (1425),adaptada para utilizar un número aleatorio de servidor para la autenticación del mensaje de disparo operativo después de recibir dicho mensaje y para realizar una nueva autenticación del mensaje de disparo operativo utilizando el número aleatorio del mensaje de disparo si falla la autenticación.Terminal Servidor101: Mensaje de disparo102: Sesión103: Respuesta104: Resultado de autenticaciónTerminal Servidor201: Mensaje de disparo202: Falla la autenticación y el mensaje de disparo Trigger es objeto de nueva autenticación utilizando el número aleatoriopor defecto203: Demanda de sesión204: Respuesta205: Resultado de autenticación y orden de actualización206: Resultado de actualizaciónTerminal Servidor301: Mensaje de disparo, número aleatorio que transmite dicho mensaje302: Demanda de sesión303: Respuesta304: Resultado de autenticaciónDigest Trigger-hdr Trigger-bodyNúmero Uso Sessionid Longitud -Servidor -Versión Modo-UI Iniciadoraleatorio futuro identificador IdentificadorCliente Servidor501: Mensaje de disparo, número aleatorio que transmite dicho mensaje502: Demanda de sesión503: Respuesta504: Falla la autenticación505: Mensaje de actualización506: Resultado de actualización y demanda de autenticación507: Resultado de autenticación Cliente Servidor601: Mensaje de disparo602: Sedescubre fallo de603: Mensaje de disparo, número autenticaciónaleatorio que transmite dicho mensaje604: Demanda de sesión605: Respuesta606: Falla la autenticación607: Mensaje de actualización608: Resultado de actualización y demanda de autenticación609: Resultado de autenticaciónServidorCliente701: Mensaje de disparo702: Falla la autenticación y el mensaje de disparo esobjeto de nueva autenticación usando elnúmero aleatorio por 703: Demanda de sesión que usa el defecto número aleatorio por defecto704: La demanda desesión es objeto de autenticación705: Respuesta706: La respuestaes objeto de autenticación707: Resultado de autenticación y orden de actualización708: Resultado de actualizaciónCliente Servidor801: Se descubre la necesidad deactualizar el número aleatorio802: Demanda de sesión que incluyedel servidorinformación de actualización803: Resultado de autenticación, resultado de actualización y demanda de autenticación804: Resultado de autenticaciónServidorCliente901: Mensaje de disparo902: Sedescubre fallo de autenticación903: Mensaje de disparo, número aleatorio que transmite dicho mensaje904: Se descubrela necesidad de actualización905: Demanda de sesión que transmite información de actualización906: Resultado de autenticación, resultado de actualización y demanda de autenticación907: Resultado de autenticaciónDigest Notification-hdr NotificationbodyNúmero Uso Length-Versión Código-Notification-aleatorio futuro Sessionid Authnameauthnameestado ID siguienteCliente Servidor1101: Mensaje de disparo1102: Falla la autenticación y el mensaje de disparo se re-autentica usando el número aleatorio por defecto1103: Demanda de sesión que transmite información de actualización1104: Resultado de autenticación, resultado de actualización y demanda de autenticación1105: Resultado de autenticaciónCliente Servidor1201: Mensaje de disparo1202: Falla la autenticación y el mensaje de disparo se re-autentica usando el número aleatorio por defecto 1203: Demanda de sesión1204: Respuesta1205: Orden de actualización y resultado de autenticación1206: Resultado de actualizaciónServidorCliente1301: Mensaje de disparo1302: Demanda de sesión1303: Respuesta que transmite una orden de actualización de número aleatorio1304: Usar el número aleatorio no actualizado para autenticación1305: Actualizar el número aleatorio 1306: Resultado de autenticación y resultado de actualizaciónUnidad numeración ascendenteUnidad numeración descendenteUnidad numeraciónUnidad reposición número aleatorio Unidad de determinaciónPrimera unidad de generaciónUnidad de tiempo Segunda unidad de generaciónUnidad de envíoUnidad ID sesión-anúmero aleatorioPrimera unidadSegunda unidad determinaciónautenticación validezUnidad de Primera unidad recepción autenticaciónUnidad IDPrimera unidad Segunda sesión-adeterminación unidad númeronúmeración determinación aleatorionúmeraciónSegunda unidad determinación validezServidor ClienteUnida de recepciónUnida de recepciónClientePrimera unidad de generaciónSegunda unidad de generaciónUnidad de generaciónUnidad cambio de contraseñaUnidad de autenticaciónUnidad de generaciónUnidad dedemandaUnida dedisparoUnidad de recepciónUnidad de actualizaciónUnidad de recepciónSegunda unidad de autenticaciónUnidad de actualizaciónPrimera unidad de autenticaciónUnidad degeneraciónUnidad dedemanda
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710170309 | 2007-11-08 | ||
| CN200710170309 | 2007-11-08 | ||
| CN200710195462 | 2007-11-27 | ||
| CN2007101954623A CN101431413B (zh) | 2007-11-08 | 2007-11-27 | 进行认证的方法、系统、服务器及终端 |
| PCT/CN2008/070686 WO2009059496A1 (en) | 2007-11-08 | 2008-04-09 | A method, system, server and terminal for processing an authentication |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2426946T3 true ES2426946T3 (es) | 2013-10-25 |
Family
ID=40646594
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES08734046T Active ES2426946T3 (es) | 2007-11-08 | 2008-04-09 | Un método, sistema, servidor y terminal para poner en práctica una autenticación |
Country Status (8)
| Country | Link |
|---|---|
| US (2) | US8392717B2 (es) |
| EP (3) | EP2579502B1 (es) |
| JP (1) | JP5209731B2 (es) |
| KR (1) | KR101134059B1 (es) |
| CN (2) | CN101431413B (es) |
| ES (1) | ES2426946T3 (es) |
| RU (1) | RU2446593C2 (es) |
| WO (1) | WO2009059496A1 (es) |
Families Citing this family (74)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9318108B2 (en) | 2010-01-18 | 2016-04-19 | Apple Inc. | Intelligent automated assistant |
| US8977255B2 (en) | 2007-04-03 | 2015-03-10 | Apple Inc. | Method and system for operating a multi-function portable electronic device using voice-activation |
| US8676904B2 (en) | 2008-10-02 | 2014-03-18 | Apple Inc. | Electronic devices with voice command and contextual data processing capabilities |
| US8776214B1 (en) | 2009-08-12 | 2014-07-08 | Amazon Technologies, Inc. | Authentication manager |
| KR101676305B1 (ko) * | 2009-09-01 | 2016-11-15 | 엘지전자 주식회사 | 네트워크상에서의 디바이스 인증 시스템 및 인증 방법 |
| WO2012005739A1 (en) * | 2010-07-09 | 2012-01-12 | Hewlett-Packard Development Company, L.P. | Responses to server challenges included in a hypertext transfer protocol header |
| WO2012110694A1 (en) * | 2011-02-14 | 2012-08-23 | Nokia Corporation | Seamless wi-fi subscription remediation |
| US9171162B2 (en) | 2011-03-29 | 2015-10-27 | Microsoft Technology Licensing, Llc | Random file request for software attestation |
| US10057736B2 (en) | 2011-06-03 | 2018-08-21 | Apple Inc. | Active transport based notifications |
| CN102231678A (zh) * | 2011-06-27 | 2011-11-02 | 华为终端有限公司 | 设备管理的方法、装置和系统 |
| US11444936B2 (en) | 2011-07-29 | 2022-09-13 | Amazon Technologies, Inc. | Managing security credentials |
| US10362019B2 (en) | 2011-07-29 | 2019-07-23 | Amazon Technologies, Inc. | Managing security credentials |
| US9767262B1 (en) | 2011-07-29 | 2017-09-19 | Amazon Technologies, Inc. | Managing security credentials |
| WO2013061614A2 (en) | 2011-10-28 | 2013-05-02 | Nec Corporation | Secure method for mtc device triggering |
| US8984276B2 (en) * | 2012-01-10 | 2015-03-17 | Jpmorgan Chase Bank, N.A. | System and method for device registration and authentication |
| US8955065B2 (en) * | 2012-02-01 | 2015-02-10 | Amazon Technologies, Inc. | Recovery of managed security credentials |
| US8863250B2 (en) | 2012-02-01 | 2014-10-14 | Amazon Technologies, Inc. | Logout from multiple network sites |
| CN107451472B (zh) * | 2012-03-08 | 2021-06-04 | 阿里巴巴集团控股有限公司 | 表单验证方法、装置和系统 |
| US10417037B2 (en) | 2012-05-15 | 2019-09-17 | Apple Inc. | Systems and methods for integrating third party services with a digital assistant |
| DE112014000709B4 (de) | 2013-02-07 | 2021-12-30 | Apple Inc. | Verfahren und vorrichtung zum betrieb eines sprachtriggers für einen digitalen assistenten |
| US8966599B1 (en) | 2013-03-14 | 2015-02-24 | Amazon Technologies, Inc. | Automatic token renewal for device authentication |
| US10475018B1 (en) | 2013-11-29 | 2019-11-12 | Amazon Technologies, Inc. | Updating account data for multiple account providers |
| CN104954327B (zh) * | 2014-03-27 | 2019-02-22 | 东华软件股份公司 | 用于终端连接控制的服务器及方法、终端及方法、和系统 |
| US10170123B2 (en) | 2014-05-30 | 2019-01-01 | Apple Inc. | Intelligent assistant for home automation |
| US9715875B2 (en) | 2014-05-30 | 2017-07-25 | Apple Inc. | Reducing the need for manual start/end-pointing and trigger phrases |
| US9338493B2 (en) | 2014-06-30 | 2016-05-10 | Apple Inc. | Intelligent automated assistant for TV user interactions |
| US9886953B2 (en) | 2015-03-08 | 2018-02-06 | Apple Inc. | Virtual assistant activation |
| KR101655439B1 (ko) * | 2015-03-26 | 2016-09-20 | 세종대학교산학협력단 | 컴퓨팅 장치의 인증 방법 및 이를 수행하기 위한 장치 |
| US10460227B2 (en) | 2015-05-15 | 2019-10-29 | Apple Inc. | Virtual assistant in a communication session |
| US9916151B2 (en) * | 2015-08-25 | 2018-03-13 | Ford Global Technologies, Llc | Multiple-stage secure vehicle software updating |
| US10747498B2 (en) | 2015-09-08 | 2020-08-18 | Apple Inc. | Zero latency digital assistant |
| US10671428B2 (en) | 2015-09-08 | 2020-06-02 | Apple Inc. | Distributed personal assistant |
| US11587559B2 (en) | 2015-09-30 | 2023-02-21 | Apple Inc. | Intelligent device identification |
| WO2017064361A1 (en) * | 2015-10-16 | 2017-04-20 | Nokia Technologies Oy | Message authentication |
| US10691473B2 (en) | 2015-11-06 | 2020-06-23 | Apple Inc. | Intelligent automated assistant in a messaging environment |
| US9967248B1 (en) * | 2015-12-28 | 2018-05-08 | Amazon Technologies Inc. | System for authenticating and processing service requests |
| US12223282B2 (en) | 2016-06-09 | 2025-02-11 | Apple Inc. | Intelligent automated assistant in a home environment |
| US10586535B2 (en) | 2016-06-10 | 2020-03-10 | Apple Inc. | Intelligent digital assistant in a multi-tasking environment |
| US12197817B2 (en) | 2016-06-11 | 2025-01-14 | Apple Inc. | Intelligent device arbitration and control |
| DK201670540A1 (en) | 2016-06-11 | 2018-01-08 | Apple Inc | Application integration with a digital assistant |
| CN106100889A (zh) * | 2016-07-01 | 2016-11-09 | 浪潮(北京)电子信息产业有限公司 | 一种snmp协议安全的增强方法及装置 |
| CN106411953A (zh) * | 2016-11-30 | 2017-02-15 | 深圳前海弘稼科技有限公司 | 一种种植箱登录方法及装置 |
| US11204787B2 (en) | 2017-01-09 | 2021-12-21 | Apple Inc. | Application integration with a digital assistant |
| CN108337210B (zh) * | 2017-01-19 | 2021-05-18 | 钉钉控股（开曼）有限公司 | 设备配置方法及装置、系统 |
| KR102228744B1 (ko) * | 2017-03-07 | 2021-03-16 | 휴렛-팩커드 디벨롭먼트 컴퍼니, 엘.피. | 난수에 기초한 데이터 메시지 인증 |
| US10659464B2 (en) * | 2017-05-10 | 2020-05-19 | Microsoft Technology Licensing, Llc | Securely authenticating a bot user |
| DK180048B1 (en) | 2017-05-11 | 2020-02-04 | Apple Inc. | MAINTAINING THE DATA PROTECTION OF PERSONAL INFORMATION |
| DK179496B1 (en) | 2017-05-12 | 2019-01-15 | Apple Inc. | USER-SPECIFIC Acoustic Models |
| DK201770428A1 (en) | 2017-05-12 | 2019-02-18 | Apple Inc. | LOW-LATENCY INTELLIGENT AUTOMATED ASSISTANT |
| DK201770411A1 (en) | 2017-05-15 | 2018-12-20 | Apple Inc. | Multi-modal interfaces |
| US10303715B2 (en) | 2017-05-16 | 2019-05-28 | Apple Inc. | Intelligent automated assistant for media exploration |
| DK179560B1 (en) | 2017-05-16 | 2019-02-18 | Apple Inc. | FAR-FIELD EXTENSION FOR DIGITAL ASSISTANT SERVICES |
| FR3071373B1 (fr) * | 2017-09-21 | 2021-01-22 | Onoff Telecom | Procede de verification de la validite d’une ligne telephonique d’un utilisateur |
| US20200367025A1 (en) * | 2017-10-24 | 2020-11-19 | Irad Deutsch | Combination system and method |
| US10818288B2 (en) | 2018-03-26 | 2020-10-27 | Apple Inc. | Natural assistant interaction |
| US10928918B2 (en) | 2018-05-07 | 2021-02-23 | Apple Inc. | Raise to speak |
| DK180639B1 (en) | 2018-06-01 | 2021-11-04 | Apple Inc | DISABILITY OF ATTENTION-ATTENTIVE VIRTUAL ASSISTANT |
| DK201870355A1 (en) | 2018-06-01 | 2019-12-16 | Apple Inc. | VIRTUAL ASSISTANT OPERATION IN MULTI-DEVICE ENVIRONMENTS |
| US11462215B2 (en) | 2018-09-28 | 2022-10-04 | Apple Inc. | Multi-modal inputs for voice commands |
| US11348573B2 (en) | 2019-03-18 | 2022-05-31 | Apple Inc. | Multimodality in digital assistant systems |
| DK201970509A1 (en) | 2019-05-06 | 2021-01-15 | Apple Inc | Spoken notifications |
| US11307752B2 (en) | 2019-05-06 | 2022-04-19 | Apple Inc. | User configurable task triggers |
| US11227599B2 (en) | 2019-06-01 | 2022-01-18 | Apple Inc. | Methods and user interfaces for voice-based control of electronic devices |
| US12326823B2 (en) * | 2019-08-19 | 2025-06-10 | Cryptography Research, Inc. | Application authentication and data encryption without stored pre-shared keys |
| JP7279668B2 (ja) * | 2020-03-12 | 2023-05-23 | トヨタ自動車株式会社 | 車載用制御装置 |
| KR102519202B1 (ko) * | 2020-03-30 | 2023-04-05 | 한양대학교 산학협력단 | 보안 시스템 |
| US11061543B1 (en) | 2020-05-11 | 2021-07-13 | Apple Inc. | Providing relevant data items based on context |
| US11490204B2 (en) | 2020-07-20 | 2022-11-01 | Apple Inc. | Multi-device audio adjustment coordination |
| US11438683B2 (en) | 2020-07-21 | 2022-09-06 | Apple Inc. | User identification using headphones |
| EP4191940B1 (en) | 2020-08-13 | 2025-07-23 | Shenzhen Yinwang Intelligent Technologies Co., Ltd. | In-vehicle network secure communication method, apparatus and device |
| CN112260997B (zh) * | 2020-09-23 | 2023-05-26 | 曙光信息产业(北京)有限公司 | 数据访问方法、装置、计算机设备和存储介质 |
| CN112367329B (zh) * | 2020-11-17 | 2023-05-02 | 北京知道创宇信息技术股份有限公司 | 通信连接认证方法、装置、计算机设备及存储介质 |
| CN114168919B (zh) * | 2021-12-02 | 2025-09-23 | Oppo广东移动通信有限公司 | 双向身份认证的方法及相关装置 |
| CN116361845A (zh) * | 2021-12-27 | 2023-06-30 | 华为技术有限公司 | 访问对象的鉴权方法、装置及系统 |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5740361A (en) * | 1996-06-03 | 1998-04-14 | Compuserve Incorporated | System for remote pass-phrase authentication |
| US6064736A (en) * | 1997-09-15 | 2000-05-16 | International Business Machines Corporation | Systems, methods and computer program products that use an encrypted session for additional password verification |
| US6148405A (en) * | 1997-11-10 | 2000-11-14 | Phone.Com, Inc. | Method and system for secure lightweight transactions in wireless data networks |
| US6065120A (en) * | 1997-12-09 | 2000-05-16 | Phone.Com, Inc. | Method and system for self-provisioning a rendezvous to ensure secure access to information in a database from multiple devices |
| US6892308B1 (en) | 1999-04-09 | 2005-05-10 | General Instrument Corporation | Internet protocol telephony security architecture |
| GB9922665D0 (en) * | 1999-09-25 | 1999-11-24 | Hewlett Packard Co | A method of enforcing trusted functionality in a full function platform |
| US7024695B1 (en) * | 1999-12-30 | 2006-04-04 | Intel Corporation | Method and apparatus for secure remote system management |
| US20020196935A1 (en) * | 2001-02-25 | 2002-12-26 | Storymail, Inc. | Common security protocol structure and mechanism and system and method for using |
| KR20040014400A (ko) * | 2000-09-22 | 2004-02-14 | 제너럴 인스트루먼트 코포레이션 | 인터넷 프로토콜 전화 보안 체계 |
| KR100445574B1 (ko) | 2001-12-19 | 2004-08-25 | 한국전자통신연구원 | 대화형 영 지식 증명을 이용한 패스워드 기반의 인증 및키 교환 프로토콜 설계 방법 |
| US7421733B2 (en) * | 2002-02-06 | 2008-09-02 | Hewlett-Packard Development Company, L.P. | System and method for providing multi-class processing of login requests |
| JP4186512B2 (ja) * | 2002-05-20 | 2008-11-26 | ソニー株式会社 | サービス提供システム、機器端末およびその処理方法、認証装置および方法、サービス提供装置および方法、並びにプログラム |
| US7574599B1 (en) * | 2002-10-11 | 2009-08-11 | Verizon Laboratories Inc. | Robust authentication and key agreement protocol for next-generation wireless networks |
| US7181572B2 (en) * | 2002-12-02 | 2007-02-20 | Silverbrook Research Pty Ltd | Cache updating method and apparatus |
| KR20040050625A (ko) | 2002-12-10 | 2004-06-16 | 한국전자통신연구원 | 대칭형 및 비대칭형 인증 키 교환을 이용한 인증방법 |
| JP4392510B2 (ja) * | 2003-06-09 | 2010-01-06 | 財団法人生産技術研究奨励会 | 認証装置及び認証方法 |
| KR100548354B1 (ko) * | 2003-06-14 | 2006-02-02 | 엘지전자 주식회사 | 동기화 프로토콜에서의 사용자 인증 방법 |
| CN1894923A (zh) | 2003-10-08 | 2007-01-10 | 史蒂芬·J·英格博格 | 用改进保密性技术来建立通讯的方法和系统 |
| US7549048B2 (en) * | 2004-03-19 | 2009-06-16 | Microsoft Corporation | Efficient and secure authentication of computing systems |
| US7437771B2 (en) * | 2004-04-19 | 2008-10-14 | Woodcock Washburn Llp | Rendering protected digital content within a network of computing devices or the like |
| US20060174103A1 (en) * | 2004-09-16 | 2006-08-03 | Nokia Corporation | System and method for integrating PKI and XML-based security mechanisms in SyncML |
| US7690026B2 (en) * | 2005-08-22 | 2010-03-30 | Microsoft Corporation | Distributed single sign-on service |
| KR101209071B1 (ko) * | 2006-09-19 | 2012-12-06 | 엘지전자 주식회사 | 디바이스 관리시스템 및 그 제어방법 |
-
2007
- 2007-11-27 CN CN2007101954623A patent/CN101431413B/zh active Active
- 2007-11-27 CN CN2011103354682A patent/CN102333100B/zh active Active
-
2008
- 2008-04-09 KR KR1020107011964A patent/KR101134059B1/ko active Active
- 2008-04-09 ES ES08734046T patent/ES2426946T3/es active Active
- 2008-04-09 JP JP2010532407A patent/JP5209731B2/ja active Active
- 2008-04-09 EP EP13150334.4A patent/EP2579502B1/en active Active
- 2008-04-09 RU RU2010123182/08A patent/RU2446593C2/ru active
- 2008-04-09 WO PCT/CN2008/070686 patent/WO2009059496A1/zh not_active Ceased
- 2008-04-09 EP EP13150335.1A patent/EP2579503B1/en active Active
- 2008-04-09 EP EP08734046.9A patent/EP2209253B1/en active Active
-
2010
- 2010-05-07 US US12/775,937 patent/US8392717B2/en active Active
-
2011
- 2011-10-11 US US13/270,579 patent/US8245048B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP2579502B1 (en) | 2015-09-02 |
| EP2579503A2 (en) | 2013-04-10 |
| EP2209253B1 (en) | 2013-06-19 |
| EP2209253A4 (en) | 2011-11-30 |
| EP2579502A3 (en) | 2013-10-16 |
| CN102333100B (zh) | 2013-11-06 |
| US20100217997A1 (en) | 2010-08-26 |
| US8392717B2 (en) | 2013-03-05 |
| CN101431413A (zh) | 2009-05-13 |
| JP2011504261A (ja) | 2011-02-03 |
| JP5209731B2 (ja) | 2013-06-12 |
| CN102333100A (zh) | 2012-01-25 |
| RU2010123182A (ru) | 2011-12-20 |
| KR20100071115A (ko) | 2010-06-28 |
| EP2579503B1 (en) | 2015-09-02 |
| CN101431413B (zh) | 2012-04-25 |
| US8245048B2 (en) | 2012-08-14 |
| WO2009059496A1 (en) | 2009-05-14 |
| EP2579503A3 (en) | 2013-10-09 |
| KR101134059B1 (ko) | 2012-05-09 |
| EP2209253A1 (en) | 2010-07-21 |
| RU2446593C2 (ru) | 2012-03-27 |
| EP2579502A2 (en) | 2013-04-10 |
| US20120030472A1 (en) | 2012-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2426946T3 (es) | Un método, sistema, servidor y terminal para poner en práctica una autenticación | |
| JP5414898B2 (ja) | 有線ｌａｎのセキュリティアクセス制御方法及びそのシステム | |
| US12074883B2 (en) | Systems and methods for network access granting | |
| US11895501B2 (en) | Methods, systems, and computer readable media for automatic key management of network function (NF) repository function (NRF) access token public keys for 5G core (5GC) authorization to mitigate security attacks | |
| RU2414086C2 (ru) | Аутентификация приложения | |
| US7929703B2 (en) | Methods and system for managing security keys within a wireless network | |
| US20100313019A1 (en) | Method and system for managing a software application on a mobile computing device | |
| US20200076791A1 (en) | Information processing apparatus, authorization system, and verification method | |
| JP2008519488A (ja) | 複数の信用証明認証プロトコルを提供するシステム及び方法 | |
| CN101686458A (zh) | 一种终端配置和管理方法及终端装置 | |
| US11695751B2 (en) | Peer-to-peer notification system | |
| Zhou et al. | Heracles: Scalable, fine-grained access control for internet-of-things in enterprise environments | |
| US20230171099A1 (en) | Methods, systems, and computer readable media for sharing key identification and public certificate data for access token verification | |
| Zhou et al. | Towards fine-grained access control in enterprise-scale Internet-of-Things | |
| US12476950B2 (en) | Method, device, and system for authentication and authorization with edge data network | |
| US20240373215A1 (en) | Security configuration update in communication networks | |
| Tsai et al. | An efficient blockchain-based firmware update framework for iot environment | |
| Yuan et al. | eSIM Technology in IoT Architecture | |
| WO2022183427A1 (en) | Method, device, and system for protecting sequence number in wireless network | |
| WO2021115554A1 (en) | A service based interface for establishing distributed consensus | |
| KR102300487B1 (ko) | Mptcp의 서브플로우 보안 연결 방법 및 이를 위한 클라우드 서버, 호스트 | |
| WO2022066076A1 (en) | Binding a subscriber's identity in a mobile network to transactions in a distributed ledger network |