Secure payment systems

From CryptoWiki
Jump to: navigation, search


Security challenge

Next conditions must be met in any of the modern payment systems:

1) Confidentiality. Customer data, such as credit card number, should be known only to the relevant organizations involved in the payment process.

2) Preservation of the integrity of the information. Information about the purchase and transaction data must be protected from unauthorized changes.

3) Authorization. Both parties should be confident that they are dealing with exactly the person it claims to be.Check the authenticated user of the transaction(e.g. solvency).

4) Wide range of means of payment. The buyer may pay any transaction available funds.

5) Guarantee risks. The seller must have a warranty from the many risks associated with the use of the payment system. For example, the rejection of the goods. Risks are defined and documented in agreements between the provider payment system and other involved organizations.

6) Minimization of the payment transaction. Payment order processing, obviously, will be included in the cost of operation and should be minimized. Payment must be paid even in the case when the buyer refuses to accept the purchased goods.


3-D Secure is an XML-based protocol designed to be an additional security layer for online credit and debit card transactions. It was developed by Visa with the intention of improving the security of Internet payments and is offered to customers under the name Verified by Visa. Services based on the protocol have also been adopted by MasterCard as MasterCard SecureCode, and by JCB International as J/Secure. American Express added 3dsecure on November 8, 2010, as American Express SafeKey, in select markets and continues to launch additional markets.[1] Analysis of the protocol by academia has shown it to have many security issues that affect the consumer, including greater surface area for phishing and a shift of liability in the case of fraudulent payments.[2] 3-D Secure adds an authentication step for online payments.

Description and basic aspects

The basic concept of the protocol is to tie the financial authorization process with an online authentication. This authentication is based on a three-domain model (hence the 3-D in the name). The three domains are:

  • Acquirer Domain (the merchant and the bank to which money is being paid).
  • Issuer Domain (the bank which issued the card being used).
  • Interoperability Domain (the infrastructure provided by the card scheme, credit, debit, prepaid or other type of finance card, to support the 3-D Secure protocol). Interoperability Domain includes the Internet, MPI, ACS and other software providers

The protocol uses XML messages sent over SSL connections with client authentication[citation needed] (this ensures the authenticity of both peers, the server and the client, using digital certificates). A transaction using Verified-by-Visa or SecureCode will initiate a redirection to the website of the card issuing bank to authorize the transaction. Each issuer could use any kind of authentication method (the protocol does not cover this) but typically, a password-based method is used, so to effectively buy on the Internet means using a password tied to the card. The Verified-by-Visa protocol recommends the bank's verification page to load in an inline frame session. In this way, the bank's systems can be held responsible for most security breaches. Today, with the ease of sending white-listed text messages from registered bank senders, it is easy to send a one-time password as part of an SMS text message to users' mobile phones and emails for authentication, at least during enrollment and for forgotten passwords. The main difference between Visa and MasterCard implementations lies in the method to generate the UCAF (Universal Cardholder Authentication Field): MasterCard uses AAV (Accountholder Authentication Value) and Visa uses CAVV (Cardholder Authentication Verification Value).


The specifications are currently at version 1.0.2. Previous versions 0.7 (only used by Visa USA) and 1.0.1 have become redundant and are no longer supported. MasterCard and JCB have adopted version 1.0.2 of the protocol only. In order for a Visa or MasterCard member bank to use the service, the bank has to operate compliant software that supports the latest protocol specifications. Once compliant software is installed, the member bank will perform product integration testing with the payment system server before it rolls out the system.

ACS providers

In the 3-D Secure protocol, ACS (Access Control Server) is on the issuer side (banks). Currently, most banks outsource ACS to a third party. Commonly, the buyer's web browser shows the domain name of the ACS provider, rather than the bank's domain name; however, this is not required by the protocol. Dependent on the ACS provider, it is possible to specify a bank-owned domain name for use by the ACS.

MPI providers

Each 3-D secure transaction involves two Internet request/response pairs: VEReq/VERes and PAReq/PARes. Visa and MasterCard don't license merchants for sending requests to their servers. They isolate their servers by licensing software providers which are called MPI (merchant plug-in) providers.


The advantage for merchants is the reduction of "unauthorized transaction" chargebacks. One disadvantage for merchants is that they have to purchase MPI to connect to the Visa or MasterCard Directory Server. This is expensivive (setup fee, monthly fee and per-transaction fee); at the same time, it represents additional revenue for MPI providers. Supporting 3-D Secure is complicated and, at times, creates transaction failures. Perhaps the biggest disadvantage for merchants is that many users view the additional authentication step as a nuisance or obstacle, which results in a substantial increase in transaction abandonment and lost revenue.

Buyers and credit card holders

The intention behind the system is that cardholders will have a decreased risk of other people being able to use their payment cards fraudulently on the Internet. In most current implementations of 3-D Secure, the issuing bank or its ACS provider prompts the buyer for a password that is known only to the bank/ACS provider and the buyer. Since the merchant does not know this password and is not responsible for capturing it, it can be used by the issuing bank as evidence that the purchaser is indeed their cardholder. This is intended to help decrease risk in two ways:

  1. Copying card details, either by writing down the numbers on the card itself or by way of modified terminals or ATMs, does not result in the ability to purchase over the Internet because of the additional password, which is not stored on or written on the card.
  2. Since the merchant does not capture the password, there is a reduced risk from security incidents at online merchants; while an incident may still result in hackers obtaining other card details, there is no way for them to get the associated password.

