New standards for ensuring safe payment card transmissions across the Internet.
Early last year, Visa and MasterCard joined forces to develop a single standard to secure payment card transactions over insecure networks. They released the first draft of the standards last summer, and since then they have been working feverishly to educate potential users and software developers. The final version of the specification came out May 31, and Secure Electronic Transactions (SET)-compliant applications should appear by the end of the year. Other major card brands, including American Express and NOVUS (Discover), have also endorsed the SET standard.
SET's goals are to provide confidentiality, authentication, and integrity of payment card transmissions. To do this, SET uses a variety of cryptographic techniques, including encryption, digital signatures, and certificates.
To help maintain security, cardholder certificates contain a one-way hashed value of the card number, expiration date, and a secret value generated by the cardholder's software. The information cannot be recovered directly from the certificate, but the cardholder can prove the certificate is his or hers by providing account information. For most cardholders, their certificate authority will be the same company that issues their card. How a certificate authority verifies the identity of the certificate holder is outside the scope of the standard, but the process is likely to be similar to opening an account at a bank.
The developers of the SET standard are aware that most cardholders don't know, or care, about certificates right now, and educating them and building the infrastructure to issue and maintain large numbers of certificates takes time. As a result, they have allowed "interim" implementations to temporarily forgo issuing cardholder certificates (all other certificates are required). In this case, messages back to the cardholder (order status, for example) are not encrypted, but the integrity of messages from the cardholder is still ensured by the use of a message digest.
Let's say you've decided what you want to buy, your software has completed the round of certificate exchanges successfully, and now you're ready to send your purchase on its way. From the certificate exchange, you have the merchant's public key, the payment processor's key, and a unique transaction identifier issued by the merchant. How does SET deliver your purchase securely?
First, you create the necessary order information (OI) and payment instructions (PI). Both include the merchant-assigned transaction identifier. Next, you apply a one-way hashing function to make digests of both the order information and payment instructions. Then you create a "dual signature." This allows both the merchant and payment processor to independently verify that your payment instructions and order information belong together without requiring either processor to see the other's data. SET's dual signature is a digest of the concatenation of the OI and PI message digests, encrypted with your private key. For better encryption/decryption performance, you select a random symmetric key and encrypt the payment instructions with it; and, finally, you encrypt the random symmetric key and your account number with the payment processor's public key. When you're done, you have a message containing:
What did you think of this article? Send a letter to the editor.