Secure Electronic Transactions (SET) is an open protocol which has the potential to emerge as a dominant force in the securing of electronic transactions. Jointly developed by Visa and MasterCard, in conjunction with leading computer vendors such as IBM, SET is an open standard for protecting the privacy, and ensuring the authenticity, of electronic transactions.
This is critical to the success of electronic commerce over the Internet; without privacy, consumer protection cannot be guaranteed, and without authentication, neither the merchant nor the consumer can be sure that valid transactions are being made. Technology Secure Electronic Transactions (SET) relies on the science of cryptography – the art of encoding and decoding messages. Cryptography dates back many centuries – even in the time of Julius Caesar, encryption was used to preserve the secrecy of messages.
Preserving the secrecy of transactions is no different, though stronger encryption algorithms are used, as well as significantly stronger encryption keys. Encryption advancements have come about through its application by the military, and by advances in computing power and mathematics. The SET protocol relies on two different encryption mechanisms, as well as an authentication mechanism. SET uses symmetric encryption, in the form of the aging Data Encryption Standard (DES), as well as asymmetric, or public-key, encryption to transmit session keys for DES transactions (IBM, 1998).
Rather than offer the security and protection afforded by public-key cryptography, SET simply uses session keys (56 bits) which are transmitted asymmetrically – the remainder of the transaction uses symmetric encryption in the form of DES. This has disturbing connotations for a “secure” electronic transaction protocol – because public key cryptography is only used only to encrypt DES keys and for authentication, and not for the main body of the transaction.
The computational cost of asymmetric encryption is cited as reason for using weak 56 bit DES (IBM, 1998), however other reasons such as export/import restrictions, and the perceived need by law enforcement and government agencies to access the plain-text of encrypted SET messages may also play a role. Overview of symmetric and asymmetric cryptography Modern cryptography uses encryption keys, which can encode (lock) and decode (unlock) messages when an encryption algorithm is used. Symmetric encryption works by using a single key, which must be known by all parties wishing to unlock the message.
Figure 1. 0 – Symmetric encryption with a single key If we apply a specific key to a message, using a good encryption algorithm, then it will be unreadable by unauthorized parties. If we then apply the same key to the encrypted message, then the message will be restored to its original form. However, this presents a problem, because we must find a secure means of transmitting the key to all parties. Asymmetric encryption, also known as public-key encryption, frees us from this limitation. Asymmetric algorithms use two keys – a public and a private key.
These keys are completely independent – a private key cannot be easily deduced from a public one. When we sign a message using someone’s public key, only the holder of the private key can read it. We can place our public key out in the open, and rest assured that only the private key holder can read messages encrypted for him or her. Figure 2. 0 – Asymmetric encryption with a public and a private key Symmetric and Asymmetric encryption in SET In the SET protocol, two different encryption algorithms are used – DES and RSA. The DES algorithm has been used since the 1970’s.
It is believed by some that the National Security Agency (NSA) of America played “an invisible hand in the development of the algorithm” (Schneier, 1996), and that they were responsible for reducing its key size from the original 128-bits to 56. DES quickly became a federal standard in 1976, and has been used ever since. In the SET protocol, a DES 56-bit key is used to encrypt transactions. This level of encryption, using DES, can be easily cracked using modern hardware. In 1993, a brute-force DES cracking machine was designed by Michael Wiener – one which was massively parallel.
For less than a million dollars (well within the budget of many large companies), a 56-bit DES key could be cracked in average time of 3. 5 hours. For a billion dollars, which might be considered small change for a military or security organisation such as the NSA or a foreign power, a parallel machine can be constructed that cracks 56-bit DES in a second (Schneier, 1996). Clearly, this is of great concern, since DES encrypts the majority of a SET transaction. As the power of computers grows, and the cost diminishes, such code-crackers may become more and more common.
One may wonder why such crippled cryptography would be used in a “secure” transaction protocol. One possible reason may be that the organizations involved recognise the desire by government organizations (both foreign and domestic to the US) to observe and monitor financial transactions conducted over the Internet. “Governments tend to look favorably upon SET based cryptography” (IBM, 1998), and the prospect that any government with enough resources to build a code cracker could have access to people’s financial transactions is disturbing.
While many people believe that it is legitimate for a government to observe the financial transactions of its citizens, it is unthinkable that a “secure” protocol would allow those same transactions to be observed by foreign, and possibly hostile, governments. Transaction Authenticity Authentication is an important issue for users of electronic commerce. Consumers must have faith in the authenticity of the merchant, and merchants must have faith in the authenticity of the consumer. Without authentication, any individual could pose as a merchant, and besmirch a merchant’s good name by failing to deliver goods and billing up credit card bills.
Without authentication, any individual could pose as a consumer, ordering costly goods to an abandoned house or apartment, and defrauding the merchant. Without authentication, an individual could pose as a willing buyer, accept the goods, and then repudiate the transaction. Authentication is critical to achieving trust in electronic commerce. Authentication is achieved through the use of digital signatures. Using a hashing algorithm, SET can sign a transaction using the sender’s private key. This produces a small message digest, which is a series of values that sign” a message. By comparing the transaction message and the message digest, along with the sender’s public key, the authenticity of the transaction can be verified. Digital signatures are aimed at achieving the same level of trust as a written signature has in real life. This helps achieve non-repudiation, as the consumer cannot later establish that the message wasn’t sent using his private key1. Importance of secure transactions Secure electronic transactions will be an important part of electronic commerce in the future.
Without such security, the interests of the merchant, the consumer, and the credit or economic institution cannot be served. Privacy of transactions, and authentication of all parties, is important for achieving the level of trust that will allow such transactions to flourish. However, it is important that the encryption algorithms and key-sizes used, will be robust enough to prevent observation by hostile entities (either criminal or foreign powers). The ideal of the secure electronic transactions protocol (SET) is important for the success of electronic commerce.
However, it remains to be seen whether the protocol will be widely used because of the weakness of the encryption that it uses. SECURE SOCKET LAYER SSL (Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral. SSL is an industry standard and is used by millions of websites in the protection of their online transactions with their customers. To be able to create an SSL connection a web server requires an SSL Certificate.
When you choose to activate SSL on your web server you will be prompted to complete a number of questions about the identity of your website and your company. Your web server then creates two cryptographic keys – a Private Key and a Public Key. The Public Key does not need to be secret and is placed into a Certificate Signing Request (CSR) – a data file also containing your details. You should then submit the CSR. During the SSL Certificate application process, the Certification Authority will validate your details and issue an SSL Certificate containing your details and allowing you to use SSL.
Your web server will match your issued SSL Certificate to your Private Key. Your web server will then be able to establish an encrypted link between the website and your customer’s web browser. The complexities of the SSL protocol remain invisible to your customers. Instead their browsers provide them with a key indicator to let them know they are currently protected by an SSL encrypted session – the lock icon in the lower right-hand corner, clicking on the lock icon displays your SSL Certificate and the details about it. All SSL Certificates are issued to either companies or legally accountable individuals.
Typically an SSL Certificate will contain your domain name, your company name, your address, your city, your state and your country. It will also contain the expiration date of the Certificate and details of the Certification Authority responsible for the issuance of the Certificate. When a browser connects to a secure site it will retrieve the site’s SSL Certificate and check that it has not expired, it has been issued by a Certification Authority the browser trusts, and that it is being used by the website for which it has been issued.
If it fails on any one of these checks the browser will display a warning to the end user letting them know that the site is not secured by SSL.
References IBM Corporation. An overview of the IBM SET and the IBM CommercePoint Products, http://www. software. ibm. com/commerce/set/overview. html, June 1998 IBM Corporation. Cryptography and SET : What’s under the hood? , http://www. software. ibm. com/commerce/payment/part2. html, June 1998 Schneier, Bruce. Applied Cryptography, John Wiley ; Sons, Canada 1996 http://info. ssl. com/article. aspx? id=10241