3-D Secure does not strictly require the use of password authentication. It is said to be possible to use it in conjunction with smart card readers, security tokens and the like. These types of devices might provide a better user experience for customers as they free the purchaser from having to use a secure password. Some issuers are now using such devices as part of the Chip Authentication Program or Dynamic Passcode Authentication schemes. One significant disadvantage is that cardholders are likely to see their browser connect to unfamiliar domain names as a result of vendors' MPI implementations and the use of outsourced ACS implementations by issuing banks, which might make it easier to perform phishing attacks on cardholders.

American Express SafeKey

American Express SafeKey is live in the following markets: United Kingdom, India, Singapore, Switzerland, Russia, Turkey, Malaysia, France, Spain, Italy, Germany, Netherlands, Japan, Hong Kong, Australia, Cyprus, China, Greece, Vietnam.

General 3-D Secure Criticism

Verifiability of site identity

The system involves a pop-up window or inline frame appearing during the online transaction process, requiring the cardholder to enter a password which, if the transaction is legitimate, their card-issuing bank will be able to authenticate. The problem for the cardholder is determining if the pop-up window or frame is really from their card issuer, when it could be from a fraudulent website attempting to harvest the cardholder's details. Such pop-up windows or script-based frames lack any access to any security certificate, eliminating any way to confirm the credentials of the implementation of 3-DS. The Verified-by-Visa system has drawn some criticism, since it is hard for users to differentiate between the legitimate Verified-by-Visa pop-up window or inline frame, and a fraudulent phishing site. This is because the pop-up window is served from a domain which is:

  • Not the site where the user is shopping.
  • Not the card issuing bank
  • Not or

In some cases, the Verified-by-Visa system has been mistaken by users for a phishing scam and has itself become the target of some phishing scams. The newer recommendation to use an inline frame (IFrame) instead of a pop-up has reduced user confusion, at the cost of making it harder, if not impossible, for the user to verify that the page is genuine in the first place. As of 2011, most web browsers do not provide a way to check the security certificate for the contents of an iframe. Some card issuers also use Activation During Shopping (ADS), in which cardholders who are not registered with the scheme are offered the opportunity of signing up (or forced into signing up) during the purchase process. This will typically take them to a form in which they are expected to confirm their identity by answering security questions which should be known to their card issuer. Again, this is done within the iframe where they cannot easily verify the site they are providing this information to—a cracked site or illegitimate merchant could in this way gather all the details they need to pose as the customer. Implementation of 3-D Secure sign-up will often not allow a user to proceed with a purchase until they have agreed to sign up to 3-D Secure and its terms and conditions, not offering any alternative way of navigating away from the page than closing it, thus suspending the transaction. Cardholders who are unwilling to take the risk of registering their card during a purchase, with the commerce site controlling the browser to some extent, can in some cases go to their bank's home page on the web in a separate browser window and register from there. When they return to the commerce site and start over they should see that their card is registered. The presence on the password page of the Personal Assurance Message (PAM) that they chose when registering is their confirmation that the page is coming from the bank. This still leaves some possibility of a man-in-the-middle attack if the card holder cannot verify the SSL Server Certificate for the password page. Some commerce sites will devote the full browser page to the authentication rather than using a frame (not necessarily an iFrame, which is a less secure object). In this case, the lock icon in the browser should show the identity of either the bank or the operator of the verification site. The cardholder can confirm that this is in the same domain that they visited when registering their card, if it is not the domain of their bank. Mobile browsers present particular problems for 3-D Secure, due to the common lack of certain features such as frames and pop-ups. Even if the merchant has a mobile Web site, unless the issuer is also mobile-aware, the authentication pages may fail to render properly, or even at all. In the end, many analysts have concluded that the Activation During Shopping (ADS) protocols invite more risk than they remove and furthermore transfer this increased risk to the consumer. In some cases, 3-D Secure ends up providing little security to the cardholder, and can act as a device to pass liability for fraudulent transactions from the bank or retailer to the cardholder. Legal conditions applied to the 3-D Secure service are sometimes worded in a way that makes it difficult for the cardholder to escape liability from fraudulent "cardholder not present" transactions

Limited mobility

When a 3-D Secure confirmation code is required, if the confirmation code is sent by SMS on mobile phone (assuming she/he owns one) the customer may be unable to receive it depending on the country he currently is in (not every mobile network accepts SMS). The system is also not convenient for customers who tend to change mobile numbers from time to time - such as due to travelling (and some banks require a visit to their office to change the mobile number on the account). Some Wifi providers who charge for usage by credit card don't actually allow accessing the 3-D Secure site before the payment is completed, so the user is unable to purchase Internet access.

Geographic discrimination

