ES2712150T3 - Sistemas y métodos para comunicación segura - Google Patents

Sistemas y métodos para comunicación segura Download PDF

Info

Publication number
ES2712150T3
ES2712150T3 ES14728765T ES14728765T ES2712150T3 ES 2712150 T3 ES2712150 T3 ES 2712150T3 ES 14728765 T ES14728765 T ES 14728765T ES 14728765 T ES14728765 T ES 14728765T ES 2712150 T3 ES2712150 T3 ES 2712150T3
Authority
ES
Spain
Prior art keywords
terminal
mobile device
public key
key
authentication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES14728765T
Other languages
English (en)
Inventor
Weiming Tang
James Brewer
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.)
Wayne Fueling Systems LLC
Original Assignee
Wayne Fueling Systems LLC
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 Wayne Fueling Systems LLC filed Critical Wayne Fueling Systems LLC
Application granted granted Critical
Publication of ES2712150T3 publication Critical patent/ES2712150T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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
    • H04L9/3265—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 using certificate chains, trees or paths; Hierarchical trust model
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • 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
    • 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
    • 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/045—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 hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un terminal (102), que comprende un transceptor (218) inalámbrico configurado para comunicar inalámbricamente con un dispositivo (104) móvil; un elemento (216) seguro configurado para almacenar una o más claves criptográficas pre-validadas; y un procesador (202) acoplado al elemento seguro y al transceptor inalámbrico, estando el procesador programado para recibir (S802), mediante el transceptor inalámbrico, una solicitud de autenticación desde el dispositivo móvil, autenticar el dispositivo móvil validando la solicitud de autenticación basándose en la una o más claves criptográficas pre-validadas almacenadas en el elemento seguro, generar una clave de sesión basándose en un número aleatorio recibido en la solicitud de autenticación, transmitir (S820), mediante el transceptor inalámbrico, cuando el dispositivo móvil está autenticado satisfactoriamente, una respuesta de autenticación que incluye la clave de sesión al dispositivo móvil, y recibir (S828) información segura desde el dispositivo móvil, encriptándose la información segura por la clave de sesión.

Description

