ES2581236T3 - Sistemas y métodos que permiten efectuar transacciones de pago seguras utilizando una estructura de datos con formato - Google Patents

Sistemas y métodos que permiten efectuar transacciones de pago seguras utilizando una estructura de datos con formato Download PDF

Info

Publication number
ES2581236T3
ES2581236T3 ES04776493.1T ES04776493T ES2581236T3 ES 2581236 T3 ES2581236 T3 ES 2581236T3 ES 04776493 T ES04776493 T ES 04776493T ES 2581236 T3 ES2581236 T3 ES 2581236T3
Authority
ES
Spain
Prior art keywords
authentication
bytes
aav
merchant
acs
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES04776493.1T
Other languages
English (en)
Inventor
Arthur D. Kranzley
Stephen W. Orfei
Bruce J. Rutherford
Mark Wiesman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mastercard International Inc
Original Assignee
Mastercard International Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/US2004/017756 external-priority patent/WO2005001618A2/en
Application filed by Mastercard International Inc filed Critical Mastercard International Inc
Application granted granted Critical
Publication of ES2581236T3 publication Critical patent/ES2581236T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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/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/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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • 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/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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
    • 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
    • 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/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Marketing (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

Un sistema para autenticar una transacción de titular con un comerciante en una red electrónica, el sistema que comprende: Una capa de plataforma de emisor incluyendo por lo menos un programa de autenticación 3-D Secure, Un Plug-in de comerciante, "MPI"; Un algoritmo seguro de pago, "SPA"; y Una capa transporte de datos, En donde la plataforma de emisor comprende un servidor de control de acceso, "ACS", que utiliza la SPA para procesar la transacción y la información del titular de la tarjeta para la autenticación mediante un método de autenticación y para generar un Valor de Autenticación de Titular de Cuenta, "AAV", y transmite el AAV a través de la capa de transporte de datos a la MPI, En donde el AAV es una estructura de datos con formato compatible con los protocolos de mensaje 3-D Secure, en donde la estructura de datos con formato tiene una longitud de más de 20 bytes incluyendo los bytes que identifican un resumen criptográfico (hash) del nombre del comerciante, bytes que identifican el ACS, bytes que identifican el método de autenticación, bytes que identifican las claves criptográficas secretas y bytes que incluyen un código de autenticación del comerciante, "MAC".

Description

imagen1
imagen2
Otras características de la invención, su naturaleza y varias ventajas serán más aparentes de la descripción detallada siguiente y de los dibujos que la acompañan
DESCRIPCIÓN BREVE DE LOS DIBUJOS
5 La Figura 1 es una ilustración esquemática de un ejemplo de programa de autenticación utilizando los Algoritmos de Pago Seguro (SPA) para generar los Valores de Autenticación del Titular de la Cuenta (AAV) para las transacciones de pago, de acuerdo con los principios de la presente invención. La Figura 2 es una ilustración esquemática de la estructura de un Campo de Cuenta del Titular de la Tarjeta
10 Universal (Universal Cardholder Account Field) que es utilizado para transportar la salida de los Algoritmos de Pago Seguro (SPA) de la Figura 1, de acuerdo con los principios de la presente invención. La Figura 3 es una ilustración de algunos de los pasos y de los enlaces de los mensajes entre las entidades que participan en un ejemplo de proceso de autenticación de transacciones de pago, de acuerdo con los principios de la presente invención.
15 La Figura 4 es una ilustración esquemática de la interacción entre las entidades del ejemplo de autenticación y autorización y autorización involucradas en la autenticación y autorización de las transacciones de pago en línea.
A lo largo de las figuras, a menos que se indique lo contrario, son usados los mismos numerales de referencia y los 20 caracteres con el fin de denotar similares características, elementos, componentes o partes de las realizaciones ilustradas.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
25 La presente invención proporciona las soluciones para la autenticación de las partes remotas en una transacción electrónica. En particular, las soluciones se relacionan con las Aplicaciones de Pago Seguro (por ejemplo, SPA 135 en la figura 1) que son utilizadas para autenticar un titular de tarjeta que participa de manera remota en la transacción electrónica. Las soluciones pueden ser utilizadas para la autenticación de las transacciones en las plataformas de comercio electrónico estándar de la industria, tales como las plataformas de comercio electrónico (e
30 commerce) compatibles con 3-D Secure y en entornos de no comercio electrónico tales como los pedidos por correo electrónico y teléfono o en dispositivos móviles donde puede ser utilizado una señal o código de autenticación por el emisor con el fin de autenticar al titular de la tarjeta.
La TABLA 1 es un glosario de algunos de los términos, siglas (acrónimos) o abreviaturas que son utilizadas en la 35 descripción en el presente documento TABLA 1
AAV
Valor de Autenticación del Titular de la Cuenta
Servidor de Control de Acceso (ACS)
Servicios del Servidor de Control de Acceso con el fin de validar el registro de un número de cuenta (PAN) de un titular de tarjeta específico en 3-D Secure así como las transacciones autenticadas
Valor de Autenticación del Titular de Cuenta (AAV)
Datos del titular de la tarjeta para autenticación requeridos para las transacciones de comercio electrónicos en los que la autenticación del titular de la tarjeta ha sido realizada con éxito
Valor de Verificación de la Autenticación del Titular de la Tarjeta (CAVA)
Datos del titular de la tarjeta para autenticación requeridos por VISA para las transacciones de comercio electrónicos en los que la autenticación del titular de la tarjeta ha sido realizada con éxito
Código de Verificación de la Tarjeta (CPC)
Una característica de seguridad de la tarjeta de dos partes. El CVC 1 es un valor de 3 dígitos codificado en las pistas 1 y 2 en tres posiciones contiguas en el campo "datos discrecionales" de una banda magnética en una tarjeta. El CVC 2 se diferencia del CVC 1 y es una impresión en el margen dentro del panel de firma evidente de forzar en la tarjeta. El CVC pretende inhibir la alteración o mal uso de los datos de la tarjeta y mejora la autentificación de la tarjeta.
Código de Autenticación de Mensaje (MAC)
Código generado criptográficamente que es una función de los contenidos del mensaje y una clave secreta compartida por el autor del mensaje y el destinatario del mensaje. Este valor, generador por el autor y verificado por el destinatario, permite que el destinatario pueda detectar cualquier alteración al mensaje original.
imagen3
imagen4
imagen5
5
15
25
35
45
55
65
2) Solicitud Autenticación Pagador /Respuesta
Mensaje par: PAReq/PARes
Una vez que se ha determinado que el titular de la tarjeta está inscrito por un emisor o es un participante activo en programa 1000, el proceso de autenticación del titular de tarjeta específico implica además al emisor de la tarjeta específico. Los mensajes de Solicitud Autenticación de Pagador/ Respuesta pueden ser enviados desde el MPI al ACS del emisor de la tarjeta específica con el fin de realizar la autenticación. En esta etapa del proceso de autenticación en el programa 1000, el titular de la tarjeta puede ser presentado con una ventana de autenticación. La ventana de autenticación puede ser mostrada en el navegador del titular de la tarjeta y ser rellenada con información relevante por el emisor. Puede ser solicitado al titular de la tarjeta la introducción de una contraseña, un código o símbolo para la identificación personal o de autenticación a través de la ventana mostrada de autenticación. El ACS del emisor de la tarjeta específica puede entonces utilizar, por ejemplo, la SPA 135 con la finalidad de autenticar la información recogida o introducida y de acuerdo con ello generar un Valor Autenticación del Titular de la Cuenta (AAV). El AAV es transportado en el mensaje 3-D Secure PARes (Respuesta de Autenticación de Pagador) en un campo designado de Valor de Verificación de Autenticación de Titular de Tarjeta (CAVV) en un UCAF.
Un CAAV es uno de los campos de datos en la parte de respuesta de Mensaje par PAReq/PARes devuelto por el emisor al comerciante solicitante. El emisor puede colocar firmas digitales convenientes en su respuesta. Además, el comerciante puede incluir el AAV recibido a una entidad adquiriente para enviarlo al emisor como parte de una solicitud de autorización de pago/transacción (véase por ejemplo, la figura 4).
La figura 3 muestra esquemáticamente un ejemplo de proceso de autenticación de tarjeta 300 para una transacción de un titular de tarjeta bajo un programa de autenticación 1000. Para los propósitos de la ilustración, la descripción del proceso 300 asume que el titular de la tarjeta 310 está inscrito por un emisor en el programa de autenticación 1000 y ha obtenido una contraseña o código desde el emisor con el fin de utilizarlo mientras realiza compras en línea en los comerciantes participantes. El proceso 300 también asume que todos los canales de comunicación entre los componentes (por ejemplo, el titular de la tarjeta 310, el MPI 320, el directorio 330 y el ACS del emisor 340) estén asegurados correctamente utilizando los enlaces de protocolos Secure Socket Layer (SSL) (por ejemplo, SSL1, SSl-2, SSl-3, SSl-4, SSL-5 y SSL-6).
En el proceso 300 en el paso 351, el titular de la tarjeta 310 puede comprar en un sitio web de un comerciante y, cuando esté listo para terminar la compra, introducir la información de la tarjeta de pago (por ejemplo, el número de cuenta) y otra información (por ejemplo, información de envío) mediante el enlace SSL-1. Una vez que ha sido introducida toda la información de pago y envío, el comerciante puede dar al titular de la tarjeta 310 una oportunidad para revisar la compra antes de enviar un pedido.
Lo siguiente en el paso 352, el MPI 320 consulta al directorio 330 vía el enlace SSL-2 con el fin de verificar la inscripción de titular de la tarjeta 310 con un emisor específico utilizando el mensaje de solicitud de verificación VEReq. El paso 352 puede realizarse de manera opcional localmente en MPI 320 través de un almacenamiento temporal local en el directorio de la tarjeta. En las respuestas al mensaje VEReq, el directorio 330 puede determinar que un emisor particular está participando y de acuerdo con ello reenviar una solicitud a través del enlace SSL-3 al ACS 340 del emisor particular con el fin de comprobar el estado actual de la inscripción del titular 310. Las respuestas resultantes pueden fluir de vuelta sobre los mismos enlaces (p. ej., SSL-3 y SSL-2) a MPI 320. Si el ACS 340 indica que el titular de la tarjeta 310 está inscrito en el programa 1000, MPI 320 puede crear mensaje de Solicitud de Autenticación de Pagador y enviarlo al navegador del titular de la tarjeta en el paso 354 vía el enlace SSL-4. A continuación en el paso 355, el navegador del titular de la tarjeta puede redirigir el mensaje al ACS 340 del emisor apropiado con el fin de iniciar la autenticación del titular de la tarjeta. Cuando el ACS 340 recibe el mensaje de solicitud de autenticación de Pagador, ello puede causar un inicio de dialogo de autenticación de usuario. Como parte del cuadro de diálogo de autenticación de usuario, el ACS 340 puede causar que una ventana interactiva separada de autenticación sea mostrada al titular de la tarjeta 310 con el fin de facilitar la contraseña, el código o la introducción de otros datos por el titular de la tarjeta 310.
En el paso 356, el ACS 340 (utilizando la SPA 135) puede autenticar la contraseña o código introducido por el titular de la tarjeta 310. El ACS 340puede construir un AAV SPA de acuerdo con la implementación del proveedor de programa de autenticación de 3-D Secure. El ACS 340 puede crear y firmar digitalmente un mensaje de respuesta de autenticación de pagador apropiado. El mensaje de respuesta de autenticación de pagador es entonces devuelto (a través del enlace SSL-6) a MPI 320. La ventana de autenticación mostrada al titular de la tarjeta 320 puede desaparecer en este punto.
Después de que ha sido completado el proceso de autenticación 300 del titular de la tarjeta, el comerciante puede ser requerido a pasar el AAV SPA a la entidad adquiriente vía el campo UCAF dentro de un mensaje de autorización. El AAV SPA puede entonces ser pasado a lo largo desde la entidad adquiriente al emisor como parte del proceso de mensajes de autorización convencional. Cuando es recibido por emisor, el AAV puede ser validado como parte del proceso de la solicitud de autorización y archivar para su uso en la resolución de cualesquiera conflictos que puedan surgir más adelante.
Los formatos de mensaje y los formatos de datos estándar de la versión 1.0.2 de 3-D pueden ser utilizados para las comunicaciones de datos entre todas las partes o entidades involucradas. Específicamente, el AAV SPA que el ACS 340 crea y devuelve al comerciante para la inclusión en mensajes de UCAF tiene 28 caracteres de largo y contiene un campo de 20 bytes definido para 3-D Secure en codificación base 64.
La TABLA 3 muestra un ejemplo de estructura de datos o formato de 20 bytes de un AAV de SPA.
TABLA 3
Posición
Nombre de Campo Fuente de los Datos: ACS Longitud (Bytes) Número Byte
1
Byte de control El byte de control se utiliza para indicar el formato y el contenido la estructura asociada de AAV. Un valor hexadecimal x'8C' puede indicar un AAV creado como el resultado de una autentificación con éxito del titular de la tarjeta. Un valor hexadecimal x'86' puede indicar un AAV creado como Resultado del proceso de intentos 1 Byte 1
2
Resumen criptográfico (hash) del Nombre del Comerciante La 8 bytes de más a la izquierda de un resumen criptográfico (hash) SHA-1 del campo del Nombre del Comerciante de la PAReq. 8 Bytes 2-9
3
Identificador de ACS Este campo de datos puede permitir que un emisor utilice hasta 256 facilidades diferentes del ACS. Los valores para este campo pueden ser definidos basados en el algoritmo utilizado para crear el MAC: 0 - 7 Reservados para HMAC 8-15 Reservados para CVC2 16 - 255 -Reservado para uso futuro 1 Byte 10
4
Método de Autenticación Indica cómo fue autenticado el titular de la tarjeta al ACS: 0 = No Realizada Autenticación del Titular de la Tarjeta (válido solamente para un AAV creado utilizando el valor del byte de control x '86' – Proceso de intentos.) 1 = Contraseña 2 = Clave Secreta (por ejemplo, Tarjeta de Chip) ½ (4 bytes) Byte 11, 1er digito hex
5
Identificador Clave BIN Indica cual de las posibles 16 claves secretas de conocidas por el emisor para un rango BIN dado fue utilizada por el ACS identificado mediante el identificador ACS para crear el MAC. ½ (4 bytes) Byte 11, 2º digito hex
6
Número de Secuencia de la Transacción Número único que puede ser utilizado para identificar la transacción dentro del ACS identificado por el identificador de ACS. Una vez que ha sido alcanzado el valor máximo, número debe reciclar de nuevo a 0. Este número debe ser único para cada PARes creado por un determinado identificador de ACS para un emisor dado durante el tiempo que se puede presentar un contracargo. 4 (8 dígitos hex) Bytes 12-15
7
MAC Código de Autenticación de Mensaje, creado por el ACS 5 Bytes 16-20
Los emisores que proporcionan tanto la identificación de PC existente u otras soluciones de autenticación (por ejemplo, en la figura 1) además de la solución 3-D Secure pueden distinguir entre los valores AAV que reciben de las soluciones de autenticación en el mensaje de autorización correspondiente. El AAV de 20 bytes (por ejemplo, TABLA 2) resultante del programa 1000 compatible con 3-D Secure puede diferir de las estructuras comunes de
AAV de 28 bytes (es decir, en los programas no 3-D Secure) de las siguientes maneras: El importe de la transacción y los códigos de la moneda no están incluidos en el AAV de 20 bytes según como esta información es incluida en el mensaje firmado PARes; Un sello de transacción de comerciante (MTS) no está incluido como un identificador de transacción (XID), que es incluido en el mensaje PARes firmado, puede proporcionar la misma funcionalidad.
5 Además, es ampliado el campo de resumen criptográfico (hash) del nombre del comerciante. Ahora, como un resultado, sólo pueden ser necesarias ediciones mínimas del nombre del comerciante antes de crear el resumen criptográfico (hash) SHA-1.
Puede que un comerciante no tenga que modificar el byte de control para las autorizaciones posteriores (por
10 ejemplo, dividir los envíos). Para dividir los envíos, el comerciante puede reenviar un AAV original generado por implementaciones compatibles con 3-D Secure del programa 1000.
El valor del byte de control en el AAV SPA de 20 byte está basado en el Resultado de la solicitud (PAReq) de autenticación del titular de la tarjeta. Este Resultado puede ser indicado en el campo de estado de la transacción de
15 los mensajes de Respuesta de Autenticación del Pagador (PARes). La TABLA 4 muestra los valores ejemplares del campo de estado de la transacción en un mensaje PARes.
TABLA 4
Campo Estado Transacción en PARes
Valor Byte Control en AAV (hexadecimal) Valor Byte AAV Primero después codificación Base 64 Campo Método Autenticación en AAV
Y
X´8C´ j Cualquier Valor definido diferente de “No realizada Autenticación Titular Tarjeta”
A
X´86´ h Debe ser “No realizada Autenticación Titular Tarjeta”
H
No será generado AAV para este valor de estado - -
U
No será generado AAV para este valor de estado - -
20 El nombre del comerciante contenido en el mensaje PAReq puede ser editado antes de crear el resumen criptográfico (hash) del nombre del comerciante. Las ediciones pueden abordar específicamente la codificación de Formato de Transformación Universal (UTF-8) pero también la referencia a los caracteres Unicode para otros tipos de codificación.
25 Una edición puede eliminar cualquier secuencia de bytes UTF-8 que no tiene una representación Unicode. De tal manera una edición puede borrar cualquier bytes UTF-8 empezando con 1111 binarios y todos los posteriores bytes comenzando con binario 10
30 Otra edición puede eliminar cualquier secuencia de bytes UTF-8 o secuencia de bytes con la siguiente
representación Unicode: 0000 a través de 001F (caracteres control ASCI; 007F a través de 00A0 (caracteres control DEL y C1; 00AD (guión discrecional); y
35 2000 a través de 206F (Puntuación General).
Tal tipo de edición puede borrar los siguientes bytes UTF-8: Hex 00 a través de 1F Hex 7F
40 Hex C2 80 a través de C2 A0 Hex C2 AD Hex E2 80 a través de E2 81 AF
Aún otra edición puede borrar cualesquiera espacios líderes o finales (por ejemplo, Hex 20 UTF-8 bytes).
45 En el caso de una devolución de un cargo u otro proceso potencial de conflicto, el AAV de 20 bytes permite identificar los parámetros de proceso asociados con la transacción. Entre otras cosas, los valores de campo AAV pueden identificar:
• La ubicación física en donde fue procesada la transacción.
50 • El número de secuencia que puede ser utilizado para identificar positivamente la transacción dentro del universo de transacciones para esa ubicación
imagen6
5
10
15
20
25
30
35
40
Después de la codificación Base-64, es esto: jHyn+ 7YFiIEUAREAAAAvNUe6Hv8=
EJEMPLO 2 (clave de 16 bytes)
Número de cuenta Asumido: 5432 109876543210
Nombre de Comerciante Asumido: SPA comerciante, Inc. (todos caracteres ASCII y no requiere edición)
Byte de Control Asumido AA V = 8C
Primeros 8 bytes, SHA-1 resumen criptográfico (hash) del Nombre de Comerciante = 7CA7 FBB6 058B 5114
ACS Id Asumida = 01
Método de Autenticación Asumido = 1 (contraseña)
Clave BIN Clave Id Asumida = 1
Número de Secuencia de Transacción Asumido = 0000002F
Clave (16 Bytes) Asumida = 00112233445566778899AABBCCDDEEFF Por lo tanto, SHA-1HMAC está basado en
5432 109876543210 FFFF 8C 7CA7FBB6058B5114 0111 0000002F Esto produce un MAC cuyos primeros 5 bytes son:
EB27 FC7F AB Por lo tanto, el AAV completo en hex es:
8C 7CA7FBB6058B5114 0111 0000002F EB27FC7FA Después de la codificación Base-64, es esto:
jHyn+ 7YFi1 EUAREAAAA v6yf8f6s =
El algoritmo CVC2 de también crea Criptográficamente los valores de campo de MAC. En contraste con el algoritmo HMAC, que utiliza una clave, el algoritmo CVC2 utiliza dos claves DES de 64 bits identificadas por el sub campo de identificador de clave BIN. En el algoritmo CVC2, todos los pasos de encriptación y des encriptación pueden utilizar formulario de Libro de Código Electrónico (BCE) de DES.
El algoritmo CVC2 genera un valor de tres dígitos 3 dígitos CVC2. Los datos de entrada que son procesados por el algoritmo CVC2 para la generación de este valor de tres dígitos 3 dígitos CVC2 es mostrados en la TABLA 5.
TABLA 5
Nombre de campo CVC2
Nombre de campo MAC Fuente de Datos Longitud (Dígitos)
Numero Cuenta Primario
Numero Cuenta Primario
El número de cuenta, tal y como está representado en el mensaje de Solicitud de Verificación (VEReq) 13 a 19 dígitos
Fecha Expiración Tarjeta
Número de Secuencia de la Transacción Convertir el Número de Secuencia de Transacción, tal y como figura en el AAV, a equivalente decimal BCD. Rellenar este campo con por lo menos los 4 dígitos significativos. Cualquier valor menor de 4 dígitos debe ser justificado correctamente en el campo y rellenado con ceros binarios a 4 dígitos. 4 dígitos
Código de Servicio
Método de Autenticación Método de Autenticación tal y como está contenido en el AAV. Si el valor del sub campo de Método de Autenticación es mayor que 9, restar 10 para obtener el dígito para ser utilizado 1 dígito
Byte de Control
Convertir el Byte de Control tal y como está contenido en el AAV a equivalente decimal BCD. Rellenar este campo con los por lo menos 2 dígitos significativos 2 dígitos
El valor de tres dígitos CVC2 resultante es convertido a forma decimal codificado binario y poblado en los bytes de más a la izquierda del sub campo MAC con un 0 binario principal utilizado para rellenar el primer medio byte sin usar. El resto de los bytes del sub campo MAC puede ser llenado con ceros binarios. Por ejemplo: CVC2 = 123 MAC sub campo = 0123000000 (total 10 dígitos).
El EJEMPLO 3 y la TABLA 6 ilustran la aplicación del algoritmo CVC2 y los pasos del proceso involucrados en la aplicación del algoritmo con el fin de generar los valores AAV SPA.
EJEMPLO 3
Número de cuenta Asumido: 5432109876543210 Nombre de Comerciante Asumido: SPA comerciante, Inc. (todos caracteres ASCII y no requiere de edición) Byte de control Asumido AA V = 8C Primeros 8 bytes, SHA-1 resumen criptográfico (hash) del Nombre de Comerciante = 7CA7 FBB6 058B
5 5114 ACS Id Asumido = 7 Método de Autenticación Asumido = 1 (contraseña) Clave BIN Id Asumida = 1 Número de Secuencia de Transacción Asumido = 0000002F
10 Clave A = 0011223344556677 Clave B = 8899AABBCCDDEEFF
Por lo tanto, el cálculo del algoritmo CVC2 está basado en Número de Cuenta= 5432109876543210 Fecha de vencimiento = 0047 Código Servicio = 140
Esto produce un valor de tres dígitos CVC2 = 439 (ver Tabla 6 para el cálculo): 15 Basado en el valor calculado de CVC2, el campo MAC = 0439000000 Por lo tanto, el completo AA V en hex es: 8 C 7CA7FBB6058B5114 01 0000002F 11 Codificado en Base-64-, esto es: jHyn+ 7YFi1 EUAREAAAAvBDkAAAA = 20 El proceso o cálculo de pasos que se utilizan en el ejemplo 3 están mostrados en la TABLA 6
TABLA 6
Paso
Paso del Proceso Ejemplo
1.
Construir la cadena de bits al concatenar (izquierda a derecha) los 4 bits de más a la derecha de cada carácter de los elementos de datos especificados 54321098765432100047140
2.
Colocar los resultados en un campo de 128-bit, rellenando en la derecha con ceros binario para llenar todos los bits restantes. Dividir el bloque de 128 bits en 2 bloques de 64 bits. 54321098765432100047140000000000 Bloque 1 = 5432109876543210 Bloque 2 = 0047140000000000
3.
Encriptar el Bloque 1 utilizando la Clave A Bloque 1 = 5432109876543210 Clave A = 0011223344556677 Resultado = 44DD7C814CC62702
4.
XOR los resultados del paso 3 con el Bloque 2. Encriptar este valor utilizando la Clave A Bloque 2 = 0047140000000000 Paso 3 44DD7C814CC62702 Resultado = Resultado = 449A68814CC62702
5.
Desencriptar el resultado del paso 4 utilizando la Clave B Paso 4 449A68814CC62702 Resultado = ClaveB = ClaveB = 8899AABBCCDDEEF F Resultado = 191DCA3149A5BD51
6.
Encriptar el resultado del paso 5 utilizando la Clave A Paso 5 191DCA3149A5BD51 Resultado = Clave A = 0011223344556677 Resultado = 4F AB392CE3C98B41
7.
Desde el resultado del paso 6, yendo de izquierda a derecha, extraer todos los dígitos numéricos (0-9); justificar a la izquierda estos dígitos en un campo de 16 posiciones 439239841
8.
Desde el resultado del paso 6, yendo de izquierda a derecha, extraer todos los caracteres de la A la F. Con el fin de compensar para decimales, restar 10 de cada dígito extraído. 012421
9.
Concatenar los dígitos del paso 7 a la derecha de los dígitos extraídos en el paso 8. 439239841012421
10.
Seleccionar desde los tres primeros dígitos de más a la izquierda del CVC. 439
Tal y como está definido mediante el protocolo 3-D Secure, todos los mensajes de PARes devueltos al comerciante
25 son firmados digitalmente el ACS del emisor del titular de la tarjeta asociado. El comerciante puede ser requerido para validar la firma digital antes de extraer el AAV SPA desde el mensaje de PARes para su inclusión en una solicitud de autorización enviada a la entidad adquiriente. Si un emisor soporta tanto la implementación de 3-D Secure y otras plataformas de autenticación (por ejemplo, plataformas de autenticación de PC) puede ser necesario distinguir entre las dos plataformas de autenticación durante el procesamiento del mensaje de solicitud de
autorización. Esto se puede lograr en una de dos maneras:
1. El primer carácter base 64 codificado es:
a.
"j" o "h" para el AAV de SPA dentro de la aplicación definida de 3-D Secure.
b.
"g" o "A" para el AAV SPA Autenticación de PC
5 2. El byte de control, convertido a binario, es tanto,
a.
hexadecimal8C o hexadecimal 86 para el AAV definido para la implementación de MasterCard de 3-D Secure.
b.
hexadecimal 82 ó hexadecimal 02 para el AA V SPA Autenticación PC.
10 Cada emisor que participa en el programa 1000 puede asegurar que el sub campo identificador ACS está debidamente configurado para indicar el algoritmo utilizado para crear el MAC. El fallo para establecer este indicador correctamente puede ocasionar validaciones inadecuadas durante el proceso de autorización de la transacción/pago.
15 Aunque la presente invención ha sido descrita en relación con los ejemplos específicos de realizaciones, debe ser entendido que podrían ser hecho varios cambios, sustituciones y modificaciones aparentes a aquellos especializados en la Técnica a las realizaciones divulgadas sin apartarse del ámbito de aplicación de la invención de acuerdo con lo que está definido en las reivindicaciones adjuntas.

Claims (1)

  1. imagen1
    imagen2
ES04776493.1T 2003-06-10 2004-06-10 Sistemas y métodos que permiten efectuar transacciones de pago seguras utilizando una estructura de datos con formato Expired - Lifetime ES2581236T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US47718703P 2003-06-10 2003-06-10
US477187P 2003-06-10
PCT/US2004/017756 WO2005001618A2 (en) 2003-06-04 2004-06-04 Customer authentication in e-commerce transactions
WOPCT/US2004/017756 2004-06-04
PCT/US2004/018658 WO2005001635A2 (en) 2003-06-10 2004-06-10 Systems and methods for conducting secure payment transactions using a formatted data structure

Publications (1)

Publication Number Publication Date
ES2581236T3 true ES2581236T3 (es) 2016-09-02

Family

ID=35985301

Family Applications (1)

Application Number Title Priority Date Filing Date
ES04776493.1T Expired - Lifetime ES2581236T3 (es) 2003-06-10 2004-06-10 Sistemas y métodos que permiten efectuar transacciones de pago seguras utilizando una estructura de datos con formato

Country Status (19)

Country Link
US (1) US7801825B2 (es)
EP (1) EP1636680B1 (es)
JP (1) JP2007517272A (es)
KR (1) KR20060070484A (es)
CN (1) CN1926567A (es)
AU (2) AU2004252882A1 (es)
BR (1) BRPI0411286B1 (es)
CA (1) CA2529011A1 (es)
CY (1) CY1117808T1 (es)
DK (1) DK1636680T3 (es)
ES (1) ES2581236T3 (es)
HK (1) HK1090143A1 (es)
HU (1) HUE029807T2 (es)
MX (1) MXPA05013422A (es)
PL (1) PL1636680T3 (es)
PT (1) PT1636680T (es)
SI (1) SI1636680T1 (es)
WO (1) WO2005001635A2 (es)
ZA (1) ZA200600211B (es)

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7239226B2 (en) 2001-07-10 2007-07-03 American Express Travel Related Services Company, Inc. System and method for payment using radio frequency identification in contact and contactless transactions
US7249112B2 (en) 2002-07-09 2007-07-24 American Express Travel Related Services Company, Inc. System and method for assigning a funding source for a radio frequency identification device
US7493288B2 (en) 2001-07-10 2009-02-17 Xatra Fund Mx, Llc RF payment via a mobile device
US7360694B2 (en) 2003-01-23 2008-04-22 Mastercard International Incorporated System and method for secure telephone and computer transactions using voice authentication
US7740168B2 (en) 2003-08-18 2010-06-22 Visa U.S.A. Inc. Method and system for generating a dynamic verification value
US7761374B2 (en) * 2003-08-18 2010-07-20 Visa International Service Association Method and system for generating a dynamic verification value
US20050279827A1 (en) * 2004-04-28 2005-12-22 First Data Corporation Methods and systems for providing guaranteed merchant transactions
JP4843208B2 (ja) * 2004-09-30 2011-12-21 株式会社東芝 デジタルコンテンツ編集装置、デジタルコンテンツ編集方法、デジタルコンテンツ編集プログラムおよびデジタルコンテンツ編集プログラムを記録した記録媒体
US8396922B2 (en) * 2005-11-18 2013-03-12 Aol Inc. Promoting interoperability of presence-based systems through the use of ubiquitous online identities
JP4564464B2 (ja) * 2006-01-05 2010-10-20 株式会社東芝 デジタルコンテンツ再生装置、方法およびプログラム
KR20080107400A (ko) 2006-03-02 2008-12-10 비자 인터내셔날 써비스 어쏘시에이션 통신 판매 및 전화 판매 트랜잭션에서 2개의 팩터 인증을 실행하는 방법 및 시스템
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US9065643B2 (en) 2006-04-05 2015-06-23 Visa U.S.A. Inc. System and method for account identifier obfuscation
JP4913530B2 (ja) * 2006-10-16 2012-04-11 株式会社野村総合研究所 暗号処理装置、暗号処理方法および暗号処理プログラム
US7823774B2 (en) * 2007-03-26 2010-11-02 International Business Machines Corporation Method, apparatus, and article of manufacture for automatic verification of transactions made over an insecure network
US8423479B2 (en) 2007-05-07 2013-04-16 Yahoo! Inc. Trusted third party clearing house for lead tracking
US8121956B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Cardless challenge systems and methods
US20100169218A1 (en) * 2007-06-27 2010-07-01 Koninklijke Philips Electronics N.V. Secure authentication of lectronic prescriptions
US9589152B2 (en) * 2007-09-19 2017-03-07 Visa U.S.A. Inc. System and method for sensitive data field hashing
US8938793B2 (en) * 2007-10-03 2015-01-20 Gmx Sas System and method for secure management of transactions
US20100027786A1 (en) * 2008-02-14 2010-02-04 Patrick Faith Dynamic encryption authentication
US8935528B2 (en) * 2008-06-26 2015-01-13 Microsoft Corporation Techniques for ensuring authentication and integrity of communications
CA2742963A1 (en) 2008-11-06 2010-05-14 Visa International Service Association Online challenge-response
US8826397B2 (en) * 2009-01-15 2014-09-02 Visa International Service Association Secure remote authentication through an untrusted network
WO2010111661A1 (en) * 2009-03-27 2010-09-30 Mastercard International Incorporated Methods and systems for performing a financial transaction
US8261977B2 (en) * 2009-03-27 2012-09-11 Mastercard International Incorporated Methods and systems for using an interface and protocol extensions to perform a financial transaction
EP2430112B1 (en) 2009-04-23 2018-09-12 The University of Chicago Materials and methods for the preparation of nanocomposites
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US8893967B2 (en) 2009-05-15 2014-11-25 Visa International Service Association Secure Communication of payment information to merchants using a verification token
WO2011057007A2 (en) * 2009-11-04 2011-05-12 Visa International Service Association Verification of portable consumer devices for 3-d secure services
US8534564B2 (en) 2009-05-15 2013-09-17 Ayman Hammad 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
US8706556B2 (en) * 2009-11-06 2014-04-22 Mastercard International Incorporated Methods for risk management in payment-enabled mobile device
US9424413B2 (en) 2010-02-24 2016-08-23 Visa International Service Association Integration of payment capability into secure elements of computers
WO2011136730A1 (en) * 2010-04-28 2011-11-03 Show & Pay Ab A method and an apparatus for improved electronic transaction security
CA2823685C (en) * 2010-08-12 2017-03-07 Mastercard International, Inc. Multi-commerce channel wallet for authenticated transactions
US20120072346A1 (en) * 2010-09-16 2012-03-22 Yomir Sp System and method for securing and authenticating purchase transactions
WO2012142045A2 (en) * 2011-04-11 2012-10-18 Visa International Service Association Multiple tokenization for authentication
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US9576279B2 (en) * 2012-06-05 2017-02-21 Autoscribe Corporation System and method for registering financial accounts
US10304047B2 (en) 2012-12-07 2019-05-28 Visa International Service Association Token generating component
US20150039506A1 (en) * 2013-08-05 2015-02-05 Mastercard International Incorporated Methods and systems for providing 3-d secure service on-behalf-of merchants
GB2517723A (en) * 2013-08-29 2015-03-04 Belegin Ltd Token verification
US9471913B1 (en) * 2013-10-23 2016-10-18 Compass Plus US, Corp. Method and system for cardless processing of E-invoicing
CN103561115B (zh) * 2013-11-19 2016-09-28 北京奇虎科技有限公司 实时获取电子码的方法、开放平台及***
SG10201803986RA (en) * 2013-12-02 2018-06-28 Mastercard International Inc Method and system for secure transmission of remote notification service messages to mobile devices without secure elements
FR3018378A1 (fr) * 2014-03-12 2015-09-11 Enrico Maim Systeme et procede transactionnels a architecture repartie fondees sur des transactions de transferts d'unites de compte entre adresses
US20150317630A1 (en) * 2014-04-30 2015-11-05 MasterCard Incorporated International Method and system for authentication token generation
US11282082B2 (en) 2014-07-30 2022-03-22 Visa International Service Association Authentication system with message conversion
US9906367B2 (en) * 2014-08-05 2018-02-27 Sap Se End-to-end tamper protection in presence of cloud integration
US9999924B2 (en) 2014-08-22 2018-06-19 Sigma Labs, Inc. Method and system for monitoring additive manufacturing processes
SG10201406521TA (en) * 2014-10-10 2016-05-30 Mastercard Asia Pacific Pte Ltd Methods and systems for secure online payment
US10891622B2 (en) * 2014-11-13 2021-01-12 Mastercard International Incorporated Providing online cardholder authentication services on-behalf-of issuers
WO2016081651A1 (en) 2014-11-18 2016-05-26 Sigma Labs, Inc. Multi-sensor quality inference and control for additive manufacturing processes
CN105825371A (zh) * 2015-01-07 2016-08-03 阿里巴巴集团控股有限公司 业务处理方法和装置
EP3245045A4 (en) 2015-01-13 2018-10-31 Sigma Labs, Inc. Material qualification system and methodology
CN108604983B (zh) * 2015-02-14 2021-06-15 瓦利梅尔公司 通过域名服务对私钥的安全的委托分发的介质和方法
US9825946B2 (en) * 2015-08-27 2017-11-21 Mastercard International Incorporated Method and system for enhanced validation of cryptograms in cloud-based systems
GB201516617D0 (en) * 2015-09-18 2015-11-04 Mastercard International Inc Verification for payment transations
US10207489B2 (en) 2015-09-30 2019-02-19 Sigma Labs, Inc. Systems and methods for additive manufacturing operations
US20170109752A1 (en) * 2015-10-15 2017-04-20 Mastercard International Incorporated Utilizing enhanced cardholder authentication token
GB201601796D0 (en) * 2016-02-01 2016-03-16 Comcarde Ltd Payment handling apparatus and method
AU2017238073A1 (en) * 2016-03-21 2018-09-13 Mastercard International Incorporated Method and system for recording point to point transaction processing
EP3440823B1 (en) * 2016-04-05 2020-09-02 Zamna Technologies Limited Method and system for managing personal information within independent computer systems and digital networks
RU2716042C1 (ru) 2016-07-15 2020-03-05 Кардиналкоммерс Корпорейшн Мост между аутентификацией и авторизацией с использованием расширенных сообщений
US11080697B2 (en) 2017-10-05 2021-08-03 Mastercard International Incorporated Systems and methods for use in authenticating users in connection with network transactions
RU2755196C1 (ru) 2018-04-05 2021-09-14 Нокиа Текнолоджиз Ой Управление унифицированными идентификаторами подписки в системах связи
US11283621B1 (en) * 2019-11-13 2022-03-22 Worldpay, Llc Methods and systems for enhanced endpoint identity validation in electronic transactions
US11722500B2 (en) 2020-04-01 2023-08-08 Paypal, Inc. Secure identity verification marketplace using hashed data and forward hashing search functions

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044205A (en) * 1996-02-29 2000-03-28 Intermind Corporation Communications system for transferring information between memories according to processes transferred with the information
US7133845B1 (en) * 1995-02-13 2006-11-07 Intertrust Technologies Corp. System and methods for secure transaction management and electronic rights protection
US6157721A (en) * 1996-08-12 2000-12-05 Intertrust Technologies Corp. Systems and methods using cryptography to protect secure computing environments
US5809144A (en) * 1995-08-24 1998-09-15 Carnegie Mellon University Method and apparatus for purchasing and delivering digital goods over a network
US5748740A (en) * 1995-09-29 1998-05-05 Dallas Semiconductor Corporation Method, apparatus, system and firmware for secure transactions
US6138107A (en) * 1996-01-04 2000-10-24 Netscape Communications Corporation Method and apparatus for providing electronic accounts over a public network
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
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US6590588B2 (en) * 1998-05-29 2003-07-08 Palm, Inc. Wireless, radio-frequency communications using a handheld computer
US7047416B2 (en) * 1998-11-09 2006-05-16 First Data Corporation Account-based digital signature (ABDS) system
FR2787273B1 (fr) * 1998-12-14 2001-02-16 Sagem Procede de paiement securise
US6529885B1 (en) * 1999-03-18 2003-03-04 Oracle Corporation Methods and systems for carrying out directory-authenticated electronic transactions including contingency-dependent payments via secure electronic bank drafts
US7249097B2 (en) * 1999-06-18 2007-07-24 Echarge Corporation Method for ordering goods, services, and content over an internetwork using a virtual payment account
US20010032154A1 (en) 1999-12-17 2001-10-18 Eric Schummer Internet communications and e-commerce platform
EP2278538A1 (en) * 2000-04-24 2011-01-26 Visa International Service Association Online payer authentication service
AU2001287164B2 (en) * 2000-08-04 2008-06-26 First Data Corporation Method and system for using electronic communications for an electronic contact
US6915279B2 (en) * 2001-03-09 2005-07-05 Mastercard International Incorporated System and method for conducting secure payment transactions
WO2002079911A2 (en) 2001-04-02 2002-10-10 Mastercard International Incorporated System and method for conducting secure payment transactions
US7707120B2 (en) * 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
US7349871B2 (en) * 2002-08-08 2008-03-25 Fujitsu Limited Methods for purchasing of goods and services

Also Published As

Publication number Publication date
KR20060070484A (ko) 2006-06-23
EP1636680A4 (en) 2013-03-13
SI1636680T1 (sl) 2016-08-31
AU2004252882A1 (en) 2005-01-06
WO2005001635A3 (en) 2006-10-12
HUE029807T2 (en) 2017-03-28
CA2529011A1 (en) 2005-01-06
EP1636680A2 (en) 2006-03-22
PL1636680T3 (pl) 2016-10-31
MXPA05013422A (es) 2006-03-17
PT1636680T (pt) 2016-07-15
BRPI0411286A (pt) 2006-08-01
JP2007517272A (ja) 2007-06-28
EP1636680B1 (en) 2016-04-13
HK1090143A1 (zh) 2006-12-15
CN1926567A (zh) 2007-03-07
AU2011201884B2 (en) 2011-09-08
CY1117808T1 (el) 2017-05-17
ZA200600211B (en) 2007-04-25
WO2005001635A2 (en) 2005-01-06
US7801825B2 (en) 2010-09-21
BRPI0411286B1 (pt) 2016-12-20
AU2011201884A1 (en) 2011-05-19
DK1636680T3 (en) 2016-07-18
US20070143227A1 (en) 2007-06-21

Similar Documents

Publication Publication Date Title
ES2581236T3 (es) Sistemas y métodos que permiten efectuar transacciones de pago seguras utilizando una estructura de datos con formato
ES2875391T3 (es) Expedición de documentos virtuales en una cadena de bloques
CN110692214B (zh) 用于使用区块链的所有权验证的方法和***
CN108370319B (zh) 用于令牌验证的方法及计算机
ES2606602T3 (es) Método para la generación de un código, método y sistema de autorización de una operación
ES2558542T3 (es) Dispositivo y método de autenticación
US6915279B2 (en) System and method for conducting secure payment transactions
ES2319722T3 (es) Procedimiento de telepago y sistema para la puesta en practica de este procedimiento.
US7983987B2 (en) System and method for conducting secure payment transaction
ES2779750T3 (es) Sistema de firma electrónica para un documento electrónico que utiliza un circuito de autenticación de terceros
KR101364210B1 (ko) 검증 에러 감소 시스템
JP2003534585A (ja) コンピュータネットワークを越える安全な支払い方法およびそのシステム
ES2436426T3 (es) Método basado en una tarjeta SIM para la realización de servicios con altas características de seguridad
ES2359881T3 (es) Procedimiento para la preparación de una tarjeta chip para servicios de firma electrónica.
ES2797111T3 (es) Intercambio seguro de unos datos sensibles a través de una red basada en códigos de barras y testigos
AU2011239307B2 (en) Systems and methods for conducting secure payment transactions using a formatted data structure
WO2020099690A1 (es) Método y sistema para financiar compras con autenticación reforzada de cliente
TW201710941A (zh) 資料保護裝置及其資料保護方法
WO2002079911A2 (en) System and method for conducting secure payment transactions
ES2250889T3 (es) Procedimiento y dispositivo para la realizacion de documentos comprobables a prueba de falsificacion.
AU2002254513A1 (en) System and method for conducting secure payment transactions
RU2810139C1 (ru) Способ и система для запуска или администрирования офлайн-устройства управления
KR102464429B1 (ko) 디지털 골드 토큰을 기초로 금 거래를 가능하게 하는 클라우드 기반의 금 거래 플랫폼 서버 및 그 동작 방법
TW535380B (en) Method of generating the non-repudible signature, especially by an embarking system, and the embarking system for utilizing this method
KR20120025708A (ko) 통합 청구용 코드 이미지 제공 방법 및 시스템