Banks and merchants may use 3-D Secure systems unevenly with regard to banks that issue cards in several geographic locations, creating differentiations, for example, between domestic US- and non-US-issued cards. For example, since VISA and MasterCard treat the United States territory of Puerto Rico as a non-US international, rather than a domestic US location, cardholders there may confront a greater incidence of 3-D Secure queries than cardholders in the 50 states. Complaints to that effect have been received by Puerto Rico's Department of Consumer Affairs "equal treatment" economic discrimination site,

3D Secure as Strong authentication

The newest variant of 3D Secure, which incorporates one time passwords, is a form of software based Strong Authentication. However, the legacy variant with static password does not meet the European Central Bank's (ECB) January 2013 requirements. 3D Secure relies upon the issuer actively being involved and ensuring that any card issued becomes enrolled by the cardholder, making it very much an issuer focused solution. The ECB has mandated in its January 2013 requirements 'Security for Internet Payments' that all transactions acquired within the Single Euro Payment Area (SEPA) must be authenticated using strong customer authentication by 1 February 2015. This mandate by the ECB, and supported by the European Commission's Payment Services Directive Mk2 (PSD2), is intended to provide a level and technology neutral playing field within SEPA to foster eCommerce, mCommerce and supporting technologies, including competitive forms of strong customer authentication. As 3D Secure relies upon issuer advance involvement and enrollment of cards, acquirers cannot rely upon 3D Secure to meet their acquiring side authentication requirements, until such time as 3D Secure has a meaningful enrollment approaching 100% of all cards issued. This in turn makes 3D Secure a weak solution for the acquiring side strong customer authentication requirements, particularly as 3D Secure is not available on the 25 smaller card schemes recognised by the ECB. 3D Secure must also be implemented for each card scheme to which it is to be applied, generally on a case by case basis, unless a specialist integration company is used. Thus, acquirers may be faced with either accepting cards that are not enrolled and susceptible to fraud, or, to reject such cards until a means of strong authentication is available. As acquirers and payment gateways are liable for fraud on their networks from 1 February 2015, unless they have strong customer authentication in place, it is unclear what impact the ECB's requirements will have on SEPA eCommerce. Acquiring side authentication differs from issuing side authentication, in that cards are enrolled upon being acquired as part of a transaction, rather than requiring to be pre-enrolled following issue. Acquiring side authentication can thus enroll cards progressively on demand, achieving an effective enrollment rate of 100%. Card enrollment and authentication can this be at the same time. Examples of acquiring side authentication include PayPal's patented 'verification' method, where one or more dummy transactions are directed towards a credit card, and the cardholder must confirm the value of these transactions. The iSignthis patented method uses the transaction value at the point of sale, such that the sales amount as agreed between the eMerchant and cardholder, is split into two (or more) amounts, with the first amount being a randomly generated value, and the second value being the balancing amount between sales amount and the random value. Both of these methods rely upon the card holder accessing the account associated with the credit card, and confirming the value of the random transaction in order to prove that they are the owner of the account. PayPal's method however does not specifically relate to a transaction between an eMerchant and card holder, so unless it is augmented with another process that relates directly to a transaction, the method is not a form of strong customer authentication as is thus not an alternative to 3D Secure.


EMV stands for Europay, MasterCard and Visa, a global standard for inter-operation of integrated circuit cards (IC cards or "chip cards") and IC card capable point of sale (POS) terminals and automated teller machines (ATMs), for authenticating credit and debit card transactions.

It is a joint effort initially conceived between Europay, MasterCard and Visa to ensure the security and global interoperability of chip-based payment cards. Europay International SA was absorbed into MasterCard in 2002. The standard is now defined and managed by the public corporation EMVCo LLC. JCB (formerly Japan Credit Bureau) joined the organization in December 2004, and American Express joined in February 2009. In May 2013 China UnionPay was announced as its latest member[1] with UnionPay now having an equal 1/5 interest in the standards body along with Visa, MasterCard, American Express and JCB. IC card systems based on the EMV specification are being phased in across the world, under names such as "IC Credit" and "Chip and PIN".

The EMV standards define the interaction at the physical, electrical, data and application levels between IC cards and IC card processing devices for financial transactions. There are standards based on ISO/IEC 7816 for contact cards, and standards based on ISO/IEC 14443 for contactless cards (PayPass, payWave, ExpressPay).

The first standard for payment cards was the Carte Bancaire M4 from Bull-CP8 deployed in France in 1986 followed by the B4B0' (compatible with the M4) deployed in 1989. Geldkarte in Germany also predates EMV. EMV was designed to allow cards and terminals to be backwardly compatible with these standards. France has since migrated all its card and terminal infrastructure to EMV.

The most widely known chip card implementations of EMV standard are:

  • VSDC - Visa
  • M/Chip - MasterCard
  • AEIPS - American Express
  • J Smart - JCB
  • D-PAS - Discover/Diners Club International.

Visa and MasterCard have also developed standards for using EMV cards in devices to support card-not-present transactions over the telephone and Internet. MasterCard has the Chip Authentication Program (CAP) for secure e-commerce. Its implementation is known as EMV-CAP and supports a number of modes. Visa has the Dynamic Password Authentication (DPA) scheme, which is their implementation of CAP using different default values.

