Roger Clarke's 'Overview of SET'

Secure Electronic Transactions (SET) is an "open, vendor-neutral, non-proprietary, license-free specification for securing on-line transactions". It leverages off the existing payment-card infrastructure and card-base. It is a collaborative initiative, spear-headed by Visa and MasterCard, but including other important players such as Microsoft and Netscape.

This document provides an overview and tentative assessment of the SET specification.

Overview

Visa and MasterCard are seeking to protect and exploit their current dominance of the world's payment mechanisms, and their members' investments in payment-processing infrastructure and market-share in transactions and funds management. To do this, they are proposing a means whereby card-details can be used over an open network such as the Internet, with a far higher level of fraud-prevention than is available with manual (flick-flack) and even data-capture at POS arrangements.

The scheme involves the use of digital signatures based on public key encryption, as a means of authenticating all participants in a card-based payment transaction.

The SET initiative is claimed to be, and appears to be, collaborative in nature, but it creates a platform upon which competitive services can be offered. In addition, to Visa and MasterCard (which have about 50% and 25% of the world's card-based payment processing respectively), AmEx has signalled its intention to use SET.

A preliminary version of the specification was published in mid-1996, and `reference code' (i.e. a restricted prototype implementation) is to be available by the end of 1996. A revised and extended version of the specification is intended for early-mid 1997.

The SET Mechanism

The operation of SET depends on software that implements a series of protocols being installed in the workstations or servers of four kinds of people and organisations.

These are:

cardholders;
merchants;
payment gateways / acquirers; and
certification authorities.

The processes involved are complex, because of the need for multiple security risks to be addressed, for multiple parties to authenticate one another, for the approaches of multiple payment processing services providers to be accommodated, and to reflect the needs and practices of multiple countries around the world.

The simplified representation that follows describes the two key elements:

the establishment of the necessary framework; and
the conduct of a payment transaction.

The Establishment of the Framework

Each of the participants has to create a key-pair, store the private key in a secure manner, and make the public key available to organisations that seek it.

SET envisages a hierarchy of certification authorities (CAs), independent from other CA hierarchies. These are:

an as-yet vaguely defined `root CA' (God) that certifies payment-processing organisations like Visa, MasterCard and AmEx;
a CA run by or for each payment-processing organisation that certifies its member-institutions / banks / card-issuers; and
a CA run by each card-issuer that certifies its cardholders.

A cardholder will (quite probably unconsciously) acquire a certificate from the CA of their card-issuer, a copy of which they can provide whenever they make a purchase. Each card-issuer will acquire a certificate from the CA of each payment-processing organisation that they use. Each payment-processing organisation will acquire a certificate from the root CA.

The Conduct of a Payment Transaction

To effect a transaction, a card-holder invokes software on their workstation that initiates the following sequence:

the card-holder states that he wishes to make a payment;
the merchant responds;
the card-holder provides details of the amount to be paid, together with a copy of their certificate;
the merchant sends to the payment-processing organisation (via the payment gateway or acquirer) a request for authorisation;
authorisation is handled by existing processes using existing networks;
the merchant receives authorisation;
the merchant sends a capture request (to actually commit the transaction);
the merchant receives confirmation that the transaction has been accepted;
the merchant sends the card-holder confirmation that the payment has been accepted.

SET Strengths

The scheme uses accepted technologies (including public-key encryption, digital signatures, and certificates) and established protocols (including the secure hashing algorithm - SHA, RSA's asymmetric encryption algorithm, DES symmetric encryption algorithm, and X.509 version 3 certificates).

It promises secure transmission, and a considerable level of confidence that the participants have the authority to undertake the transaction.

SET has been designed with credit-card transactions in mind, and does not support transmission of PINs. The early versions of SET can therefore not be used to support debit-card transactions (at least in countries like Australia for which PIN protection is obligatory). On the other hand, SET transactions are potentially more secure than PIN-based transactions, and SET could in due course become accepted as a means of conducting payments against a revolving line of credit, or the card-holder's own funds.

SET Weaknesses

The scheme is complex, and depends on many participants conforming with the specification.

The scheme contains nothing that manages participants' private keys. It appears that these will need to be stored on participants' workstations and servers, or additional peripherals installed on workstations and servers to handle a secure token (probably a chip-card).

The scheme says nothing about the apportionment of responsibility for losses. A great deal of this is already addressed in the existing systems. However the payment-processing organisations and banks may seek to make card-holders responsible for transactions undertaken using the card-holder's private key. Given that no workable solution exists whereby card-holders can secure their private keys, consumers would be at risk of someone breaking into their premises, or taking control of their workstation from a remote site, and spending the card-holder's money without their knowledge, and without recourse.

SET in Context

Card-based payment is only one of the ways in which transfers of funds are likely to be effected over the net (although, hope Visa, MasterCard and AmEx, perhaps the dominant one).

In parallel with SET, a protocol has been established whereby web-browsers and web-servers, representing payers and payees, can conduct a negotiation, in order to determine which payment mechanism to use, what protocol and what transport. The Joint Electronic Payments Initiative (JEPI) consists of two parts: an extension layer that sits on top of http, and is known as - Protocol Extensions Protocol (PEP), and Universal Payment Preamble (UPP), the negotiations protocol that identifies the appropriate payment methodology. For more information on JEPI, see http://www.w3.org/pub/WWW/Payments

Personalia Photographs
Presentations
Videos Access
Statistics

The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 65 million in early 2021.

Sponsored by the Gallery, Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer

Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 27 November 1996 - Last Amended: 27 November 1996 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/EC/SETOview.html
Mail to Webmaster - © Xamax Consultancy Pty Ltd, 1995-2022 - Privacy Policy