DESCRIPCION
Sistemas y metodos para comunicacion segura
Campo
La materia objeto desvelada en el presente documento se refiere en general a sistemas y metodos para asegurar la comunicacion inalambrica, y mas particularmente a pago inalambrico seguro en un entorno de dispensacion de combustible.
Antecedentes
Se ha desarrollado un numero de sistemas de pago movil en los que un dispositivo movil puede usarse para pagar por bienes o servicios en un terminal de pago. En algunos sistemas, el dispositivo movil no comunica directamente con el terminal de pago. En su lugar, la transaccion se realiza entre una infraestructura de pago de dispositivo movil y una infraestructura de pago comercial. Integrar estas infraestructuras complejas y ampliamente divergentes, sin embargo, puede a menudo ser prohibitivo en coste.
Otros sistemas implican comunicacion directa entre el dispositivo movil y el terminal de pago. En tales sistemas, se transmiten datos de usuario sensibles tales como informacion de pago y de fidelizacion como texto limpio, elevando un numero de problemas de seguridad. Por ejemplo, los datos de usuario sensibles pueden interceptarse por terceras partes sin escrupulos. Esto puede ser de preocupacion particular en entornos de aprovisionamiento de combustible, donde el terminal de pago a menudo esta dispuesto en una configuracion de exteriores sin nombre donde existe un riesgo elevado de espionaje o manipulacion. Puede desalentarse a los usuarios de usar tales sistemas por temor de que el terminal de pago pueda haberse comprometido.
Aunque se han desarrollado algunos esquemas de comunicacion seguros, no se han aplicado en sistemas de pago movil. Ademas, tipicamente implican validacion en tiempo de ejecucion de certificados digitales y un procedimiento de toma de contacto complejo en el que tienen lugar varias rondas de intercambio de datos de carga util grande. Tales esquemas introducen por lo tanto retardos significativos, y son problematicos y consumen tiempo para el usuario.
Por consiguiente, existe una necesidad de sistemas de pago movil mejorados.
El documento EP 1653655 (Research In Motion Limited) se refiere a un sistema y metodo para verificar una firma digital en un certificado, que puede usarse en el procesamiento de mensajes codificados. En una realizacion, cuando una firma digital se verifica satisfactoriamente en una operacion de verificacion de firma, se almacena en cache la clave publica usada para verificar esa firma digital. Cuando se realiza un intento posterior para verificar la firma digital, la clave publica a usarse para verificar la firma digital se compara a la clave almacenada en cache. Si las claves coinciden, la firma digital puede verificarse satisfactoriamente sin requerir que se realice una operacion de verificacion de firma en la que algunos datos se decodifican usando la clave publica.
El documento US 2008/294894 (Microsoft Corporation) describe sistemas, metodos, y/o tecnicas para vincular licencias de contenido a dispositivos de almacenamiento portatiles. En relacion con la vinculacion de las licencias de contenido a los dispositivos de almacenamiento portatiles, un anfitrion puede realizar protocolos de autenticacion que incluyen generar un numero aleatorio utilizado solo una vez, enviar el numero aleatorio utilizado solo una vez a una tienda, y recibir una clave de sesion de la tienda, generandose la clave de sesion usando el numero aleatorio utilizado solo una vez. La tienda puede realizar protocolos de autenticacion que incluyen recibir el numero aleatorio utilizado solo una vez desde el anfitrion, generar una clave de sesion aleatoria basandose en el numero aleatorio utilizado solo una vez, y enviar la clave de sesion al anfitrion.
Breve descripcion
Puede conseguirse comunicacion movil rapida y segura en algunas realizaciones con sistemas y metodos que validan una solicitud de autenticacion basandose en una o mas claves criptograficas pre-validadas.
Se desvelan en el presente documento sistemas y metodos para proporcionar comunicacion segura entre un terminal de pago y un dispositivo movil, por ejemplo, en un entorno de aprovisionamiento de combustible. En algunas realizaciones, el terminal de pago y el dispositivo movil realizan un proceso de autenticacion mutua que, si es satisfactorio, produce una clave de sesion que puede usarse para encriptar datos sensibles para intercambiarse entre el terminal de pago y el dispositivo movil. El proceso de autenticacion mutua puede expedirse, por ejemplo, transfiriendo una clave publica en lugar de un certificado completo y/o manteniendo en cada dispositivo una base de datos de certificados pre-autenticados indexados por una tabla de busqueda. Los certificados pre-autenticados pueden ser superiores en una jerarqrna de confianza a certificados de nivel de unidad asociados con un dispositivo movil particular o terminal de pago, de manera que se reduce la cantidad de validacion que debe realizarse en tiempo de ejecucion.
Breve descripcion de los dibujos
Estas y otras caractensticas se entenderan mas facilmente a partir de la siguiente descripcion detallada tomada en conjunto con los dibujos adjuntos, en los que:
La Figura 1 es un diagrama esquematico de una realizacion ejemplar de un entorno de aprovisionamiento de combustible;
La Figura 2 es un diagrama esquematico de una realizacion ejemplar de un sistema informatico;
La Figura 3 es un diagrama esquematico de una realizacion ejemplar de un terminal de pago;
La Figura 4 es un diagrama esquematico de una realizacion ejemplar de una jerarqrna de certificados;
La Figura 5 es un diagrama de secuencia de un metodo ejemplar de gestion de certificados digitales durante la produccion de un terminal de pago;
La Figura 6 es un diagrama esquematico de una realizacion ejemplar de un dispositivo movil;
La Figura 7 es un diagrama de secuencia de una realizacion ejemplar de un metodo de autenticacion mutua realizado por un terminal de pago y un dispositivo movil;
La Figura 8 es un diagrama de flujo que representa el metodo de la Figura 7 desde la perspectiva del terminal de pago; y la Figura 9 es un diagrama de flujo que representa el metodo de la Figura 7 desde la perspectiva del dispositivo movil.
Se observa que los dibujos no estan necesariamente a escala. Los dibujos se pretende que representen unicamente aspectos tfpicos de la materia objeto desvelada en el presente documento, y por lo tanto no debenan considerarse como que limitan el alcance de la divulgacion. En los dibujos, numeracion similar representa elementos similares entre los dibujos.
Descripcion detallada
Se describiran ahora ciertas realizaciones ejemplares para proporcionar un entendimiento global de los principios de la estructura, funcion, fabricacion y uso de los dispositivos, sistemas, y metodos desvelados en el presente documento.
Se desvelan en el presente documento sistemas y metodos para proporcionar comunicacion segura entre un terminal de pago y un dispositivo movil, por ejemplo, en un entorno de aprovisionamiento de combustible. En algunas realizaciones, el terminal de pago y el dispositivo movil realizan un proceso de autenticacion mutua que, si es satisfactorio, produce una clave de sesion que puede usarse para encriptar datos sensibles para intercambiarse entre el terminal de pago y el dispositivo movil. El proceso de autenticacion mutua puede expedirse, por ejemplo, transfiriendo una clave publica en lugar de un certificado completo y/o manteniendo en cada dispositivo una base de datos de certificados pre-autenticados indexados por una tabla de busqueda. Los certificados pre-autenticados pueden ser superiores en una jerarqrna de confianza a certificados de nivel de unidad asociados con un dispositivo movil particular o terminal de pago, de manera que se reduce la cantidad de validacion que debe realizarse en tiempo de ejecucion.
Entorno de aprovisionamiento de combustible
La Figura 1 ilustra una realizacion ejemplar de un entorno 100 de aprovisionamiento de combustible en el que pueden implementarse uno o mas de los sistemas y metodos desvelados en el presente documento. El entorno 100 de aprovisionamiento de combustible incluye en general un terminal 102 de pago y un dispositivo 104 movil asociado con un usuario (por ejemplo, un cliente que busca adquirir combustible o personal de servicio que busca acceso de servicio al terminal de pago).
El terminal 102 de pago puede estar integrado con un dispensador 106 de combustible, que puede incluir diversas caractensticas bien entendidas por los expertos en la materia tales como una boquilla, una bomba, botones para seleccionar el grado de combustible, una pantalla de visualizacion y asf sucesivamente. El terminal 102 de pago puede incluir un sistema informatico, como se describe a continuacion. El terminal 102 de pago puede estar acoplado a un servidor 108 de extremo trasero, que puede estar configurado para comunicar con diversas redes, tales como una red 110 de fidelizacion de aprovisionamiento de combustible para mantener, comprobar y actualizar informacion de fidelizacion de cliente y una red 112 de pago de combustible para procesar compra de combustible y otras transacciones. Juntos, el servidor 108 de extremo trasero, la red 110 de fidelizacion de aprovisionamiento de combustible, y la red 112 de pago de aprovisionamiento de combustible forman una infraestructura de pago de aprovisionamiento de combustible.
El dispositivo 104 movil puede incluir tambien un sistema informatico, como se describe a continuacion. El dispositivo 104 movil puede estar configurado para comunicar con diversas redes, tales como una nube 114 de fidelizacion movil para mantener, comprobar y actualizar informacion de fidelizacion de cliente y una nube 116 de pago movil para procesar compras y otras transacciones ejecutadas usando el dispositivo 104 movil. La nube 114 de fidelizacion movil y la nube 116 de pago movil juntas forman una infraestructura de pago movil. El dispositivo 104 movil puede ser o puede incluir cualquier dispositivo que este configurado para intercambiar datos a traves de una red de comunicaciones, tal como un telefono movil, ordenador de tableta, ordenador portatil, monedero digital, y asf sucesivamente. El dispositivo movil puede sujetarse por un usuario o estar integrado con un objeto movible.
El terminal 102 de pago y el dispositivo 104 movil pueden autenticarse mutualmente entre sf para facilitar comunicacion de pago segura u otra informacion directamente entre el terminal 102 de pago y el dispositivo 104 movil. Un canal de comunicacion seguro entre el terminal 102 de pago y el dispositivo 104 movil puede permitir pago movil seguro sin requerir que se cambien o se integren la infraestructura de pago de aprovisionamiento de combustible y la infraestructura de pago movil.
Aunque se muestra un entorno de aprovisionamiento de combustible en la Figura 1, se apreciara que los sistemas y metodos desvelados en el presente documento pueden aplicarse facilmente en otros ajustes, por ejemplo, cualquier ajuste en el que se use un dispositivo movil para realizar una transaccion con un terminal. Las transacciones pueden incluir transacciones de pago, transacciones de reembolso, transacciones de servicio, transacciones de control, o cualquier otra transaccion que requiera comunicacion. Los terminales pueden incluir terminales de pago, quioscos, y asf sucesivamente, y/o pueden ser parte de un dispensador (por ejemplo, un dispensador de combustible, un dispensador de aperitivos o bebidas, un dispensador de efectivo, etc.).
Sistema informatico
La Figura 2 ilustra una arquitectura ejemplar de un sistema 200 informatico que puede usarse para implementar el terminal 102 de pago o el dispositivo 104 movil de la Figura 1. Aunque se representa y describe un sistema 200 informatico ejemplar en el presente documento, se apreciara que esto es por motivo de generalidad y conveniencia. En otras realizaciones, el sistema informatico puede diferenciarse en arquitectura y operacion de la mostrada y descrita en el presente documento.
El sistema 200 informatico puede incluir un procesador 202 que controla la operacion del sistema 200 informatico, por ejemplo ejecutando un sistema operativo (SO), controladores de dispositivo, programas de aplicacion, y asf sucesivamente. El procesador 202 puede incluir cualquier tipo de microprocesador o unidad de procesamiento central (CPU), incluyendo microprocesadores de fin general o de fin especial programables y/o cualquiera de una diversidad de sistemas de unico o multiple procesador propietarios o comercialmente disponibles.
El sistema 200 informatico puede incluir tambien una memoria 204, que proporciona almacenamiento temporal o permanente para que se ejecute codigo por el procesador 202 o para datos que se procesan por el procesador 202. La memoria 204 puede incluir memoria de solo lectura (ROM), memoria flash, una o mas diversidades de memoria de acceso aleatorio (RAM), y/o una combinacion de tecnologfas de memoria.
Los diversos elementos del sistema 200 informatico pueden acoplarse entre sf. Por ejemplo, el procesador 202 puede acoplarse a la memoria 204. Los diversos elementos del sistema 200 informatico pueden acoplarse directamente entre sf o pueden acoplarse entre sf mediante uno o mas componentes intermedios. En la realizacion ilustrada, los diversos elementos del sistema 200 informatico estan acoplados a un sistema 206 de bus. El sistema 206 de bus ilustrado es una abstraccion que representa uno cualquiera o mas buses ffsicos separados, lmeas/interfaces de comunicacion, y/o conexiones multipunto o de punto a punto, conectadas por puentes adaptadores y/o controladores apropiados.
El sistema 200 informatico puede incluir tambien una interfaz 208 de red que posibilita que el sistema 200 informatico comunique con dispositivos remotos (por ejemplo, otros sistemas informaticos) a traves de una red. En el caso del terminal 102 de pago, la interfaz de red puede facilitar comunicacion con el servidor 108 de extremo trasero, la red 110 de fidelizacion de aprovisionamiento de combustible, y la red 112 de pago de aprovisionamiento de combustible. En el caso del dispositivo 104 movil, la interfaz de red puede facilitar comunicacion con la nube 114 de fidelizacion movil y la nube 116 de pago movil, por ejemplo mediante Wi-Fi o una red de datos celular.
El sistema 200 informatico puede incluir tambien una interfaz 210 de entrada/salida (E/S) que facilita comunicacion entre uno o mas dispositivos de entrada, uno o mas dispositivos de salida, y los diversos otros componentes del sistema 200 informatico. Dispositivos de entrada y salida ejemplares incluyen teclados numericos, pantallas tactiles, botones, lectores de tarjeta de banda magnetica, luces, altavoces, y asf sucesivamente.
El sistema 200 informatico puede incluir tambien un dispositivo 212 de almacenamiento, que puede incluir cualquier medio convencional para almacenar datos de una manera no volatil y/o no transitoria. El dispositivo 212 de almacenamiento puede por lo tanto mantener datos y/o instrucciones en un estado persistente (es decir, el valor se mantiene a pesar de la interrupcion de alimentacion en el sistema 200 informatico). El dispositivo 212 de almacenamiento puede incluir una o mas unidades de disco duro, unidades flash, unidades USB, unidades opticas, diversos discos o tarjetas de medios y/o cualquier combinacion de los mismos y que pueden estar directamente conectados a los otros componentes del sistema 200 informatico o conectados de manera remota a los mismos, tal como a traves de una red.
El sistema 200 informatico puede incluir tambien un controlador 214 de visualizacion que puede incluir un procesador de video y una memoria de video, y puede generar que se visualicen imagenes en una o mas pantallas de acuerdo con instrucciones recibidas desde el procesador 202.
El sistema 200 informatico puede incluir tambien un elemento 216 seguro. El elemento 216 seguro puede ser una plataforma resistente a la manipulacion (por ejemplo, un microcontrolador seguro de un chip) que puede alojar de manera segura aplicaciones y sus datos confidenciales y criptograficos (por ejemplo, gestion de clave) de acuerdo con los requisitos de reglas y seguridad expuestos por un conjunto de autoridades confiables bien identificadas. El elemento 216 seguro puede proporcionar generacion de numero aleatorio, generar pares de clave publica/privada espedficos de dispositivo y ejecutar un algoritmo de seguridad. Ejemplos conocidos de algoritmos de seguridad incluyen, pero sin limitacion: Hash, TDES, AES, RSA, etc. Elementos 216 seguros ejemplares incluyen Tarjetas de Circuito Integrado Universales (UICC), elementos seguros embebidos, y tarjetas micro Secure Digital (microSD).
El sistema 200 informatico puede incluir tambien una interfaz 218 de comunicacion segura a traves de la cual el sistema 200 informatico puede realizar procedimientos de autenticacion mutua y comunicar con otros sistemas informaticos. La interfaz 218 de comunicacion segura puede ser inalambrica (por ejemplo, comunicacion de campo cercano (NFC), Wi-Fi, Bluetooth, y similares) o alambrica (por ejemplo, USB o Ethernet). En el caso de NFC, por ejemplo, el sistema 200 informatico puede incluir un transceptor de radio configurado para comunicar con un transceptor de radio de otro dispositivo usando una o mas normas tales como ISO/IEC 14443, FeliCa, ISO/IEC 18092, y aquellas definidas por el Foro NFC.
Modulos en general
Las diversas funciones realizadas por el terminal 102 de pago y el dispositivo 104 movil pueden describirse logicamente como que se realizan por uno o mas modulos. Se apreciara que tales modulos pueden implementarse en hardware, software, o una combinacion de los mismos. Se apreciara adicionalmente que, cuando se implementan en software, los modulos pueden ser parte de un unico programa o uno o mas programas separados, y pueden implementarse en una diversidad de contextos (por ejemplo, como parte de un sistema operativo, un controlador de dispositivo, una aplicacion independiente, y/o combinaciones de los mismos). Ademas, el software que incorpora uno o mas modulos puede almacenarse como un programa ejecutable en uno o mas medios de almacenamiento no transitorios legibles por ordenador. Las funciones desveladas en el presente documento como que se realizan por un modulo particular pueden utilizarse tambien por cualquier otro modulo o combinacion de modulos, y el terminal 102 de pago y el dispositivo 104 movil pueden incluir menos o mas modulos que lo que se muestra y describe en el presente documento.
Modulos de terminal de pago
La Figura 3 es un diagrama esquematico de los modulos de una realizacion ejemplar del terminal 102 de pago. Como se muestra, el terminal 102 de pago puede incluir un modulo 302 de certificado, un modulo 304 de recepcion de solicitud de autenticacion, un modulo 306 de autenticacion, un modulo 308 de generacion de clave de sesion, un modulo 310 de transmision de respuesta de autenticacion, y un modulo 312 de recepcion de informacion segura.
El modulo 302 de certificado puede mantener un repositorio 316 de uno o mas certificados digitales y una tabla 314 de busqueda asociada. La Figura 4 ilustra una jerarqrna 400 de certificados ejemplar que puede mantenerse por el modulo 302 de certificado.
Como se muestra, la jerarqrna puede incluir un certificado 402 rafz que identifica una Autoridad de Certificado Rafz (CA rafz) normalizada industrial. CA Rafz ejemplares incluyen VeriSign, GlobalSign, DigiCert, y similares. El certificado 402 rafz forma la rafz de confianza para la jerarqrna 400 de certificado, y puede ser un certificado de clavel publica sin firma o un certificado auto-firmado. La confiabilidad del certificado 402 rafz puede establecerse por distribucion ffsica segura, por ejemplo, durante la produccion del terminal 102 de pago como se analiza en detalle adicional a continuacion. Por conveniencia de descripcion, el certificado 402 rafz se denomina en el presente documento como un certificado de nivel 1 o "L1". Se apreciara que la jerarqrna 400 puede incluir una pluralidad de certificados L1, por ejemplo, emitidos desde una pluralidad de diferentes CA rafz. Cada certificado L1, o la clave publica contenida en el mismo, puede asociarse con un identificador unico (un "LevelliD"). El LevelliD puede ser una asignacion de numero unico industrial similar a una direccion de MAC, una funcion de troceo de todo el certificado L1, o algun otro codigo unico, cadena, numero, etc. Cada certificado L1 o su clave publica y el correspondiente identificador unico pueden asociarse entre sf en la tabla 314 de busqueda de manera que, cuando se proporciona un identificador unico, el certificado o certificados asociados o la clave o claves publicas pueden recuperarse rapidamente desde el repositorio 316 de certificados.
La jerarqma de certificados puede incluir tambien uno o mas niveles de certificados subordinados que se firman por una autoridad de certificado superior y de esta manera heredan la confiabilidad de la autoridad de certificado superior.
En la realizacion ilustrada, por ejemplo, la jerarqma 400 incluye uno o mas certificados 404 de red de terminal de pago emitidos de redes de pago tales como bancos de emision de tarjeta, u otros procesadores de pago. La jerarqma 400 ilustrada tambien incluye uno o mas certificados 406 de operadora movil emitidos de operadoras moviles. Por conveniencia de descripcion, los certificados 404 de red de terminal de pago y los certificados 406 de operadora movil se denominan en el presente documento como certificados de nivel 2 o "L2". Cada certificado L2 puede almacenarse en el repositorio 316 de certificados y el certificado o su clave publica pueden asociarse en la tabla 314 de busqueda con un identificador unico (un "Level2lD"), como se ha descrito anteriormente. Los certificados L2 son inmediatamente subordinados a los certificados L1, y pueden firmarse por lo tanto por la CA rafz para heredar la confiabilidad de la CA rafz. Cada clave publica L2 puede por lo tanto indexarse en la tabla 314 de busqueda por un identificador unico que especifica la clave publica l2 y su clave publica L1 superior (por ejemplo, Level2ID LevelliD).
La jerarqma puede incluir tambien certificados que son subordinados a los certificados L2. En la realizacion ilustrada, por ejemplo, la jerarqma 400 incluye uno o mas certificados 408 de proveedor de terminal de pago emitidos de fabricantes o distribuidores de terminales de pago. La jerarqma 400 puede incluir tambien uno o mas certificados 410 de proveedor de dispositivo movil emitidos de fabricantes o distribuidores de dispositivos moviles. Por conveniencia de descripcion, los certificados 408 de proveedor de terminal de pago y los certificados 410 de proveedor de dispositivo movil se denominan en el presente documento como certificados de nivel 3 o "L3". Cada certificado L3 puede almacenarse en el repositorio 316 de certificados y el certificado o su clave publica puede asociarse en la tabla 314 de busqueda con un identificador unico (un "Level3ID)"), como se ha descrito anteriormente. Los certificados L3 son inmediatamente subordinados a los certificados L2, y pueden por lo tanto firmarse por una autoridad de certificado L2 para heredar la confiabilidad de la autoridad de certificado L2. Cada clave publica L3 puede indexarse por lo tanto en la tabla 314 de busqueda por un identificador unico que especifica la clave publica L3 y sus claves publicas superiores L2 y L1 (por ejemplo, Level3ID Level2ID LevelliD).
La jerarqma 400 puede incluir tambien un certificado 412 espedfico de dispositivo unico para el terminal de pago del individuo 102. Por conveniencia de descripcion, el certificado 412 espedfico de dispositivo se denomina en el presente documento como certificado de nivel 4 o certificado "L4". El certificado L4 puede firmarse por una autoridad de certificado L3 para heredar la confiabilidad de la autoridad de certificado L3.
Los certificados 402 rafz, certificados 404 de red de terminal de pago, certificados 408 de proveedor de terminal de pago, y el certificado 412 de terminal de pago pueden denominarse como certificados del "lado del terminal". Los certificados 402 rafz, certificados 406 de operadora movil, certificados 410 de proveedor de dispositivo movil, y un certificado 414 de dispositivo movil (analizado adicionalmente a continuacion) pueden denominarse como certificados del "lado movil". Los certificados pueden denominarse como "certificados superiores", "certificados mas superiores", "certificados inferiores", "certificados mas inferiores", y asf sucesivamente basandose en su posicion dentro de la jerarqma 400 y el certificado cuya perspectiva se esta describiendo. Por ejemplo, desde la perspectiva de un certificado L4, un certificado L3 puede denominarse como un certificado superior y un certificado L2 puede denominarse como un certificado mas superior. Analogamente, desde la perspectiva de un certificado L4, un certificado L2 puede denominarse como un certificado superior y un certificado L1 puede denominarse como un certificado mas superior.
Aunque se muestra y describe en el presente documento una jerarqma 400 de certificado de cuatro niveles, se apreciara que la jerarqma puede incluir cualquier numero de niveles. Por ejemplo, puede usarse una jerarqma de dos niveles en la que los certificados espedficos de dispositivo se firman directamente por una CA rafz. Puede usarse tambien una jerarqma de tres niveles en la que certificados espedficos de dispositivo se firman por una sub-CA cuyo certificado se firma a su vez por una CA rafz. Pueden usarse tambien las jerarqmas en las que existen tres o mas autoridades de certificado intermedias en la cadena de verdad entre el certificado espedfico de dispositivo y una CA rafz. Ademas, el nivel en la jerarqma en la que reside una entidad particular o clase de certificados puede variar de lo que se muestra y describe en el presente documento. Por ejemplo, los certificados de operadora movil pueden ser subordinados a los certificados de proveedor de dispositivo movil. En algunas realizaciones, el repositorio 316 puede configurarse, para uno o mas certificados en la jerarqma 400, para almacenar unicamente la porcion de clave publica encriptada de dicho certificado o certificados (por ejemplo, los certificados L3 y L4).
En algunas realizaciones, la jerarqma 400 de certificados puede ser parte de una infraestructura de clave publica (PKI), por ejemplo de acuerdo con la norma industrial X.509. Una PKI usa pares de clave publica / clave privada para encriptar y desencriptar de manera segura informacion. Una clave publica puede distribuirse libremente y puede usarse para encriptar la informacion. Para desencriptar la informacion, sin embargo, una parte debe poseer una clave privada asociada con la clave publica. Un algoritmo de encriptacion de clave publica/clave privada ejemplar es el sistema de criptograffa RSA. Un certificado digital puede incluir una clave publica y una firma digital. La firma digital se crea usando una clave privada de la parte, de manera que uno cualquiera con acceso a la clave publica de la parte puede probar ser el firmante que tema acceso a la clave privada de la parte y por lo tanto que la firma es autentica.
Por lo tanto, en el ejemplo anterior, la CA rafz almacena una clave privada en una localizacion altamente segura. El certificado 402 rafz almacenado en el repositorio 316 de certificados incluye la clave publica que corresponde a la clave privada y una firma digital Armada por la CA rafz usando la clave privada. Un certificado 402 râ z bien conocido puede instalarse en un entorno controlado (por ejemplo, durante fabricacion) de manera que puede confiarse en el certificado. Puede confiarse en otros certificados en el repositorio 316 o autenticarse basandose en un sistema jerarquico de claves criptograficas y firmas digitales que se remonta al certificado rafz, como se apreciara por los expertos en la materia.
La Figura 5 ilustra un diagrama de secuencia ejemplar para pre-cargar el repositorio 316 de certificados durante fabricacion o produccion del terminal 102 de pago. Haciendo referencia ahora a las Figuras 3, 4, y 5, en primer lugar, el terminal 102 de pago auto-genera un par de claves L4 espedficas de dispositivo. La clave privada se almacena en una localizacion segura dentro del terminal 102 de pago, por ejemplo, el elemento 216 seguro. La clave publica se entrega a un sistema 500 de gestion de seguridad de produccion con una solicitud para encriptacion. El sistema 500 de gestion de seguridad de produccion encripta la clave publica L4 espedfica de dispositivo usando su propia clave privada (por ejemplo, una clave privada de proveedor de terminal de pago L3). El certificado de clave publica resultante (firmado por la sub-CA L3) se devuelve a continuacion al terminal 102 de pago. Los otros certificados de clave publica en la cadena de verdad para este terminal de pago particular (por ejemplo, el certificado rafz L1402, el certificado 404 de red de terminal de pago L2, y el certificado 408 de proveedor de terminal de pago L3) se envfan tambien al terminal 102 de pago, junto con sus correspondientes identificadores unicos (LevelliD, Level2ID, y Level3ID). Puesto que el sistema 500 de gestion de seguridad de produccion es un entorno controlado, pueden pre-cargarse certificados bien conocidos en el repositorio 316 de certificados del terminal 102 de pago.
El sistema 500 de gestion de seguridad de produccion tambien puede pre-cargar en el repositorio 316 de certificados una pluralidad de certificados del lado movil y sus correspondientes identificadores unicos. Como alternativa, o ademas, uno o mas de los certificados del lado movil pueden cargarse en el repositorio 316 de certificados en el campo, por ejemplo mediante una red tal como la red 112 de pago de aprovisionamiento de combustible. Por lo tanto, cuando se hace necesario que el terminal 102 de pago autentique un dispositivo 104 movil, el terminal de pago puede tener pre-instalado uno o mas certificados en la cadena de verdad del dispositivo movil.
Una vez que se cargan los certificados del lado movil en el repositorio 316 de certificados, pueden pre-autenticarse. Por ejemplo, un certificado del lado movil L3 (por ejemplo, un certificado 410 de proveedor de dispositivo movil) puede pre-autenticarse por el modulo 302 de certificado contra sus correspondientes certificados L2 y L1 de manera que la clave publica L3 puede usarse directamente en tiempo de ejecucion sin requerir que se ejecute un proceso de autenticacion de certificado L3 que consuma tiempo en tiempo de ejecucion. Si la pre-autenticacion es satisfactoria, las claves publicas L1, L2, y L3 ahora confiables pueden almacenarse en el repositorio 316 de certificados con un correspondiente identificador unico que se anade a la tabla 314 de busqueda. En algunas realizaciones, el identificador unico puede ser una concatenacion del LevelliD, el Level2ID, y el Level3ID. El siguiente pseudocodigo demuestra el proceso de pre-autenticar un certificado L3 e indexar su clave publica en la tabla 314 de busqueda de acuerdo con su cadena de verdad:
Level1PubKey = RetrievePublicKeyFromCertificate(Level1);
AddIntolevel1PublicKeylookup (Level1PubKey, Levei11D);
Levei2PubKey = DecryptPubKeyfromCertificate (Level2, Level1PubKey);
AddIntolevei2PublicKeylookup (Levei2PubKey, Levei11D, Levei21D);
Levei3PubKey = DecryptPubKeyFromCertificate (Level 3, Levei2PubKey);
AddIntolevei3PublicKeylookup (Levei3PubKey, Levei11D, Levei21D, Levei31D);
El modulo 302 de certificado puede estar configurado por lo tanto para pre-autenticar uno o mas certificados de lado movil para expedir autenticacion de tiempo de ejecucion de un dispositivo 104 movil.
El modulo 304 de recepcion de solicitud de autenticacion puede estar configurado para recibir una solicitud de autenticacion desde un dispositivo que busca autenticacion (por ejemplo, un dispositivo 104 movil). La solicitud de autenticacion puede incluir una diversidad de informacion. En algunas realizaciones, la solicitud de autenticacion puede incluir una clave publica espedfica de dispositivo (por ejemplo, una clave publica L4) del dispositivo 104 movil. La solicitud puede incluir tambien una o mas claves publicas superiores en la jerarqrna de certificados del lado movil. Aunque la solicitud puede incluir el certificado o certificados completos, en algunas realizaciones, unicamente se incluye la porcion de clave publica del certificado, reduciendo de esta manera la carga util de los datos y acelerando el tiempo de transaccion. La solicitud puede incluir tambien informacion de identificacion para especificar la cadena de verdad mediante la cual el dispositivo 104 movil se remonta a un certificado 402 rafz confiable mutuo. Por ejemplo, la solicitud puede incluir una concatenacion de identificadores unicos asociados con cada certificado (o clave publica de los mismos) en la cadena de verdad. La solicitud puede incluir tambien informacion usada como un precursor a una clave de sesion que finalmente puede usarse para encriptar datos sensibles una vez que la autenticacion mutua esta completa. Por ejemplo, el precursor puede ser o puede incluir un numero aleatorio generado por el dispositivo 104 movil.
El modulo 306 de autenticacion puede estar configurado para validar claves publicas recibidas en la solicitud de autenticacion. En particular, el modulo 306 de autenticacion puede usar la informacion de identificacion en la solicitud para determinar desde la tabla 314 de busqueda el conjunto de claves publicas pre-autenticadas requeridas para desencriptar la clave publica espedfica de dispositivo incluida en la solicitud. El modulo 306 de autenticacion puede estar tambien configurado para solicitar cualesquiera certificados en la cadena que pueden estar faltantes del repositorio 316 de certificados, por ejemplo, desde el dispositivo 104 movil o desde la red 112 de pago de aprovisionamiento de combustible.
El modulo 308 de generacion de clave de sesion puede estar configurado para generar una clave de sesion cuando la solicitud de autenticacion se valida satisfactoriamente. Por ejemplo, el modulo 308 de generacion de clave de sesion puede combinar un precursor de clave de sesion generado por el terminal 102 de pago (por ejemplo, un numero aleatorio) con el precursor de clave de sesion incluido en la solicitud para producir una clave de sesion final. La clave de sesion puede usarse por dos dispositivos mutuamente autenticados para encriptar y desencriptar informacion comunicada entre los dispositivos. El modulo 308 de generacion de clave de sesion puede estar configurado tambien para generar una suma de comprobacion para su uso por una parte mutuamente autenticada para validar la clave de sesion.
El modulo 310 de transmision de respuesta de autenticacion puede estar configurado para transmitir una respuesta de autenticacion al dispositivo 104 movil. La respuesta de autenticacion puede incluir una diversidad de informacion. En algunas realizaciones, la respuesta de autenticacion puede incluir una clave publica espedfica de dispositivo (por ejemplo, una clave publica L4) del terminal 102 de pago. La respuesta puede incluir tambien una o mas claves publicas superiores en la jerarqrna de certificados del lado de terminal. Aunque la respuesta puede incluir el certificado o certificados enteros, en algunas realizaciones, unicamente se incluye la porcion de clave publica del certificado, reduciendo de esta manera la carga util y acelerando el tiempo de transaccion. La respuesta puede incluir tambien informacion de identificacion para especificar la cadena de verdad mediante la cual el terminal 102 de pago se remonta a un certificado 402 rafz mutuo. Por ejemplo, la respuesta puede incluir una concatenacion de identificadores unicos asociados con cada certificado (o clave publica del mismo) en la cadena de verdad. La respuesta puede incluir tambien la clave de sesion encriptada y suma de comprobacion.
El modulo 312 de recepcion de informacion segura puede estar configurado para recibir informacion segura desde un dispositivo autenticado y para desencriptar la informacion usando la clave de sesion. En particular, una informacion de pago o de fidelizacion del usuario puede encriptarse por el dispositivo 104 movil usando la clave de sesion y recibirse por el modulo 312 de recepcion de informacion segura, el modulo 312 de recepcion de informacion segura puede desencriptar a continuacion la informacion usando la clave de sesion de manera que el terminal 102 de pago puede completar la transaccion.
Modulos de dispositivo movil
La Figura 6 es un diagrama esquematico de los modulos de una realizacion ejemplar del dispositivo 104 movil. Como se muestra, el dispositivo 104 movil puede incluir un modulo 602 de certificado, un modulo 604 de transmision de solicitud de autenticacion, un modulo 606 de recepcion de respuesta de autenticacion, un modulo 608 de autenticacion, un modulo 610 de validacion de clave de sesion, y un modulo 612 de transmision de informacion segura. El dispositivo 104 movil puede incluir tambien una tabla 614 de busqueda y un repositorio 616 de certificados.
El modulo 602 de certificado, la tabla 614 de busqueda, y el repositorio 616 de certificados del dispositivo 104 movil son sustancialmente identicos a aquellos del terminal 102 de pago, con unas pocas excepciones como se analiza a continuacion. Una diferencia es que el certificado L4414 en el modulo 602 de certificado corresponde al dispositivo 104 movil en lugar de al terminal 102 de pago. El dispositivo 104 movil se pre-carga con certificados instalados durante fabricacion y produccion del dispositivo 104 movil, o los certificados pueden descargarse mediante la nube 116 de pago movil o la nube 114 de fidelizacion movil. La jerarqrna de certificados del dispositivo 104 movil es la misma que la anteriormente descrita, incluyendo el dispositivo 104 movil los certificados en su propia cadena de verdad asf como uno o mas certificados del lado de terminal pre-autenticados.
El modulo 604 de transmision de solicitud de autenticacion esta configurado para ensamblar la solicitud de autenticacion anteriormente descrita y para enviar la solicitud al terminal 102 de pago cuando se activa por un usuario (por ejemplo, cuando el usuario coloca el dispositivo 104 movil en proximidad al terminal de pago, cuando el usuario lanza una aplicacion en el dispositivo movil, o cuando el usuario acciona un elemento de interfaz de usuario en el dispositivo movil).
El modulo 606 de recepcion de respuesta de autenticacion esta configurado para recibir la respuesta de autenticacion anteriormente descrita del terminal 102 de pago.
El modulo 608 de autenticacion esta configurado para autenticar la clave publica L4 recibida desde el terminal 102 de pago usando un sistema de autenticacion como se ha descrito anteriormente con respecto al modulo 306 de autenticacion del terminal 102 de pago.
El modulo 610 de validacion de clave de sesion esta configurado para desencriptar la clave de sesion recibida desde el terminal 102 de pago usando la clave publica L4 del terminal de pago y para validar la clave de sesion usando la suma de comprobacion recibida desde el terminal de pago.
El modulo 612 de transmision de informacion segura esta configurado para encriptar informacion segura usando la clave de sesion y para transmitir la informacion segura encriptada al terminal 102 de pago para completar una transaccion.
Operacion
Un metodo ejemplar de realizacion de una transaccion mutuamente autenticada se ilustra esquematicamente en las Figuras 7, 8, y 9. Aunque diversos metodos desvelados en el presente documento pueden mostrarse en relacion con diagramas de flujo o diagramas de secuencia, debena observarse que cualquier ordenacion de etapas de metodo implicadas por tales diagramas de flujo, diagramas de secuencia, o la descripcion de los mismos no ha de interpretarse como que limitan el metodo para realizar las etapas en ese orden. En su lugar, las diversas etapas de cada uno de los metodos desvelados en el presente documento pueden realizarse en cualquiera de una diversidad de secuencias. Ademas, como los diagramas de flujo ilustrados y diagramas de secuencia son realizaciones meramente ejemplares, diversos otros metodos que incluyen etapas adicionales o que incluyen menos etapas que las ilustradas tambien estan dentro del alcance de la presente divulgacion.
La Figura 7 es un diagrama de secuencia de la transaccion mutuamente autenticada. El proceso de autenticacion mutua puede implicar, en algunas realizaciones, unicamente un unico intercambio entre el terminal 102 de pago y el dispositivo 104 movil (por ejemplo, una solicitud de autenticacion transmitida desde el dispositivo 104 movil al terminal 102 de pago y una respuesta de autenticacion transmitida desde el terminal 102 de pago al dispositivo 104 movil). Completar el proceso de autenticacion en un unico intercambio puede reducir ventajosamente la cantidad de tiempo requerida para completar una transaccion, aumentando la conveniencia de usuario. Inicialmente, el terminal 102 de pago esta en un estado listo para que un dispositivo 104 movil inicie una transaccion. El terminal 102 de pago puede visualizar un mensaje que solicita que el usuario inicie una transaccion usando su dispositivo 104 movil.
Para comenzar la transaccion, el dispositivo 104 movil envfa una solicitud de autenticacion al terminal 102 de pago. Por ejemplo, el modulo 604 de transmision de solicitud de autenticacion del dispositivo 104 movil puede transmitir una solicitud de autenticacion al modulo 304 de recepcion de solicitud de autenticacion del terminal 102 de pago. La solicitud de autenticacion puede incluir:
(1) la clave publica espedfica de dispositivo (por ejemplo, L4) del dispositivo 104 movil, que se encripta por una clave privada L3 del lado movil,
(2) la clave publica L3 del lado movil, encriptada por una clave privada L2 del lado movil,
(3) un identificador unico que especifica la cadena de claves publicas requeridas para desencriptar la clave publica L4 del dispositivo 104 movil (por ejemplo, Level1iD+ Level2lD Level3lD), y
(4) un numero aleatorio R1 generado por el dispositivo 104 movil y encriptado por la clave privada L4 del dispositivo movil.
Tras la recepcion de la solicitud de autenticacion, el terminal 102 de pago puede intentar autenticar la clave publica L4 recibida usando la tabla 314 de busqueda y el repositorio 316 de certificados. En particular, el modulo 306 de autenticacion del terminal 102 de pago puede usar el identificador unico recibido (Level1ID Level2ID Level3ID) para localizar la clave publica L3 pre-autenticada que desencripta la clave publica L4 del dispositivo 104 movil. Si la clave publica L3 esta presente en el terminal 102 de pago, la clave publica L4 recibida puede desencriptarse y a continuacion usarse para desencriptar el numero aleatorio R1.
En algunos casos, la clave publica L3 que puede desencriptar la clave publica L4 del dispositivo 104 movil puede no precargarse en el terminal 102 de pago. Por ejemplo, el certificado del lado movil L3 puede no estar aun disponible para descargar a traves de la red 112 de pago de aprovisionamiento de combustible, por ejemplo, si el dispositivo 104 movil es de una marca, modelo u operadora particular que es nuevo. En tales casos, el modulo 306 de autenticacion puede usar el identificador unico recibido sin el Level3ID (es decir, Level1 iD Level2ID) para localizar la clave publica L2 pre-autenticada que puede desencriptar la clave publica L3 del dispositivo 104 movil. Si la clave publica L2 esta presente en el terminal 102 de pago, la clave publica L3 recibida puede desencriptarse y a continuacion usarse, como se ha descrito anteriormente, para desencriptar la clave publica L4 que a su vez desencripta el numero aleatorio R1. La clave publica L3 nuevamente desencriptada puede a continuacion almacenarse en el repositorio 316 de certificados para uso futuro y su correspondiente identificador unico (Level 1iD+ Level2ID Level3ID) puede anadirse a la tabla 314 de busqueda.
Si la clave publica L2 no esta presente en el terminal 102 de pago, el terminal de pago puede intentar localizar la clave publica L2 a traves de una red, solicitar la clave publica del dispositivo 104 movil, o denegar la transaccion.
Despues de que se desencripta el numero aleatorio R1, el modulo 308 de generacion de clave de sesion del terminal 102 de pago puede generar una clave de sesion S1 a usarse para llevar a cabo la transaccion. En algunas realizaciones, el modulo 308 de generacion de clave de sesion puede generar su propio numero aleatorio R2 y crear la clave de sesion S1 basandose en una combinacion del numero aleatorio de dispositivo movil R1 y numero aleatorio del terminal de pago R2. Por ejemplo, la clave de sesion S1 puede definirse por la o exclusiva de R1 y R2:
81 = XOR (R1, R2)
El modulo 308 de generacion de clave de sesion puede generar tambien una suma de comprobacion CHKS1 de la clave de sesion S1, por ejemplo calculando un troceo de la clave de sesion:
CHK81 = Hash (81)
El modulo 308 de generacion de clave de sesion puede a continuacion encriptar la clave de sesion S1 usando la clave publica L4 del dispositivo movil, de manera que unicamente la clave privada almacenada en el elemento seguro del dispositivo 216 movil puede usarse para desencriptar y obtener la clave de sesion S1. La suma de comprobacion CHKS1 puede encriptarse usando la propia clave privada L4 del terminal de pago,
El siguiente pseudocodigo demuestra el proceso de autenticacion del dispositivo 104 movil y generacion de la clave de sesion S1 y suma de comprobacion de clave de sesion CHKS1:
PubKey = Lookup(MobileDevicelevei11D MobileDevicelevei21D MobileDevicelevei31D)
If (PubKey == null)
{Levei2PubKey = Lookup (MobileDeviceleveillD MobileDevicelevei21D);
If (Levei2PubKey != null)
{
PubKey = DecryptPubKey (Encrypted Level3 PubKey, Levei2PubKey); NewCertificateAvailable=true;
}
}
If (PubKey !=null)
{
Levei4PubKey=Decrypt (Given Encrypted Level4 Pub Key, PubKey);
R1 = Decrypt (Given Encrypted R1, Levei4PubKey);
R2 = RandomGeneration();
81 = R1 XOR R2;
Encrypted81 = Encrypt (81, Levei4PubKey);
EncryptedCHK81 = Encrypt (Hash(81), MyPrivateKey);
Como se ha indicado anteriormente, si la clave publica L2 del lado movil no esta disponible en el terminal 102 de pago, puede obtenerse en algunos casos a partir de la red 112 de pago de aprovisionamiento de combustible, la red 110 de fidelizacion de aprovisionamiento de combustible, el dispositivo 104 movil, o alguna otra fuente. Un proceso ejemplar para obtener y desencriptar la clave publica del lado movil L2 se demuestra por el siguiente pseudocodigo:
If (Levei2PubKey == null)
{
Obtainlevei2Certificate (*Given Level2);
Level1PubKey =Lookup (Given MobileDevicelevei11D);
If (Level1PubKey == null)
Throw Exception of "No Pre-stored Trusted Level1 Root CA"
Levei2PubKey = DecryptPubKeyFromCertificate (Level2, Level1PubKey);
PubKey = DecryptPubKey (Encrypted Level3 PubKey, Levei2PubKey);
NewCertificateAvailable = true;
Como se ha indicado tambien anteriormente, el terminal 102 de pago puede estar configurado para almacenar nuevos certificados obtenidos en tiempo de ejecucion (por ejemplo, desde el dispositivo 104 movil) y para anadirlos a la tabla 314 de busqueda para facilitar procesamiento mas rapido en el futuro. Un proceso ejemplar para almacenar un nuevo certificado y anadirlo a la tabla 314 de busqueda se demuestra por el siguiente pseudocodigo:
If (NewCertificateAvailable ==true)
{
if (CanStoreAdditionaiPubKeyIntolookupTable() ==true)
{
Addintolevei3LookupTable (PubKey, MobileDevicelevei11D,
MobileDevicelevei21D, MobileDevicelevei31 D);
AddIntolevei2LookupTable (Levei2PubKey, MobileDevicelevei11D,
MobileDevicelevei21D);
ReportToMyNetwork();
}
}
Despues de generar la clave de sesion S1 y la suma de comprobacion de clave de sesion CHKS1, el terminal 102 de pago puede transmitir una respuesta de autenticacion al dispositivo 104 movil. En particular, el modulo 310 de transmision de respuesta de autenticacion del terminal 102 de pago puede transmitir la respuesta de autenticacion al modulo 606 de recepcion de respuesta de autenticacion del dispositivo 104 movil.
La respuesta de autenticacion puede incluir:
(1) la clave publica espedfica de dispositivo (por ejemplo, L4) del terminal 102 de pago, que se encripta por una clave privada L3 del lado de terminal,
(2) la clave publica L3 del lado de terminal, encriptada por una clave privada L2 del lado de terminal,
(3) un identificador unico que especifica la cadena de claves publicas requeridas para desencriptar la clave publica L4 del terminal 102 de pago (por ejemplo, Level1iD Level2ID Level3ID),
(4) la clave de sesion S1, encriptada por la clave publica L4 del dispositivo movil; y
(5) la suma de comprobacion de clave de sesion CHKS1, encriptada por la clave privada L4 del terminal de pago.
Tras la recepcion de la respuesta de autenticacion, el dispositivo 104 movil puede intentar autenticar la clave publica L4 recibida usando la tabla 614 de busqueda y el repositorio 616 de certificados. En particular, el modulo 608 de autenticacion del dispositivo 104 movil puede usar el identificador unico recibido (Level1iD Level2ID Level3ID) para localizar la clave publica L3 pre-autenticada que puede desencriptar la clave publica L4 del terminal 102 de pago. Si la clave publica L3 esta presente en el dispositivo 104 movil, la clave publica L4 recibida puede desencriptarse.
En algunos casos, la clave publica L3 que puede desencriptar la clave publica L4 del terminal 102 de pago puede no pre-cargarse en el dispositivo 104 movil. Por ejemplo, el certificado L3 del lado de terminal, puede no estar aun disponible para descargar a traves de la nube 114 de fidelizacion movil o la nube 116 de pago movil, por ejemplo, si el terminal 102 de pago es de una marca, modelo o red de pago particular que es nuevo. En tales casos, el modulo 608 de autenticacion puede usar el identificador unico recibido sin el Level3lD (es decir, Level1iD+ Level2ID) para localizar la clave publica L2 pre-autenticada que puede desencriptar la clave publica L3 del terminal 102 de pago. Si la clave publica L2 esta presente en el dispositivo 104 movil, la clave publica L3 recibida puede desencriptarse y a continuacion usarse, como se ha descrito anteriormente, para desencriptar la clave publica L4. La clave publica L3 nuevamente desencriptada puede a continuacion almacenarse en el repositorio 616 de certificados para uso futuro y su correspondiente identificador unico (Level1iD Level2ID Level3ID) puede anadirse a la tabla 614 de busqueda.
Si la clave publica L2 no esta presente en el dispositivo 104 movil, el dispositivo movil puede intentar localizar la clave publica L2 a traves de una red, solicitar la clave publica del terminal 102 de pago, o denegar la transaccion.
Si la autenticacion es satisfactoria, el modulo 610 de validacion de clave de sesion puede usar la clave privada L4 del propio dispositivo movil para desencriptar la clave de sesion S1 y usar la clave publica L4 desencriptada del terminal 102 de pago para desencriptar la suma de comprobacion de clave de sesion CHKS1. El modulo 610 de validacion de clave de sesion puede a continuacion comprobar si la suma de comprobacion CHKS1 coincide con la clave de sesion S1. Si se halla una coincidencia, tanto el dispositivo 104 movil como el terminal 102 de pago estan en posesion de la clave de sesion acordada S1 y el proceso de autenticacion mutua esta completo.
La clave de sesion S1 puede a continuacion usarse para encriptar y desencriptar datos de usuario transmitidos entre el dispositivo 104 movil y el terminal 102 de pago. Por ejemplo, el modulo 612 de transmision de informacion segura del dispositivo 104 movil puede encriptar el numero de cuenta primaria del usuario (PAN), fecha de caducidad de tarjeta de credito, y codigo de seguridad de tarjeta de credito (CVV) usando la clave de sesion S1 y puede transmitir los datos encriptados al terminal 102 de pago. El modulo de recepcion de informacion segura 312 del terminal 102 de pago puede recibir la informacion de pago encriptada y desencriptar si se usa la clave de sesion S1. La informacion de fidelizacion de usuario puede comunicarse de una forma similar.
El siguiente pseudocodigo demuestra el proceso de autenticacion del terminal 102 de pago y encriptacion de la informacion de pago usando la clave de sesion S1, asf como obtencion de certificados adicionales y actualizacion de la tabla 614 de busqueda si fuera necesario:
PubKey = Lookup(PaymentTerminallevel11D PaymentTerminallevel21D PaymentTerminallevel31D)
If (PubKey == null)
{
Level2PubKey = Lookup(PaymentTerminallevel11D
PaymentTerminallevel21D);
If (Level2PubKey != null)
{
PubKey = DecryptPubKey (Encrypted Level3 PubKey, Level2PubKey);
NewCertificateAvailable = true;
}
If (Level2PubKey == null)
{
Obtainlevel2Certificate ("Given Level2);
Level1 PubKey = Lookup (Given PaymentTerminallevei11D);
If (Level1 PubKey == null)
Throw Exception of "No Pre-stored Trusted Level1 Root CA"
Level2PubKey = DecryptPubKeyFromCertificate (Level2, Level1 PubKey); PubKey = DecryptPubKey (Encrypted Level3 PubKey, Level2PubKey);
NewCertificateAvailable =true;
}
}
If (PubKey != null)
{
Level4PubKey =Decrypt (Given Encrypted Level4 Pub Key, PubKey);
81 = Decrypt (Given Encrypted 81, MyPrivateKey);
CHK81 = Decrypt(Given Encrypted CHK81, Level4PubKey);
If (Hash(81) == CHK81)
{
EncryptedCardData = EncryptCardData (PAN, Expiration, CVV, 81);
}
}
If (NewCertificateAvailable ==true)
{
If (Can8toreAdditionalPubKeyIntolookupTable() ==true) {
AddIntolevel3LookupTable (PubKey, PaymentTerminallevei11D, PaymentTerminallevei21D, PaymentTerminallevel31D);
AddIntolevel2LookupTable (Level2PubKey, PaymentTerminallevei11D, PaymentTerminallevei21D);
ReportToMyNetwork();
}
}
Una vez recibido por el terminal 102 de pago, la informacion de pago y/o de fidelizacion puede procesarse a traves de la red 112 de pago de combustible y la red de fidelizacion de combustible 110 de la misma manera como si el usuario hubiera presentado una tarjeta de plastico de banda magnetica tradicional.
La Figura 8 proporciona una vista general del metodo anteriormente descrito desde la perspectiva del terminal 102 de pago. Inicialmente, en la etapa S800, el terminal 102 de pago esta en reposo. En la etapa S802, se recibe una solicitud de autenticacion de entrada desde un dispositivo 104 movil. En el bloque de decision D804, el terminal 102 de pago determina si una clave publica L3 que puede desencriptar la clave publica L4 recibida del dispositivo 104 movil esta disponible. Si no, el terminal 102 de pago determina en el bloque de decision D806 si una clave publica L2 que puede desencriptar la clave publica L3 recibida esta disponible. Si no, se solicita el certificado L2 desde el dispositivo 104 movil en la etapa S808, recibida en la etapa S810, y se evalua para confiabilidad en el bloque de decision D812. Si el certificado L2 no es confiable, la autenticacion mutua falla en la etapa S814. Si el certificado L2 es confiable o si la clave publica L2 esta disponible en el terminal 102 de pago, la clave publica L3 se desencriptan en la etapa S816. Si la clave publica L3 se desencripta en la etapa S816 o esta disponible en el bloque de decision D804, la clave publica L4 recibida y, a su vez, el numero aleatorio R1 recibido se desencripta en la etapa S818. En la etapa S820, la respuesta de autenticacion se entrega al dispositivo 104 movil para autenticacion y el terminal 102 de pago espera una respuesta del dispositivo movil en la etapa S822. Si el dispositivo 104 movil solicita el certificado L2 del lado de terminal (sf en el bloque de decision D824), se transmite al dispositivo movil en la etapa S826 y la ejecucion vuelve a la etapa S822, si el dispositivo 104 movil puede autenticar el terminal 102 de pago, se recibe informacion de pago y/o de fidelizacion encriptada desde el dispositivo movil en la etapa S828 y el pago se procesa en la etapa S830.
La Figura 9 proporciona una vista general del metodo anteriormente descrito desde la perspectiva del dispositivo 104 movil. Inicialmente en la etapa S900, el dispositivo 104 movil recibe una instruccion para iniciar una transaccion, por ejemplo cuando un usuario lanza una aplicacion de pago movil o acciona un boton u otra interfaz de elemento de usuario. En la etapa S902, el dispositivo 104 movil envfa una solicitud de autenticacion al terminal 102 de pago, y espera en la etapa S904 para una respuesta desde el terminal de pago. Si el dispositivo 104 movil recibe una solicitud desde el terminal 102 de pago para el certificado L2 del lado movil, (sf en el bloque de decision D906), el dispositivo movil envfa el certificado en la etapa S908 y la ejecucion vuelve a la etapa S904. De otra manera, el dispositivo 104 movil procesa la respuesta de autenticacion recibida desde el terminal 102 de pago y determina en el bloque de decision D910 si una clave publica L3 que puede desencriptar la clave publica L4 del terminal de pago esta presente en el dispositivo movil. Si no, el dispositivo 104 movil determina en el bloque de decision D912 si una clave publica L2 que puede desencriptar la clave publica L3 recibida esta disponible. Si no, se solicita el certificado L2 desde el terminal de pago en la etapa S914, recibido en la etapa S916, y se evalua para confiabilidad en el bloque de decision D918. Si el certificado L2 no es confiable, la autenticacion mutua falla en la etapa S920. Si el certificado L2 es confiable o si la clave publica L2 esta disponible en el dispositivo 104 movil, la clave publica L3 se desencripta en la etapa S922. Si la clave publica L3 se desencripta en la etapa S922 o estaba disponible en el bloque de decision D910, la clave publica L4 recibida y, a su vez, la clave de sesion S1 recibida se desencriptan en la etapa S924. Finalmente, en la etapa S926, el dispositivo 104 movil envfa datos sensibles encriptados por la clave de sesion S1 al terminal 102 de pago.
En los ejemplos anteriores, la solicitud de autenticacion y la respuesta de autenticacion cada una incluye una clave publica L4 encriptada y una clave publica L3 encriptada. Se apreciara, sin embargo, que pueden incluirse mas o menos claves publicas en la solicitud de autenticacion y/o la respuesta de autenticacion. Por ejemplo, la solicitud y/o la respuesta pueden incluir unicamente una unica clave (por ejemplo, la clave publica L4 encriptada). Por medio de ejemplos adicionales, la solicitud y/o la respuesta pueden incluir la clave publica L4 encriptada, la clave publica L3 encriptada, y una o mas claves adicionales, tal como una clave publica L2 encriptada.
El metodo de las Figuras 7, 8, y 9 puede por lo tanto permitir que el terminal 102 de pago y el dispositivo 104 movil de la Figura 1 participen en comunicacion segura usando un proceso de autenticacion rapida mutua. En particular, el terminal 102 de pago puede recibir una solicitud de autenticacion desde el dispositivo 104 movil y, si el dispositivo movil esta autenticado, contestar con una respuesta de autenticacion. Despues de este unico intercambio, suponiendo que la autenticacion es satisfactoria, ambas partes poseen una clave de sesion segura que puede usarse para encriptar informacion sensible para transmision inalambrica. Por ejemplo, el dispositivo 104 movil puede usar la clave de sesion para encriptar informacion de pago o de fidelizacion de cliente y transmitir la informacion encriptada al terminal 102 de pago, que puede desencriptar la informacion usando la clave de sesion y a continuacion procesa la informacion a traves de canales normales.
Acceso de servicio
En algunas realizaciones, el dispositivo movil puede ser un dispositivo movil de servicio posefdo por usuario que busca acceder al terminal de pago, o un dispensador de combustible u otro sistema del cual sea una parte, para fines de servicio. En tales casos, en lugar de transmitir informacion de pago o de fidelizacion tras la finalizacion del proceso de autenticacion mutua, el dispositivo movil de servicio puede configurarse para transmitir una instruccion para abrir o desbloquear una puerta de servicio, realizar una prueba de diagnostico o realizar otras funciones relacionadas de servicio. Si el dispositivo movil de servicio esta autenticado por el terminal de pago, el terminal de pago puede responder a la solicitud de servicio controlando un accionador para abrir o desbloquear la puerta de servicio, etc. Por consiguiente, puede autenticarse a personal de servicio para evitar acceso no autorizado o servicio de campo no autorizado u operaciones de resolucion de problemas, proporcionando de esta manera seguridad mejorada en comparacion con un modelo de clave mecanica tradicional.
Ventajas / efectos tecnicos
Los sistemas y metodos desvelados en el presente documento pueden producir un numero de ventajas y/o efectos tecnicos.
Por ejemplo, en algunas realizaciones, los certificados digitales se pre-almacenan y pre-autentican en el terminal de pago y el dispositivo movil, de manera que puede intercambiarse un par de clave publica / identificador de tamano reducido en lugar de una pluralidad de certificados mas grandes, posibilitando de esta manera rapida autenticacion y ejecucion de transaccion. En algunas realizaciones, el proceso de autenticacion mutua completo puede completarse en menos de 500 ms, menos de 250 ms, o menos de 100 ms. En algunas realizaciones, el modulo de transmision de respuesta de autenticacion puede configurarse para transmitir la respuesta de autenticacion menos de 500 ms, menos de 250 ms, o menos de 100 ms despues de que se reciba una solicitud de autenticacion por el modulo de recepcion de solicitud de autenticacion.
Por medio de ejemplo adicional, en algunas realizaciones, la autenticacion mutua segura entre dos dispositivos puede completarse con unicamente una transferencia desde el primer dispositivo (por ejemplo, un terminal de pago) al segundo dispositivo (por ejemplo, un dispositivo movil) y una transferencia desde el segundo dispositivo al primer dispositivo, posibilitando de esta manera rapida autenticacion y ejecucion de transaccion.
Ventajas ejemplares adicionales y/o efectos tecnicos que pueden producirse por uno o mas de los sistemas y metodos desvelados en el presente documento incluyen: (1) comunicacion mutuamente autenticada segura entre un dispositivo movil y un terminal de pago sin requerir cambios extensivos a, o integracion de infraestructura de pago de combustible existente e infraestructura de pago movil, (2) una interfaz de NFC segura para permitir que un terminal de pago se autentique mutuamente con una aplicacion de pago movil para posibilitar comunicacion rapida segura entre los dos, (3) no requisito para cambio en comunicacion entre una nube de pago movil y una nube de terminal de pago, y (4) seguridad mejorada para acceso de servicio.
Esta descripcion escrita usa ejemplos para desvelar la invencion, que incluye el mejor modo, y tambien para posibilitar a cualquier experto en la materia que ponga en practica la invencion, que incluye hacer y usar cualesquiera dispositivos o sistemas y realizar cualesquiera metodos incorporados. El alcance patentable de la invencion se define mediante las reivindicaciones, y puede incluir otros ejemplos que se les ocurrira a los expertos en la materia. Tales otros ejemplos se pretende que esten dentro del alcance de las reivindicaciones si tienen elementos estructurales que no difieren del lenguaje literal de las reivindicaciones, o si incluyen elementos estructurales equivalentes con diferencias insustanciales de los lenguajes literales de las reivindicaciones.

Claims (15)

REIVINDICACIONES
1. Un terminal (102), que comprende
un transceptor (218) inalambrico configurado para comunicar inalambricamente con un dispositivo (104) movil; un elemento (216) seguro configurado para almacenar una o mas claves criptograficas pre-validadas; y un procesador (202) acoplado al elemento seguro y al transceptor inalambrico, estando el procesador programado para
recibir (S802), mediante el transceptor inalambrico, una solicitud de autenticacion desde el dispositivo movil, autenticar el dispositivo movil validando la solicitud de autenticacion basandose en la una o mas claves criptograficas pre-validadas almacenadas en el elemento seguro,
generar una clave de sesion basandose en un numero aleatorio recibido en la solicitud de autenticacion, transmitir (S820), mediante el transceptor inalambrico, cuando el dispositivo movil esta autenticado satisfactoriamente, una respuesta de autenticacion que incluye la clave de sesion al dispositivo movil, y recibir (S828) informacion segura desde el dispositivo movil, encriptandose la informacion segura por la clave de sesion.
2. El terminal de reivindicacion 1, en el que el terminal comprende al menos uno de un terminal de pago, un quiosco, y un dispensador de combustible.
3. El terminal de reivindicacion 1, en el que el transceptor comprende un transceptor de comunicacion de campo cercano, NFC.
4. El terminal de reivindicacion 1, en el que la solicitud de autenticacion comprende:
una primera clave publica espedfica para el dispositivo movil, encriptandose la primera clave publica por una clave privada que es superior a la primera clave publica en una jerarqrna de certificados;
un identificador unico que especifica la cadena de claves publicas en la jerarqrna de certificados que desencriptan finalmente la primera clave publica; y
un numero aleatorio R1 encriptado por una clave privada que corresponde a la primera clave publica.
5. El terminal de reivindicacion 4, en el que el procesador esta configurado para validar la solicitud de autenticacion:
usando una tabla (314) de busqueda para determinar si una clave publica superior especificada en el identificador unico se almacena en el terminal y esta pre-validada; y
si la clave publica superior se almacena en el terminal y esta pre-validada, recuperar la clave publica superior y desencriptar la primera clave publica usando la clave publica superior.
6. El terminal de reivindicacion 5, en el que la solicitud de autenticacion incluye la clave publica superior y en el que el procesador esta configurado para validar la solicitud de autenticacion:
si la clave publica superior no esta almacenada en el terminal o no esta pre-validada, usar la tabla de busqueda para determinar si una clave publica mas superior especificada en el identificador unico esta almacenada y pre-validada en el terminal, y
si la clave publica mas superior esta almacenada y pre-validada en el terminal, recuperar la clave publica mas superior y desencriptar la clave publica superior usando la clave publica mas superior; y
si la clave publica mas superior no esta almacenada en el terminal o no esta pre-validada, al menos uno de solicitar la clave publica mas superior desde el dispositivo movil, obtener la clave publica mas superior desde una red, y rechazar la solicitud de autenticacion segun se origina desde un dispositivo movil que no puede autenticarse.
7. El terminal de reivindicacion 4, en el que la clave de sesion comprende una combinacion del numero aleatorio R1 y un numero aleatorio R2 generado por el terminal.
8. El terminal de reivindicacion 4, en el que la respuesta de autenticacion comprende:
una segunda clave publica espedfica para el terminal, encriptandose la segunda clave publica por una clave privada del lado de terminal que es superior a la segunda clave publica en la jerarqrna de certificados;
un identificador unico de lado de terminal que especifica la cadena de claves publicas en la jerarqrna de certificados que desencriptan finalmente la segunda clave publica;
la clave de sesion, encriptandose dicha clave de sesion por la primera clave publica del dispositivo movil; y una suma de comprobacion de clave de sesion generada por el procesador, encriptandose dicha suma de comprobacion de clave de sesion por una clave privada que corresponde a la segunda clave publica del terminal.
9. El terminal de reivindicacion 8, en el que la respuesta de autenticacion comprende una clave publica superior de lado de terminal que corresponde a la clave privada superior de lado de terminal.
10. El terminal de reivindicacion 1, en el que el terminal esta configurado para completar un proceso de autenticacion con el dispositivo movil en menos de 500 ms.
11. El terminal de reivindicacion 1, en el que el terminal esta configurado para completar un proceso de autenticacion con el dispositivo movil en un unico intercambio.
12. El terminal de reivindicacion 1, en el que la informacion segura comprende informacion de pago.
13. El terminal de reivindicacion 1, en el que la informacion segura comprende una instruccion de servicio para abrir una puerta del terminal, y en el que el terminal esta configurado para abrir la puerta en respuesta a la instruccion de servicio.
14. Un metodo de comunicacion segura para ejecucion por un terminal (102) que incluye un transceptor (218) inalambrico configurado para comunicar inalambricamente con un dispositivo (104) movil, un elemento (216) seguro configurado para almacenar una o mas claves criptograficas pre-validadas, y un procesador (202) acoplado al elemento seguro y al transceptor inalambrico, comprendiendo el metodo:
recibir (S802), mediante el transceptor inalambrico, una solicitud de autenticacion desde el dispositivo movil; autenticar el dispositivo movil usando el procesador para validar la solicitud de autenticacion basandose en la una o mas claves criptograficas pre-validadas almacenadas en el elemento seguro;
usar el procesador para generar una clave de sesion basandose en un numero aleatorio recibido en la solicitud de autenticacion; transmitir (S820), mediante el transceptor inalambrico, cuando el dispositivo movil esta autenticado satisfactoriamente, una respuesta de autenticacion que incluye la clave de sesion al dispositivo movil; y recibir (S828), mediante el transceptor inalambrico, informacion segura desde el dispositivo movil, encriptandose la informacion segura por la clave de sesion.
15. El metodo de la reivindicacion 14, que comprende adicionalmente ejecutar una transaccion de pago usando la informacion segura y dispensar combustible desde un dispensador de combustible operativamente acoplado al terminal.
ES14728765T 2013-05-09 2014-05-02 Sistemas y métodos para comunicación segura Active ES2712150T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/890,734 US11127001B2 (en) 2013-05-09 2013-05-09 Systems and methods for secure communication
PCT/US2014/036526 WO2014182557A1 (en) 2013-05-09 2014-05-02 Systems and methods for secure communication

Publications (1)

Publication Number Publication Date
ES2712150T3 true ES2712150T3 (es) 2019-05-09

Family

ID=50896554

Family Applications (1)

Application Number Title Priority Date Filing Date
ES14728765T Active ES2712150T3 (es) 2013-05-09 2014-05-02 Sistemas y métodos para comunicación segura

Country Status (10)

Country Link
US (2) US11127001B2 (es)
EP (1) EP2995039B1 (es)
CN (1) CN105556892B (es)
BR (1) BR112015028071B1 (es)
CA (1) CA2911637C (es)
DK (1) DK2995039T3 (es)
ES (1) ES2712150T3 (es)
PT (1) PT2995039T (es)
TR (1) TR201902104T4 (es)
WO (1) WO2014182557A1 (es)

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9860274B2 (en) 2006-09-13 2018-01-02 Sophos Limited Policy management
CA2977461C (en) 2009-02-11 2020-04-28 Pepsico, Inc. Beverage dispense valve controlled by wireless technology
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US8959331B2 (en) 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
US9948614B1 (en) * 2013-05-23 2018-04-17 Rockwell Collins, Inc. Remote device initialization using asymmetric cryptography
CN105408913B (zh) * 2013-08-21 2019-03-15 英特尔公司 在云中隐私地处理数据
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
SG11201603232VA (en) * 2013-10-30 2016-05-30 Gilbarco Inc Cryptographic watermarking of content in fuel dispensing environments
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9133012B2 (en) 2013-11-18 2015-09-15 Wayne Fueling Systems Sweden Ab Systems and methods for fuel dispenser security
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
US10861090B2 (en) * 2013-11-27 2020-12-08 Apple Inc. Provisioning of credentials on an electronic device using passwords communicated over verified channels
US9413759B2 (en) 2013-11-27 2016-08-09 At&T Intellectual Property I, Lp Apparatus and method for secure delivery of data from a communication device
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
WO2015184306A1 (en) 2014-05-30 2015-12-03 Wayne Fueling Systems Llc Methods and systems for communication between a fuel dispenser and a mobile device
US20150372865A1 (en) * 2014-06-23 2015-12-24 Rockwell Automation Technologies, Inc. System and method for autonomous dynamic provisioning
US20160065374A1 (en) * 2014-09-02 2016-03-03 Apple Inc. Method of using one device to unlock another device
US9716716B2 (en) 2014-09-17 2017-07-25 Microsoft Technology Licensing, Llc Establishing trust between two devices
US10210500B2 (en) * 2014-09-23 2019-02-19 Mastercard International Incorporated Ultrasonic triangulation for payments method and apparatus
US10419271B2 (en) * 2014-12-30 2019-09-17 Lg Cns Co., Ltd. Public transportation fee payment system and operating method thereof
US10009324B2 (en) * 2015-06-29 2018-06-26 American Express Travel Related Services Company, Inc. Host card emulation systems and methods
US10586042B2 (en) 2015-10-01 2020-03-10 Twistlock, Ltd. Profiling of container images and enforcing security policies respective thereof
US10915628B2 (en) 2015-10-01 2021-02-09 Twistlock, Ltd. Runtime detection of vulnerabilities in an application layer of software containers
US10943014B2 (en) 2015-10-01 2021-03-09 Twistlock, Ltd Profiling of spawned processes in container images and enforcing security policies respective thereof
US10664590B2 (en) 2015-10-01 2020-05-26 Twistlock, Ltd. Filesystem action profiling of containers and security enforcement
US10223534B2 (en) 2015-10-15 2019-03-05 Twistlock, Ltd. Static detection of vulnerabilities in base images of software containers
US10599833B2 (en) 2015-10-01 2020-03-24 Twistlock, Ltd. Networking-based profiling of containers and security enforcement
US10922418B2 (en) 2015-10-01 2021-02-16 Twistlock, Ltd. Runtime detection and mitigation of vulnerabilities in application software containers
US10567411B2 (en) 2015-10-01 2020-02-18 Twistlock, Ltd. Dynamically adapted traffic inspection and filtering in containerized environments
US20170099980A1 (en) * 2015-10-08 2017-04-13 Michel Abou Haidar Integrated tablet computer in hot and cold dispensing machine
US20170099981A1 (en) * 2015-10-08 2017-04-13 Michel Abou Haidar Callisto integrated tablet computer in hot and cold dispensing machine
US10778446B2 (en) * 2015-10-15 2020-09-15 Twistlock, Ltd. Detection of vulnerable root certificates in software containers
US9794072B2 (en) * 2015-11-05 2017-10-17 Redline Communications Inc. Certificate exchange mechanism for wireless networking
US11393051B2 (en) 2016-06-10 2022-07-19 Gilbarco Inc. Fuel dispenser utilizing tokenized user guidance and prompting for secure payment
US10897360B2 (en) * 2017-01-26 2021-01-19 Microsoft Technology Licensing, Llc Addressing a trusted execution environment using clean room provisioning
US10885212B2 (en) 2017-09-12 2021-01-05 Sophos Limited Secure management of process properties
US11620638B2 (en) 2017-10-31 2023-04-04 Wayne Fueling Systems Llc Methods, systems, and devices for loading currency into an electronic wallet
GB201720946D0 (en) * 2017-12-15 2018-01-31 Nchain Holdings Ltd Computer-implemented system and method
WO2019116187A1 (en) 2017-12-13 2019-06-20 nChain Holdings Limited System and method for securely sharing cryptographic material
US10902422B2 (en) * 2018-02-05 2021-01-26 Wayne Fueling Systems Llc Methods and devices for mobile payment transactions with a product dispenser
WO2019199836A1 (en) * 2018-04-09 2019-10-17 Averon Us, Inc. Secure communication using device-identity information linked to cloud-based certificates
WO2020091722A1 (en) 2018-10-29 2020-05-07 Visa International Service Association Efficient authentic communication system and method
WO2020117860A1 (en) * 2018-12-03 2020-06-11 Michael Derby Virtual payment system and method for dispensing fuel
EP3668135B1 (de) * 2018-12-14 2020-12-09 Deutsche Telekom AG Autorisierungsverfahren zum freigeben oder sperren von ressourcen und endgerät
GB2603363A (en) * 2019-09-25 2022-08-03 Jio Platforms Ltd System and method of multiple closed-loop secured transaction
US11496892B2 (en) * 2021-01-22 2022-11-08 Dell Products L.P. Secure infrastructure onboarding system
CN113591109B (zh) * 2021-07-23 2023-05-02 上海瓶钵信息科技有限公司 可信执行环境与云端通信的方法及系统
CN114024791A (zh) * 2021-10-28 2022-02-08 浪潮软件科技有限公司 一种智慧家庭安全通信方法和系统

Family Cites Families (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7366900B2 (en) * 1997-02-12 2008-04-29 Verizon Laboratories, Inc. Platform-neutral system and method for providing secure remote operations over an insecure computer network
US6005945A (en) * 1997-03-20 1999-12-21 Psi Systems, Inc. System and method for dispensing postage based on telephonic or web milli-transactions
US6229894B1 (en) * 1997-07-14 2001-05-08 Entrust Technologies, Ltd. Method and apparatus for access to user-specific encryption information
US6029043A (en) * 1998-01-29 2000-02-22 Ho; Chi Fai Computer-aided group-learning methods and systems
JP2001352321A (ja) 2000-04-06 2001-12-21 Sony Corp 情報処理システム、情報処理方法、および情報記録媒体、並びにプログラム提供媒体
JP2002014929A (ja) * 2000-04-26 2002-01-18 Sony Corp アクセス制御システム、アクセス制御方法、およびデバイス、アクセス制御サーバ、アクセス制御サーバ登録サーバ、データ処理装置、並びにプログラム記憶媒体
DE10025626A1 (de) * 2000-05-24 2001-11-29 Deutsche Telekom Ag Verschlüsseln von abzuspeichernden Daten in einem IV-System
US20010037302A1 (en) * 2000-05-31 2001-11-01 Javien, Inc. Data web object host discovery system
JP2002056325A (ja) * 2000-08-08 2002-02-20 Nec Corp 電子決済方法およびシステムとその決済センタ装置、個人情報入力端末およびプログラムを記録した記録媒体
US20020147905A1 (en) * 2001-04-05 2002-10-10 Sun Microsystems, Inc. System and method for shortening certificate chains
US7636840B2 (en) * 2002-07-10 2009-12-22 Dresser, Inc. Secure communications and control in a fueling environment
US7822688B2 (en) 2002-08-08 2010-10-26 Fujitsu Limited Wireless wallet
JP4617763B2 (ja) * 2003-09-03 2011-01-26 ソニー株式会社 機器認証システム、機器認証サーバ、端末機器、機器認証方法、および機器認証プログラム
CN100544247C (zh) 2004-02-16 2009-09-23 华为技术有限公司 安全能力协商方法
CN1658547B (zh) 2004-02-16 2010-08-18 华为技术有限公司 密钥分发方法
CN100359845C (zh) 2004-03-26 2008-01-02 中兴通讯股份有限公司 无线局域网自组网模式共享密钥认证和会话密钥协商方法
JP5127446B2 (ja) * 2004-05-05 2013-01-23 アイエムエス ソフトウェア サービシズ リミテッド マルチ・ソース型の長期の患者レベルデータを統合するデータ暗号化アプリケーション
JP4671783B2 (ja) * 2004-07-20 2011-04-20 株式会社リコー 通信システム
DE102004037801B4 (de) * 2004-08-03 2007-07-26 Siemens Ag Verfahren zur sicheren Datenübertragung
ATE347206T1 (de) 2004-10-29 2006-12-15 Research In Motion Ltd System und verfahren zur verifikation von digitalen unterschriften von zertifikaten
CN100544249C (zh) 2004-10-29 2009-09-23 大唐移动通信设备有限公司 移动通信用户认证与密钥协商方法
JP4502393B2 (ja) * 2005-06-13 2010-07-14 キヤノン株式会社 通信パラメータの共有方法及び通信装置
US7835528B2 (en) * 2005-09-26 2010-11-16 Nokia Corporation Method and apparatus for refreshing keys within a bootstrapping architecture
JP4435076B2 (ja) * 2005-11-18 2010-03-17 フェリカネットワークス株式会社 携帯端末，データ通信方法，およびコンピュータプログラム
US7814538B2 (en) 2005-12-13 2010-10-12 Microsoft Corporation Two-way authentication using a combined code
KR101346734B1 (ko) * 2006-05-12 2014-01-03 삼성전자주식회사 디지털 저작권 관리를 위한 다중 인증서 철회 목록 지원방법 및 장치
CN101111056B (zh) 2006-07-17 2010-05-12 西安电子科技大学 在无线局域网中的快速切换方法
EP2057819B1 (en) * 2006-08-31 2011-08-31 Encap AS Method for synchronising between a server and a mobile device
US9830637B2 (en) * 2007-02-23 2017-11-28 Epona Llc System and method for processing vehicle transactions
US8345871B2 (en) 2007-03-15 2013-01-01 Palo Alto Research Center Incorporated Fast authentication over slow channels
US8539233B2 (en) * 2007-05-24 2013-09-17 Microsoft Corporation Binding content licenses to portable storage devices
US7739169B2 (en) 2007-06-25 2010-06-15 Visa U.S.A. Inc. Restricting access to compromised account information
US10558961B2 (en) * 2007-10-18 2020-02-11 Wayne Fueling Systems Llc System and method for secure communication in a retail environment
CN101420413B (zh) 2007-10-25 2012-11-07 华为技术有限公司 会话密钥协商方法、认证服务器及网络设备
US20090144194A1 (en) * 2007-11-30 2009-06-04 Mark Dickelman Computer automated systems, devices and methods for data processing of accounting records
KR100997238B1 (ko) 2008-03-03 2010-11-29 삼성전자주식회사 Crum 유닛, 교체가능유닛 및 이를 이용하는 화상형성장치와, 그 인증 및 암호화 데이터 통신 방법
US8112066B2 (en) 2009-06-22 2012-02-07 Mourad Ben Ayed System for NFC authentication based on BLUETOOTH proximity
EP2290601A1 (en) 2009-08-24 2011-03-02 Afone Method and system for secure mobile payment
US8850203B2 (en) * 2009-08-28 2014-09-30 Alcatel Lucent Secure key management in multimedia communication system
CN102081769A (zh) 2009-11-27 2011-06-01 阿里巴巴集团控股有限公司 支付数据处理方法、系统、支付终端及支付服务器
US8601266B2 (en) * 2010-03-31 2013-12-03 Visa International Service Association Mutual mobile authentication using a key management center
US8550903B2 (en) 2010-11-15 2013-10-08 Bally Gaming, Inc. System and method for bonus gaming using a mobile device
US10380570B2 (en) * 2011-05-02 2019-08-13 Ondot System, Inc. System and method for secure communication for cashless transactions
CA3053278C (en) * 2013-02-08 2023-05-09 Schlage Lock Company Llc Control system and method
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions

Also Published As

Publication number Publication date
DK2995039T3 (en) 2019-03-18
CA2911637C (en) 2020-03-24
EP2995039A1 (en) 2016-03-16
WO2014182557A1 (en) 2014-11-13
CA2911637A1 (en) 2014-11-13
CN105556892B (zh) 2021-07-06
TR201902104T4 (tr) 2019-03-21
CN105556892A (zh) 2016-05-04
EP2995039B1 (en) 2018-11-28
PT2995039T (pt) 2019-02-26
US11127001B2 (en) 2021-09-21
US20210406882A1 (en) 2021-12-30
BR112015028071B1 (pt) 2023-04-11
BR112015028071A2 (pt) 2017-07-25
US20140337234A1 (en) 2014-11-13

Similar Documents

Publication Publication Date Title
ES2712150T3 (es) Sistemas y métodos para comunicación segura
US10439811B2 (en) Method for securing a private key on a mobile device
ES2970201T3 (es) Sistema de identificación personal con tarjeta sin contacto
ES2687191T3 (es) Método de autentificación de red para transacciones electrónicas seguras
ES2820554T3 (es) Método y aparato para autentificar un usuario, método y aparato para registrar un dispositivo ponible
ES2819200T3 (es) Un método y sistema para proporcionar autenticación del acceso del usuario a un recurso informático a través de un dispositivo móvil utilizando múltiples factores de seguridad separados
CA2931024C (en) Systems and methods for convenient and secure mobile transactions
ES2739896T3 (es) Acceso seguro a datos de un dispositivo
ES2632795T3 (es) Sistema de pago
ES2590678T3 (es) Método y sistema para verificar una solicitud de acceso
US20160036808A1 (en) Otp token, data transmission system and data transmission method for otp token
US11057196B2 (en) Establishing shared key data for wireless pairing
CA3042357A1 (en) Verifying an association between a communication device and a user
CA2892535C (en) Post-manufacture configuration of pin-pad terminals
US20210058252A1 (en) Electronic device and method, performed by electronic device, of transmitting control command to target device
WO2017028711A1 (zh) 数据处理的方法、穿戴式电子设备和系统
US11568082B2 (en) Method and system for securing sensitive information
AU2014340234A1 (en) Facilitating secure transactions using a contactless interface
KR101790121B1 (ko) 전자 기기 인증 방법 및 시스템
KR101394147B1 (ko) 모바일에서 안전하게 인증서를 사용하는 방법
KR20180003069A (ko) 오티피토큰의 배터리 교체 관리 방법
TWI633231B (zh) Smart lock and smart lock control method