In February 2010, computer scientists from Cambridge University demonstrated that an implementation of EMV PIN entry is vulnerable to a man-in-the-middle attack; however, the way PINs are processed depends on the capabilities of the card and the terminal. EMVCo published a response saying that, while such an attack might be theoretically possible, it would be extremely difficult and expensive to carry out successfully.

In May 2010, a press release from Gemalto (a global EMV card producer) indicated that United Nations Federal Credit Union in New York would become the first EMV card issuer in the US, offering an EMV Visa credit card to its customers.

Differences and benefits of EMV

The purpose and goal of the EMV standard is to specify interoperability between EMV-compliant IC cards and EMV-compliant credit card payment terminals throughout the world. There are two major benefits to moving to smart-card-based credit card payment systems: improved security (with associated fraud reduction), and the possibility for finer control of "offline" credit-card transaction approvals. One of the original goals of EMV was to allow for multiple applications to be held on a card: for a credit and debit card application or an e-purse.

EMV chip card transactions improve security against fraud compared to magnetic stripe card transactions that rely on the holder's signature and visual inspection of the card to check for features such as hologram. The use of a PIN and cryptographic algorithms such as DES, Triple-DES, RSA and SHA provide authentication of the card to the processing terminal and the card issuer's host system. The processing time is comparable to online transactions, in which communications delay accounts for the majority of the time, while cryptographic operations take comparatively little time. The supposed increased protection from fraud has allowed banks and credit card issuers to push through a 'liability shift' such that merchants are now liable (as from 1 January 2005 in the EU region) for any fraud that results from transactions on systems that are not EMV capable.[3] For transactions in which an EMV card is used, the cardholder is assumed to be liable unless they can unquestionably prove they were not present for the transaction, did not authorize the transaction, and did not inadvertently assist the transaction through PIN disclosure[citation needed].

Although not the only possible method, the majority of implementations of EMV cards and terminals confirm the identity of the cardholder by requiring the entry of a PIN (Personal Identification Number) rather than signing a paper receipt. Whether or not PIN authentication takes place depends upon the capabilities of the terminal and programming of the card. For more details of this (specifically, the system being implemented in the UK) see Chip and PIN.

EMV commands

ISO/IEC 7816-3 defines the transmission protocol between chip cards and readers. Using this protocol, data is exchanged in application protocol data units (APDUs). This comprises sending a command to a card, the card processing it, and sending a response. EMV uses the following commands:

  • application block
  • application unblock
  • card block
  • external authenticate (7816-4)
  • generate application cryptogram
  • get data (7816-4)
  • get processing options
  • internal authenticate (7816-4)
  • PIN change / unblock
  • read record (7816-4)
  • select (7816-4)
  • verify (7816-4).

Commands followed by "7816-4" are defined in ISO/IEC 7816-4 and are interindustry commands used for many chip card applications such as GSM SIM cards.

EMV transaction flow

An EMV transaction has the following steps:

  • Application selection
  • Initiate application processing
  • Read application data
  • Processing restrictions
  • Offline data authentication
  • Cardholder verification
  • Terminal risk management
  • Terminal action analysis
  • First card action analysis
  • Online transaction authorisation (only carried out if required by the result of the previous steps; mandatory in ATMs)
  • Second card action analysis
  • Issuer script processing.

Initiate application processing

The terminal sends the get processing options command to the card. When issuing this command, the terminal supplies the card with any data elements requested by the card in the processing options data objects list (PDOL). The PDOL (a list of tags and lengths of data elements) is optionally provided by the card to the terminal during application selection. The card responds with the application interchange profile (AIP), a list of functions to be performed in processing the transaction. The card also provides the application file locator (AFL), a list of files and records that the terminal needs to read from the card.

Read application data

Smart cards store data in files. The AFL contains the files that contain EMV data. These all need to be read using the read record command. EMV does not specify which files data is stored in, so all the files need to be read. Data in these files is stored in BER TLV format. EMV defines tag values for all data used in card processing.

Processing restrictions

The purpose of the processing restrictions is to see if the card should be used. Three data elements read in the previous step are checked.

  • Application version number
  • Application usage control (This shows whether the card is only for domestic use, etc.)
  • Application effective/expiration dates checking.

If any of these checks fails, the card is not necessarily declined. The terminal sets the appropriate bit in the terminal verification results (TVR), the components of which form the basis of an accept/decline decision later in the transaction flow. This feature allows, for example, card issuers to permit their cardholders to continue to use expired cards after their expiry date, but for all transactions made with an expired card to be performed on-line.

Offline data authentication

Offline data authentication is a cryptographic check to validate the card using public-key cryptography. There are three different processes that can be undertaken depending on the card:

  • Static data authentication (SDA) ensures data read from the card has been signed by the card issuer. This prevents modification of data, but does not prevent cloning.
  • Dynamic data authentication (DDA) provides protection against modification of data and cloning.
  • Combined DDA/generate application cryptogram (CDA) combines DDA with the generation of a card's application cryptogram to assure card validity. Support of CDA in devices may be needed, as this process has been implemented in specific markets. This process is not mandatory in terminals and can only be carried out where both card and terminal support it.

