ES2644739T3 - Solicitud de certificados digitales - Google Patents

Solicitud de certificados digitales Download PDF

Info

Publication number
ES2644739T3
ES2644739T3 ES02735717.7T ES02735717T ES2644739T3 ES 2644739 T3 ES2644739 T3 ES 2644739T3 ES 02735717 T ES02735717 T ES 02735717T ES 2644739 T3 ES2644739 T3 ES 2644739T3
Authority
ES
Spain
Prior art keywords
certificate
entity
request
issuer
request message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES02735717.7T
Other languages
English (en)
Inventor
Nadarajah Asokan
Philip Ginzboorg
Valtteri Niemi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Technologies Oy
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Application granted granted Critical
Publication of ES2644739T3 publication Critical patent/ES2644739T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • 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
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption

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)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
Solicitud de certificados digitales
DESCRIPCION
La presente invention se refiere a la solicitud y a la emision de certificados digitales.
Cada vez se esta volviendo mas comun que las transacciones sean llevadas a cabo por medios electronicos. En las transacciones financieras, y en muchas otras transacciones, existe una necesidad de establecer un nivel de confianza entre las partes de la transaction. Por ejemplo, si un comprador desea comprar bienes en llnea, entonces se ha dar garantla al proveedor de los bienes de que el comprador proporcionara el pago de los bienes. El comprador tambien puede desear que se le de garantla de que su pago se va a transferir de hecho al proveedor.
Un medio para que se establezca tal confianza es mediante un sistema de clave publica/privada. En un sistema de este tipo, cada usuario tiene un par de claves. Una clave es una clave publica, que se puede facilitar a otros usuarios. La otra clave es una clave privada, que es mantenida en secreto por el usuario del cual es la clave. Las claves publicas y privadas estan relacionadas por medio de algoritmos de tal modo que, a pesar de que es extremadamente diflcil generar la clave privada a partir del conocimiento de la clave publica, la clave privada y la clave publica se pueden usar para la realization de firmas digitales. En la realization de firmas digitales, un primer algoritmo es aplicado por un usuario a su clave privada y a sus datos de origen, para formar datos de resultado; entonces, los datos de resultado se transmiten a otro usuario. El otro usuario aplica un segundo algoritmo a la clave publica del primer usuario, los datos de resultado, y, dependiendo del esquema de firma, otra entrada, para formar unos datos de verification. La clave publica y privada y el primer y el segundo algoritmos estan relacionados de tal modo que los datos de verificacion indican, con un alto nivel de probabilidad, si la clave privada del primer usuario se uso para generar los datos de resultado. Con la condition de que la clave privada del primer usuario sea secreta salvo para el mismo, y que el segundo usuario pueda confiar en que la clave publica pertenece en realidad a el primer usuario, esto autentica al primer usuario con un alto nivel de probabilidad. Un ejemplo de un sistema de este tipo es el sistema de clave publica/privada de Privacidad Bastante Buena (PGP, Pretty Good Privacy).
Un certificado digital se usa normalmente para vincular una identidad de un sujeto a una clave publica. Los certificados son, en si mismos, declaraciones firmadas que son emitidas por una autoridad de certification. Si un usuario tiene la clave publica de la autoridad, este puede verificar los certificados que son emitidos por esa autoridad. Si un usuario (verificador) tiene acceso a un certificado que es emitido para la clave publica de otro usuario (firmante) por una autoridad en la que confla el verificador, entonces el verificador puede confiar realmente en que la clave publica pertenece al firmante. Este tipo de certificado se conoce como certificado de identidad. Los certificados de identidad no son suficientes para las transacciones que requieren autorizacion. Por ejemplo, en el caso de una compra en llnea, puede que el vendedor desee verificar no solo la identidad del comprador sino tambien que el comprador tiene el dinero para pagar la compra. Ademas, la parte que emite el certificado tiene, por lo general, responsabilidades legales y empresariales en lo que respecta a como se usan sus certificados. Por estas razones, cada certificado contiene normalmente unos parametros que definen como se deberla usar ese certificado. Son ejemplos de esos parametros el fin para el cual se ha emitido el certificado, el tiempo de expiration del certificado y el llmite sobre la cantidad de dinero que se permite en una unica transaccion usando el certificado. Los certificados se pueden referir a una unica transaccion o se pueden usar para autorizar un numero de transacciones, cada una dentro de un llmite de valores que se especifica en el certificado.
Durante la emision de un certificado digital a traves de una conexion de red, se han de intercambiar al menos dos mensajes entre las partes solicitante y emisora. Esos dos mensajes son la solicitud de certificacion que es enviada por la parte solicitante y una respuesta correspondiente que es enviada por la parte emisora. Hay normas para el procedimiento de emision, por ejemplo, la norma PKCS10 de RSA (vease, en especial, PKCs n.° 10, v1.7: Certification Request Syntax Standard (norma de sintaxis de solicitudes de certificacion), RSA Laboratories, 26 de mayo de 2000) y la norma RFC 2511 [CRMF] del grupo de trabajo de pkix de IETF (Internet X.509 Certificate Request Message Format, formato de mensajes de solicitud de certificados X.509 de Internet, RFC 2511).
La emision de certificados a traves de una red se puede asegurar de un numero de formas. Por ejemplo, la solicitud de patente de los Estados Unidos "System and method of boot-strapping a temporary public key infrastructure from a cellular telecommunication authentication and billing infrastructure", de Nokia, US 09/659-781, 11 de septiembre 2000, (y las solicitudes correspondientes) describe un sistema en el que la seguridad de los mensajes de solicitud y de respuesta de certificado se basa en un secreto que es conocido tanto por el terminal movil como por la red celular. En general, la solicitud de certificado se puede asegurar al adjuntar un campo autenticador a la misma, que puede ser, por ejemplo, un codigo de autenticacion de mensaje que se computa usando un secreto compartido, o una firma digital que se computa usando una clave privada diferente de aquella cuya clave publica se esta certificando.
Lo siguiente es un ejemplo de un campo autenticador que se computa usando un secreto compartido. En el sistema universal de telecomunicaciones moviles (UMTS, Universal Mobile Telecommunications System) el USIM (Universal Subscriber Identity Module, modulo universal de identidad de abonado) computa una clave de integridad IK de sesion durante el proceso de autenticacion y de acuerdo de claves entre el telefono (equipo de usuario) y la red celular. El USIM se puede encontrar en la forma de una tarjeta inteligente. El USIM exporta la IK al soporte logico del
5
10
15
20
25
30
35
40
45
50
55
60
65
telefono, que usa la IK para proteger la integridad de todos los mensajes de senalizacion. En el caso de los certificados de abonado de UMTS, la clave de integridad (IK, integrity key) de UMTS se puede usar para autenticar la solicitud de certificado, tal como se analiza en la solicitud de EE. UU. con numero de serie 09/659.781 a la que se ha hecho referencia en lo que antecede. Una forma de hacer esto serla proteger de forma individual todas las solicitudes y respuestas de certificado por medio de la IK. Otra forma serla enviar todas las solicitudes y respuestas de certificado como mensajes de senalizacion, debido a que en UMTS (por ejemplo) el plano de senalizacion se protege por IK de forma automatica.
Lo siguiente es un ejemplo de un autenticador en la forma de firmas digitales. La tarjeta inteligente se fabrica de tal modo que la misma contiene un par de claves de gestion antes de que la misma salga de la fabrica. El fabricante conoce la clave publica de gestion de cada tarjeta. El usuario puede, cuando obtiene la tarjeta, desencadenar que la tarjeta genere un nuevo par de claves. Este nuevo par de claves se podrla usar, por ejemplo, para generar y, mas adelante, verificar firmas para autorizar transacciones. El usuario puede obtener del fabricante un certificado para la nueva clave publica. Un certificado de este tipo se denomina normalmente certificado de dispositivo. Entonces, el certificado de dispositivo es una garantla de calidad de un par de claves (en concreto, de que las claves se generaron usando unos algoritmos correctos y de que la clave privada se encuentra en una ubicacion segura). El autenticador para esta solicitud de certificado sera una firma digital que se realiza usando la clave privada de gestion.
Cuando un usuario usa un dispositivo tal como un ordenador portatil, un telefono movil o un asistente personal digital (PDA, Personal Digital Assistant) para solicitar un certificado para una clave publica, esa clave publica se puede originar a partir del dispositivo desde el cual se realiza la solicitud o a partir de otro dispositivo.
Es deseable que, ademas de comprobar el derecho del usuario a realizar la solicitud, el emisor del certificado tambien tenga en cuenta la procedencia del par de claves, con el fin de inhibir el fraude. Por ejemplo, con el fin de que el emisor del certificado se proteja a si mismo y proteja al propietario de la clave frente a un potencial fraude, puede ser deseable que el emisor del certificado emita un certificado en respuesta a una solicitud si la clave publica que es especificada por la solicitud se origina en otro dispositivo que no sea el que ha realizado la solicitud. Sin embargo, las presentes normas de emision de certificados y otras descripciones publicamente disponibles de emision de certificados no tienen en cuenta el origen de la clave publica para permitir que se realice esto.
El documento US 5.745.574 divulga un sistema de certificacion que comprende una pluralidad de autoridades de certificacion. Se proporciona un conjunto comun de funciones de certificacion para facilitar servicios de seguridad dentro del sistema.
De acuerdo con un aspecto de la presente invencion, se proporciona un metodo para solicitar, de un emisor de certificados digitales, un certificado digital para una clave publica que esta asociada a una clave privada correspondiente que es almacenada por una entidad de almacenamiento, comprendiendo el metodo: generar, por medio de una entidad de generacion, un mensaje de solicitud de certificado indicativo de una solicitud para un certificado; y transmitir el mensaje de certificado del emisor de certificados digitales; incluyendo el mensaje de solicitud de certificado una indication de la relation entre la entidad de almacenamiento y la entidad de generacion.
De acuerdo con un segundo aspecto de la presente invencion, se proporciona una entidad de generacion para generar un mensaje de solicitud de certificado para solicitar, de un usuario de certificados digitales, un certificado digital para una clave publica que esta asociada a una clave privada correspondiente que es almacenada por una entidad de almacenamiento, estando dispuesta la entidad de generacion para generar el mensaje de solicitud de certificado que incluye una indicacion de la relacion entre la entidad de almacenamiento y la entidad de generacion.
De acuerdo con un tercer aspecto de la presente invencion, se proporciona un emisor de certificados digitales para procesar mensajes de solicitud de certificado que son generados por una entidad de generacion, estando dispuesto el emisor de certificados digitales para analizar el mensaje de solicitud para determinar si este es una solicitud aceptable; y, si se determina que la solicitud es aceptable, emitir un certificado digital en respuesta a la solicitud, siendo dicho certificado para una clave publica que esta asociada a una clave privada correspondiente que es almacenada por una entidad de almacenamiento, y estando dispuesto para limitar el certificado digital dependiendo de una indicacion de una relacion entre la entidad de generacion y la entidad de almacenamiento que se incluye en el mensaje de solicitud de certificado.
De acuerdo con un cuarto aspecto de la presente invencion, se proporciona un sistema de comunicacion que comprende una entidad de generacion de este tipo y un emisor de certificados digitales de este tipo.
Preferiblemente, la indicacion es de una relacion flsica entre la entidad de almacenamiento y la entidad de generacion. Como alternativa, o ademas, la indicacion puede ser de una relacion de seguridad entre la entidad de almacenamiento y la entidad de generacion.
Preferiblemente, la indicacion puede adoptar una de un conjunto previamente determinado de formas. Una de las formas puede indicar que la entidad de almacenamiento esta flsicamente comprendida en la entidad de generacion y
5
10
15
20
25
30
35
40
45
50
55
60
65
que la entidad de almacenamiento es flsicamente segura, por ejemplo, resistente a manipulacion indebida. Una de las formas puede indicar que la entidad de almacenamiento esta flsicamente comprendida en la entidad de generacion y que la entidad de almacenamiento no es flsicamente segura. Una de las formas puede indicar que la entidad de almacenamiento no esta flsicamente comprendida en la entidad de generacion. Una de las formas puede indicar que la clave publica se ha proporcionado a la entidad de generacion mediante una entrada de usuario. La entidad de generacion se dispone preferiblemente para determinar la relacion entre la misma y la entidad de almacenamiento y para proporcionar la indicacion de acuerdo con el resultado de esa determinacion.
Preferiblemente, el emisor de certificados digitales: analiza el mensaje de solicitud para determinar si este es una solicitud aceptable; y, si se determina que la solicitud es aceptable, emite un certificado digital en respuesta a la solicitud.
El mensaje de solicitud de certificado preferiblemente comprende unos datos que son una funcion de la clave privada, con lo que el mensaje de solicitud de certificado puede ser autenticado por el emisor de certificados digitales. El emisor de certificados digitales puede autenticar el mensaje de solicitud por medio de la clave publica o por medio de una clave simetrica compartida, que tambien puede ser almacenada por un almacen que esta asociado al emisor de certificados digitales.
Preferiblemente, el emisor de certificados digitales se dispone para limitar el certificado digital a un nivel previamente determinado si no se autentica el mensaje de solicitud. Ese nivel puede ser nulo, caso en el cual podrla ser que no se emitiera certificado alguno.
Preferiblemente, el emisor de certificados digitales se dispone para limitar el certificado digital dependiendo de la indicacion de la relacion que se incluye en el mensaje de solicitud de certificado. El emisor de certificados digitales puede almacenar una pluralidad de niveles de uso, correspondiendose uno con cada valor disponible de la indicacion de la relacion, y puede aplicar esos niveles como llmites sobre el certificado que se puede emitir en respuesta a una solicitud de acuerdo con la indicacion en el mensaje.
La limitacion del certificado es preferiblemente una limitacion de las capacidades o el uso previsto del certificado. La indicacion de la relacion entre el elemento de almacenamiento y el elemento de generacion de equipo en el interior de la solicitud de certificado puede influir en la decision acerca de que tipo de certificado producira el emisor. La propia indicacion se puede dejar fuera del certificado emitido, o esta se puede registrar de forma expllcita en el interior del certificado, caso en el cual la misma es visible a la entidad que maneja el certificado.
La entidad de generacion puede ser un elemento de equipo de usuario (UI, user equipment) de una red celular de comunicaciones, por ejemplo, un telefono movil de UMTS. La entidad de almacenamiento puede ser una tarjeta universal de circuito integrado (UICC, universal integrated Circuit Card) o un modulo inalambrico de identidad (WIM, Wireless identity Module) que se instala en el elemento de equipo de usuario, por ejemplo, en la forma de una tarjeta inteligente. La entidad de generacion y la entidad de almacenamiento pueden ser la misma, por ejemplo, estas se pueden encontrar, ambas, en una tarjeta inteligente.
El emisor de certificados puede ser parte de la red celular de comunicaciones, o puede ser externo a la red celular. La red puede, por ejemplo, ser una red de GSM (Global System for Mobile Communications, sistema global para comunicaciones moviles), o su sucesora, una red de 3G (tercera generacion), o una derivada de la misma.
La presente invencion se describira a continuacion a modo de ejemplo con referencia a los dibujos adjuntos.
En los dibujos:
la figura 1 ilustra la arquitectura de un sistema de comunicacion; la figura 2 ilustra un metodo para emitir un certificado digital;
las figuras 3 a 6 ilustran ejemplos de un equipo que implementa aspectos de la presente invencion.
En el presente sistema, los dispositivos en una red de comunicacion pueden solicitar, de un emisor de certificados, certificados para su uso en los aspectos de autenticacion y de autorizacion de las transacciones. Cada certificado se solicita y se emite con respecto a una clave publica para la cual existe una clave privada correspondiente. La solicitud de un certificado se realiza de acuerdo con un metodo en el que la solicitud para el certificado incluye una indicacion del origen o procedencia de la clave con respecto a la cual se solicita un certificado.
La figura 1 muestra un sistema de comunicacion. El sistema incluye una red de conmutacion y de transferencia de datos que se muestra en general en 1. Esta podrla incluir una o mas redes de telefonla e Internet. Se proporciona un numero de puntos de acceso 2 por medio de los cuales los dispositivos pueden acceder a la red 1. Estos puntos de acceso podrlan ser (sin limitacion) estaciones de base inalambricas, puntos de acceso de red cableados, etc. Los dispositivos podrlan ser cualquier dispositivo con capacidades de red tal como un ordenador portatil 3, un PDA 4, un telefono de llnea fija 5, un telefono movil 6 o una television con capacidades multimedia interactivas 7. Los dispositivos se pueden comunicar a traves de la red 1. Los dispositivos se pueden comunicar con un emisor de certificados 8 y un servidor de transacciones 9 a traves de la red 1 y, normalmente, los dispositivos pueden ser
5
10
15
20
25
30
35
40
45
50
55
60
65
capaces de comunicarse entre si a traves de la red.
Al menos algunos de los dispositivos tienen pares asociados de clave publica/privada. Tales dispositivos almacenan su clave privada en secreto, pero pueden facilitar la clave publica a otros dispositivos para fines de cifrado y de autenticacion. Al menos algunos de los dispositivos son capaces de soportar aplicaciones que pueden solicitar certificados con respecto a una clave publica. Por ejemplo, el ordenador portatil 3 incluye una memoria 10 (tal como una unidad de disco duro) que almacena claves publicas y privadas que estan asociadas al ordenador portatil. La memoria 10 tambien almacena un soporte logico que es capaz de solicitar y de usar un certificado, tal como se describira con mas detalle en lo sucesivo. El ordenador portatil incluye unos medios de procesamiento (de forma conveniente, al menos un procesador 11 con una memoria asociada) para ejecutar el soporte logico. El soporte logico se dispone preferiblemente para inhibir la transmision de la clave privada fuera del dispositivo.
Cuando un dispositivo tal como el ordenador portatil 3 va a solicitar un certificado para una clave publica, el mismo transmite un mensaje de solicitud a traves de la red 1 al emisor de certificados 8. Ese mensaje incluye una indicacion de la clave publica para la cual se solicita el certificado. Si la red incluye un directorio de claves publicas 12, que almacena una lista de identificadores de usuario o de dispositivo y las claves publicas asociadas, entonces el mensaje puede incluir un identificador que esta asociado a la clave publica y el emisor de certificados puede entonces, si es necesario, recuperar, del directorio, la clave publica asociada por medio de una consulta que se realiza sobre el identificador. Como alternativa, el mensaje de solicitud puede incluir la propia clave publica. A la recepcion del mensaje de solicitud, el emisor de certificados realiza un proceso de verificacion, que se describe con mas detalle en lo sucesivo y, si es apropiado, emite un certificado. En el caso de un certificado para autorizar una transaccion financiera, el certificado se puede asociar a una cantidad monetaria que limita el valor para el cual se puede depender del certificado en una unica transaccion.
Ademas del autenticador de solicitudes de certificado que se ha descrito anteriormente, la solicitud de certificado tambien se puede autenticar por medio de la clave privada que esta asociada a la clave publica para la cual se realiza la solicitud. Esto solo se puede realizar si esa clave privada se encuentra disponible para el dispositivo que forma la solicitud. Este metodo se denomina prueba de posesion.
En el presente sistema, el mensaje de solicitud incluye un parametro que indica la relacion entre:
(a) la unidad que ha iniciado la solicitud, normalmente, la unidad en la que se genera la solicitud, (se hara referencia a la misma como la "unidad A"); y
(b) la unidad que esta asociada a la clave publica para la cual se solicita el certificado, normalmente, la unidad que almacena la clave privada asociada, (se hara referencia a la misma como la "unidad B").
Se puede hacer referencia a este parametro como parametro de procedencia o Key_origin. Algunos ejemplos no limitantes de las relaciones que se pueden indicar mediante el parametro Key_origin son:
1. que la unidad B sea un elemento o modulo de seguridad especffico en el interior de la unidad A, por ejemplo, una tarjeta universal de circuito integrado (UICC, Universal Integrated Circuit Card) en el interior del telefono de UMTS;
2. que la unidad B sea un elemento o modulo de seguridad que se incorpora en la unidad A;
3. que la unidad B sea una memoria interna no asegurada de la unidad A;
4. que la unidad B sea un dispositivo externo a la unidad A; y
5. que la clave publica se haya identificado directamente a partir de una entrada de usuario.
En general, el parametro Key_origin indica el grado del conocimiento del equipo solicitante de como de bien esta
protegida la clave privada. Por ejemplo, si el parametro Key_origin tiene unos valores de 1 o 2 en lo que antecede, entonces se puede asumir razonablemente que la clave privada se encuentra en una ubicacion segura.
Algunos ejemplos del uso del parametro Key_origin se daran a continuacion.
En la figura 3, el numero de referencia 6 designa un terminal de telefono movil o un dispositivo de equipo de usuario (UE, user equipment). El UE incluye un elemento o modulo de seguridad 16, en la forma de una tarjeta inteligente asegurada especlfica, por ejemplo, en una UICC 16. Si el UE solicita un certificado con respecto a una clave publica cuya clave privada asociada esta almacenada en la UICC 16, entonces se esperarla que una solicitud de este tipo tuviera un alto grado de confianza debido a que se puede esperar que el UE solo permita un acceso seguro a, o un uso seguro de, la clave privada. En este caso, se usarla el valor de Key_origin 1 que se ha indicado en lo que antecede.
En la figura 4, el UE 6 incluye un elemento o modulo 17, tal como un modulo inalambrico de identidad (WIM, wireless identity module), el cual no es especlficamente conocido por el emisor de certificados, pero aun as! el UE 6 asevera que es un elemento o modulo seguro. En este caso, se usarla el valor de Key_origin 2 que se ha indicado en lo que antecede.
5
10
15
20
25
30
35
40
45
50
55
60
65
En la figura 5, el UE 6 incluye un elemento o modulo de almacenamiento 18, tal como un modulo de memoria flash en el que se almacena la clave privada. Esta no es una ubicacion segura y las claves pueden ser vulnerables a hurto o modificacion por parte de un programa de tipo virus, o alguien que robe el dispositivo. En este caso, se usarla el valor de Key_origin 3 que se ha indicado en lo que antecede, de tal modo que el emisor de certificados puede limitar el riesgo al restringir las capacidades que se conceden a la clave publica en el certificado.
En la figura 6, el ordenador portatil 3 y el UE 6 podrlan pertenecer al mismo usuario, el cual puede desear usar el UE 6 para solicitar un certificado para transacciones usando la clave publica del ordenador portatil 3. El ordenador portatil 3 y el UE 6 se comunican usando un enlace de comunicacion local 19, tal como un enlace de comunicacion de infrarrojos o de Bluetooth. Por ejemplo, el enlace 19 se puede usar para transferir la clave publica desde el ordenador portatil 3 al UE 6 o el certificado de vuelta del UE 6 al ordenador portatil 3. En ese caso, se usarla el valor de Key_origin 4 que se ha indicado en lo que antecede. A pesar de que en este caso el mismo usuario tiene el control del ordenador portatil 3 y el UE 6, esto no se puede asegurar; ademas, debido a que la clave privada se encuentra en una ubicacion externa cuya seguridad no se puede conocer, esta puede ser vulnerable a hurto, por lo que el uso del valor de Key_origin 4 puede ayudar a reducir el riesgo (por ejemplo, el riesgo de que un dispositivo pueda solicitar certificados para transacciones que no estan asociadas a ese dispositivo o su usuario) al limitar las capacidades que se conceden a la clave publica en el certificado.
La presente invencion se podrla poner en practica, de forma ventajosa, en un sistema de telecomunicaciones moviles de 3G (tercera generacion) o un derivado del mismo.
A continuacion, los inventores de la presente invencion describen un ejemplo en el que se usan el Key_origin y el certificado digital. El emisor de certificados puede establecer llmites sobre el valor que esta asociado a un certificado, dependiendo del parametro Key_origin que se especifica en la solicitud para el certificado. Por ejemplo, el emisor puede autorizar certificados para unos valores de hasta 42 EUR si el valor de Key_origin es de 1 en lo que antecede, unos valores de hasta 1 eUr si el valor de Key_origin es de 3 en lo que antecede, y con un certificado que autoriza el acceso a un determinado servicio pero sin transacciones monetarias si Key_origin es el valor 5 en lo que antecede. Los llmites se pueden aplicar de forma global a todas las emisiones de certificado, o se pueden permitir diferentes llmites para diferentes usuarios o clases de usuarios.
Ademas, el emisor de certificados se puede conectar a un servidor financiero 14, por ejemplo, en un banco, mediante un enlace de datos seguro 13. Cuando se va a emitir un certificado a un usuario para un cierto valor, el emisor de certificados puede reservar ese valor en fondos de la cuenta del usuario en el banco al comunicarse a traves del enlace 13. Cuando el usuario usa el certificado en una transaccion, por ejemplo, para comprar bienes, los fondos se pueden transferir a la cuenta del beneficiario de la transaccion. El beneficiario puede iniciar esta transferencia a traves de otro enlace seguro 15 al servidor financiero. Si el certificado expira o se cancela sin haber sido usado para una transaccion, entonces el emisor de certificados puede devolver los fondos reservados a la cuenta.
La figura 2 ilustra el procedimiento de un procedimiento para solicitar, emitir y usar un certificado en el ejemplo tal como se ha descrito en lo que antecede.
En el procedimiento de la figura 2, un usuario da lugar a que una solicitud se transmita del ordenador portatil 3 al emisor de certificados 8 para un certificado con respecto a un valor de n EUR. La solicitud incluye una clave publica que esta asociada a una clave privada que se almacena en la unidad de disco duro 10 del ordenador portatil, o indica la identidad del ordenador portatil/usuario de tal modo que el emisor de certificados puede recuperar, del directorio 12, la clave publica relevante. Tal como se ha indicado en lo que antecede, el valor de Key_origin se establece a 3. (Etapas 30 y 31).
Si la solicitud se ha firmado, entonces la firma se verifica en el emisor de certificados y, si tal verificacion no tiene exito, se rechaza la solicitud. La firma se realiza preferiblemente por medio de la clave privada que se corresponde con la clave publica para la cual se ha emitido el certificado. Dependiendo del algoritmo de firma que se ha usado, la verificacion se puede realizar por medio de la clave publica asociada, o por medio de la propia clave privada si esta es conocida por el emisor de certificados. Si la solicitud no se ha firmado, entonces el emisor de certificados puede limitar el valor de las potenciales transacciones que se realizan usando un certificado resultante a un nivel previamente determinado, por ejemplo, al suponer que el campo de Key_origin tiene el valor que esta asociado a el grado mas bajo de confianza. Otra forma de asegurar la solicitud es el uso de un secreto compartido entre el terminal y la red y un canal de comunicacion que es asegurado por el secreto compartido, mediante el uso, por ejemplo, de codigos de autenticacion de mensaje.
El emisor de certificados comprueba, en la etapa 32, si el valor solicitado (n EUR) se encuentra dentro del llmite establecido para los certificados en respuesta al valor de Key_origin tal como se especifica en la solicitud. (En el presente caso, Key_origin = 3). Si este se encuentra por encima de ese llmite, entonces se rechaza la solicitud para un certificado. (Etapa 33).
5
10
15
20
25
Si la cantidad solicitada se encuentra dentro del llmite, entonces el emisor de certificados reserva n EUR de fondos de la cuenta del usuario. La identidad de esta cuenta se puede indicar en la solicitud, o se puede almacenar en una base de datos tal como el directorio 12. (Etapa 34). Si la reserva de fondos no tiene exito, entonces se rechaza la solicitud. La reserva de fondos puede ser realizada, como alternativa, por alguna entidad que no sea el propio emisor de certificados.
Si la reserva tiene exito, entonces se emite el certificado. (Etapa 35). Posteriormente, el usuario puede transmitir el certificado a otra parte con la que el mismo desee llevar a cabo una transaccion (por ejemplo, el usuario del servidor 9), y ese servidor puede entonces verificar el certificado con el emisor de certificados 8. (Etapas 36 y 37). Si la verificacion tiene exito, entonces puede tener lugar la transaccion. (Etapa 38). De lo contrario, por ejemplo si el certificado ha expirado o se ha revocado, se rechaza la transaccion. (Etapa 39).
Se prefiere que el dispositivo que genera la solicitud este preprogramado para aplicar el valor de Key_origin correcto a una solicitud. El emisor puede tambien ser capaz de conocer que tipo de dispositivo esta creando la solicitud en, para ejemplo, un caso en el que las capacidades de terminal se comunican al lado de red. En la situacion en la que el emisor de certificados no confla en que el dispositivo solicitante aplique el valor correcto de Key_origin, el emisor de certificados puede aplicar otro llmite previamente determinado al valor que se puede certificar, por ejemplo, al suponer que el campo de Key_origin tiene el valor que esta asociado al grado mas bajo de confianza.
El solicitante de la presente invencion divulga por la presente, de forma aislada, cada caracterlstica individual que se describe en el presente documento y cualquier combinacion de dos o mas de tales caracterlsticas, en la medida en la que tales caracterlsticas o combinaciones se puedan llevar a cabo sobre la base de la presente memoria descriptiva como un todo a la luz del conocimiento general y comun de un experto en la materia, con independencia de si tales caracterlsticas o combinaciones de caracterlsticas solucionan cualquier problema que se divulgue en el presente documento, y sin limitacion al alcance de las reivindicaciones. El solicitante indica que algunos aspectos de la presente invencion pueden consistir en cualquier caracterlstica individual o combinacion de caracterlsticas de este tipo. A la vista de la descripcion anterior, sera evidente a un experto en la materia que se pueden realizar diversas modificaciones.

