Content deleted Content added
Line 3:
==Operating principle==
The CAP specification supports several authentication methods. The user first inserts their smartcard into the CAP reader and enables it by entering the PIN. A button is then pressed to select the transaction type. Most readers have 2 or 3 transaction types available to the user under a variety of names. Some known implementations are:
*'''Code/Identify:''' Without requiring any further input, the CAP reader interacts with the smartcard to produce a decimal [[one-time password]], which can be used, for example, to log in to a banking website.
*'''Response:''' This mode implements [[challenge-response authentication]], where the bank's website asks the customer to enter a "challenge" number into the CAP reader, and then copy the "response" number displayed by the CAP reader into the web site.
*'''Sign:''' This mode is an extension of the previous, where not only a random "challenge" value, but also crucial transaction details such as the transferred value, the currency, and recipient's account number have to be typed into the CAP reader.
The above noted transaction types are implemented using one of two modes. One of these modes has two forms in which it can operate, creating three distinct modes, though they are not named this way in the specification.
*'''Mode1:''' This is the mode for normal monetary transactions such as an online purchase through a merchant. The transaction value and currency may be included in the computation of the cryptogram. If the card does not require it or the terminal does not support it, then both amount and currency are set to zero during the computation.
*'''Mode2:''' This mode may be useful for authenticating a user in which no transaction is taking place, such as logging into an Internet banking system. The computation differs as there is no transaction data included, making these responses very easy to precompute or reuse.
*'''Mode2 with TDS:''' This mode may be used for more complicated transactions, such as a funds transfer between accounts. Multiple data fields pertaining to the transaction are concatenated and then hashed using the value that would result from a Mode2 operation as the key for the hashing algorithm. The resultant hash is used in place of the cryptogram calculated in a non-TDS Mode2 operation.
Mode1 sounds very much like a specific use of Mode2 with TDS (Transaction Data Signing), but there is a critical difference. In Mode1 operation, the transaction data (amount and currency type) are used in the cryptogram calculation in addition to all the values used in Mode2 without TDS, whereas Mode2 includes its transaction data in a successive step rather than including it in the cryptogram calculation step. If it were not for this difference, then all operations could be generalized as a single operation with varying optional transaction data.
==Protocol details==
| |||