Cardholder verification

Cardholder verification is used to evaluate whether the person presenting the card is the legitimate cardholder. There are many cardholder verification methods (CVMs) supported in EMV. They are:

  • Signature
  • Offline plaintext PIN
  • Offline enciphered PIN
  • Offline plaintext PIN and signature
  • Offline enciphered PIN and signature
  • Online PIN
  • No CVM required
  • Fail CVM processing.

The terminal uses a CVM list read from the card to determine the type of verification to be performed. The CVM list establishes a priority of CVMs to be used relative to the capabilities of the terminal. Different terminals support different CVMs. ATMs generally support online PIN. POS terminals vary in their support of CVM depending on their type and in which country they are located.

Terminal action analysis

The results of previous processing steps are used to determine whether a transaction should be approved offline, sent online for authorization, or declined offline. This is done using a combination of Terminal action codes (TACs) which are held in the terminal and Issuer action codes (IACs) which are read from the card.

An online-only device such as an ATM always attempts to go on-line with the authorization request, unless declined off-line due to Issuer action codes—Denial settings. During IAC—Denial and TAC—Denial processing, for an online only device, the only relevant Terminal verification results bit is “Service not allowed”.

When an online-only device performs IAC—Online and TAC—Online processing the only relevant TVR bit is “Transaction value exceeds the floor limit”. Because the floor limit is set to zero, the transaction should always go online and all other values in TAC—Online or IAC—Online are irrelevant.

Online-only devices do not need to perform IAC-default processing.

First card action analysis

One of the data objects read from the card in the Read application data stage is CDOL1 (Card Data object List). This object is a list of tags that the card wants to be sent to it to make a decision on whether to approve or decline a transaction (including transaction amount, but many other data objects too). The terminal sends this data and requests a cryptogram using the generate application cryptogram command. Depending on the terminal′s decision (offline, online, decline), the terminal requests one of the following cryptograms from the card:

  • Transaction certificate (TC)—Offline approval
  • Authorization Request Cryptogram (ARQC)—Online authorization
  • Application Authentication Cryptogram (AAC)—Offline decline.

This step gives the card the opportunity to accept the terminal's action analysis or to decline a transaction or force a transaction on-line. The card cannot return a TC when an ARQC has been asked for, but can return an ARQC when a TC has been asked for.

Online transaction authorisation

Transactions go online when an ARQC has been requested. The ARQC is sent in the authorisation message. The card generates the ARQC. Its format depends on the card application. EMV does not specify the contents of the ARQC. The ARQC created by the card application is a digital signature of the transaction details which can be checked in real time by the card issuer. This provides a strong cryptographic check that the card is genuine. The issuer responds to an authorisation request with a response code (accepting or declining the transaction), an authorisation response cryptogram (ARPC) and optionally an issuer script (a string of commands to be sent to the card).

Second card action analysis

CDOL2 (Card data object list) contains a list of tags that the card wants to be sent following online transaction authorisation (response code ARPC, etc.). Even if for any reason the terminal could not go online (e.g., communication failure), the terminal should send this data to the card again using the generate authorisation cryptogram command. This lets the card know the issuer's response. The card application may then reset offline usage limits.

Issuer script processing

If a card issuer wants to update a card post issuance it can send commands to the card using issuer script processing. Issuer scripts are encrypted between the card and the issuer, so are meaningless to the terminal. Issuer script can be used to block cards, or change card parameters.

Control of the EMV standard

The first version of EMV standard was published in 1995. Now the standard is defined and managed by the public corporation EMVCo LLC. The current members of EMVCo are JCB International, American Express, MasterCard Worldwide, China UnionPay and Visa, Inc. Each of these organizations owns one fifth of EMVCo and has representatives in the EMVCo organization and EMVCo working groups.

Recognition of compliance with the EMV standard (i.e., device certification) is issued by EMVCo following submission of results of testing performed by an accredited testing house.

EMV Compliance testing has two levels: EMV Level 1, which covers physical, electrical and transport level interfaces, and EMV Level 2, which covers payment application selection and credit financial transaction processing.

After passing common EMVCo tests, the software must be certified by payment brands to comply with proprietary EMV implementations such as Visa VSDC, American Express AEIPS, MasterCard MChip, JCB JSmart, or EMV-compliant implementations of non-EMVCo members such as LINK in the UK, or Interac in Canada.

The EMVCo standards have been integrated into the broader electronic payment security standards being developed by the Secure POS Vendor Alliance, with a specific effort to develop a common interpretation of EMVCo's place relative to, and interactions with, other existing security standards, such as PCI-DSS.

List of EMV documents and standards

Since version 4.0, the official EMV standard documents that define all the components in an EMV payment system are published as four "books" and some additional documents:


