Electronic commerce on the Internet has been the Holy Grail of the marketeer ever since the great Web explosion of the early 1990s. While individual sites have sprung up to take credit card orders online, banks and many merchants have shied away from Internet commerce until a secure credit card transaction infrastructure administered by major financial companies is in place.
The chances looked grim when MasterCard and Visa International split into warring factions, each with major computer vendors in its camp. But the pressure brought to bear on the two credit card giants by the banking industry was rewarded when they announced they would work together to forge a single standard. The fruit of this accord is SET - Secure Electronic Transactions.
Together, MasterCard and Visa serve around 700 million customers worldwide.
Their size and their ability to draw major banks into the arena mean that many observers see SET as the catalyst which will finally allow Internet commerce to take off.
Before their accord, the two companies had each come up with a separate protocol for conducting secure credit card transactions over the Internet.
MasterCard was working with IBM and Netscape to create a system called SEPP (Secure Encryption Payment Protocol), based on Netscape's SSL (Secure Sockets Layer) protocol, while Visa was working with Microsoft on a system called STT (Secure Transaction Technology). Terisa Systems introduced another protocol called S-HTTP (Secure HyperText Transfer Protocol), which both camps pledged to support.
With MasterCard and Visa basing their systems on incompatible protocols, merchants and banks would have to choose sides or support two systems.
A standards war loomed on a scale to rival VHS vs Betamax.
The SET announcement in late February this year it shook the Net. The agreement brought together the major players in the emerging secure transactions arena, including GTE, IBM, Microsoft, Netscape, SAIC, Terisa Systems and VeriSign. While network vendors such as GTE and IBM made sure their existing hardware switches and banking networks could handle the protocol, Microsoft and Netscape competed to provide secure browser and server transaction software. SAIC was to contribute the RSA-based encryption techniques which S-HTTP and STT had used in their earlier efforts, while Terisa Systems would provide the tools that software developers would need to develop e-commerce applications. VeriSign (and GTE) would provide the certificate authentication mechanism to be used by sellers, customers and credit companies.
So far, VeriSign has signed up Visa International and MasterCard, and American Express has plumped for GTE. As these and other companies develop systems built around SET, it will probably be at least six months before systems are available which enable users to conduct transactions using the technology. The agreement to support SET was a major step forward in itself.
SET addresses five major business requirements put forward by the proposal group:
Provide confidentiality of payment and ordering information
It is necessary to assure cardholders that this information is safe and accessible only to the intended recipient. Confidentiality reduces the risk of fraud by either party to the transaction or by malicious third parties which are seeking to intercept financial transactions. Confidentiality in the SET protocol derives from the message encryption.
Ensure integrity for all transmitted data
That is, ensure that no changes in content occur during transmission between the originator and the recipient. SET uses digital signatures to ensure the contents of all order and payment messages received match the contents of messages sent. A hash function (a publicly available algorithm) is applied to the appropriate data to produce a statistically unique integrity value called the hash value. It is impossible to recreate the original data even with the hash value. A digital signature is a hash value which has been encrypted using the private key of the sender.
Provide authentication that the cardholder is a legitimate user of an account
A mechanism which links a cardholder to a specific account number reduces the incidence of fraud and the overall cost of payment processing. SET defines the mechanism - digital signatures and cardholder authorisation certificates - to verify that a cardholder is a legitimate user of a valid account.
Provide authentication that a merchant can accept bank card payments through its relationship with a financial institution - called the acquirer
The complement to the above authentication concern. Cardholders need to be able to identify merchants with whom they can conduct secure transactions.
Again, digital signatures and merchant certificates are used to provide authentication.
Facilitate and encourage interoperability across software and network providers
No preferences for one hardware and software platform should be established, otherwise SET would not be adopted ubiquitously. Users would not change their computers for an arbitrary transaction standard and merchants must be able to use any software which meets the defined standards. SET uses specific protocols and message formats which may be adopted by software vendors creating programs for any major computer platform.
SET describes a method of securing data in transit. It does not provide end-to-end security because other possible security problems, such as those at either the buyer's or merchant's site, are considered beyond its scope. Yet security must be considered if any electronic transaction scheme is to be widely accepted as a truly secure system.
First Virtual, the first Internet bank - uses a competing scheme. It has published details on its Web page of a method in which it believes SET-like secure transaction systems could be attacked.
A keystroke-stealing program which attaches itself to the keyboard drivers in a PC can lie dormant until it is activated by the presence of a digital wallet program. It then records the key presses performed, before they are encrypted, and sends them to a third party. Such a phantom program could be disseminated inside a modified but seemingly normal electronic commerce software package, which could be unknowingly distributed by a financial institution.
Digital certificates play a major part in SET's security scheme and their validity is implicitly assumed. The parameter which gives the certificates mathematical resistance to decryption is the length of the original encryption key. SET certificates will use a key 1,024 bits long, which is felt to provide strong enough security. But what one user encodes another can decode, given enough time and computer power.
The length of time a certificate remains valid is important. The shorter the duration, the greater the security. A certificate generated with a 1,024-bit key which is valid for five years may be secure for its lifetime, but it must necessarily provide less security than a certificate generated with a key of similar length which is valid for only one month. According to Visa's manager for technology research, Tony Lewis, current thought about SET certificates is that they will be valid for one or two years.
Indeed, whether reliance on any cryptographic method provides an acceptable level of security or whether alternate security systems should be used are open questions. The problem with full reliance on cryptographic methods is that if they are decrypted, they fail. Worse, if a decryption is performed by a third party and goes undetected by the legitimate users, a false sense of security is engendered.
If better security is to be incorporated into electronic transactions, they must have some sort of backup mechanism in place rather than simple faith in a particular encryption scheme. Allan Schiffman of Terisa Systems takes this in his stride: "You have to look at a reasonable threat model.
The standard that we need to be at is to make the SET system as secure as, but preferably more secure than, the use of credit cards in the physical world."
Under SET, Schiffman explains, it is difficult or impossible for unscrupulous merchants to sell credit card numbers because the numbers are given only to the acquirer. If a merchant does not deliver the goods bought through a SET transaction, the same dispute mechanisms which exist for a credit card purchase in the physical world are brought into play.
"I may be alone in thinking this, but I believe the amount of cryptography used in SET is overkill," he says. "It's in there to increase cardholder confidence but it adds to the complexity and overhead of processing. SET has prevention against attacks against RSA encryption that no-one has yet proved are even possible. It's better than the system used by the military for nuclear launch codes!"
People use credit cards over phone lines, argues Schiffman, and it's just as easy to tap a phone line as it is to install a packet sniffer.
"If you just want to get credit card numbers, hang around a gas station and pick up the receipts lying on the floor," he says. "I believe that cardholders need to be educated that there is no such thing as absolute security."
Help from the outside
There have been attempts to solve the secure transaction problem for companies which conduct business electronically, although not necessarily on the Internet. In the US, for instance, CheckFree has established itself as an automated receivables operation to businesses including America Online, Cellular One and CompuServe. It specialises in "card not present" transactions, in which a buyer does not hand a card to a seller. The company can authorise and collect transactions involving credit cards and it can pay merchants.
According to Jim Moran, CheckFree vice-president of corporate commerce services: "Last year CheckFree processed more than $10 billion in transactions and only had to write off $14,000 in bad debt. We've established a patented way of determining whether the transaction is likely to be fraudulent.
We leverage off our consumer payment division's experience."
CheckFree's retail experience has paid off online, giving the company what Moran calls "a core competency in transactions". There are some differences, of course, in the way it conducts business on the Internet. While the company can send and receive sensitive data over its leased phone lines, it turns to RSA encryption when the same information is being electronically.
Last September, CheckFree teamed up with CyberCash to offer a secure "digital wallet", a technology which CompuServe has bought and now offers to its four million customer base. The wallet resides on a PC, enabling the user to choose from a variety of payment options, including credit cards, and initiate an order request. The wallet sends order information to the merchant and CheckFree sends a payment authorisation, based on information that the wallet has sent to it, to the merchant along with the order. A merchant never sees the buyer's credit card information but knows it will be paid.
Says Moran: "As far as the Net goes, we'd like to be the one that goes to a Fortune 1,000 company which has a Web catalogue and enables it to take an order from the Internet and integrate the Web system with its existing order and inventory systems for maximum leverage."
Another major player is VeriFone, the leading supplier of point-of-sale credit car systems. Last autumn, VeriFone bought EIT, the company which developed S-HTTP and from which Commerce Net sprung. VeriFone, which invested $4 million in CyberCash and allied with Netscape to market e-commerce solutions, is intent on becoming a major Internet transaction system supplier.
First Virtual Holdings is another rival. Rather than relying on any form of cryptography, its system allows non-sensitive transaction information to travel over the Internet while users' credit card numbers are gathered by phone. A buyer feedback mechanism is built atop existing Net application protocols, including email, finger, FTP, telnet and the World Wide Web.
Because those protocols carry no proof of identity, First Virtual had to design a payment system which provided stronger guarantees based on email callbacks. When First Virtual is asked to process a financial transaction, it looks up the buyer's account and sends an email message for confirmation of the transaction. The buyer can respond with "yes", "no" or "fraud".
Only when the buyer says yes will the financial transaction be initiated.
Another scheme for electronic payments was developed by DigiCash, a Dutch company whose system is based on a digital wallet containing tokens. The tokens are validated (digitally countersigned) by a bank, but the bank cannot trace the tokens to an individual user. DigiCash foresees the widespread use of smart credit cards which contain the user's balance to prevent fraud, but these cards are not yet being issued by the major companies.
Banks have already experimented with electronic cash, including Mark Twain of St Louis, Missouri in the US and NatWest in the UK with a trial of its Mondex system in Swindon. But the St Louis trial failed to achieve critical mass and NatWest is still not ready to roll out Mondex nationally.
Charge cards are another story. Bank credit cards are widely used already, and they are accepted by financial institutions and consumers. Expanding the use of credit cards with which consumers feel comfortable could help Internet commerce become a mass phenomenon. Which is where SET comes in.
But SET is by no means a perfect solution. It does not address issues such as balance-containing smart cards and micro-payments, although these may come up in the next major revision to the protocol which is scheduled in about a year's time. What is clear at the moment, however, is that with the backing of the two largest bank card issuers behind it, SET has a great chance of emerging as the way consumer e-commerce will be handled on the Internet.
The key to encryption
To understand exactly how a SET transaction works, you need to understand the basics of encryption and digital signatures, which ensure a message goes only to the intended recipient and that the sender can be verified.
Encryption is a method of scrambling a message so that no-one can read it except people who have the key to decrypt it. That key can be a code book, secret decoder ring or electronic file.
There are two standard methods in use today - secret key cryptography and public key cryptography. SET uses both methods.
Secret key cryptography, which is also known as symmetric cryptography, uses the same key, known to both the sender and recipient, to encrypt and decrypt the message. One well known secret key algorithm is the Data Encryption Standard (DES), which is currently used by many financial institutions for transmitting data to automatic teller machines over unsecured phone lines.
Public key cryptography, or asymmetric cryptography, uses two keys, one to encrypt a message and the other to decrypt it. A message encrypted with one key can only be decrypted with the other.
Users who exchange encrypted messages in this way have a public and a private key. They distribute the public key in a file, via email or even on a Web page. Anyone with the public key can use it to send a message that can only be decrypted using the owner's private key.
The best known public key cryptography algorithm is RSA - named after its inventors, Rivest, Shamir and Adleman - which is used in software such as Phil Zimmermann's PGP.
A public key system also enables the use of digital signatures. A user can sign a message, by adding a code to the end of it, for instance, using his or her secret key. Anyone who has the corresponding public key can verify that the message came from the intended recipient.
With secret and public key cryptography, and digital signatures, the SET specification ensures that transactions between customers, merchants and banks remain secure.
With SET-enabled software (Microsoft and Netscape are expected to release SET-enabled Web browsers) and an account with a financial institution which supports the system, you, the buyer, can go to any Web site, choose the products you want to purchase and order them with a few mouse clicks.
Within seconds, the order is processed, your own identity and account are verified and the transaction is complete. But what goes on behind the scenes is somewhat more complex:
The customer opens an account
Whether it's a checking or credit card account, or a different payment system such as DigiCash or First Virtual, it will be with a financial institution which supports electronic payments such as MasterCard or Visa.
Call it the bank.
The customer receives a certificate
When you open the account, you receive from the bank an electronic file called a certificate, which acts like a credit card for online purchases.
It contains information about you, including your public key. It has an expiry date and has been digitally signed by the bank to ensure its validity.
Merchants have their own certificates
Merchants doing business with the banks - including MasterCard and Visa - also get certificates which contain the merchant's public key and the bank's public key. Again, the certificate is signed by the bank to indicate the merchant is legitimate. The merchant's key will be used for the ordering process and the bank's key will be used for paying.
The customer places an order
Whether by email, through the Web page or via some other system, you tell the merchant which product or service you wish to purchase. This sets in motion a series of events which take just seconds to complete:
1. The merchant is verified First, your software receives a copy of the merchant's certificate and verifies you are dealing with a valid store.
2. The order and money are sent Your software sends the merchant three things, all of which you have signed - the order information, which is encrypted with the merchant's public key, the payment information, which is encrypted with the bank's public key (the merchant cannot see the payment information) and a message digest, a code containing both payment and order information, which ensures the payment is used only for that order.
3. The merchant receives the information On receipt of all the above details, the merchant checks your digital signature.
4. The customer is verified The merchant sends a signed message to the bank using the bank's public key. This message includes the customer's payment information (which the merchant can't see) and the merchant's certificate.
5. The bank checks the merchant and the message The bank opens the enclosed payment information from the customer and verifies it. It also checks the payment information is for that particular merchant and that particular order.
6. The payment is authorised The bank signs and encrypts an authorisation to the merchant, which can then ship the goods.
Relevant Web sites
Found by calculating the strength of the material deep inside the crust of neutron stars
Can highlight in real-time the relevant regions of an image being described
Double legal trouble for Musk as he also faces civil lawsuit over renewed British pot-holer 'paedo' claims
Battery development could help boost performance of smartphones