Claims (24)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un metodo para solicitar a un emisor de certificados (8) un certificado para una clave publica que esta asociada a una clave privada correspondiente almacenada por una entidad de almacenamiento (B), comprendiendo el metodo:
    generar, por medio de una entidad de generacion (A), un mensaje de solicitud de certificado indicativo de una solicitud para un certificado; y
    transmitir el mensaje de solicitud de certificado al emisor de certificados; y caracterizado por que:
    el mensaje de solicitud de certificado incluye una indicacion de la relacion entre la entidad de almacenamiento y la entidad de generacion.
  2. 2. Un metodo de acuerdo con la reivindicacion 1, en el que la indicacion es de una relacion flsica entre la entidad de almacenamiento y la entidad de generacion.
  3. 3. Un metodo de acuerdo con las reivindicaciones 1 o 2, en el que la indicacion es de una relacion de seguridad entre la entidad de almacenamiento y la entidad de generacion.
  4. 4. Un metodo de acuerdo con la reivindicacion 3, en el que la indicacion es de conocimiento de la entidad de generacion en lo que respecta al nivel de seguridad de la clave privada almacenada por la entidad de almacenamiento.
  5. 5. Un metodo de acuerdo con cualquier reivindicacion anterior, en el que la indicacion puede adoptar una de un conjunto previamente determinado de formas y una de las formas indica que la entidad de almacenamiento esta flsicamente comprendida en la entidad de generacion y que la entidad de almacenamiento es flsicamente segura.
  6. 6. Un metodo de acuerdo con cualquier reivindicacion anterior, en el que la indicacion puede adoptar una de un conjunto previamente determinado de formas y una de las formas indica que la entidad de almacenamiento esta flsicamente comprendida en la entidad de generacion y que la entidad de almacenamiento no es flsicamente segura.
  7. 7. Un metodo de acuerdo con cualquier reivindicacion anterior, en el que la indicacion puede adoptar una de un conjunto previamente determinado de formas y una de las formas indica que la entidad de almacenamiento no esta flsicamente comprendida en la entidad de generacion.
  8. 8. Un metodo de acuerdo con cualquier reivindicacion anterior, en el que la indicacion puede adoptar una de un conjunto previamente determinado de formas y una de las formas indica que se ha proporcionado la clave publica a la entidad de generacion mediante una entrada de usuario.
  9. 9. Un metodo de acuerdo con cualquier reivindicacion anterior, que comprende las etapas del emisor de certificados de
    analizar el mensaje de solicitud para determinar si este es una solicitud aceptable; y,
    si se determina que la solicitud es aceptable, emitir un certificado en respuesta a la solicitud.
  10. 10. Un metodo de acuerdo con la reivindicacion 9, en el que el certificado incluye una indicacion de la relacion entre la entidad de almacenamiento y la entidad de generacion.
  11. 11. Un metodo de acuerdo con las reivindicaciones 9 o 10, en el que el mensaje de solicitud de certificado comprende unos datos que son una funcion de una clave de firma, con lo que el mensaje de solicitud de certificado puede ser autenticado por el emisor de certificados.
  12. 12. Un metodo de acuerdo con la reivindicacion 11, que comprende la etapa del emisor de certificados de autenticar el mensaje de solicitud por medio de una clave de verificacion.
  13. 13. Un metodo de acuerdo con la reivindicacion 11, en el que hay una clave simetrica que es conocida tanto por la entidad de generacion como por el emisor de certificados y el metodo comprende la etapa del emisor de certificados de autenticar el mensaje de solicitud por medio de la clave simetrica compartida.
  14. 14. Un metodo de acuerdo con cualquiera de las reivindicaciones 9 a 13, en el que se dispone el emisor de certificados para limitar el certificado a un nivel previamente determinado si no se autentica el mensaje de solicitud.
  15. 15. Un metodo de acuerdo con cualquiera de las reivindicaciones 9 a 14, en el que se dispone el emisor de certificados para limitar el certificado dependiendo de la indicacion de la relacion incluida en el mensaje de solicitud de certificado.
    5
    10
    15
    20
    25
    30
    35
  16. 16. Un metodo de acuerdo con cualquier reivindicacion anterior, en el que la entidad de generacion es un elemento de equipo de usuario de una red celular de comunicaciones.
  17. 17. Un metodo de acuerdo con la reivindicacion 16, en el que la entidad de almacenamiento es una tarjeta inteligente instalada en el elemento de equipo de usuario.
  18. 18. Un metodo de acuerdo con las reivindicaciones 16 o 17, en el que la entidad de almacenamiento es una tarjeta universal de circuito integrado (UICC) instalada en el elemento de equipo de usuario.
  19. 19. Un metodo de acuerdo con las reivindicaciones 16 o 17, en el que el emisor de certificados es parte de la red celular de comunicaciones.
  20. 20. Una entidad de generacion (A) para generar un mensaje de solicitud de certificado para solicitar a un emisor de certificados (8) un certificado con respecto a una clave publica que esta asociada a una clave privada correspondiente almacenada por una entidad de almacenamiento (B), estando la entidad de generacion caracterizada por estar dispuesta para generar el mensaje de solicitud de certificado que incluye una indicacion de la relacion entre la entidad de almacenamiento y la entidad de generacion.
  21. 21. Un emisor de certificados (8) para procesar mensajes de solicitud de certificado generados por una entidad de generacion (A), estando dispuesto el emisor de certificados para analizar el mensaje de solicitud para determinar si este es una solicitud aceptable; y, si se determina que la solicitud es aceptable, emitir un certificado en respuesta a la solicitud, siendo dicho certificado para una clave publica que esta asociada a una clave privada correspondiente almacenada por una entidad de almacenamiento (B), y caracterizado por estar dispuesto para limitar el certificado dependiendo de una indicacion de una relacion entre la entidad de generacion (A) y la entidad de almacenamiento (B) incluida en el mensaje de solicitud de certificado.
  22. 22. Un sistema de comunicacion que comprende una entidad de generacion de acuerdo con la reivindicacion 20 y un emisor de certificados de acuerdo con la reivindicacion 21.
  23. 23. Un sistema de comunicacion de acuerdo con la reivindicacion 22, en el que la entidad de almacenamiento y la entidad de generacion se encuentran en el mismo equipo.
  24. 24. Un sistema de comunicacion de acuerdo con la reivindicacion 22, en el que la entidad de almacenamiento y la entidad de generacion se encuentran en equipos diferentes.