First EMV standard came into view in 1995 as EMV 2.0. This was upgraded to EMV 3.0 in 1996 (sometimes referred to as EMV '96) with later amendments to EMV 3.1.1 in 1998. This was further amended to version 4.0 in December 2000 (sometimes referred to as EMV 2000).

  • Version 4.0 became effective in June 2004
  • Version 4.1 became effective in June 2007
  • Version 4.2 is in effect since June 2008
  • Version 4.3 is in effect since November 2011.

Chaum's scheme

Here we provide a description of two schemes of work Chaum. However, these schemes are simple enough and well illustrate the main ideas and methods underlying the Bank of cryptographic protocols.

In both schemes the Bank produces the two large Prime numbers p and q and publishes their work, N = pq keeping multipliers secret (initialization schemes electronic signature RSA). In addition, selected and published some one-way function f: Zn → Zn. Sets the agreement, according to which the Exhibitor equal to i-th odd Prime number, corresponds to the nominal value of the 2^(i-1), say cents. I.e., the bearer of the pairs (n,f(n)^(1/3) mod N) is the owner of e-banknotes in denominations of 1 cent. If this pair instead of cubic root there is the root of the 7-th degree, the banknote has the dignity of 4 cents, and if the 21-St class-5 cents. In other words, for banknotes of S cents need root of degree equal to a product of all simple, relevant units in the binary representation of the number of S.

The first scheme

In the first scheme, all banknotes issued by the Bank, are of the same value. For simplicity we will assume that it is equal to 15 cents. Then the signature of the Bank on the bill, this is -- root h the second degree, where h=3*5*7*11. This scheme also need an additional module to RSA N1, which is used in the work with the so-called piggy Bank (see below). This module is selected and published in the same manner as the module N.

The transaction withdrawal from the account of the buyer selects a random value is n1 ϵ Zn and calculates the f(n1). He needs to get the signature of the Bank on this banknote, i.e. to calculate the f(n1)^(1/h). But just to send the value f(n1)to the Bank, the buyer may not, because to withdraw money from the account, he must identify himself. Therefore, if the Bank receives f(n1). The solution is to use a darkened signature: the buyer selects a random value is r1 ϵ Zn, r1 PD 0, calculates the f(n1)r1^h mod N and sends this value to the Bank. Multiplier r1^h often called затемняющим multiplier. The Bank calculates the value f(n1)^(1/h)r1 mod N and return it to the purchaser. The buyer easily removes затемняющий multiplier and receives a signed bill f(n1)^(1/h) mod N.

Suppose now that the buyer is willing to pay the seller 5 cents. For this, he calculates the f(n1)^(1/3*7) mod N, simply erecting received a bill in the 55-th degree, and creates a piggy Bank, choosing a random value j and computing f(j)s1^(5*11) mod n 1. Here again s1^(5* 11) -- dark multiplier. Transaction of payment starts with forwarding values n1, f(n1)^(1/3* 7) mod N, f(j)s1^(5* 11) mod n 1, and the payment amount (5 cents) to the seller. The seller, in turn, passes this information to the Bank. The Bank easily verifies that the pair (n1,f(n1)^(1/3*7)) represents a real banknote advantage 5 cents. It checks a special case, if the banknote number n1 spent earlier. If not, writes in the register of the obtained bill and sends the seller notice of the completion of the transaction payment, as well as "change" for 10 cents for a buyer, returned through the Treasury: f(j)^(1/5*11)s1 mod N1.


The security of the Bank in these transactions is based on the belief in the persistence schema electronic signature RSA. If all payments made by the buyer made on the maximum amount (15 cents), the scheme provides unconditional (or theoretical information) !traceability buyer: giving a darkened signature, the Bank receives no information about the room подписываемой banknotes.

The necessity of Deposit received from the Bank "Deposit" violates !traceability: Bank remembers all payments and, therefore, all the "surrender", and when a transaction Deposit can calculate the client that made the payment. This problem can be partly solved due to repeated use of the spike in transactions of payment.

Assume that the buyer has received the second Bank of the banknote number n2 and is willing to pay the same or a different seller the amount of 3 cents. Then in the transaction of payment it may use a piggy Bank with the "surrender", remaining after the first payment, and send the seller a n2, f(n2)^(1/3*5) mod N, f(j)^(1/5* 11)s2^(7*11) mod n 1. The payment is performed in the same manner as described above, and thus the buyer will receive a piggy Bank f(j)^(1/5*11*7*11) mod n 1.

In transaction Deposit the buyer puts accumulated in the Bank amount to his account in the Bank. It sends the Bank values j, f(j)^(1/5* 7* 11* 11) mod n 1 and indicate the amount. The Bank verifies the Treasury as well as banknote, i.e. it checks for all the roots disclosed to buyer multiplisity, as well as verifies that the piggy Bank with the number j was not used before, in any transaction Deposit. If all conditions are met, the Bank calculates the amount in the Bank, and credits it to the buyer's account.

The more payments executed with the same moneybox and the more clients in the system, the lower the chances of the Bank to monitor the activity of each of them.

The second scheme

The second scheme, is based on the same ideas, so here describes only the differences from the previous one. First, use only one module (in the descriptions we've omitted). Secondly, the Bank can issue banknotes of different denominations. Namely, let h as above, corresponds to the maximum dignity of banknotes and g | h. Then the Bank can issue a banknote, which value represents the number of g. Let, in addition, d corresponds to the amount of the payment, where d | g and c = g/d -- "surrender".

Transaction withdrawal from the account is the same as in the previous scheme. In the transaction of payment the buyer sends to the seller and the Bank the following values:


The Bank shall return to the buyer the seller value


The number of m can be selected as f(n1) for some new value n1, that allows in future to use "change" in the new payment without the need for an intermediate Deposit and withdrawals from the account. I.e., "delivery" is the same e-bill, as the amount withdrawn from the account.

Multiplier f(f(n)^(1/c)) in the value that is returned by the Bank, is required to ensure that the buyer could calculate m^(1/c) only when he knows f(n)^(1/c).

Transaction Deposit in this scheme does not differ (from a cryptographic point of view) from the payment transaction.

"Surrender", returned by the transaction of payment can be divided into several banknotes. Suppose, for example, that the last payment was d=5* 11, c=3* 7and m was formed as the m=f(n1)^3f(n2)^7. Then, after removing the blackening out of multipliers from the value returned by the Bank, will be obtained value a=m^(1/21). After that the buyer calculates


In the result, the two banknotes in denominations of 1 and 4 cents respectively.

Provided that the Bank releases a great amount of banknotes from each dignity, this scheme provides practical don't traceability clients. Here the thin moment: the scheme provides unconditional !traceability, but only within a set of customers снявших from the account of the banknote, the dignity, or inside a set of customers снявших from the account of the banknote, the dignity and gaining the payment for such amount and etc.

Brands' system

Scheme Eugen brands stands out from all the Autonomous systems of electronic payments due to, firstly, its high efficiency, and secondly, an attempt to justify its resistance. In the work of a number of results, claiming the durability of this system. We evaluate them carefully, as an attempt of justification of resistance, because the work is not enough formal definitions, and for evidence of the author refers to its technical report. Everywhere below we denote the buyer through Uand seller -- S.

Initializing system

The Bank chooses three of generating Img903.gif group Gq Prime order and number of Img905.gif. In addition, he selects two hash functions (in the work they are called hash functions with difficult findable collisions) H and H0. H displays the five elements of a group Gq in the Img177.gifand that "theH0 -- pair of elements Gq -- Zq. In addition, H0 depends on a certain value of ID, identifying S as well -- from the time and date t of the transaction. The Bank publishes the description of the group Gq (primes p and qif Img907.gif), three of the Img903.gifand functions H, H0, as his or her public key. The secret key of the Bank is the number of x. In the descriptions of protocols also appears to have some value'h', which in the work of nowhere defined, but of Protocol analysis we can understand that the h=g^x and this value must be published as part of a public key. Signature sign(A,B) Bank for pairs (A,B), Gq with (z,a,b,r) z,a,b ϵ Gq, r ϵ Zq, such that


Account opening

U selects the number of Img916.gif and computes Img917.gif. If Img918.gif U passes a value of I Bank, u1 keeps secret. For the security of the Bank significantly to the value I were different for different clients. The Bank calculates the Img920.gif and passes this value to U.


Before you remove an electronic coin from the account, U must authenticate, i.e. to prove to the Bank that he is the owner of this account. Then it performs the following Protocol.

1. The Bank chooses the number of Img921.gif and sends the Img922.gifand Img923.gif client U.

2. U selects three numbers Img924.gif, Img925.gif and computes Img926.gif, Img927.gif and Img928.gif. In addition, U selects a number of Img929.gif and computes Img930.gif and Img931.gif. Then he evaluates Img932.gif and sends a request Img933.gif to the Bank.

3. The Bank sends a response Img934.gif and withdraw from the account U the appropriate amount. U receives a reply then and only then, when Img935.gif and Img936.gif. If these conditions are met, U computes Img937.gif. Pair (A,B) and signature of the Bank (z',a',b',r') for it form the electronic coin.


In the transaction of payment U and S perform the following Protocol.

1. U sends a S electronic coin: A, B, sign(A,B).

2. If A ≠ 1, S calculates the query Img940.gif, whereID -- ID Sand t -- transaction date and time. S sends a U valued.

3. U computes answers Img941.gif and Img942.gif and sends them S. S take a coin and then only when sign(A,B). is signature'(A, B)Img943.gif.


S sends to the Bank A, B, sign(A,B),(r1,r2), and the date and time of the transaction of payment t. If A = 1, the Bank shall not accept the coin. Otherwise it evaluates the d using the data obtained and the ID sellerS. Then the Bank will check that Img943.gif and that "the sign(A,B) is the signature for (A,B). If everything is correct, the Bank checks whether the coin spent earlier. If not, the Bank remembers (A,t,r1,r2) and puts a coin on account of S.

If this electronic coin has already been spent previously, the Bank has at its disposal two divergent Troika (d, r1, r2) and (d', r'1, r'2) and can calculate ID offender Img949.gif.

Of the claims formulated in the work, implies the assumption of the difficulty of the task, taking the logarithm of discrete and durability authentication Protocol Schnorr, the security of the above protocols for all participants. This means that: clients can't create electronic coins without the Bank's involvement. if the seller is acting in the transaction of payment according to the Protocol, the customer cannot deceive him, paying a false coin; if the buyer is acting according to the protocols, the Bank may not falsely accuse him, submitting to arbitration fabricated evidence re spending one and the same e-coins; messages sent during the implementation of the protocols that do not require encryption, i.e. the opponent, an eavesdropper transaction withdrawal from the account, can not create an electronic coin, and eavesdropping transaction is the payment helps to Deposit intercepted coins to another account. In addition, under certain assumption, which seems to be stronger than the assumption on the difficulty of the task, Diffie-Hellman, it is proved that the perpetrator, double-spending one electronic coin will always be identified.


Secure Electronic Transaction (SET) was a communications protocol standard for securing credit card transactions over insecure networks, specifically, the Internet. SET was not itself a payment system, but rather a set of security protocols and formats that enabled users to employ the existing credit card payment infrastructure on an open network in a secure fashion. However, it failed to gain attraction in the market. VISA now promotes the 3-D Secure scheme.

History and development

SET was developed by the SET Consortium, established in 1996 by VISA and MasterCard in cooperation with GTE, IBM, Microsoft, Netscape, SAIC, Terisa Systems, RSA, and VeriSign.[1] The consortium’s goal was to combine the card associations' similar but incompatible protocols (STT from Visa/Microsoft and SEPP from Mastercard/IBM) into a single standard. The first review draft of the protocol was published February 1996 and the v1.0 standard document was published in May 1997. Although there were several attempts to update or revise the protocol, no official version was produced beyond 1.0.[2] An official reference implementation developed by Terisa Systems was announced in 1997.[3] In December 1997 Visa and Mastercard created an independent company, SET Secure Electronic Transaction LLC (a.k.a. SETco), announcing American Express and JCB as cooperating members. SETco managed the development and deployment of the protocol and was responsible for branding and certification. Unofficial and informal interoperability testing among vendors occurred during 1997.[4] Formal pilot tests began in 1998, but they were reportedly problematic.[5] SET allowed parties to identify themselves to each other and exchange information securely. Binding of identities was based on X.509 certificates with several extensions.[6] SET used a cryptographic blinding algorithm that, in effect, would have let merchants substitute a certificate for a user's credit-card number. If SET were used, the merchant itself would never have had to know the credit-card numbers being sent from the buyer, which would have provided verified good payment but protected customers and credit companies from fraud. SET was intended to become the de facto standard payment method on the Internet between the merchants, the buyers, and the credit-card companies. Despite heavy publicity to win market share, it failed to gain widespread use. Reasons for this include:

  • Network effect - need to install client software (an e-wallet).
  • Cost and complexity for merchants to offer support, contrasted with the comparatively low cost and simplicity of the existing SSL based alternative.
  • Client-side certificate distribution logistics.

Key features

To meet the business requirements, SET incorporates the following features:

  • Confidentiality of information
  • Integrity of data
  • Cardholder account authentication
  • Merchant authentication


A SET system includes the following participants:

  • Cardholder
  • Merchant
  • Issuer
  • Acquirer
  • Payment gateway
  • Certification authority


The sequence of events required for a transaction is as follows:

  • The customer obtains a credit card account with a bank that supports electronic payment and SET
  • The customer receives a X.509v3 digital certificate signed by the bank.
  • Merchants have their own certificates
  • The customer places an order with the merchant.
  • The merchant sends the customer his public key and a copy of his certificate so that the customer can verify that it's a valid store.
  • The customer sends the merchant:
    • His certificate.
    • His order details encrypted with the merchant's public key
    • His bank account details encrypted with the bank's public key.
  • The merchant requests payment authorization by sending the bank:
    • The payment details encrypted with the bank's public key.
    • The customer's bank account details encrypted with the bank's public key.
Note that the merchant doesn't know the client's payment and bank account details.
  • The bank sends the merchant a confirmation encrypted with the merchant's public key.
  • The merchant sends the client the bank's response encrypted with the client's public key.
  • The merchant ships the goods or provides the service to the customer.
  • The merchant sends the bank a transaction request encrypted with the bank's public key.
  • The bank transfers the payment to the merchant.

Dual signature

As described in (Stallings 2000):

An important innovation introduced in SET is the dual signature. The purpose of the dual signature is to link two messages that are intended for two different recipients. In this case, the customer wants to send the order information (OI) to the merchant and the payment information (PI) to the bank. The merchant does not need to know the customer's credit-card number, and the bank does not need to know the details of the customer's order. The customer is afforded extra protection in terms of privacy by keeping these two items separate. However, the two items must be linked in a way that can be used to resolve disputes if necessary. The link is needed so that the customer can prove that this payment is intended for this order and not for some other goods or service.

The message digest (MD) of the OI and the PI are independently calculated by the customer. The dual signature is the encrypted MD (with the customer's secret key) of the concatenated MD's of PI and OI. The dual signature is sent to both the merchant and the bank. The protocol arranges for the merchant to see the MD of the PI without seeing the PI itself, and the bank sees the MD of the OI but not the OI itself. The dual signature can be verified using the MD of the OI or PI. It doesn't require the OI or PI itself. Its MD does not reveal the content of the OI or PI, and thus privacy is preserved.



Navigate to bibliography.

On Main Page

Edited by Ablekov V. & Moroz M., 2013