Welcome Guest. | Log In| Register | Membership Benefits

InformationWeek Labs

August 31, 1998


Security Standard For Credit-Card Transactions


By Jason Levitt

Related stories:
Security Standard For Credit-Card Transactions

Biometrics Is Poised For A Breakthrough

The IETF's X.509 Public Key Infrastructure Drafts

C redit-card transactions are the heart of many E-commerce sites, especially those that cater to online consumers, but the methods used to handle online credit-card transactions range from the home-brewed to sophisticated standards based on public-key cryptographic methods. The Secure Electronic Transaction specification, developed by Visa and MasterCard to secure credit-card transactions over public networks, is widely regarded as the front-runner in credit-card transaction systems, but acceptance has been slow.

SET was an important solution when version 1.0 was released in mid-1997.Now, although there is still a lot of interest in SET 1.0, relatively few sites are using it. Though all the major E-commerce solutions offer a SET 1.0 implementation in one form or another, problems with the implementations have kept sites from embracing it. "Market acceptance has been slower than expected," says Julie Fergerson, chief technology officer of ClearCommerce, "and we are concerned about potential interoperability problems."

Despite SET compliance testing by SET Secure Electronic Transaction LLC (www.setco.org), interoperability problems aren't unusual in a system as large and complex as the one described in the SET 1.0 specification. It mandates a custom message-passing protocol as well as a large amount of public-key cryptography. Resolution of digital certificates, for example, requires that a hierarchy of certificate authorities is in place. Authentication of a user requires an exchange of digital certificates and verification of public keys that progresses up a hierarchy of certificate authorities to the SET Root certificate authority, which is maintained by SET LLC. This method of authentication is known as trust chaining.

The complexity and bulk of the SET specification has also led to complaints that SET implementations are slow, a fact that doesn't sit well with E-commerce sites.

Despite the drawbacks, SET is a comprehensive solution. Win Treese, director of security for OpenMarket, whose Transact 4 product includes a SET implementation, points out that SET solves a difficult problem. "The hard part is all the exceptional cases in the credit-card transaction," he says. "If something goes wrong, you want to reverse the charges. None of this is rocket science, but you want to make sure your business records match the bank's record of the transaction."

Microsoft is currently building client-side SET extensions, using the Windows Crypto API and Certificate Store, for Microsoft Wallet 3.0, which is due for release later this year. Citing the readiness (or lack thereof) of certain market segments, Microsoft is not developing a SET implementation for Site Server Commerce Edition (though third parties sell SET implementations for Site Server).

On the Java front, the standard Java client API for SET is just now entering "early access" release as part of the Java Commerce extensions (java.sun.com/products/commerce) to the Java Wallet.

For now, most E-commerce sites are content to use homegrown systems for credit-card transactions rather than the one specified by SET. Integrating SET into existing E-commerce infrastructures will take time and a lot of work.

Return to The Keys To Security


Back to Labs

Send Us Your Feedback

Top of the Page