ES02735717.7T 2002-02-22 2002-02-22 Solicitud de certificados digitales Expired - Lifetime ES2644739T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2002/002033 WO2003071734A1 (en) 2002-02-22 2002-02-22 Requesting digital certificates

Publications (1)

Publication Number Publication Date
ES2644739T3 true ES2644739T3 (es) 2017-11-30

Family

ID=27742210

Family Applications (1)

Application Number Title Priority Date Filing Date
ES02735717.7T Expired - Lifetime ES2644739T3 (es) 2002-02-22 2002-02-22 Solicitud de certificados digitales

Country Status (6)

Country Link
US (1) US8397060B2 (es)
EP (1) EP1476980B1 (es)
AU (1) AU2002309088A1 (es)
DK (1) DK1476980T3 (es)
ES (1) ES2644739T3 (es)
WO (1) WO2003071734A1 (es)

Families Citing this family (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8352400B2 (en) 1991-12-23 2013-01-08 Hoffberg Steven M Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
US8364136B2 (en) 1999-02-01 2013-01-29 Steven M Hoffberg Mobile system, a method of operating mobile system and a non-transitory computer readable medium for a programmable control of a mobile system
US7904187B2 (en) 1999-02-01 2011-03-08 Hoffberg Steven M Internet appliance system and method
US8918073B2 (en) 2002-03-28 2014-12-23 Telecommunication Systems, Inc. Wireless telecommunications location based services scheme selection
US8290505B2 (en) 2006-08-29 2012-10-16 Telecommunications Systems, Inc. Consequential location derived information
US9154906B2 (en) 2002-03-28 2015-10-06 Telecommunication Systems, Inc. Area watcher for wireless network
US8126889B2 (en) 2002-03-28 2012-02-28 Telecommunication Systems, Inc. Location fidelity adjustment based on mobile subscriber privacy profile
US7426380B2 (en) 2002-03-28 2008-09-16 Telecommunication Systems, Inc. Location derived presence information
US8027697B2 (en) * 2007-09-28 2011-09-27 Telecommunication Systems, Inc. Public safety access point (PSAP) selection for E911 wireless callers in a GSM type system
US8666397B2 (en) 2002-12-13 2014-03-04 Telecommunication Systems, Inc. Area event handling when current network does not cover target area
US7424293B2 (en) 2003-12-02 2008-09-09 Telecommunication Systems, Inc. User plane location based service using message tunneling to support roaming
US7260186B2 (en) 2004-03-23 2007-08-21 Telecommunication Systems, Inc. Solutions for voice over internet protocol (VoIP) 911 location services
US20080126535A1 (en) 2006-11-28 2008-05-29 Yinjun Zhu User plane location services over session initiation protocol (SIP)
US20080090546A1 (en) 2006-10-17 2008-04-17 Richard Dickinson Enhanced E911 network access for a call center using session initiation protocol (SIP) messaging
US9282455B2 (en) * 2004-10-01 2016-03-08 Intel Corporation System and method for user certificate initiation, distribution, and provisioning in converged WLAN-WWAN interworking networks
US6985105B1 (en) 2004-10-15 2006-01-10 Telecommunication Systems, Inc. Culled satellite ephemeris information based on limiting a span of an inverted cone for locating satellite in-range determinations
US7629926B2 (en) 2004-10-15 2009-12-08 Telecommunication Systems, Inc. Culled satellite ephemeris information for quick, accurate assisted locating satellite location determination for cell site antennas
US8543814B2 (en) * 2005-01-12 2013-09-24 Rpx Corporation Method and apparatus for using generic authentication architecture procedures in personal computers
US8532304B2 (en) * 2005-04-04 2013-09-10 Nokia Corporation Administration of wireless local area networks
US7353034B2 (en) 2005-04-04 2008-04-01 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
US8660573B2 (en) 2005-07-19 2014-02-25 Telecommunications Systems, Inc. Location service requests throttling
US9282451B2 (en) 2005-09-26 2016-03-08 Telecommunication Systems, Inc. Automatic location identification (ALI) service requests steering, connection sharing and protocol translation
US7825780B2 (en) 2005-10-05 2010-11-02 Telecommunication Systems, Inc. Cellular augmented vehicle alarm notification together with location services for position of an alarming vehicle
US8467320B2 (en) 2005-10-06 2013-06-18 Telecommunication Systems, Inc. Voice over internet protocol (VoIP) multi-user conferencing
US7907551B2 (en) 2005-10-06 2011-03-15 Telecommunication Systems, Inc. Voice over internet protocol (VoIP) location based 911 conferencing
US8150363B2 (en) 2006-02-16 2012-04-03 Telecommunication Systems, Inc. Enhanced E911 network access for call centers
US8059789B2 (en) 2006-02-24 2011-11-15 Telecommunication Systems, Inc. Automatic location identification (ALI) emergency services pseudo key (ESPK)
US9167553B2 (en) 2006-03-01 2015-10-20 Telecommunication Systems, Inc. GeoNexus proximity detector network
US7471236B1 (en) 2006-03-01 2008-12-30 Telecommunication Systems, Inc. Cellular augmented radar/laser detector
US7899450B2 (en) 2006-03-01 2011-03-01 Telecommunication Systems, Inc. Cellular augmented radar/laser detection using local mobile network within cellular network
US8037522B2 (en) * 2006-03-30 2011-10-11 Nokia Corporation Security level establishment under generic bootstrapping architecture
US8208605B2 (en) 2006-05-04 2012-06-26 Telecommunication Systems, Inc. Extended efficient usage of emergency services keys
US8527770B2 (en) * 2006-07-20 2013-09-03 Research In Motion Limited System and method for provisioning device certificates
US7966013B2 (en) 2006-11-03 2011-06-21 Telecommunication Systems, Inc. Roaming gateway enabling location based services (LBS) roaming for user plane in CDMA networks without requiring use of a mobile positioning center (MPC)
US20080208748A1 (en) * 2006-12-22 2008-08-28 Frank Ozment Transaction system and method
US8050386B2 (en) 2007-02-12 2011-11-01 Telecommunication Systems, Inc. Mobile automatic location identification (ALI) for first responders
US8185087B2 (en) 2007-09-17 2012-05-22 Telecommunication Systems, Inc. Emergency 911 data messaging
US9130963B2 (en) 2011-04-06 2015-09-08 Telecommunication Systems, Inc. Ancillary data support in session initiation protocol (SIP) messaging
US7929530B2 (en) 2007-11-30 2011-04-19 Telecommunication Systems, Inc. Ancillary data support in session initiation protocol (SIP) messaging
US8068587B2 (en) 2008-08-22 2011-11-29 Telecommunication Systems, Inc. Nationwide table routing of voice over internet protocol (VOIP) emergency calls
US8525681B2 (en) 2008-10-14 2013-09-03 Telecommunication Systems, Inc. Location based proximity alert
US8892128B2 (en) 2008-10-14 2014-11-18 Telecommunication Systems, Inc. Location based geo-reminders
US9301191B2 (en) 2013-09-20 2016-03-29 Telecommunication Systems, Inc. Quality of service to over the top applications used with VPN
US8867485B2 (en) 2009-05-05 2014-10-21 Telecommunication Systems, Inc. Multiple location retrieval function (LRF) network having location continuity
US8315599B2 (en) 2010-07-09 2012-11-20 Telecommunication Systems, Inc. Location privacy selector
US20120006610A1 (en) 2010-07-09 2012-01-12 Erik Wallace Telematics enhanced mobile device safety interlock
JP5569201B2 (ja) * 2010-07-12 2014-08-13 株式会社リコー 画像処理装置、電子証明書設定方法及び電子証明書設定プログラム
JP5488716B2 (ja) * 2010-11-30 2014-05-14 富士通株式会社 鍵更新方法、ノード、ゲートウェイ、サーバ、およびネットワークシステム
WO2012073339A1 (ja) * 2010-11-30 2012-06-07 富士通株式会社 鍵更新方法、ノード、ゲートウェイ、サーバ、およびネットワークシステム
US8942743B2 (en) 2010-12-17 2015-01-27 Telecommunication Systems, Inc. iALERT enhanced alert manager
US8688087B2 (en) 2010-12-17 2014-04-01 Telecommunication Systems, Inc. N-dimensional affinity confluencer
US8682321B2 (en) 2011-02-25 2014-03-25 Telecommunication Systems, Inc. Mobile internet protocol (IP) location
US20120308003A1 (en) * 2011-05-31 2012-12-06 Verisign, Inc. Authentic barcodes using digital signatures
US8649806B2 (en) 2011-09-02 2014-02-11 Telecommunication Systems, Inc. Aggregate location dynometer (ALD)
US9479344B2 (en) 2011-09-16 2016-10-25 Telecommunication Systems, Inc. Anonymous voice conversation
WO2013048551A1 (en) 2011-09-30 2013-04-04 Telecommunication Systems, Inc. Unique global identifier for minimizing prank 911 calls
US9264537B2 (en) 2011-12-05 2016-02-16 Telecommunication Systems, Inc. Special emergency call treatment based on the caller
US9313637B2 (en) 2011-12-05 2016-04-12 Telecommunication Systems, Inc. Wireless emergency caller profile data delivery over a legacy interface
US8984591B2 (en) 2011-12-16 2015-03-17 Telecommunications Systems, Inc. Authentication via motion of wireless device movement
US9384339B2 (en) 2012-01-13 2016-07-05 Telecommunication Systems, Inc. Authenticating cloud computing enabling secure services
US8688174B2 (en) 2012-03-13 2014-04-01 Telecommunication Systems, Inc. Integrated, detachable ear bud device for a wireless phone
US9307372B2 (en) 2012-03-26 2016-04-05 Telecommunication Systems, Inc. No responders online
US9544260B2 (en) 2012-03-26 2017-01-10 Telecommunication Systems, Inc. Rapid assignment dynamic ownership queue
US9338153B2 (en) 2012-04-11 2016-05-10 Telecommunication Systems, Inc. Secure distribution of non-privileged authentication credentials
WO2014028712A1 (en) 2012-08-15 2014-02-20 Telecommunication Systems, Inc. Device independent caller data access for emergency calls
US9208346B2 (en) 2012-09-05 2015-12-08 Telecommunication Systems, Inc. Persona-notitia intellection codifier
US9456301B2 (en) 2012-12-11 2016-09-27 Telecommunication Systems, Inc. Efficient prisoner tracking
US8983047B2 (en) 2013-03-20 2015-03-17 Telecommunication Systems, Inc. Index of suspicion determination for communications request
US9408034B2 (en) 2013-09-09 2016-08-02 Telecommunication Systems, Inc. Extended area event for network based proximity discovery
US9516104B2 (en) 2013-09-11 2016-12-06 Telecommunication Systems, Inc. Intelligent load balancer enhanced routing
US9479897B2 (en) 2013-10-03 2016-10-25 Telecommunication Systems, Inc. SUPL-WiFi access point controller location based services for WiFi enabled mobile devices
US10769626B2 (en) * 2015-12-17 2020-09-08 Mastercard International Incorporated Method and system for distribution, use and validation of electronic entitlement certificates
US11463267B2 (en) * 2016-09-08 2022-10-04 Nec Corporation Network function virtualization system and verifying method
KR102382851B1 (ko) 2017-07-04 2022-04-05 삼성전자 주식회사 eSIM 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5745574A (en) * 1995-12-15 1998-04-28 Entegrity Solutions Corporation Security infrastructure for electronic transactions
AU2908101A (en) * 1999-12-20 2001-07-03 Online Resources Corp. Method and apparatus for securely conducting financial transactions over an insecure network
US7010690B1 (en) * 2000-07-07 2006-03-07 Sun Microsystems, Inc. Extensible system for building and evaluating credentials
US7107248B1 (en) 2000-09-11 2006-09-12 Nokia Corporation System and method of bootstrapping a temporary public-key infrastructure from a cellular telecommunication authentication and billing infrastructure
US6940979B1 (en) * 2000-11-09 2005-09-06 Nortel Networks Limited Management of certificates for public key infrastructure
US7110986B1 (en) * 2001-04-23 2006-09-19 Diebold, Incorporated Automated banking machine system and method
US7114175B2 (en) * 2001-08-03 2006-09-26 Nokia Corporation System and method for managing network service access and enrollment

Also Published As

Publication number Publication date
WO2003071734A1 (en) 2003-08-28
US8397060B2 (en) 2013-03-12
EP1476980B1 (en) 2017-09-13
AU2002309088A1 (en) 2003-09-09
US20050086467A1 (en) 2005-04-21
EP1476980A1 (en) 2004-11-17
DK1476980T3 (da) 2017-11-13

Similar Documents

Publication Publication Date Title
ES2644739T3 (es) Solicitud de certificados digitales
US20210258162A1 (en) Methods for secure cryptogram generation
CN108270571B (zh) 基于区块链的物联网身份认证系统及其方法
US7047405B2 (en) Method and apparatus for providing secure processing and data storage for a wireless communication device
US9160732B2 (en) System and methods for online authentication
ES2626064T3 (es) Procedimiento y sistema para autenticar a un usuario que utiliza un dispositivo móvil y por medio de certificados
US7194765B2 (en) Challenge-response user authentication
US20110022835A1 (en) Secure Communication Using Asymmetric Cryptography and Light-Weight Certificates
JP4213664B2 (ja) サービス合意の否認防止（ｎｏｎ−ｒｅｐｕｄｉａｔｉｏｎ）
KR100910432B1 (ko) 무선 통신 장치용 보안 처리 및 데이터 저장을 제공하는 방법 및 장치
ES2923919T3 (es) Protección de una comunicación P2P
EP3178073B1 (en) Security management system for revoking a token from at least one service provider terminal of a service provider system
AU2015202661B2 (en) System and methods for online authentication
JP3634279B2 (ja) 複数ｉｃカード間及び同一ｉｃカード内のアプリケーション連携方法
AU2016228254A1 (en) System and methods for online authentication
CN103888263B (zh) 一种应用于移动商务系统的安全解决方法
RU2282311C2 (ru) Использование пары открытых ключей в оконечном устройстве для аутентификации и авторизации пользователя телекоммуникационной сети по отношению к сетевому провайдеру и деловым партнерам
KR20100052587A (ko) 스마트카드 기반의 원격 사용자 인증 방법
AU2015202677B2 (en) System and methods for online authentication