scispace - formally typeset
Search or ask a question

Showing papers by "Visa Inc. published in 2001"


Patent
24 Apr 2001
TL;DR: In this paper, the authentication service of the present invention allows a card issuer to verify a cardholder's identity using a variety of authentication methods, such as the use of passwords, and the only system participant requiring a certificate is the issuing financial institution.
Abstract: A payment authentication service authenticates the identity of a payer during online transactions. The authentication service of the present invention allows a card issuer to verify a cardholder's identity using a variety of authentication methods, such as the use of passwords. Also, the only system participant requiring a certificate is the issuing financial institution. One embodiment of the invention for authenticating the identity of a cardholder during an online transaction involves querying an access control server to determine if a cardholder is enrolled in the payment authentication service, requests a password from the cardholder, verifies the password, and notifies a merchant whether the cardholder's authenticity has been verified. In another aspect of the invention, a chip card and the authentication service independently generate cryptograms that must match in order for the service to verify that the correct chip card is being used by the cardholder.

361 citations


Patent
15 Mar 2001
TL;DR: In this article, the authors propose a POS (point-of-sale) check service that converts any paper check online and in real-time into an electronic funds transaction, and the paper check is returned to the customer.
Abstract: A POS (point-of-sale) Check Service converts any paper check online and in real-time into an electronic funds transaction. The paper check is returned to the customer. A merchant enters the amount of the sale and electronically captures checking account data from the MICR line encoded on the check. The check data, identification data and sale amount are forwarded to a service organization for processing. The service has three options: Conversion Only; Verification with Conversion; and Guarantee with Conversion. Under Conversion Only the transaction is approved or declined with no account verification processing and the merchant retain the risk of loss. Under Verification with Conversion the check authorization message is routed to the participating drawee bank or to a third-party authorizing agent for verification that the check will be paid. Under Guarantee with Conversion, the check authorization request message is routed to the participating drawee bank or to a third party to guarantee the check. A check guarantor buys the check from the merchant at a discount.

162 citations


Book ChapterDOI
11 Jul 2001
TL;DR: A family of new forgery attacks are described, which raise serious questions about the effectiveness of certain countermeasures against CBC-MACs.
Abstract: This paper is concerned with a particular type of attack against CBC-MACs, namely forgery attacks, i.e. attacks which enable an unauthorised party to obtain a MAC on a data string. Existing forgery attacks against CBC-MACs are briefly reviewed, together with the effectiveness of various countermeasures. This motivates the main part of the paper, where a family of new forgery attacks are described, which raise serious questions about the effectiveness of certain countermeasures.

15 citations


Book ChapterDOI
11 Jun 2001
TL;DR: The aim of this work is to emphasise the importance of these delaying factors of smart card application developers and smart card technology researchers, and also to provide a reference point as to the performance of each API.
Abstract: It is generally believed that among the major delaying factors of smart card performance is the speed of the cryptographic algorithms. This is only partially true, as a number of other factors that add substantial delays to the overall performance of a smart card application should also be taken into account. In this paper we analyse the significance of these delaying factors. Furthermore, we also present some performance measurements of the two most widely used terminal application programming interfaces (APIs) and Java Cards. The aim of this work is to emphasise, both to smart card application developers and smart card technology researchers, the importance of these delaying factors and also to provide a reference point as to the performance of each API.

12 citations


Patent
08 Mar 2001

8 citations


Patent
08 Mar 2001
TL;DR: In this paper, the authors present a set-top box module that interfaces with a card reader which accepts a smart card for payment of goods and services purchased on-line over the Internet or directly from a cable provider.
Abstract: An architecture and system loads and uses a smart card for payment of goods and/or services purchased on-line over the Internet or directly from a cable provider A set-top box module on a set-top box controls the interaction with a consumer and interfaces to a card reader which accepts a smart card Debiting works in conjunction with a merchant server and a merchant payment server In addition, debiting works in conjunction with a cable head end server and a cable head end payment server Loading works in conjunction with a bank server and a load server Alternatively, loading functions in conjunction with a load server when value is loaded from a pre-funded account To load value, the cable head end server requests a load from a user account at the bank server or a pre-funded account at the load server

6 citations


Book ChapterDOI
TL;DR: As it is necessary for the cryptographic API to offer the means to 'part-compute' a MAC, such chaining variables need very careful handling lest they increase the possibility of MAC key compromise.
Abstract: This paper is concerned with the design of cryptographic APIs (Application Program Interfaces), and in particular with the part of such APIs concerned with computing Message Authentication Codes (MACs). In some cases it is necessary for the cryptographic API to offer the means to 'part-compute' a MAC, i.e. perform the MAC calculation for a portion of a data string. In such cases it is necessary for the API to input and output 'chaining variables'. As we show in this paper, such chaining variables need very careful handling lest they increase the possibility of MAC key compromise. In particular, chaining variables should always be output in encrypted form; moreover the encryption should operate so that re-occurrence of the same chaining variable will not be evident from the ciphertext.