MXPA05012969A - Autenticacion de cliente en transacciones de comercio electronico. - Google Patents
Autenticacion de cliente en transacciones de comercio electronico.Info
- Publication number
- MXPA05012969A MXPA05012969A MXPA05012969A MXPA05012969A MXPA05012969A MX PA05012969 A MXPA05012969 A MX PA05012969A MX PA05012969 A MXPA05012969 A MX PA05012969A MX PA05012969 A MXPA05012969 A MX PA05012969A MX PA05012969 A MXPA05012969 A MX PA05012969A
- Authority
- MX
- Mexico
- Prior art keywords
- authentication
- information
- transaction
- chip
- reader
- Prior art date
Links
Classifications
-
- 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/3827—Use of message hashing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
- G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
- G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
-
- 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/04—Payment circuits
-
- 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- 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/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
-
- 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/409—Device specific authentication in transaction processing
- G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
- G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1025—Identification of user by a PIN code
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Storage Device Security (AREA)
Abstract
Se proporciona un programa de Autenticacion de Chips basado en protocolos 3-D Secure para autentificar las transacciones en linea de los clientes (180). Un emisor, que puede ser un emisor de tarjetas de pago opera a traves de los Servicios de Peticion de Autenticacion y Control de Acceso (120) para autentificar las transacciones de clientes individuales (180) que estan identificados por sus tarjetas inteligentes de quejas EMV personales (170). Se genera una senal de autentificacion en el punto de interaccion (POI) para cada transaccion basandose en la informacion de la tarjeta inteligente del cliente (170) y la informacion especifica de la transaccion enviada directamente por el emisor para poblar una pagina web en el POI. Las senales de autenticacion generadas en el POI son evaluadas por el Servidor de Peticiones de Autenticacion (120) apara autenticar la presencia de clientes y/o tarjetas individuales en el POI de la transaccion. Los valores de la autenticacion se transportan en linea en los Campos de Autenticacion del titular de la tarjeta universal en congruencia con los protocolos 3-D Secure.
Description
GM, KF.. LS, MW, MZ, NA, Sl). SL, SZ. TZ, UG, ZM. (88) Dale ?G publkalion <>f Dio ¡nlirn;il¡on¡il soar li rrporl: ZW), Eurasian (AM, AZ, BY. KG, KZ. MD. Rll.TJ.TM ), 10 Mar h 2005 Europcan (??', BH, BG, CU, CY, C:Z. DH. DK, Hl-, BS, Ll. FR, ÜB, GR, IIU, IL\ IT, LU, MC, NL, PL, ?'. Rü, SFi. SI. h~m t o-lcti r oiles antl oi/ier übbreviatinns. referi ihe "G td- SK, TR), ???? (BI-, BJ, CK CG, Cl, CM, GA. GN, GQ, imee Nales on CoJes and Ahbreviaiions" appearing ai ¡he begin- GW. MI., MR. NI-, SN, TD, TCi). nirií; of eticli regular issue of ihe l'C'í G zeííe. Fublishcd: — wilh iníenialioiwl sear repon
AUTENTICACIÓN DE CLIENTE EN TRANSACCIONES DE COMERCIO ELECTRÓNICO
REFERENCIA A LAS SOLICITUDES RELACIONADAS
Esta solicitud reclama el beneficio ante la solicitud de patente provisional ÜS Serie No. 60/475,639, expediente del 4 de junio de 2003, la totalidad de la cual se incorpora en la presente para su referencia.
ANTECEDENTES DE LA INVENCIÓN
La presente invención se refiere a los sistemas y métodos para autentificar o autenticar transacciones efectuadas sobre redes electrónicas abiertas, como la Internet. En particular, la invención se refiere a la autenticación de transacciones por la Internet en las cuales los clientes cargan los pagos a tarjetas de crédito o débito.
El comercio electrónico es ahora muy común. Manejar transacciones sobre redes electrónicas como la Internet tiene ahora ventajas de conveniencia frecuentemente citadas, costos bajos, mercado real y elección, tanto para comerciantes como clientes. Sin embargo, el anonimato de la Internet acarrea para la venta comercial 2
o de menudeo los problemas de fraude y mal uso. ün comerciante tiene el deseo de autenticar la venta, certificar la venta, confirmar la venta, asegurar el no rechazo de la venta, asegurar el pago y controlar el anonimato. Del mismo modo, un comprador desea controlar la autenticidad de la venta, la integridad de la venta, cancelación de venta, confirmación de la venta, privacidad y el anonimato.
La solicitud de patente Internacional WO03073389 de invención mancomunada y en copropiedad, que se incorpora en la presente totalmente para su referencia, describe un sistema de pago por red para autenticar al cliente en una transacción cliente-comerciante manejada por Internet. La Internet enlaza el servidor de un comerciante y la terminal del cliente a un servidor de pagos. El cliente usa una Tarjeta de Circuito Integrado (ICC) como recurso de identificación. La ICC está en comunicación con la terminal del cliente por medio de un lector de tarjetas. La ICC genera un criptograma en respuesta a la información sobre una transacción pendiente. Esta información puede ser un mensaje de desafio generado por la terminal del cliente. El lector de tarjetas convierte una parte del criptograma generado por la ICC en un símbolo único de autenticación, el cual se transmite 3
entonces por Internet, por ejemplo, al servidor de pagos, para autenticar al cliente.
Otro sistema de pago por Internet, el cual recae sobre un chip de tarjeta inteligente para pago de mercancías y servicios comprados por Internet, se describe en Davis et al, Patente U.S. No. 6,282,522. La ICC y otras tarjetas inteligentes se pueden basar en especificaciones comunes de la industria (es decir, estándares SMV desarrollados conjuntamente por Europay International, Mastercard International y Visa International) para permitir la interoperabilidad a través de diversos sistemas de pago.
Los emisores de tarjetas y otras instituciones financieras ahora ofrecen o usan protocolos estandarizados para las transacciones por Internet para mejorar las transacciones en línea y acelerar el crecimiento del comercio electrónico. Bajo estos mismos protocolos estandarizados (es decir, el Protocolo 3-D Secure™ desarrollado por Visa International) los emisores de tarjetas o los bancos emisores pueden autenticar transacciones reduciendo así la probabilidad de fraude y devoluciones de cargos asociados, atribuidos a transacciones no autorizadas por los titulares. La presencia de una transacción puede ocasionar que un 4
emisor asuma la responsabilidad por el fraude si éste ocurre a pesar de los esfuerzos para autenticar al titular durante una compra en linea. Los titulares o bancos emisores garantizan a los comerciantes que pagarán por las transacciones autenticadas. El protocolo 3D Secure es consistente con y asume la responsabilidad de los programas de autenticación que ofrecen los emisores de tarjetas (por ejemplo, Verified de Visa o SecureCode de MasterCard) para autenticar clientes para los comerciantes durante transacciones remotas como las asociadas con la Internet. El protocolo 3-D Secure apalanca la funcionalidad criptográfica existente en Secure Sockets Layer (SSL) y mejora la seguridad a través de la autenticación de los titulares durante la sesión de compra en linea. Los comerciantes participantes usan el software llamado Merchant Plug In (MPI) para intercambiar mensajes, pasar información y hacer preguntas a los participantes para establecer una sesión de autenticación entre el titular y su emisor de tarjetas durante una compra en linea.
Los servicios del protocolo 3-D Secure se basan en un modelo de 3 dominios - el dominio del emisor, el dominio del adquirente y de interoperabilidad. El emisor es responsable de manejar el registro de los titulares en el 5
servicio, y de los procedimientos de autenticación durante las transacciones en linea. El adquirente es responsable de definir los procedimientos para que los comerciantes participantes en las transacciones por Internet operen bajo un acuerdo con el Adquirente, y de proporcionar el procesamiento final (back end) para las transacciones autenticadas. El dominio de interoperabilidad facilita el intercambio de la transacción entre los otros dos dominios con un protocolo común y servicios compartidos. Los titulares y sus bancos pueden estar bajo el "Dominio del Emisor", los comerciantes y sus bancos pueden estar bajo el "Dominio del Adquirente". La comunicación entre bancos emisores y adquirentes o instituciones financieras y la infraestructura del emisor de tarjeta puede estar bajo el "Dominio de Interoperabilidad". Mientras que la transacción con 3-D Secure satisface a los bancos y comerciantes, el consumidor puede tener la misma experiencia de compra por Internet antes mencionada, excepto que hay una ventana separada de autenticación o pantalla emergente del banco del titular para determinar si la parte que está haciendo la transacción es efectivamente el titular del registro. El flujo de la transacción de compra en linea por Internet bajo el protocolo puede ser como sigue: 6
(1) El cliente llena la información de pago en el sitio web del comerciante en la forma normal, por medio de una conexión encriptada de Secure Sockets Layer (SSL) .
(2) El comerciante envía entonces un mensaje a través del MPI a un Directorio en el cual se turnan las preguntas a los emisores de tarjetas para encontrar si el cliente está registrado en el programa 3-D Secure.
(3) El emisor de la tarjeta responde al Directorio con un mensaje indicando si el titular está registrado y, si es así, proporciona una dirección de correo electrónico para el banco que emitió la tarjeta. Entonces se procesa este mensaje y se envía la respuesta al comerciante.
(4) El comerciante envía entonces un mensaje al banco emisor, a través del dispositivo del titular, para iniciar la sesión de autenticación entre el titular y el emisor de la tarjeta, en el cual se detalla el nombre del comerciante y la cantidad de la transacción, para la confirmación por parte del titular.
(5) El banco emisor poblará entonces una ventana de autenticación al titular detallando la información 7
relacionada con la transacción, como nombre del comerciante y cantidad, un mensaje personal de seguridad, y un área de respuesta, donde el titular puede ingresar los detalles de la autenticación.
(6) El cliente aprueba la transacción en una de las diferentes formas, dependiendo de la forma en la que el banco emisor elija implementar el sistema. Las opciones pueden variar desde ingresar una contraseña estática o PIN, o utilizar una tarjeta inteligente y un Lector de Tarjetas Personal (PCR) para generar un símbolo de autenticación .
(7) Si la autenticación es válida, el emisor envía un mensaje al comerciante indicando que la transacción fue satisfactoria. El emisor también notifica al comerciante si la autenticación falló o si fue imposible completarla.
Ahora consideramos las formas de mejorar las soluciones para autenticar a los clientes que utilicen tarjetas de crédito o débito para pagar transacciones electrónicas. La atención se dirige a soluciones para asegurar el canal de ventas por Internet de los comerciantes y autenticar al titular en el punto de interacción (POI) y generar en el POI evidencia explícita de la presencia tanto de la 8
tarjeta como del titular. Las soluciones deseables son compatibles con las implementaciones de la industria de protocolos comunes como el 3-D Secure y otros estándares industriales como el estándar EMV para tarjetas inteligentes para reforzar la autenticación más allá de la simple y estática contraseña o los PIN.
COMPENDIO DE LA INVENCIÓN
De acuerdo con la presente invención, se proporciona un Programa de Autenticación por Chip (CAP) , basado en el protocolo 3-D Secure, para autenticar transacciones de clientes en el comercio electrónico. Las implementaciones del CAP, que pueden ser estratificadas en la parte alta de la infraestructura y técnicas existentes del comercio electrónico proporcionan una integración continua de las tecnologías EMV y 3-D Secure para obtener autenticación más fuerte que las soluciones convencionales de contraseña estática. Las implementaciones del CAP proporcionan un mecanismo para que los comerciantes en linea reciban una garantía de pago global de los emisores de tarjetas similares a las garantías de disfrutan los minoristas con las transacciones físicas en los puntos de venta en los cuales se verifica rápidamente la identidad de los clientes.
9
En el CAP, el emisor (es decir, el emisor de la tarjeta de pago) proporciona servicios de autenticación a las partes transacción por transacción. El emisor puede operar un Servidor de Control de Acceso y un Servidor de Solicitud de Autenticación asociado para autenticar las transacciones de los clientes que tiene registrados en el programa. Se crea un símbolo de autenticación en el punto de interacción (POI) para cada una de las transacciones para las cuales se solicitó la autenticación basándose en la información encriptada que identifica únicamente al cliente y la transacción. El cliente que hace la transacción usa una solicitud de autenticación basada en los EMV anidada en una tarjeta de Chip de Circuito Integrado (ICC) como identificador personal en el POI para crear el símbolo. La información específica del comerciante o transacción que se va a incluir en el símbolo puede ser proporcionada directamente por el emisor al POI, por ejemplo, poblando la página web de un navegador usual de Internet en el POI. Las implementaciones ventajosas del CAP no requieren descargas de software o presentaciones separadas, específicas del comerciante (es decir, applets) en el POI (es decir, en el dispositivo de acceso del cliente) .
10
Los símbolos de autenticación generados en el POI son evaluados por el ARS para autenticar al cliente y/o tarjeta presente en la transacción del POI. Al completar la evaluación, el ACS genera un AAV. Este AAV es transportado por la red electrónica en un UCAF en un formato compatible con el protocolo 3-D Secure.
Se prefiere que un sistema de la presente invención para autenticar una transacción de un cliente en una red electrónica, incluya el recurso de acceso de red, un chip de circuito integrado que se emite al cliente y contiene información de identificación del cliente, un lector que permita enlazar (por medio físico, electrónico o manual del titular) al recurso de acceso y pueda comunicarse con el chip, un servidor de solicitud de autenticación (ARS) y un Servidor de Control de Acceso (ACS) que se enlace con la red electrónica y se pueda comunicar con la parte que solicita la autenticación de la transacción. El ACS está configurado para comunicarse directamente con el recurso de acceso del cliente (es decir, por medio de una Página de Autenticación del Titular) para autenticación de la transacción. F.sta comunicación directa hace innecesario bajar software de autenticación (es decir, applet específico para el comerciante) de la parte solicitante (por ej , comerciantes) al recurso de acceso 11
del cliente. El ARS recibe la información de la transacción de la parte solicitante y comunica la información de la transacción al lector por medio del recurso de acceso del cliente. El lector puede procesar la información de la transacción y comunicar un valor basado en la información de la transacción al chip. El chip tiene una solicitud de autenticación para generar un criptograma basado en, por lo menos, una parte de la información de la transacción y por lo menos una parte de la información de identificación del cliente en el chip. El lector puede generar y comunicar un símbolo de autenticación basado en el criptograma del ARS, el cual está configurado para evaluar la información de identificación del cliente a partir del símbolo de autenticación y por consiguiente validar el símbolo de autenticación. El símbolo de autenticación puede ser en un formato compatible con los formatos de mensaje del protocolo 3-D Secure. Al completar satisfactoriamente la evaluación del símbolo de autenticación, el ACS genera un AAV, el cual se transporta en una red electrónica en un ÜCAP, el cual tiene una longitud de 20 bytes.
El ARS evalúa la información de identificación del cliente a partir del símbolo de autenticación reconstruyendo primero la información usada por el chip 12
para generar el criptograma, después genera una réplica o regenera el criptograma a partir de la información reconstruida, y entonces compara el símbolo de autenticación con la réplica del criptograma.
Preferentemente, el método de la presente invención para autenticación remota de un cliente que participa en una transacción electrónica usando un recurso de acceso a red, incluye proporcionar al cliente un chip de circuito integrado que tiene la información de identificación del cliente, que cuenta con un lector que está enlazado al recurso de acceso a red del cliente y puede comunicarse con el chip. El método además incluye utilizar un servidor de solicitud de autenticación (ARS) , el cual está enlazado a la red electrónica y puede comunicar información al lector, para recibir información específica de la transacción y comunicársela al lector, usando el lector para comunicar información específica de la transacción al chip e instruir al chip para generar un criptograma basado en, por lo menos, una parte de la información específica de la transacción y en, por lo menos, una parte de la información de identificación del cliente, y usando el lector para generar un símbolo de autenticación basado en, por lo menos, parte del criptograma generado por el chip. El método 13
adicionalmente involucra el uso del ARS para validar el símbolo de autenticación y por consiguiente generar un AAV para transportarlo por la red electrónica en un mensaje de UCAF al emisor.
Las características adicionales de la invención, su naturaleza y las diversas ventajas serán más evidentes en los dibujos que se acompañan y la siguiente descripción detallada .
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Las características adicionales de la invención, su naturaleza y diversas ventajas serán más evidentes en la siguiente descripción detallada y los dibujos que la acompañan, en las cuales los caracteres de referencia similares representan elementos similares, y en las cuales :
Las figuras 1 y 2 son muestras esquemáticas de implementaciones de ejemplo de programas de Autenticación por C ip y flujos del proceso, de acuerdo con los principios de la presente invención.
14
Las figuras 3 y 4 son muestras esquemáticas de los procesos de Lector de Tarjetas Personales y flujos de información involucrados en generar un número de desafio y en la verificación de un PIN para una no PCR conectado o conectado, respectivamente de acuerdo con los principios de la presente invención.
La figura 5 muestra un ejemplo de un Desafio de 8 dígitos de acuerdo con los principios de la presente invención.
La figura 6 muestra un ejemplo de un IIPB Data Token (Símbolo de Información IIPB) de acuerdo con los principios de la presente invención.
La figura 7 muestra un ejemplo de la técnica de compresión para tratar a un criptograma de patrón de bits como un número binario y ejecutar una conversión matemática de Base 2 a Base 10, de acuerdo con los principios de la presente invención.
La figura 8 muestra (en conjunto con las figuras 1 y 2) los pasos o flujo de mensajes entre las entidades involucradas en el ejemplo de la transacción del CAP (chip-autenticado) en un ambiente de 3-D Secure, de acuerdo con los principios de la presente invención.
15
La figura 9 muestra un ejemplo de la Estructura de Información IIPB, de acuerdo con los principios de la presente invención.
La figura 10 muestra una Estructura ÜCAF compatible con 3-D Secure, de acuerdo con los principios de la presente invención.
La figura 11 muestra (junto con las figuras 1 y 2) los pasos del proceso involucrados con la compra en linea de un cliente en un ambiente de comercio electrónico en el cual los comerciantes pueden solicitar opcional mente la autenticación para la transacción, de acuerdo con los principios de la presente invención.
La figura 12 es una muestra esquemática de un ejemplo de recursos integrados en el cual las funciones de los recursos de un ICC, PCR y/o PC se integran en un paquete físico conveniente, de acuerdo con los principios de la presente invención.
En las figuras, a menos que se especifique de otra manera, los mismos números y caracteres de referencia se usan para describir características, elementos, componentes o partes similares de las modalidades ilustradas.
16
DESCRIPCION DETALLADA DE LA INVENCION
La presente invención proporciona soluciones para autenticar las partes remota en una transacción electrónica. En particular, las soluciones se refieren a autenticación de titulares que remotamente participan en la transacción electrónica. Las soluciones también se refieren a la autenticación en el contexto de transacciones electrónicas efectuadas en plataformas de comercio electrónico estándar de la industria, como las plataformas de comercio electrónico que cumplan con 3-D Secure, y también se puede referir a transacciones en el contexto de ambientes que no son de comercio electrónico como Órdenes por Correo y Ordenes Telefónicas o recursos móviles donde el emisor tiene que usar un símbolo de autenticación para autenticar al titular.
Una solución, el "Chip Authentication Programa (Programa de Autenticación por Chip, CAP)," da preponderancia al emisor de tarjetas o banco emisor como entidad autentificadora . Esta entidad puede operar un Servidor de Control de Acceso y un Servidor de Solicitud de Autenticación asociado para la autenticación de los clientes que se han registrado en el programa. El CAP utiliza una aplicación de autenticación basada en EMV que 17
se incorpora en las tarjetas inteligentes de circuito electrónico (es decir, ICC) , las cuales se emiten a los titulares registrados. Un titular puede usar la solicitud de autenticación basada en EMV en la ICC durante la transacción en línea para obtener autenticación remota para una transacción específica. La solicitud de autenticación puede ser aparte o además de otras solicitudes de pago EMV tradicionales con Tarjetas Inteligentes diseñadas para transacciones comerciante cliente.
El titular puede usar la ICC junto con un Lector de Tarjetas Personal (PCR) para generar el "código seguro" dinámico o símbolo de autenticación para usarse una vez. Una Página de Autenticación de Titular se puede generar y desplegar en el recurso de acceso de Internet del Titular para este propósito (es decir, para recibir el código seguro) . La Página de Autenticación del Titular se puede controlar totalmente por el Servicio de Control de Acceso del emisor sin ninguna necesidad de otro software preinstalado o adicional en los recursos del titular. El CAP se puede implementar como una solución de seguridad alternativa o adicional para la autenticación de los titulares. Las otras soluciones de seguridad pueden incluir, por ejemplo, autenticación por medio de 18
contraseñas estáticas. Se entiende que el CAP se puede implementar usando cualquier tecnología estándar para chip en tarjetas inteligentes. La implementación, sin embargo, se hace preferentemente usando la tecnología estándar para chip EMV.
El CAP puede proporcionar un mecanismo confiable para la autenticación de pagos de comercio electrónico y servicios a los emisores. El CAP puede utilizar rutas tradicionales de autorización a través de redes de sistema de pago común para autorización de transacción de pago. Una versión del CAP es compatible con la infraestructura de la versión 1.0.2 de 3-D Secure para interoperabilidad extremo a extremo entre el comerciante, adquirente y emisor de sistemas, los cuales, por medio de estándares industriales de común acuerdo, deben soportar la infraestructura de 3-D Secure.
La solicitud de Patente Internacional WO03073389, incorporada para su referencia, describe un programa de autenticación de ICC usando un Lector de Tarjeta Personal (PCR) , el cual genera símbolos de autenticación para ser transportados a un Emisor en un Campo de Autenticación de Titular Universal (UCAF) liberando una serie de Lenguaje de Hipertexto oculto definido de MasterCard (HTML) en los 19
campos del comerciante en lugar de la tecnología 3-D Secure para intercambiar información de autenticación entre el emisor, el titular y el comerciante. Se entiende que generalmente los mismos términos, acrónimos y abreviaturas que están definidas en la solicitud de referencia se usan en la presente descripción. Para ayudar al entendimiento de la presente invención, se reproduce aquí una lista de terminología y otras partes de la solicitud de referencia:
AAC Criptograma de Autenticación de Solicitud. AAV Valor de Autenticación del Titular de la cuenta. AC Criptograma de Autenticación. AFL Localizador de Archivo de Solicitud, identifica que registros están disponibles en la ICC. AID Identificador de Solicitud, la cadena hex que identifica una solicitud determinada en la ICC. AIP Perfil de Intercambio de Solicitud, indica las capacidades de la ICC para soportar funciones específicas. APDU Unidad de Información del Procesamiento de Solicitud, los mensajes enviados entre la ICC y alguna aplicación externa. ARQC Criptograma de Solicitud de Aplicación. ATC Contador de Transacción de Solicitud.
20
BCD Código Binario Decimal. Big-Endian ün estilo codificado donde se almacena un valor con sus primeros bytes más significativos seguidos por cada byte sucesivo, con los bytes menos significativos almacenados al final. CAP Programa de Autenticación de Chip. CDOL Gestión del riesgo de la tarjeta. CID Datos de Información del Criptograma. CSN Número Secuencial de Tarjeta. CVC2 Código de Verificación de Tarjeta. CVM Método de Verificación de Titular, el método usado para verificar un titular de la tarjeta. DAC Criptograma de Autenticación Dinámica. DOM Modelo de Objeto de Documento, la vista programática de la página HTML actual proporcionada por un navegador a un plug-in. HHD Dispositivo manual (Portátil) , es decir, un lector de tarjetas. EMV Europay MasterCard Visa. ?? Solicitud de Interfaz. IAD Solicitud de Información del Emisor. IAF Banderas de Autenticación de Internet, el primer byte del IIPD. ICC Tarjeta de Circuito Integrado, también conocida como Tarjeta de Chip o Tarjeta Inteligente.
21
IIPB Mapa de Bits del emisor propiedad de la Internet, identifica los bits necesarios para enviarlos al emisor con el fin de validar la AC IIPD Información Propiedad del Emisor de Internet, información propia usada por el emisor referente al cálculo de un criptograma para los propósitos de transacciones relacionadas con la Internet. ITV Televisión Interactiva. LATC El Contador (byte de) Inferior de Transacción de Solicitud. Little-Endian Un estilo de codificación donde el valor se almacena con su primer byte menos significativo seguido de cada byte sucesivo, con el byte más significativo almacenado al último. MAC Mensaje de Código de Autenticación. Una firma criptográfica calculada sobre los ítems de datos en un mensaje tanto para probar el origen del mensaje como para permitir la detección de aquellos ítems de datos o artículos de información que han sido modificados. MCD Recurso o dispositivo Principal de Titular, el recurso en el cual se realiza la navegación y/u orden y/o el pago. Nibble medio byte, es decir, 4 bits. PI Parámetro 1, de un APDU, personaliza efectivamente el comando enviado a la ICC.
22
PAN Número de Cuenta Primaria. PC Computadora Personal . PCR Lector de Tarjetas Personal. Card older IA Aplicación Interfaz del Titular, la aplicación que corre en el MCD, que forma la interfaz entre el solicitante de autenticación, el Titular y el Lector . PDA Asistente Digital Personal. PDOL Lista de Objetos de Datos de Opciones de Procesamiento, la lista de opciones de procesamiento disponible para/soportada por la terminal (es decir, el PCR) . PIN Número de Identificación Personal. SPA Solicitud de Pago Seguro. TLV Valor de Longitud de la Etiqueta. UCAF Campo Universal de Autenticación del Titular. UN Número impredecible .
El esquema de Autenticación descrito en WO03073389 es un uso del (UCAF) Campo Universal de Autenticación del Titular. Comprende los siguientes elementos: Chip proporcionado por el emisor-UCAF-Solicitud de Interfase Habilitada, generación de Valor de Autenticación de Titular de la Cuenta (AAV) Chip-UCAF, autenticación de titular de la tarjeta, presentación de comerciante, 23
recopilación y procesamiento de la información AAV en el UCAF, Campo de Información de Autenticación, aceptación del adquirente y proceso de Información AAV de acuerdo con el UCAF, desarrollo de red Bancaria que incluya soporte para transportar la información AAV en el Campo de Información de Autenticación UCAF, y soporte de Autorización de Información AAV en el Campo de Información de Autenticación UCAF.
Las siguientes entidades están involucradas en el tiempo de vida de una transacción de autenticación Chip-UCAF: Titular - El titular inicia la transacción y es responsable de ingresar información en la página web de pago del comerciante, el Titular, Solicitud de la Interfase, y el Lector de Tarjetas Personal. Comerciante - El comerciante provee, es decir desde el servidor del comerciante en comunicación con la Internet, la información necesaria para empezar la transacción de autenticación y recibe la información resultante UCAF para enviarla, por medio del adquirente, al emisor de la tarjeta para aprobación.
Aplicación Interfaz (IA) del Titular - La IA del Titular detecta la información relevante proporcionada por el comerciante e interactúa con el titular directa e 24
indirectamente, a través del titular, con el Lector de Tarjeta Personal. La ?? del Titular crea la AAV y UCAF y llena la página del comerciante con la información apropiada .
Por ejemplo, la IA del Titular puede correr como parte de un navegador de Internet en el recurso principal del titular (MCD) que se usa para acceder al comerciante en el Internet.
Lector de Tarjeta Personal - El PRC interactúa con el Titular, y la ICC para producir un símbolo de autenticación que se pasa, indirectamente, al Emisor. La tarjeta de chip ICC autentica al Titular por la verificación del PIN usado y genera un criptograma adecuado basado en la información proporcionada por el PCR.
Adquirente - Un adquirente acepta la información con formato UCAF de un comerciante, es decir, en un servidor del adquirente, y lo envía, con un indicador del uso y presencia de información UCAF, al banco emisor por medio de la red de telecomunicaciones apropiada.
Mastercard es un adquirente 25
Emisor - El emisor de tarjetas distribuye los PCR a aquellos titulares que han firmado el esquema Chip-UCAF. El emisor mantiene una plataforma de servidor de emisor en comunicación con Internet. De acuerdo con la presente invención el servidor del Emisor valida el símbolo de autenticación codificado en el UCAF, transmitida en la solicitud de autorización de un adquirente, de acuerdo con las reglas del emisor.
De acuerdo con O03073389, el campo de información UCAF (Campo Universal de Autenticación de Titular) es un área de transporte de información multipropósito en un mensaje digital que permite la comunicación de información de autenticación a un Emisor de un Adquirente sobre cualquier forma de red de telecomunicaciones. Por ejemplo, el UCAF puede ser un campo de 32 caracteres (24 bytes, 1 byte de control y 23 bytes de información que se codifica en base-54 para convertirse en 32 caracteres) con una estructura de información flexible que se puede ajusfar para soportar las necesidades de una variedad de requerimientos de seguridad y autenticación de los Emisores. Por ejemplo, El elemento de Información 48, sub-elemento 43 del ISO 8583 puede ser designado para contener el UCAF. El término UCAF también se utiliza para referirse a la interfaz definida para pasar información 26
entre el Comerciante y el MCD y de regreso, es decir, los nombres de campo en la especificación de cualquier canal dado. El UCAF puede contener un símbolo de autenticación de usuario de 24 bytes. Estos 24 bytes están preferentemente codificados, es decir, codificados en Base 64, por la IA del Titular para dar 32 caracteres ASCII de información que se regresa al comerciante. El comerciante pasa la información del UCAF, en sus comunicaciones con el Adquirente, quien puebla el UCAF en el mensaje de Solicitud de Autorización enviado al Emiso .
El (AAV) Valor de Autenticación del Titular de la Cuenta es el término dado a una parte, es decir, los 23 bytes, de la información específica de solicitud del UCAF. Cada Solicitud de UCAF es responsable de determinar la estructura apropiada para sus AAV. Cada instancia de una implementación de una aplicación de UCAF determinado debe usar esa estructura AAV de la solicitud de una manera consistente, es decir, el formato AAV está estándarizado para una aplicación UCAF determinada.
Para usar el esquema de autenticación del titular Chip-UCAF, el titular necesita tener una tarjeta de pago ICC apropiada y un lector de Tarjeta Personal. El PCR será 27
proporcionado al titular por el emisor de la tarjeta, quien registrará que ese titular tiene un PCR y está "registrado" en el esquema de autenticación de titular Chip-UCAF. La información de la transacción ÜCAF proporcionada por el Comerciante se usa con el propósito de mostrar y algunos de ellos se usan para generar una transacción referente a un Desafio PCR. El Comerciante no se necesita un proceso adicional para ejecutar la información AAV dentro de la respuesta del ÜCAF. Esto se le indica al Comerciante a través del valor del Byte de Control ÜCAF establecido en el valor del Chip-UCAF. La Solicitud de Interfaz del Titular (Titular IA) proporciona la interacción entre el solicitante de la autenticación (Comerciante), el titular y el PRC. La Solicitud de Interfaz presenta la cara segura del presente esquema UCAF para el Titular. Es responsable de presentar la información de la transacción al titular, generando el desafio transferido al PCR, recibir el símbolo de respuesta del PCR, formatear el ÜCAF y poblar la información de retorno para el canal determinado. El IA del Titular tiene un mínimo de requerimientos que debe llenar para efectuar una transacción Chip-UCAF.
En el contexto de la presente invención, el Adquirente Habilitado UCAF tiene una relación con un comerciante 28
habilitado ÜCAF. Los Adquirentes habilitan a sus comerciantes a pasar la información ÜCAF extra a los sistemas adquirentes y permiten a sus sistemas identificar la presencia de y pasar la información ÜCAF proporcionada al banco emisor. El Emisor Huésped, o algún otro elemento actuante, en el esquema, como Emisor Huésped es responsable de tomar la información pasada en el mensaje de red de autorización, incluyendo la información en el ÜCAF, y permitiendo la validación del símbolo de autenticación.
Un ÜCAF, el cual de acuerdo con la presente invención conforme a los protocolos 3-D Secure, puede contener un símbolo de autenticación de usuario de máximo20-bytes . La figura 10 muestra la estructura del ÜCAF de acuerdo al 3-D Secure.
Las figuras 1 y 2 muestran implementaciones esquemáticas del CAP de la presente invención. Además del titular, él o ella, componentes de sistemas varios o actores están involucrados en la implementación de un CAP. Los componentes de sistema varios, que pueden ser lógicos o físicos, incluye un Servidor de Solicitud de Autenticación, un Recurso de PC del Titular, una Solicitud de Autenticación de código seguro (SCAA) , Y los 29
PCR conectados o desconectados. Estos componentes de sistema pueden ser convencionalmente enlazadas o configuradas usando, por ejemplo, redes alámbricas o inalámbricas .
El Servidor de Solicitud de Autenticación es una entidad lógica, que puede configurarse para proporcionar servicio de solicitud de autenticación a otra entidad o componente en un ambiente de servidor de Web, independientemente de la entidad o componente. Dicho Servidor de Solicitud de Autenticación puede adaptarse fácilmente y desenvolverse con diferentes ambientes y necesidades de comercio electrónico. Una vez que el Servidor de Solicitud de Autenticación autentica al titular, el Servidor puede regresar un resultado de autenticación positivo o negativo a la entidad o componente solicitante.
El Recurso Computacional Personal del titular puede tener cualquier plataforma de computadora o recursos de acceso en la cual el titular realice la actividad que se requiere para la autenticación. La plataforma de computadora puede ser una plataforma de PC, la cual pueda ser conectada al PCR. Alternativamente, la plataforma de computadora puede ser cualquier recurso que con capacidad para entrar a Internet, incluyendo, por ejemplo, las PDA 30
u otro recurso móvil Wi-Fi. Al titular se le asignará una tarjeta de pago inteligente, (es decir, ICC) y un PCR. En las implementaciones preferentes del CAP, el titular debe ingresar un número de identificación personal (PIN) dentro de su PCR antes degenerar un código seguro y proporcionarlo al Servidor de Solicitud de Autenticación para validación.
El PCR puede ser cualquier recurso compatible EMV-lector de tarjeta, el cual es designado para interactuar con el titular y la ICC para producir un código seguro. Las técnicas criptográficas convencionales (es decir, técnicas clave) se pueden usar para producir el código seguro. El PCR debe tener una pantalla y un teclado numérico para permitir interacción limitada al titular. Un PCR adecuado puede ser, por ejemplo, un lector de tarjeta inteligente portátil de bajo costo, con pantalla y teclado numérico. El PCR puede ser independiente, no necesitando conexión independiente a la computadora personal del titular. En tales casos, el titular debe transferir manualmente toda la información entre el PCR y la computadora.
Los PCR también pueden ser recursos conectados físicamente a la computadora del titular. En tales casos, 31
el titular únicamente necesitará ingresar su PIN en el PCR para iniciar el proceso de autenticación y el código seguro se pasa automáticamente del PCR a la interfaz del usuario en su computadora que esta conectada. Un PCR conectado puede proporcionar seguridad convencional o protección del PIN durante el proceso de entrada del PIN. La pantalla del PCR debe ser capaz de mostrar el resultado de validación del PIN y, para los recursos independientes, desplegar un "código seguro" para ingresarlo a la PC o PDA del titular. Un lector conectado puede funcionar como un lector independiente si no hay conexión disponible. Los PCR usados en las implementaciones del CAP pueden ser de diseño genérico, las cuales pueden soportar una variedad de implementaciones de tarjetas. El Servidor de Solicitud de Autenticación puede sugerir al titular que ingrese o no (por medio de la pantalla de la interfaz de la PC) un desafio en el PCR. Cuando se hace tal indicación, el PCR debe ser capaz de permitir al titular ingresar el desafio y después incluir el desafio en el código seguro de la computadora.
La Solicitud o Aplicación de Autenticación de código seguro (SCAA) puede residir en una multi-aplicación tarjeta de crédito, débito u otra tar eta multi- 32
aplicación (es decir, ICC) junto con una solicitud de pago estándar. La SCAA puede ser una instancia separa de la solicitud de pago, en cuyo caso el emisor tiene la opción de usar ambientes de seguridad separados para pagos y autenticaciones remotas. La aplicación puede soportar tanto la generación de una "contraseña de un solo uso" como la creación de un código de "prueba de aceptación de la transacción". Los emisores de tarjetas pueden escoger opcionalmente el uso del SCAA para otros servicios. El SCAA puede incluir información de formato o plantillas, las cuales instruyen al PCR sobre el tipo de formato de código seguro esperado por varios emisores de tarjeta. De esta forma se puede usar un solo diseño de PCR para soportar una gran variedad de tipos de tarjeta. En implementaciones preferentes, las funciones de uno o más de los Recursos Computacionales Personales del Titular, IC y PCR pueden estar integrados en u solo instrumento, el cual puede ser usado por el Titular para acceder a Internet y realizar transacciones autenticadas. Un recurso integrado adecuado puede ser, por ejemplo, una tarjeta con una pantalla que integre funciones de ICC y un PCR independiente en un paquete conveniente para el usuario. Otro recurso integrado adecuado que integre las funciones de una ICC y un PCR independiente en un paquete conveniente para el usuario, puede ser un fob clave. Un 33
PDA u otro recurso personal de acceso a Internet también debe ser configurado para realizar las funciones de ICC y PCR asignado al Titular. La figura 23 es una representación esquemática de una tarjeta 230, un fob 240, y un PDA 250, los cuales incluyen circuitos que pueden realizar las funciones de PCR e ICC. El PDA 250 puede funcionar adicionalmente como un recurso de acceso a Internet.
La figura 1 muestra esquemáticamente un ejemplo del proceso de autenticación CAP 100 que se puede usar para autenticar a un titular 180 para una transacción en linea 180. Al Titular 180 se le puede emitir una ICC personal 170 y un PCR 160 independiente para realizar transacciones en linea. Se entiende que la ICC 170 Y EL PCR 160 juntos pueden ser una tarjeta integrada con una pantalla (Fig.23 tarjeta 230). El proceso 100 se puede iniciar en respuesta a una solicitud de autenticación 150 enviada por una Entidad externa 110 a un Servidor de Solicitud de Autenticación 120. En el proceso 100, el Servidor de Solicitud de Autenticación 120 interactúa con el titular 180 a través de la Página de Autenticación de Tarjeta 130 (es decir, una página HTML) desplegada en la PC del Titular 140. El servidor ce Solicitud de Autenticación genera la página HTML 130 y puede 34
proporcionarlo directamente. Alternativamente la página HTML 130 puede ser proporcionada por medio del solicitante de autenticación (Entidad 110) dependiendo de la infraestructura particular del servidor web o técnicas desplegadas en la red electrónica. La solicitud de autenticación (es decir, solicitud 150) puede ser el resultado de una pregunta http, el cual es capaz de procesar HTML en respuesta (es decir, resultado 150) generado por el Servidor de Solicitud de Autenticación 120. En el proceso 100, la solicitud de la autenticación (150) puede solicitar que se incluya o de otra forma proporcionar la siguiente información o datos:
• Número de Cuenta Personal (PAN) - El PAN de la tarjeta se puede usar en el proceso de autenticación
• Mensaje de Garantía Personal del Titular (PAM) - A los Titulares registrados en los programas CAP se les puede solicitar que proporcionen un Mensaje de Garantía Personal que se desplegará cuando solicite la autenticación. • Detalles de la Transacción - Detalles de la transacción para la cual se solicita la autenticación al titular, ya sea para pago de mercancía de un sitio web o para obtener acceso a una cuenta bancaria.
35
Con referencia a los pasos numerados en la figura 1, en el paso 1 del proceso 100, el Servidor de Control Solicitante de Autenticación 120 genera una Página de Autenticación de Titular 130 para desplegarla al titular. La Página de Autenticación del Titular puede ser una página HTML desplegada en la PC del titular 140. La Página de Autenticación del Titular puede desplegar detalles de la transacción proporcionados por la Entidad solicitante 110. Un PAN de 16 dígitos se puede desplegar en grupos: tres grupos de X (es decir, "XXXX") , seguido de los últimos cuatro dígitos actual e el PAN para ayudar al titular 180 para reconocer la tarjeta correcta para autenticación. El PAM del titular, que se proporciona cuado el titular se registra en el CAP también se puede desplegar. En el paso 2, el titular 180 puede iniciar la solicitud para un símbolo de seguridad, es decir, un código seguro, para pagos remotos o identificación. Se le puede sugerir al titular que su PCR 160 lea su ICC 170. Al titular se le proporcionará una serie de preguntas de diferentes tipos de códigos de seguridad (paso 2a) . Los diferentes tipos de códigos de seguridad pueden corresponder, por ejemplo a firmas de autenticación de pago remoto, o autenticación para identificación de acceso a cuenta bancaria. Para el primer tipo de código seguro, (Bruce, Alfred, por favor confirma) , se le puede 36
sugerir al titular que ingrese un desafio desplegado en la página web 130 al PCR 160. Si no se proporciona un desafio, el titular puede proceder a activar cualquier tecla designada en el PCR 160 (es decir, un botón de proceso) . Además, para transacciones donde la ICC 170 tiene una bandera de autenticación de Internet (1AF) , que indica una cantidad de transacción que debe ser firmada o autenticada, se desplegará al titular 180 una cantidad de transacción en la página web 130. Se le puede sugerir al titular 180 seleccionar la moneda de la transacción de una lista integrada e ingresar la cantidad desplegada en la página web. Después de esta entrada el titular puede proceder con el paso 3 activando la tecla adecuada designada en el PCR 160.
En el paso 3 al titular 180 se le puede sugerir que ingrese un PIN del titular. Si el PIN no se ingresa correctamente, se le sugerirla titular que reingrese el PIN. Se le permitirá al titular 180 un número limitado de intentos para ingresar el PIN correctamente. Este número limitado puede ser un número pre-seleccionado que se establece en un contador interno en la ICC 170. Si el titular 180 no puede ingresar el PIN correcto en el número permitido de intentos, se rechaza la transacción.
37
Entonces se le puede solicitar al Titular 180 que someta medios de pago diferentes o alternativos.
Una vez que se ha ingresado el PIN correcto, en el paso 4 el PCR 160 realiza un diálogo de transacción óptima EMV con la tarjeta 170 para generar un criptograma de aplicación. El criptograma puede ser un Criptograma de Solicitud de Autorización (ARQC) en la terminología estándar EMV. En algunas instancias la ICC 170 puede tener rutinas de manejo de riesgo interno que causan la generación de un Criptograma de Autenticación de Aplicación (AAC) en lugar de un ARQC. Cualquiera de los dos tipos de criptograma puede ser aceptado por el PCR 160. En el paso 5a, el PCR 160 convierte el AQRC o AAC a un código numérico seguro para desplegarlo al titular 180. El código numérico seguro puede tener, por ejemplo, una longitud de 8 dígitos. En el paso 5brel código seguro generado por el PCR 160 se lee y puede ser ingresado manualmente por el titular 180 en un campo de entrada apropiado en la página HTML 130 en la PC del Titular 140. En el paso 6, el titular puede someter la página HTML 130 con la entrada de código seguro al Servidor de Solicitud de Autenticaciónl20 para aprobación o validación. En el paso 7, el Servidor de Solicitud de Autenticación 120 puede acceder a una base de datos del titular para 38
recuperar o actualizar la información específica estática o dinámica de la tarjeta. la información dinámica especifica de la tarjeta, que puede ser investigada por el Servidor de Solicitud de Autenticación 120, puede incluir un Contador de Transacción de Aplicación (ATC) . La base de datos del titular puede conservar una copia del último ATC conocido 190 para que un ATC completo pueda ser correctamente reconstruido en combinación con un ATC parcial (bits inferiores) regresados en el código seguro.
En el paso 8, El Servidor de Solicitud de Autenticación 120 puede validar el código seguro reconstruyendo la información ingresada usada por la ICC en la generación del criptograma. La información ingresada reconstruida puede incluir información estática conocida, cualquier información específica de la transacción (desafío, cantidad/moneda) que fue sometida a la ICC 170 por el PCR 160 (paso 4) , e información recuperada de la base de datos de la tarjeta 190. En los casos donde se use desafío en el pase 3, se puede configurar el PCR 160 para que use un valor nulo por defecto para el número no predecible. Igualmente, si no se usan valores de cantidad y moneda en el paso 3, se puede configurar el PCR 160 para que use valores de 0 por defecto para ambas 39
variables. A partir de la información de entrada reconstruida, el criptograma de aplicación (AQRC o AAC) se puede volver a calcular y comparar con el criptograma de aplicación parcial (AC) en el código seguro recibido en el paso 6 por el servidor de solicitud de aplicación 120. Si el AC recalculado y el recibido coinciden, un valor ATC puede ser actualizado en la base de datos de la tarjeta 190.
Un paso final 195 en el proceso 100, el Servidor de Solicitud de Aplicación 120 proporciona el resultado de la prueba de autenticación a la Entidad 110 solicitante.
La figura 2 muestra en esquema otro ejemplo del proceso de autenticación 200 que se puede usar en los casos en donde el titular 180 se emite en un PCR conectado. El proceso 200 es generalmente similar al proceso 100 excepto en que cualquier desafio e información de cantidad/moneda se comunica directa o automáticamente al PCR 160 por un componente de software anidado en la página HTML 130. Similarmente, se puede ingresar un código seguro automáticamente en un campo de información propio después de que el titular 180 ingresa correctamente su PIN (en el paso 3) para verificación. Como en el proceso 100, el proceso 200 puede presentar la 40
opción de una firma u operación de identificación al titular 180 por medio del PCR 160. En instancias donde se requiere que el titular 170 firme una cantidad de transacción, el proceso 200 puede desplegar la cantidad en el PCR 160 antes de permitir la entrada del PIN. El Servidor de Solicitud de Autenticación 120 procesa el código seguro generado por el proceso 200 en forma idéntica al proceso del código seguro generado por el PCR 160 (Figura 1) .
En ambos proceso 100 y 200, las características de seguridad EMV son la base para la seguridad del CAP. Más específicamente, el CAP depende de la generación del criptograma, llamado Criptograma de Aplicación (AC) , por la ICC para establecer prueba de la presencia de la tarjeta y del titular para generar un código seguro de una-vez. La prueba de la aprobación de la transacción por el titular se basa en el uso de un desafío. El uso de los criptogramas específicos de la transacción ofrece protección contra la solicitud repetitiva de una transacción genuina y la generación de transacciones fraudulentas .
La ICC (es decir, ICC 170) está programada para generar un criptograma para una transacción particular en 41
respuesta a un comando EMV estándar (es decir, GENERAR un comando AC) . La respuesta generada por la ICC 170 para GENERAR un comando AC incluye los siguientes elementos de información: Datos de Información de Criptograma (CID), Contador de Transacción de Aplicación (ATC) , Criptograma computarizado por la ICC (AC) , e Información de Solicitud del Emisor (IAD) . Estos elementos de información contienen información que es única para una transacción particular e información no-única, que se puede obtener de otros recursos. La información que es única para la transacción se transfiere (en forma de criptograma) el PRC a una Interfaz de Aplicación (es decir, como código seguro por medio de la página HTML 130) para proceso posterior. La información, que se obtiene de otros recursos, no se incluye en el código seguro. Se asume que tal información no-única tiene un valor particular para un determinado esquema de tarjeta de un emisor, única para la ICC particular y conocida (o al menos deducible) por el huésped emisor, por medio de la bases de datos del titular.
La ICC 170 puede incluir un objeto de información o máscara (es decir, Un Emisor de Mapa de Bits Propietario de Internet (IIPB) con un marbete de A0x9F56')que usa el PCR para determinar que porciones (es decir, bits) de la 42
respuesta de las ICC debe usar para generar información de autenticación c criptogramas. El número de bits que se usan pueden ser definidos o seleccionados por el emisor. El número de bits se puede seleccionar, por ejemplo, sobre consideraciones ergonómicas del número limite de bits de información que puede ser convenientemente transferido manualmente por el titular desde un PCR independiente 160 a una PC 140. El IIPB se puede usar como máscara de bits por el PCR 160 o 160' para obtener un "Símbolo de Información IIPB" que al comprimirse forme el símbolo de código seguro que se pasa al solicitante de la autenticación .
La figura 9 muestra un ejemplo de una estructura IIPB 900. Los bits que componen el IIPB 900 se pueden considerar como banderas de transmisión, indicando cuales bits de la respuesta AC Generada requiere el emisor para incluirlos en el código seguro. Estas banderas pueden corresponder, en una base bit-a-bit, a los bits que deben ser enviados desde el PCR (es decir, CID 1 byte, ATC 2 bytes, AC 8 bytes, y IAD 0-32 Bytes) . El IIPB 900 puede ser de hasta 11 bytes de longitud en el remoto caso de que no esté definido un IAD. El IIPB puede ser de hasta 43 bytes de longitud en casos donde la tecnología de aplicación del emisor usa los32 bytes disponibles en la 43
Información de Aplicación del Emisor (IAD) . Además, el IIPB 900, que se usa como máscara contra la concatenación de los elementos de la información CID, ATC, AC y IAD, puede resultar en una estructura que tenga una longitud de entre 11 y43 bytes. Ambos, el PCR 160 y 160' pueden ser adecuadamente configurados para determinar que la longitud del IIPB 900 concuerde con la longitud de la información de los artículos regresados en la respuesta AC Generada en las ICC 170.
Una longitud efectiva de IIPB se refiere al número de bits - como lo define el IIPB - que serán transferidos dentro del Símbolo de Información IIPB (el cual se gobierna por el número de bits del PIB que se establecen en 1 para indicar la transferencia requerida de bits) . En implementaciones CAP de ejemplo, el código seguro no excede 26bits, que es el número máximo de bits que pueden ser transferido con un número decimal de 8 dígitos (es decir, 67,108,863). La longitud efectiva del IIPB no puede exceder los 26 bits, ya que esto requeriría más de 8 dígitos para el símbolo.
La ICC 170 establece prueba de presencia del titular por medio del uso de validación de PIN no interactivo. Las especificaciones estándar EMV requieren que la validación 44
de PIN no interactivo se realice antes de generar un AC. Consecuentemente, se requiere la presencia del titular para generar un AC válido, y la existencia de un criptograma válido es suficiente para demostrar la presencia del titular. El AC generalmente se basa en el ARQC, pero puede basarse en el AAC si las rutinas de manejo de riesgo interno de la tarjeta determinan declinar el pago de una transacción.
La prueba de la aceptación o aprobación de una transacción por el titular se basa en el uso de información proporcionada por el Servidor de Solicitud de Autenticación para generar el criptograma y el código seguro. La información proporcionada por el Servidor de Solicitud de Autenticación se usa como un desafio especifico de transacción desplegado al titular. El desafio es un valor numérico que se desarrolla a partir de información conocida únicamente por el Servidor de Solicitud de Autenticación. El valor numérico se basa en cualquier información adecuada que el emisor puede considerar relevante o pertinente (es decir, la cantidad de la transacción y el código de moneda) . Un desafio diferente producirá un código seguro diferente y no hay forma predecible de saber que desafio se podrá usar para crear un código seguro especifico. Por consiguiente, el 45
uso de un desafío especifico de transacción proporciona al emisor y Servidor de Solicitud de Autenticación con la prueba de que el titular aprobó esa transacción específica porque el desafío desplegado se incluye en el criptograma generado por el PCR y el criptograma se incluye en el código seguro.
Para asegurar la protección contra réplicas fraudulentas o solicitudes duplicadas de transacciones genuinas, las implementaciones del CAP se pueden configurar para revisar el Contador de Transacción de Aplicación (ATC) recibido de la ICC contra el último ATC recibido para esa ICC particular. Las transacciones que usen un ATC previamente recibido se declinarán como duplicadas. Además, el AC generado por la ICC se puede calcular para que varíe como una función de la ATC. Esto se puede realizar incluyendo el ATC como parte de la información de entrada usada para el cálculo del AC.
Únicamente porciones truncadas del AC generado por la ICC se transfieren al emisor. Cada criptograma és truncado, como lo especifica el Emisor de Mapa de Bits Propietario de Internet (IIPB) . El emisor puede, por ejemplo, definir el PIB, de tal manera que 16 bits del AC se incluyan en el código seguro regresado por los PCR.
46
Debido al tamaño reducido de los criptogramas truncados, los emisores pueden implementar sistemas de detección de fraude para detectar números anormales o validaciones de criptogramas fallidos.
Las figuras 3 y 4 muestran procesos de ejemplo de PCR y flujo de información involucradas en la generación de un numero de desafio y en la verificación de PIN para un PCR independiente y un conectado, respectivamente. Una diferencia primaria en el uso de un PCR conectado y un PCR independiente es la conveniencia del usuario. En el caso del PCR conectado, el enlace entre la PC y el PCR transporta información entre los dos. En el caso de un PCR independiente, la información debe ser copiada manualmente por el titular para transferirla entre los dos. Se entenderá que las figuras 5.3 y 3.4 no son ilustraciones detalladas de los comandos exactos enviados a la ICC o los pasos de proceso exactos en el PCR. Como aclaración, estos elementos que ayudan a ilustrar el sistema, sus estructuras de información y principios generales de proceso, se muestran esquemáticamente .
Con referencia a los pasos numerados mostrados en la figura 3, la secuencia de los pasos de proceso para 47
verificación del PIN y sugerencias correspondientes que se despliegan al titular puede ser como sigue:
1. Se le solicita al titular que inserte su tarjeta. El titular inserta su tarjeta habilitada de autenticación del emisor (ICC) en el lector de tarjeta personal. Insertar Tarjeta Con los lectores independientes, la acción de insertar la tarjeta puede encender el PCR o el titular puede necesitar encenderlo.
2. Se le solicita al titular seleccionar el tipo de funcionalidad de PCR requerida. [S] Firma o [I] PIN
3. El titular hace la selección de la funcionalidad del PCR por medio de teclas de función especifica o menú.
4. El PCR usa la lista de selección apropiada a la funcionalidad solicitada para buscar y seleccionar una aplicación para usarla al generar el código seguro apropiado .
5. El PCR lee los elementos de información seleccionados de la ICC, incluyendo IIPB e IAF.
48
Si el titular selecciona una operación de Firma:
6. El PCR sugiere al titular ingresar un Desafio.
La generación del Desafio es propiedad del emisor; el Desafio se usará para el Número Impredecible (UN) en el manejo de transacción EMV. Desafio>
7. El titular debe ingresar este Desafio en el teclado del PCR y presionar la tecla [Entrar] para indicar el término de la entrada del Desafio. 5 58 581 5811 58113 581139 5811396 58113967 [Entrar]
Cuando los Servidores de Solicitud de Autenticación no requieren un Desafio, el titular simplemente presiona el botón [Entrar] sin ingresar ningún dígito de Desafio. El PCR usará un valor nulo (0) , para el UN en respuesta a un comando GENERATE AC posterior.
49
8. Si la ICC indica que se ha incluido moneda y cantidad en el criptograma, el PCR despliega una lista estándar de monedas para que el titular seleccione de ella: 1. EUR 2. USD 3. GBP 4. Otro > [Entrar] 9. Se le sugiere al titular que ingrese > ?????999 ?? EUR El titular ingresa la cantidad y presiona [Entrar]
Los emisores que requieren una cantidad y moneda para incluirlas en el criptograma pueden indicar este requerimiento al establecer el IAF. La cantidad y moneda se despliega al titular en la Página de Autenticación del Titular .
10. El PCR despliega una sugerencia para que el titular ingrese su PIN: Ingrese su PIN
11. El titular ingresa los dígitos de su PIN y presiona [Entrar] para indicar que ya terminó la entrada 50
del PIN, como se ilustra con un PIN de ejemplo, de 4 dígitos, abajo:
* ** *** ****_ [Entrar]
12. El PCR somete el PIN a la ICC para verificación. Detección de error: Si la ICC reporta una entrada inválida de PIN, el PCR informa al titular de los intentos de número de PIN remanentes: PIN malo, quedan 2
El titular ingresa entonces el PIN correcto, presiona la tecla [Entrar] , y el PCR reporta una entrada válida de PIN. *****_ [Entrar]
PIN OK!
El proceso de verificación de PIN 310 usando un lector conectado (Figura 3.4) puede ser generalmente similar al proceso de verificación de PIN 300 usando un lector independiente (Figura 5.3) . Sin embargo, en el proceso 51
310, la recepción del comando APDÜ apropiado puede empezar el flujo del proceso de transacción en lugar de la inserción de la tarjeta o encender el lector como en el proceso 300. El proceso 310 también puede diferir del proceso 300 en la forma de recibir la información del desafio. El titular no requiere ingresar un desafio, ya que cualquier información de desafio necesaria puede ser proporcionada con el APDÜ que inició la transacción.
En ambos procesos 300 y310, los PCR pueden calcular los códigos seguros en forma idéntica. En el proceso 310, se puede requerir que el código seguro calculado sea regresado en la respuesta APDÜ. Este Requerimiento asegura que el Servidor de Solicitud de Autenticación puede tratar a los PCR conectados e independientes de la misma manera al procesar la respuesta.
El CAP usa un Criptograma de Aplicación (AC) como el mecanismo para autenticar la ICC y el Titular. El comando AC GENERADO por la EMV se usa para solicitar a la ICC que genere un Criptograma de Solicitud de Aplicación (ARQC) . El elemento de información EMV especifica la información que debe ser proporcionada en este comando, identificada convencionalmente como CD0L1. ün número impredecible (UN) es un componente de 4-bytes (32-bits) de la información 52
pasada a la ICC en el comando GENERATE AC. Es el número (o información) que es impredecible a la ICC como opuesto a la aplicación. El desafio pasado al PCR se usa como número no predecible (UN) para la generación del criptograma. El número máximo de 8 dígitos se puede usar para el Desafío en una forma BCD (Decimal Codificado Binario) cuando se envía a la ICC. Cualquier desafío de menos de 8 dígitos puede involucrar el uso de relleno convencional (es decir, colocando 0) hasta los 8 dígitos al crear un UN. La figura 5 muestra un ejemplo de Desafío de 8 dígitos.
En implementaciones de CAP, el PCR se configura para procesar la respuesta de la ICC al comando GENERATE AC para llegar al código seguro o símbolo que debe ser regresado a la Aplicación Interfaz. La respuesta completa de un PCR al comando GENERATE AC puede ser muy largo para ser enviado al emisor. Por consiguiente, el PCR usa el IIPB para realizar la extracción de información y proceso de compresión para generar un Símbolo de Información PIB, que es la información que se transfiere (después de cifrarla) del PCR a la Aplicación Interfaz. Los PCR conectados pueden transferir esta información directamente a la Aplicación Interfaz, mientras que para los lectores independientes, el titular debe transferir esta información manualmente.
53
Al establecer un bit ?1' y el IIPB (Ver por ejemplo la Figura 9) indica que se Requiere' la posición del bit correspondiente en la información de respuesta y necesita ser enviada.
Al establecer un bit 0' indica que el emisor sabe o puede deducir que debe estar el bit establecido y entonces el bit no necesita ser enviado como parte del código seguro.
El Símbolo de Información IIPB se construye, de derecha a izquierda, con el primer bit que se va a extraer colocado en el bit 1 del último byte de la información saliente, el segundo en el bit 2 , etc. Un ejemplo de Símbolo de Información IIPB 3700, el cual se llena de esta manera hasta que no haya más bits que transferir, se muestra en la figura 7.
La información (es decir, el ejemplo de Símbolo de Información IIPB) que se transfiere del PCR a la Interfaz de Aplicación se cifra primero como un código seguro. En las implementaciones del CAP, los PCR se configuran con algoritmos adecuados para computar un número que represente el patrón de bits de la información que se va a transferir. Un lector independiente desplegará este 54
número - el código seguro- para que el titular pueda ingresarlo en el campo apropiado desplegado en la Página de Autenticación del Titular. Los algoritmos de cifrado del PCR usados para convertir los bits requeridos a dígitos numéricos desplegados son preferentemente interoperables y reversibles en el Servidor de Solicitud de Autenticación. El mismo algoritmo que se usa para convertir de bits a símbolo se puede usar para convertir de símbolo a bits. Una técnica de compresión adecuada involucra el trato de patrón de bit como un número binario y realizando una conversión de Base-2 a Base-10, como se muestra en la figura 6.
Las implementaciones de CAP se diseñan para ser consistentes o compatibles con las plataformas de 3-D Secure, sistemas y métodos de todas las partes en la cadena de transacción, incluyendo el comerciante, el adquirente, el emisor y el titular. El CAP estándariza ventajosamente el uso de información de autenticación emisor-chip definido. Las implementaciones del CAP pueden aprovechar la infraestructura de mensaje estándar
Las siguientes Entidades 3-D Secure lógicas o físicas se pueden involucrar a lo largo del tiempo de vida de un CAP Transacción autenticada por el chip (Figura 8) .
55
Titular - El titular inicia la transacción y es responsable de ingresar la información en las páginas web de pago del comerciante, el Lector de Tarjetas Personal, y la Página de Autenticación del Titular. El titular debe ingresar su PIN en el PCR para que el PCR cree un código seguro usando una Solicitud de Autenticación de Código Seguro (SCAA) .
Comerciante - El comerciante proporciona la información necesaria para empezar la autenticación, y recibe la información de autenticación resultante para enviarla, por medio del adquirente, al emisor para verificación. El comerciante opera el proceso normal 3-D Secure.
Página de Autenticación de Titular - La Página de Autenticación del Titular es la presencia del ACS en la página web. Esta página despliega la información relevante e instrucciones proporcionadas por el ACS, e interactúa con el titular. El ACS regresa la Página de Autenticación de Titular al titular y corre como parte del navegador de Internet (es decir, como una ventana emergente) . Esta página, además de la información estándar desplegada para las implementaciones 3-D Secure de MasterCard, 56
también puede incluir un Desafio si el emisor lo solicita .
Lector de Tarjeta Personal - El Lector de Tarjeta Personal interactúa con el titular y la ICC para producir un Código Seguro y pasarlo, indirectamente, al emisor a través del ACS. Dependiendo del tipo de lector y tipo de transacción, el titular puede necesitar ingresar un Desafio y posiblemente se despliegue cantidad/moneda en la ventana emergente de autenticación generada por el emisor antes de ingresar el PIN requerido. El titular debe ingresar el Código Seguro (desplegado en un PCR independiente) en la página web de Autenticación del Titular. (Ingreso de información, además del PIN y posible confirmación de cantidad/moneda, no es necesaria con un lector conectado) .
ICC - La tarjeta inteligente compatible con EMV autentica al titular por medio de la verificación del PIN y genera un criptograma adecuado basado en la información proporcionada por el Lector de Tarjeta Personal.
57
Adquirente - El adquirente acepta la información de la transacción del comerciante y la envia al emisor por medio de la red apropiada. El adquirente puede seguir los procedimientos estándar o de común acuerdo para obtener la autorización del emisor.
Emisor - El emisor distribuye los Lectores de Tarjetas Personales a aquellos titulares que firman el Programa de Autenticación por Chip MasterCard para 3-D Secure. Importante, el usuario puede validar opcionalmente la información de autenticación (AAV] transmitida en el campo DCAF dentro de la solicitud de autorización del adquirente, de acuerdo con las reglas del emisor.
Servidor de Control de Acceso - El emisor opera el Servidor de Control de Acceso como se especifica en 3-D Secure con la habilidad adicional de presentar la Página de Autenticación de Titular y recibir el código seguro del PCR (ya sea directamente, o indirectamente del titular) . El ACS verifica la validación del código seguro usando un Servicio de Solicitud de Autenticación, el cual: 58
Extrae la información conocida únicamente del chip (ATC e indicador del tipo de criptograma) del código seguro .
Regenera el criptograma.
Compara el resultado con el criptograma parcial del código seguro.
Servidor de Registro - El servidor de registro y el proceso de registro son lo mismo que el proceso normal de 3-D Secure. Puede haber un requerimiento para el titular de indicar que el PAN se refiere a una tarjeta inteligente y que el chip se usará para crear un código seguro en lugar de una contraseña estática. Esto puede ser una decisión del titular o del emisor, o posiblemente una opción de configuración. El emisor debe indicar el formato del código seguro y si el Desafio se despliega o no para que el titular lo ingrese en el PCR. Lo ideal es que la mayoría de estas decisiones sean opciones de las cuales puede escoger el emisor.
Servidor de Directorio - El Servidor de Directorio opera en el modo normal de 3-D Secure.
59
La figura 8 muestra algunos de los pasos y flujo de mensajes 500 entre las entidades involucradas en el ejemplo de las transacciones CAP (autenticadas por chip) en un ambiente 3-D Secure, el cual, por ejemplo, puede ser el ambiente de la versión 1.0.2 de 3-D Secure. El CAP proporciona el necanismo de autenticación entre la Tarjeta/Titular y el Servidor de Control de Acceso del emisor (ACS) 510. El ejemplo de flujo de mensajes mostrado, asume que antes de conducir la transacción, el titular 580 se registró con un emisor para el servicio, y tiene una tarjeta inteligente y PCR compatible. Además, el titular 580, que desea hacer una compra, ha seleccionado la mercancía o servicios e iniciado el proceso de "revisión" en el sitio web del comerciante. El comerciante ya ha solicitado al titular 580 que proporcione detalles de su tarjeta de pago, la cual ha sido ingresada por el titular 580 en el sitio web del comerciante de una forma protegida. El CAP basado en la autenticación afecta únicamente el paso 8 - creación y entrada del código seguro.
Los formatos estándar de información y mensaje de la versión 1.0.2 de 3-D Secure, se pueden usar para todo el flujo de mensajes 500. Específicamente, CAVV, cuyo ACS 510' crea y regresa al comerciante para la inclusión del UCAF, 60
transportado en 28 caracteres de longitud y que contiene el campo de 20 bytes definido por 3-D Secure en base a código 64 (Ver es decir, Figura 10) . El uso del CAP de la Solicitud de Autenticación (SCAA) se puede indicar en el campo "Modo de Autenticación" (valor 2' ) . El mismo formato para AAV se puede usar en una operación CAP de código seguro dinámico y para los modos de operación tradicional de 3-D Secure de contraseña estática.
Con referencia a la figura 8, los pasos numerados completos o flujo de mensajes 500 son como sigue:
1. Detalles de pago: El Titular al Comerciante (Forma HTTPS/POST (remitida)
El titular, habiendo navegado y seleccionado los artículos, proporciona sus detalles personales "eligiendo", incluyendo - de interés particular en este campo de aplicación - detalles de la tarjeta de pago al comerciante, es decir, el número de tarjeta grabado (PAN) .
2. VEReq (Solicitud de Verificación de Registro): Comerciante al Servidor de Directorio (DS) (HTTPS/Remitir) 61
El software de procesamiento 3-D Secure del comerciante envía una VEReq a la sucursal apropiada del servidor de directorio para determinar si el PAN está registrado en el programa 3-D Secure del Emisor.
Se puede estimular al comerciante a mantener, diario, una memoria caché local del servidor de directorio para evitar que tenga que consultar el servidor de directorio para cada pago. La caché puede contener todos los tipos de tarjetas seleccionadas participantes en este programa. El uso de la opción de caché evita llamadas al directorio para aquellos casos en que el PAN del titular no es elegible para participar en el programa.
3. VEReq: Servidor de Directorio a Servidor de Control de Acceso (ACS) HTTPS/Remitir) .
Basado en el tipo de tarjetas, el servidor de directorio pasa el VEReq al ACS apropiado. El ACS determina si la tarjeta (PAN del titular) está registrada o no en 3-D Secure .
4. VERes (Respuesta de Verificación de Registro): ACS a DS (Respuesta a HTTPS/REMITIR) 62
El ACS regresa una indicación de si el PAN especifico está registrado en el sistema, y, si es asi, el URL que se usará para redireccionar el navegador del titular hacia el ACS para realizar la autenticación.
El ACS regresa un Identificador de Cuenta único, que no debe ser el PAN, y lo usará el ACS cuando el titular lo contacte con un PARed para identificar la tarjeta de pago en cuestión. Este Identificador de Cuenta debe concordar con el PAN de la tarjeta actual de uno-en-uno para que la clave se pueda generar correctamente y el código seguro pueda verificarse.
5. VERes: DS a Comerciante (Respuesta a HTTPS/remitir) El DS regresa esa respuesta al comerciante.
6. PAReq (Solicitud de Autenticación de Pagador) : Comerciante a Titular (Página HTML)
El software de proceso 3-D Secure del comerciante construye un PAReq, lo cifra en Base64 y lo coloca en el campo de la forma HTML (PAReq) . El URL del comerciante al cual el navegador del titular debe redireccionar después de la autenticación, se coloca en el campo de la forma HTML (Termino URL) y cualquier información establecida 63
por el comerciante que pueda ser solicitada al contactarlo via Término URL también se coloca en un campo de la forma HTML (MD) . Una página HTML se regresa al titular como respuesta al remitir los detalles de su pago. La dirección para REMITIR de esta forma es el URL del ACS, de acuerdo al VERes.
7. PAReq: Titular a ACS (HIT/REMITIR)
La página regresada por el comerciante puede abrir típicamente una pequeña ventana emergente adicional, la cual entonces REMITE la información de la forma llenada por el comerciante al ACS.
El ACS revisa los detalles del titular y determina el mecanismo de autenticación que se va a usar en este pago de tarjeta particular y, en caso de autenticación por chip, el tipo de Desafío requerido para la autenticación.
8. Autenticación de Titular: ACS a Titular a ACS (Página HTML seguido por HTTPS/REMITIR)
El paso 8 será conducido de una manera apropiada para el emisor y/o titular particular. En las implementaciones del CAP, el proceso de autenticación se puede llevar a 64
cabo usando un Servidor de Solicitud de Autenticación como se describe en las Figuras 1, 2 y Anexo ¡ . El ACS 510 proporcionará más de un tipo de autenticación de titular, pero únicamente se puede permitir un método por tarjeta. El ACS 510 puede determinar el método permitido para una tarjeta de la información almacenada para la tarjeta/titular. El ACS controla la interfaz con el titular y dirige el uso del PCR del titular. Basado en los parámetros de configuración dentro del ACS, el emisor puede implementar un código seguro de "contraseña de una vez" o puede implementar un código seguro de "aceptación de transacción". La diferencia es que el titular debe ingresar un Desafio en un PCR independiente antes de ingresar su PIN para aceptar una transacción especifica. Este paso no se requiere con la contraseña de una vez.
9. Generar CAVY: ACS
En la validación satisfactoria por medio del mecanismo de autenticación empleado, el ACS construye una Solicitud de Pago Seguro (SPA) AAV de acuerdo a la arquitectura imple entada por 3D Secure. Este valor será colocado en el CA VV del subcampo del PARes que se regresa al comerciante .
65
10. PARes (Respuesta de Autenticación de Pagador) ACS a Titular (Página HTML)
El ACS construye un PARes, incluyendo el AAV y la firma del mensaje, lo cifra en Base 64 y lo coloca en el campo de la forma HTML (PaRes) . La información del comerciante recibida en el PAReq también se regresa al comerciante en el campo de la forma HTML (MD) . La dirección para REMITIR para la forma de esta página es el URL del comerciante, de acuerdo con el campo Término URL del PAReq.
11. PARes: Titular a Comerciante (HTTPS/REMITIR)
La página regresada por el ACS después REMITE la información de la forma llenada por el ACS al comerciante, donde el software de proceso 3-D Secure del comerciante verifica la firma del mensaje generado por el ACS.
12. Solicitud de Autorización: Comerciante a Adquirente (Propietario de la Comunicación)
El Comerciante incluye el AAV recibido en el PARes en la solicitud de autorización enviada al Adquirente, junto con la información estándar de la solicitud de autorización.
66
13. MT0100&0200: Adquirente a Emisor (BancaNet)
El solicitante extrae la información de autenticación y la inserta en el campo UCAF dentro del mensaje de autorización y la envía a la red apropiada de autorización MasterCard.
14. Verificar SPA AAV: Emisor
El emisor puede verificar el valor AAV contenido en el campo UCAF del mensaje de autorización para asegurar que la autenticación del titular tuvo lugar con la tarjeta dada .
15. MT0110/0210: Emisor a Adquirente (BancaNet)
El proceso de autorización estándar se lleva a cabo y la respuesta se regresa al Adquirente.
16. Respuesta de Autorización: Adquirente a Comerciante (Propietario)
El comerciante recibe la respuesta de autorización de su adquirente .
67
17. Respuesta/Recibo: Comerciante a Titular (HTML)
El comerciante regresa una indicación al titular de que su pago ha sido aceptado.
La Figura 11 muestra un ejemplo de la secuencia de los pasos del proceso que puede estar involucrado en la compra en linea de un cliente en un ambiente de 3-D Secure con una implementación de CAP. La implementación del CAP puede estar diseñada para estar estratificado en los sistemas existentes de comercio electrónico de modo que las transacciones se puedan efectuar con o sin servicios de autenticación de titular solicitados por el comerciante y/o titulares registrados.
En el paso 2200, el cliente compra y selecciona artículos para compra, por ejemplo, en una página web de un comerciante. El cliente puede, por ejemplo, usar PDA 250 INTEGRADO (Fig. 23) para este propósito. En el paso 2210, el comerciante puede solicitar al cliente información de pago en respuesta a lo cual el cliente puede ingresar un número de tarjeta. En el paso 2230, el comerciante puede desplegar una solicitud de confirmación y requerir al cliente que presione un botón para confirmar. En el paso 223, el MPI puede revisar si el número de tarjeta está en el intervalo de tarjeta oculta, el MPI puede generar una 68
VEreq para ver si el titular está registrado en el programa CAP (paso 2240) y esperar la verificación. En el paso 224, si no se recibe una verificación positiva en un tiempo de espera determinado, el MPI puede proceder con el paso 2270 para solicitar una autorización de no autenticación. Además en el paso 224, si se recibe una respuesta de verificación positiva dentro de un tiempo de espera predeterminado, el MPI puede proceder con el paso 2250 para generar un mensaje al emisor para solicitar la autenticación del titular.
En el paso 225, si no se recibe una respuesta positiva dentro de un periodo de tiempo, el MPI puede proceder con el paso 2270 para solicitar una autorización de no autenticación. Además en el paso 225, si se recibe una respuesta positiva dentro de un periodo de tiempo, el proceso puede progresar sucesivamente a los pasos 226 y 227 respectivamente para confirmar si se obtuvo una firma de validación y si el proceso de autenticación del titular se completó satisfactoriamente (por el ACS) . Si alguno de estos pasos no es satisfactorio, el MPI puede regresar al paso 2210 donde el comerciante puede volver a solicitar al titular la información de pago. Si estos pasos indican que el proceso de autenticación del titular se ha completado satisfactoriamente, en el paso 228 el MPI recibe el 69
resultado de la autenticación, que puede ser positivo o negativo y tener varios códigos de razones.
Además en el paso 228, el MPI puede cuestionar el resultado de la autenticación y proceder de acuerdo a ello para someter una solicitud de autorización de autenticación con información UCAF en el campo de transporte UCAF (paso 2260) o al paso 2270 para someter una solicitud de autorización de no autenticación. En el paso 228, el MPI también puede proceder alternativamente con el paso 229 para cuestionar la razón de los códigos recibidos en el resultado de autenticación. De acuerdo con los resultados del cuestionamiento de las razones, el MPI puede opcionalmente elegir entre volver a solicitar información de pago al cliente (paso 2210) o proceder con el paso 2270 para someter una solicitud de autorización de no autenticación en los pasos 2270 o 2260, o puede proceder a desplegar una hoja de recibo al cliente (paso 2280) .
Aunque la presen-e invención se ha descrito con las modalidades específicas como ejemplo, se entiende que diversos cambios, sustituciones y alteraciones aparentes a los expertos en el arte se les pueden hacer a las modalidades descritas sin apartarse del espíritu y alcance de la invención.
Claims (30)
- 70 REIVINDICACIONES Un sistema para autenticar la transacción de un cliente en una red electrónica, el sistema comprende : un recurso de acceso para que el cliente entre a 'la red electrónica; un chip de circuito integrado que se emite al cliente y contiene la información de identificación del cliente; un lector que se enlaza al recurso de acceso y puede comunicarse con el chip; y un servidor de solicitud de autenticación (ARS). que en conjunto con el Servidor de Control de Acceso (ACS) se enlaza a la red electrónica y se puede comunicar con la parte que solicita la autenticación de la transacción, en el cual el ACS se configura para comunicarse directamente con el recurso de acceso del cliente para autenticar la transacción derivando la necesidad de bajar software de autenticación de la parte solicitante al recurso de acceso del cliente. 71 en el cual el lector se configura para recibir información de la transacción y comunicar un valor basado en la información de la transacción al chip. en el cual el chip se configura para generar un criptograma basado en, por lo menos, una parte de la información de la transacción y, por lo menos, una parte de la información del chip de identificación del cliente, en el cual el lector también se configura para comunicar un símbolo de autenticación basado en el criptograma del ARS, y en el cual el ARS también se configura para evaluar la información de identificación del cliente a partir del símbolo de autenticación y validar la autenticidad del símbolo de autenticación de la transacción del cliente. El sistema que se describe en la reivindicación 1 en el cual la información de la transacción comunicada al lector comprende un desafío basado en la información de la transacción. 72 El sistema que se describe en la reivindicación 1 en el cual el símbolo de autenticación tiene un formato compatible con los formatos de mensaje del protocolo 3-D Secure . El sistema que se describe en la reivindicación 1, en el cual el ARS, después de la evaluación satisfactoria del símbolo de autenticación, genera un Valor de Autenticación del Titular (AAV) que se transporta por la red electrónica en un Campo de Autenticación de Titular Universal (UCAF) con una longitud de 20 bytes. El sistema que se describe en la reivindicación 1, en el cual el chip y el lector están colocados en un solo paquete físico. El sistema que se describe en la reivindicación 1, en la cual el recurso de acceso, el chip y el lector están colocados en un solo paquete físico. El sistema que se describe en la reivindicación 1, en el cual el ARS se configura para evaluar la información de identificación del cliente a partir del símbolo de autenticación, reconstruyendo primero 73 la información usada por el chip para generar el criptograma, después genera una réplica del criptograma a partir de la información reconstruida y después compara el símbolo de autenticación con la réplica del criptograma. El sistema que se describe en la reivindicación 1, la cual comprende además una base de datos del titular que puede ser accesada por el ARS para recuperar la información almacenada del cliente. El sistema que se describe en la reivindicación 1, en la cual el ARS se configura para comunicar un resultado de autenticación a la entidad solicitante. El sistema que se describe en la reivindicación 1, en la cual el ARS se configura para igualar el contador de transacción de aplicación recibido del chip contra los valores anteriores del contador de transacción de aplicación recibido del chip y de acuerdo con la transacción de autenticación. Un sistema para autenticar una transacción del cliente en el ambiente de red electrónica de 3-D Secure, el sistema comprende: 74 un comerciante; un emisor; un adquirente que acepte información especifica de la transacción de un comerciante y transferir la información al emisor; un Servidor de Solicitud de Autenticación (ARS) operado por el usuario en unión con el Servidor de Control de Acceso (ACS) ; una Página de Autenticación de Titular que proporcione una interfaz entre el ACS y el cliente; un E V - tarjeta de chip emitida al cliente por el emisor, la tarjeta de chip tiene la información de identificación del cliente; y un lector para comunicarse con el chip, donde el lector está enlazado a la Página de Autenticación del Titular, donde la tarjeta de chip y el lector están configurados para generar un símbolo de 75 autenticación basado en un criptograma de por lo menos una parte de la información de identificación del cliente y por lo menos una parte de la información especifica de la transacción recibida por el lector a través de la Página de Autenticación del Titular, donde el ARS está configurado para evaluar el símbolo de autenticación para validación, y donde la validación del símbolo de autenticación genera un AW, el cual es transportado en la red electrónica en un UCAF que tiene una longitud de 20 bytes. 12. El sistema que se describe en la reivindicación 11, en la cual el chip y el lector están colocados en un sólo paquete físico. El sistema que se describe en la reivindicación 11 en la cual la Página de Autenticación del Titular el chip y el lector están colocados en un sol paquete físico. 14. El sistema que se describe en la reivindicación 11, en la cual la tarjeta de chip genera un criptograma 76 en respuesta a los comandos estándar EMV emitidos por el lector. El sistema que se describe en la reivindicación 11, en la cual la tarjeta de chip comprende una máscara de mapa de bits seleccionado por el emisor para identificar bits específicos del criptograma que son incluidos por el lector en el símbolo de autenticación . El sistema que se describe en la reivindicación 11, en la cual la ICC está programada para generar un símbolo de autenticación en unión con el lector después de que el cliente verifica el código de identificación personal ingresado por el cliente. El sistema que se describe en la reivindicación 11, en la cual la ICC está programada para generar un símbolo de autenticación en unión con el lector después de que el cliente verifica la cantidad de la transacción . El sistema que se describe en la reivindicación 11, en la cual el ACS está configurado para desplegar la Página de Autorización de Tarjeta como un menú 77 emergente o en línea en la página web para comunicar información e instrucciones al titular. El sistema que se describe en la reivindicación 11, en la cual el emisor verifica la validez del símbolo de autenticación usando el ARS. El sistema que se describe en la reivindicación 11, en la cual el ARS está configurado para extraer la información conocida únicamente por el chip a partir del símbolo de autenticación, regenerar el criptograma, y comparar el criptograma regenerado con el símbolo de autenticación. El sistema que se describe en la reivindicación 11, que comprende mecanismos adicionales para someter las solicitudes de transacción autenticada y solicitudes de autorización de transacción no autenticada al emisor. 22. Un método para autenticación remota de un cliente que participa en una transacción electrónica usando un recurso de acceso a red, el método comprende : 78 proporcionar al cliente con un chip de circuito integrado que tenga información de identificación del cliente; proporcionar un lector enlazado con el recurso de acceso a la red del cliente y que pueda comunicarse con el chip; usar un servidor de solicitud de autenticación (ARS) , el cual está enlazado a la red electrónica y puede comunicar información al lector, recibir información especifica de la transacción y comunicar información especifica de la transacción al lector; usar el lector para comunicar información especifica de la transacción al chip e instruir al chip para generar un criptograma basado en por lo menos una parte de la información especifica de la transacción y por lo menos una parte de la información de identificación del cliente; usar el lector para generar un símbolo de autenticación basado en por lo menos una parte del criptograma generado por el chip; 79 usar el ARS para validar el símbolo de autenticación; generar un AAV después de la validación del símbolo de autenticación y transportar el AAV por la red electrónica en un mensaje de Campo de Autenticación de Titular Universal (UCAF) al emisor. El método que se describe en la reivindicación en la cual la información específica de transacción comunicada al lector; contiene desafío basado en la información específica de transacción . El método que se describe en la reivindicación 22, en la cual se usa el lector para generar un símbolo de autenticación en un formato compatible con los formatos de mensaje del protocolo 3-D Secure. El método que se describe en la reivindicación 22, en la cual el AAV se transporta en la red electrónica en un UCAF con una longitud de 20 bytes. 26. El método que se describe en la reivindicación 22, en la cual se proporcional al cliente un chip de 80 circuito integrado y un lector que comprende proporcionar un chip y un lector colocados en un solo paquete físico. El método que se describe en la reivindicación 22, en la cual la validación del ARS comprende evaluar la información de identificación del cliente en el símbolo de autenticación reconstruyendo primero la información usada por el chip para generar el criptograma, y después generar una réplica del criptograma a partir de la información reconstruida, y después comparar el símbolo de autenticación con la réplica del criptograma. El método que se describe en la reivindicación 27, que comprende accesar a la base de datos del titular a través del ARS para recuperar la información almacenada del cliente. El método que se describe en la reivindicación 27 que comprende comunicar el resultado de validación la parte solicitante. 30. El método que se describe en la reivindicación 27, en la cual la validación del ARS comprende comparar 81 el contador de transacción de aplicación recibido del chip contra valores previos del contador de transacción de aplicación recibidos del chip y de acuerdo con la autenticación de la transacción.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US47563903P | 2003-06-04 | 2003-06-04 | |
PCT/US2004/017756 WO2005001618A2 (en) | 2003-06-04 | 2004-06-04 | Customer authentication in e-commerce transactions |
Publications (1)
Publication Number | Publication Date |
---|---|
MXPA05012969A true MXPA05012969A (es) | 2006-03-17 |
Family
ID=33551554
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
MXPA05012969A MXPA05012969A (es) | 2003-06-04 | 2004-06-04 | Autenticacion de cliente en transacciones de comercio electronico. |
Country Status (10)
Country | Link |
---|---|
US (1) | US9514458B2 (es) |
EP (1) | EP1646976A4 (es) |
JP (1) | JP2006527430A (es) |
KR (1) | KR20060034228A (es) |
CN (1) | CN1853189A (es) |
AU (1) | AU2004252824B2 (es) |
BR (1) | BRPI0411005A (es) |
CA (1) | CA2528451A1 (es) |
MX (1) | MXPA05012969A (es) |
WO (1) | WO2005001618A2 (es) |
Families Citing this family (117)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7899753B1 (en) | 2002-03-25 | 2011-03-01 | Jpmorgan Chase Bank, N.A | Systems and methods for time variable financial authentication |
US10134202B2 (en) | 2004-11-17 | 2018-11-20 | Paypal, Inc. | Automatic address validation |
CA2596257C (en) | 2005-01-28 | 2016-05-17 | Cardinal Commerce Corporation | System and method for conversion between internet and non-internet based transactions |
US7533047B2 (en) * | 2005-05-03 | 2009-05-12 | International Business Machines Corporation | Method and system for securing card payment transactions using a mobile communication device |
EP1802155A1 (en) | 2005-12-21 | 2007-06-27 | Cronto Limited | System and method for dynamic multifactor authentication |
GB2435951A (en) * | 2006-02-23 | 2007-09-12 | Barclays Bank Plc | System for PIN servicing |
AT503263A2 (de) * | 2006-02-27 | 2007-09-15 | Bdc Edv Consulting Gmbh | Vorrichtung zur erstellung digitaler signaturen |
AU2007223334B2 (en) * | 2006-03-02 | 2012-07-12 | Visa International Service Association | Method and system for performing two factor authentication in mail order and telephone order transactions |
CN100566254C (zh) * | 2007-01-24 | 2009-12-02 | 北京飞天诚信科技有限公司 | 提高智能密钥设备安全性的方法和系统 |
US10210512B2 (en) * | 2007-02-13 | 2019-02-19 | Mastercard International Incorporated | Transaction count synchronization in payment system |
GB2442249B (en) * | 2007-02-20 | 2008-09-10 | Cryptomathic As | Authentication device and method |
AU2008243004B2 (en) * | 2007-04-17 | 2013-06-27 | Visa U.S.A. Inc. | Method and system for authenticating a party to a transaction |
US8121956B2 (en) | 2007-06-25 | 2012-02-21 | Visa U.S.A. Inc. | Cardless challenge systems and methods |
US7849014B2 (en) * | 2007-08-29 | 2010-12-07 | American Express Travel Related Services Company, Inc. | System and method for facilitating a financial transaction with a dynamically generated identifier |
GR20070100592A (el) * | 2007-09-27 | 2009-04-30 | Νικος Παντελη Τσαγκαρης | Συστηματα και μεθοδοι διεκπεραιωσης διαδικτυακων συναλλαγων με διαφανως προσφερομενη ασφαλεια |
US9747598B2 (en) | 2007-10-02 | 2017-08-29 | Iii Holdings 1, Llc | Dynamic security code push |
US8794532B2 (en) * | 2008-12-29 | 2014-08-05 | Mastercard International Incorporated | Methods and apparatus for use in association with identification token |
US20090198618A1 (en) * | 2008-01-15 | 2009-08-06 | Yuen Wah Eva Chan | Device and method for loading managing and using smartcard authentication token and digital certificates in e-commerce |
US8255688B2 (en) | 2008-01-23 | 2012-08-28 | Mastercard International Incorporated | Systems and methods for mutual authentication using one time codes |
WO2009121905A1 (en) * | 2008-04-04 | 2009-10-08 | International Business Machines Corporation | Handling expired passwords |
US8160064B2 (en) | 2008-10-22 | 2012-04-17 | Backchannelmedia Inc. | Systems and methods for providing a network link between broadcast content and content located on a computer network |
US9094721B2 (en) | 2008-10-22 | 2015-07-28 | Rakuten, Inc. | Systems and methods for providing a network link between broadcast content and content located on a computer network |
CA2742963A1 (en) | 2008-11-06 | 2010-05-14 | Visa International Service Association | Online challenge-response |
EP2192540A1 (fr) * | 2008-11-28 | 2010-06-02 | Gemalto Canada Inc. | Objet portable comportant un afficheur et application à la réalisation de transactions électroniques |
EP2394225B1 (en) | 2009-02-05 | 2019-01-09 | Wwpass Corporation | Centralized authentication system with safe private data storage and method |
US9715681B2 (en) | 2009-04-28 | 2017-07-25 | Visa International Service Association | Verification of portable consumer devices |
US10846683B2 (en) | 2009-05-15 | 2020-11-24 | Visa International Service Association | Integration of verification tokens with mobile communication devices |
US9105027B2 (en) | 2009-05-15 | 2015-08-11 | Visa International Service Association | Verification of portable consumer device for secure services |
US8893967B2 (en) | 2009-05-15 | 2014-11-25 | Visa International Service Association | Secure Communication of payment information to merchants using a verification token |
US8602293B2 (en) | 2009-05-15 | 2013-12-10 | Visa International Service Association | Integration of verification tokens with portable computing devices |
US9038886B2 (en) | 2009-05-15 | 2015-05-26 | Visa International Service Association | Verification of portable consumer devices |
US8534564B2 (en) | 2009-05-15 | 2013-09-17 | Ayman Hammad | Integration of verification tokens with mobile communication devices |
US9124566B2 (en) * | 2009-06-23 | 2015-09-01 | Microsoft Technology Licensing, Llc | Browser plug-in for secure credential submission |
US20110035294A1 (en) * | 2009-08-04 | 2011-02-10 | Authernative, Inc. | Multi-tier transaction processing method and payment system in m- and e- commerce |
US9084071B2 (en) * | 2009-09-10 | 2015-07-14 | Michael-Anthony Lisboa | Simple mobile registration mechanism enabling automatic registration via mobile devices |
FR2950768A1 (fr) * | 2009-09-30 | 2011-04-01 | Xiring Sa | Systeme et procede de transaction securisee en ligne |
US10454693B2 (en) | 2009-09-30 | 2019-10-22 | Visa International Service Association | Mobile payment application architecture |
US8332325B2 (en) * | 2009-11-02 | 2012-12-11 | Visa International Service Association | Encryption switch processing |
CA2780278A1 (en) * | 2009-11-04 | 2011-05-12 | Visa International Service Association | Verification of portable consumer devices for 3-d secure services |
EP2320395A1 (en) * | 2009-11-05 | 2011-05-11 | Multos International Pty Ltd. | Method for providing data during an application selection process |
CN101739771A (zh) * | 2009-12-01 | 2010-06-16 | 孙伟 | 一种公交一卡通业务系统及其实现方法 |
US10255591B2 (en) | 2009-12-18 | 2019-04-09 | Visa International Service Association | Payment channel returning limited use proxy dynamic value |
EP2526517B1 (en) * | 2010-01-19 | 2018-08-08 | Visa International Service Association | Token based transaction authentication |
US10255601B2 (en) * | 2010-02-25 | 2019-04-09 | Visa International Service Association | Multifactor authentication using a directory server |
WO2012021864A2 (en) | 2010-08-12 | 2012-02-16 | Mastercard International, Inc. | Multi-commerce channel wallet for authenticated transactions |
US8949616B2 (en) * | 2010-09-13 | 2015-02-03 | Ca, Inc. | Methods, apparatus and systems for securing user-associated passwords used for identity authentication |
US8746553B2 (en) | 2010-09-27 | 2014-06-10 | Mastercard International Incorporated Purchase | Payment device updates using an authentication process |
CN102469091B (zh) * | 2010-11-18 | 2014-12-10 | 金蝶软件(中国)有限公司 | 一种页面验证码处理的方法、装置及终端 |
AU2012225684B2 (en) | 2011-03-04 | 2016-11-10 | Visa International Service Association | Integration of payment capability into secure elements of computers |
EP2530868A1 (en) * | 2011-05-31 | 2012-12-05 | Gemalto SA | Method for generating an anonymous routable unlinkable identification token |
SG10201706477YA (en) | 2011-07-15 | 2017-09-28 | Mastercard International Inc | Methods and systems for payments assurance |
DE102011108069A1 (de) * | 2011-07-19 | 2013-01-24 | Giesecke & Devrient Gmbh | Verfahren zum Absichern einer Transaktion |
CN102300182B (zh) * | 2011-09-07 | 2013-08-14 | 飞天诚信科技股份有限公司 | 一种基于短信的身份验证方法、系统和装置 |
WO2013036944A1 (en) | 2011-09-09 | 2013-03-14 | Backchannelmedia, Inc. | Systems and methods for consumer control over interactive television exposure |
US10242368B1 (en) * | 2011-10-17 | 2019-03-26 | Capital One Services, Llc | System and method for providing software-based contactless payment |
US9767453B2 (en) | 2012-02-23 | 2017-09-19 | XRomb Inc. | System and method for processing payment during an electronic commerce transaction |
US10282724B2 (en) | 2012-03-06 | 2019-05-07 | Visa International Service Association | Security system incorporating mobile device |
CN110009329B (zh) * | 2012-05-24 | 2021-01-29 | 谷歌有限责任公司 | 管理非接触式商务交易的系统、方法和计算机可读介质 |
US10592978B1 (en) * | 2012-06-29 | 2020-03-17 | EMC IP Holding Company LLC | Methods and apparatus for risk-based authentication between two servers on behalf of a user |
US8856923B1 (en) * | 2012-06-29 | 2014-10-07 | Emc Corporation | Similarity-based fraud detection in adaptive authentication systems |
RU2509359C1 (ru) * | 2012-09-26 | 2014-03-10 | Пэйче Лтд. | Способ подтверждения платежа |
US10304047B2 (en) * | 2012-12-07 | 2019-05-28 | Visa International Service Association | Token generating component |
US9741032B2 (en) * | 2012-12-18 | 2017-08-22 | Mcafee, Inc. | Security broker |
US10504111B2 (en) * | 2012-12-21 | 2019-12-10 | Intermec Ip Corp. | Secure mobile device transactions |
US20150026070A1 (en) * | 2013-07-16 | 2015-01-22 | Mastercard International Incorporated | Systems and methods for correlating cardholder identity attributes on a payment card network to determine payment card fraud |
EP2827291A1 (en) * | 2013-07-19 | 2015-01-21 | Gemalto SA | Method for securing a validation step of an online transaction |
EP3025293A4 (en) * | 2013-07-24 | 2017-03-29 | Visa International Service Association | Systems and methods for communicating risk using token assurance data |
US11004069B2 (en) * | 2013-10-03 | 2021-05-11 | Nxp B.V. | Article and method for transaction irregularity detection |
JP6386567B2 (ja) | 2013-10-11 | 2018-09-05 | ビザ インターナショナル サービス アソシエーション | ネットワーク・トークン・システム |
CA2931093A1 (en) | 2013-12-19 | 2015-06-25 | Visa International Service Association | Cloud-based transactions methods and systems |
US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
CA2884611C (en) * | 2014-03-12 | 2024-04-16 | Scott Lawson Hambleton | System and method for authorizing a debit transaction without user authentication |
CN103841111B (zh) * | 2014-03-17 | 2017-11-14 | 北京京东尚科信息技术有限公司 | 一种防止数据重复提交的方法和服务器 |
US20150317630A1 (en) * | 2014-04-30 | 2015-11-05 | MasterCard Incorporated International | Method and system for authentication token generation |
WO2015179637A1 (en) | 2014-05-21 | 2015-11-26 | Visa International Service Association | Offline authentication |
US10311434B2 (en) * | 2014-05-29 | 2019-06-04 | Paypal, Inc. | Systems and methods for reporting compromised card accounts |
US11023890B2 (en) | 2014-06-05 | 2021-06-01 | Visa International Service Association | Identification and verification for provisioning mobile application |
AU2015296239A1 (en) | 2014-07-30 | 2017-02-02 | Visa International Service Association | Authentication system with message conversion |
US9775029B2 (en) | 2014-08-22 | 2017-09-26 | Visa International Service Association | Embedding cloud-based functionalities in a communication device |
TWI503693B (zh) * | 2014-09-04 | 2015-10-11 | Joe Chi Chen | 全動態數位電子支付交易身份認證方法 |
WO2016089993A1 (en) | 2014-12-03 | 2016-06-09 | D Alisa Albert | Proprietary token-based universal payment processing system |
GB2533333A (en) | 2014-12-16 | 2016-06-22 | Visa Europe Ltd | Transaction authorisation |
US10187363B2 (en) | 2014-12-31 | 2019-01-22 | Visa International Service Association | Hybrid integration of software development kit with secure execution environment |
AU2016245988B2 (en) | 2015-04-10 | 2021-05-20 | Visa International Service Association | Browser integration with cryptogram |
WO2017053403A1 (en) | 2015-09-21 | 2017-03-30 | Vasco Data Security, Inc | A multi-user strong authentication token |
GB2542617B (en) * | 2015-09-28 | 2020-06-24 | Touchtech Payments Ltd | Transaction authentication platform |
US20170103396A1 (en) * | 2015-10-13 | 2017-04-13 | Mastercard International Incorporated | Adaptable messaging |
US9800580B2 (en) | 2015-11-16 | 2017-10-24 | Mastercard International Incorporated | Systems and methods for authenticating an online user using a secure authorization server |
WO2017083961A1 (en) * | 2015-11-19 | 2017-05-26 | Securter Inc. | Coordinator managed payments |
EP3179431A1 (en) * | 2015-12-11 | 2017-06-14 | Mastercard International Incorporated | User authentication for transactions |
CN105528699A (zh) * | 2015-12-24 | 2016-04-27 | 中国银行股份有限公司 | 一种金融芯片卡的芯片信息验证方法和装置 |
US10282726B2 (en) * | 2016-03-03 | 2019-05-07 | Visa International Service Association | Systems and methods for domain restriction with remote authentication |
US10607224B2 (en) * | 2016-04-04 | 2020-03-31 | Mastercard International Incorporated | Systems and methods for secure authentication of transactions initiated at a client device |
US20170344989A1 (en) * | 2016-05-27 | 2017-11-30 | Mastercard International Incorporated | Systems and Methods for Use in Facilitating Interactions Between Merchants and Consumers |
KR101806390B1 (ko) * | 2016-05-31 | 2017-12-07 | 주식회사지니 | 생체 정보를 이용한 카드 결제 처리 시스템 및 그의 처리 방법 |
US20180047018A1 (en) * | 2016-08-15 | 2018-02-15 | Capital One Services, Llc | Browser extension for field detection and automatic population and submission |
US12056675B1 (en) * | 2016-10-25 | 2024-08-06 | Worldpay, Llc | Browser plug-in enabling use of EMV card information |
EP3631735A4 (en) * | 2017-05-25 | 2020-04-15 | MIR Limited | DYNAMIC VERIFICATION METHOD AND CARD TRANSACTION SYSTEM |
US11080697B2 (en) * | 2017-10-05 | 2021-08-03 | Mastercard International Incorporated | Systems and methods for use in authenticating users in connection with network transactions |
JP6381837B1 (ja) * | 2018-01-17 | 2018-08-29 | 株式会社Cygames | 通信を行うためのシステム、プログラム、方法及びサーバ |
US11108811B2 (en) | 2018-01-22 | 2021-08-31 | Avaya Inc. | Methods and devices for detecting denial of service attacks in secure interactions |
US10581611B1 (en) * | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
CA3115064A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
CA3062211A1 (en) * | 2018-11-26 | 2020-05-26 | Mir Limited | Dynamic verification method and system for card transactions |
EP3935595A4 (en) | 2019-03-07 | 2022-11-30 | Mastercard International Incorporated | USER VERIFICATION FOR AUTHORIZATION DEVICE |
CN110264212B (zh) * | 2019-05-24 | 2023-09-01 | 创新先进技术有限公司 | 一种风控方法、装置、电子设备及存储介质 |
SE546367C2 (en) * | 2019-06-28 | 2024-10-15 | Assa Abloy Ab | Cryptographic signing of a data item |
US20210004793A1 (en) * | 2019-07-03 | 2021-01-07 | Visa International Service Association | Mobile-OTP Based Authorisation of Transactions |
EP3809350A1 (en) * | 2019-10-18 | 2021-04-21 | Mastercard International Incorporated | Enchanced security in sensitive data transfer over a network |
EP3809352A1 (en) | 2019-10-18 | 2021-04-21 | Mastercard International Incorporated | Authentication for secure transactions in a multi-server environment |
US20210241266A1 (en) * | 2020-01-31 | 2021-08-05 | Mastercard International Incorporated | Enhancing 3d secure user authentication for online transactions |
AU2021233841A1 (en) * | 2020-03-10 | 2022-11-03 | Duckpond Technologies, Inc. | A method of securing a payment card transaction |
WO2021204411A1 (en) * | 2020-04-06 | 2021-10-14 | Daimler Ag | A method for performing a payment process of a user by a payment system, as well as a corresponding payment system |
US11361315B2 (en) * | 2020-05-13 | 2022-06-14 | Capital One Services, Llc | Systems and methods for card authorization |
US20220138803A1 (en) * | 2020-11-02 | 2022-05-05 | Jpmorgan Chase Bank, N.A. | Systems and methods for payment product verification and authorization using a customer identifier |
US11843702B2 (en) | 2020-11-20 | 2023-12-12 | The Toronto-Dominion Bank | System and method for secure distribution of resource transfer request data |
US11653207B2 (en) * | 2021-02-26 | 2023-05-16 | Charter Communications Operating, Llc | Automatic authentication of wireless devices |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5604801A (en) | 1995-02-03 | 1997-02-18 | International Business Machines Corporation | Public key data communications system under control of a portable security device |
FR2733379B1 (fr) * | 1995-04-20 | 1997-06-20 | Gemplus Card Int | Procede de generation de signatures electroniques, notamment pour cartes a puces |
JPH0950465A (ja) | 1995-08-04 | 1997-02-18 | Hitachi Ltd | 電子ショッピング方法、電子ショッピングシステムおよび文書認証方法 |
US5859419A (en) * | 1995-09-28 | 1999-01-12 | Sol H. Wynn | Programmable multiple company credit card system |
US5768390A (en) * | 1995-10-25 | 1998-06-16 | International Business Machines Corporation | Cryptographic system with masking |
US6038551A (en) | 1996-03-11 | 2000-03-14 | Microsoft Corporation | System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer |
US6247129B1 (en) | 1997-03-12 | 2001-06-12 | Visa International Service Association | Secure electronic commerce employing integrated circuit cards |
US6282522B1 (en) | 1997-04-30 | 2001-08-28 | Visa International Service Association | Internet payment system using smart card |
DE19724901A1 (de) | 1997-06-12 | 1998-12-17 | Siemens Nixdorf Inf Syst | Mobilfunktelefon sowie solche mit gekoppeltem Rechner für Internet- bzw. Netzanwendungen und Verfahren zum Betreiben einer solchen Gerätekombination |
US6453416B1 (en) * | 1997-12-19 | 2002-09-17 | Koninklijke Philips Electronics N.V. | Secure proxy signing device and method of use |
US6173400B1 (en) * | 1998-07-31 | 2001-01-09 | Sun Microsystems, Inc. | Methods and systems for establishing a shared secret using an authentication token |
FR2787273B1 (fr) | 1998-12-14 | 2001-02-16 | Sagem | Procede de paiement securise |
CA2259089C (en) * | 1999-01-15 | 2013-03-12 | Robert J. Lambert | Method and apparatus for masking cryptographic operations |
GB0006668D0 (en) | 2000-03-21 | 2000-05-10 | Ericsson Telefon Ab L M | Encrypting and decrypting |
EP1139200A3 (en) * | 2000-03-23 | 2002-10-16 | Tradecard Inc. | Access code generating system including smart card and smart card reader |
US20030134615A1 (en) * | 2000-04-24 | 2003-07-17 | Masaki Takeuchi | External device and authentication system |
US7478434B1 (en) * | 2000-05-31 | 2009-01-13 | International Business Machines Corporation | Authentication and authorization protocol for secure web-based access to a protected resource |
WO2002001522A1 (en) | 2000-06-26 | 2002-01-03 | Covadis S.A. | Computer keyboard unit for carrying out secure transactions in a communications network |
GB2374498B (en) | 2001-04-12 | 2004-02-18 | Intercede Ltd | Multi-stage authorisation system |
US6990471B1 (en) * | 2001-08-02 | 2006-01-24 | Oracle International Corp. | Method and apparatus for secure electronic commerce |
JP3819269B2 (ja) * | 2001-08-31 | 2006-09-06 | 株式会社損害保険ジャパン | 電子カード利用認証システム |
US20040019564A1 (en) * | 2002-07-26 | 2004-01-29 | Scott Goldthwaite | System and method for payment transaction authentication |
US20040044739A1 (en) * | 2002-09-04 | 2004-03-04 | Robert Ziegler | System and methods for processing PIN-authenticated transactions |
-
2004
- 2004-06-04 KR KR1020057023208A patent/KR20060034228A/ko not_active Application Discontinuation
- 2004-06-04 BR BRPI0411005-6A patent/BRPI0411005A/pt not_active Application Discontinuation
- 2004-06-04 US US10/560,192 patent/US9514458B2/en active Active
- 2004-06-04 WO PCT/US2004/017756 patent/WO2005001618A2/en active Application Filing
- 2004-06-04 CA CA002528451A patent/CA2528451A1/en not_active Abandoned
- 2004-06-04 AU AU2004252824A patent/AU2004252824B2/en not_active Ceased
- 2004-06-04 CN CNA2004800196327A patent/CN1853189A/zh active Pending
- 2004-06-04 EP EP04754375A patent/EP1646976A4/en not_active Ceased
- 2004-06-04 MX MXPA05012969A patent/MXPA05012969A/es active IP Right Grant
- 2004-06-04 JP JP2006515197A patent/JP2006527430A/ja active Pending
Also Published As
Publication number | Publication date |
---|---|
CA2528451A1 (en) | 2005-01-06 |
US9514458B2 (en) | 2016-12-06 |
KR20060034228A (ko) | 2006-04-21 |
CN1853189A (zh) | 2006-10-25 |
US20080154770A1 (en) | 2008-06-26 |
WO2005001618A2 (en) | 2005-01-06 |
AU2004252824B2 (en) | 2011-03-17 |
JP2006527430A (ja) | 2006-11-30 |
AU2004252824A1 (en) | 2005-01-06 |
EP1646976A4 (en) | 2008-02-27 |
BRPI0411005A (pt) | 2006-07-04 |
EP1646976A2 (en) | 2006-04-19 |
WO2005001618A3 (en) | 2005-03-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
AU2004252824B2 (en) | Customer authentication in e-commerce transactions | |
KR100994289B1 (ko) | 모바일 계정 인증 서비스 | |
AU2007203383B2 (en) | Online payer authentication service | |
AU2001257280B2 (en) | Online payer authentication service | |
JP4597529B2 (ja) | 金融取引で使用するための認証の仕組みおよび方法 | |
AU2001257280A1 (en) | Online payer authentication service | |
KR20060135726A (ko) | 전화 거래 및 컴퓨터 거래의 보안을 위한 시스템 및 방법 | |
US20050289052A1 (en) | System and method for secure telephone and computer transactions | |
US20030164851A1 (en) | Method and system for securing credit transactions | |
MXPA06008274A (es) | Sistema y metodo para transacciones seguras por telefono y computadora |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FG | Grant or registration |