The lack of reasonable security infrastructure has prevent banking card institutions to develop and broaden their business for Electronic Commerce. To solve this problem Visa and Mastercard in February 1996 published a protocol and specification for open networks to protect payment card purchases. In this presentation announced SET (Secure Electronic Transaction) protocol and some of its fundamental specifications are briefly presented.
There is no doubt that electronic commerce together with the huge growth of the Internet will soon change the infrastructure of the whole financial service industry. It is anticipated that approximately 30 million daily users of the Internet will within two years grow to 90 million daily users [1] . Insurance, home banking and bill payment (e.g. Kultaraha-home banking of OKOBANK group [2]), brokerage etc. in the Internet are having a real business value for the financial institutions. There are lots of totally new products and services available for the on-line consumers and at the same time the security problems seems to be solved.
One of the recent achievement of secure networking in electronic commerce is the announcement of Secure Electronic Transaction (SET) specification. "SET is an open specification for protecting payment card purchases on any type of network"[3].
SET protocol was mainly developed by Visa [4] and Mastercard [5] but assistant work was also given by GTE [6], IBM [7], Microsoft [8], Netscape [9], SAIC [10], Terisa [11] and Verisign [12]. GTE is one of the largest publicly held telecommunications companies in the world, the largest U.S.-based local telephone company and a leader in government and defense communications systems and equipment [13]. "Science Applications International Corporation (SAIC) is the largest employee-owned research and engineering company in the United States" [10]. Terisa Systems is privately hold company and its mission is to create the technologies that make secure Internet commerce possible [11]. Verisign was founded 1995 as a spin-off of RSA Data Security [14] and it is the leading provider of digital authentication services and products for electronic commerce and other forms of secure communications [12]. Other companies mentioned reader should be familiar with.
Though SET protocol is very new many companies are planning to use this protocol in their commercial products. One example of these companies is Netscape and the product called LivePayment [15]. "The LivePayment system provides a convenient, simple, low cost solution for developers who want to create a Web site that executes financial transactions over the Internet, using high-grade encryption technology"[15]. Also American Express [16] has announced to support the SET [17].
SET has not been developed by IETF but some 800 million card users obviously push SET as a de-facto standard of electronic commerce [18].
The development of SET is mainly driven by banking card companies. There are several obvious reasons for this [1]: Banking card companies see the electronic commerce as potential competitor for their current business. They want to protect their ready business infrastructure, the integrity of banking card brands and want to preserve the relationships between their current counterparts (i.e. between merchants and acquirers and between cardholders and card issuers). Finally banking card companies want to avoid the extra future costs by making the adequate specification for electronic commerce by themselves.
SET protocol is thoroughly presented in the three books: Business Description [1], Programmer's Guide [19] and Formal Protocol Definition [20]. The most useful information for this coarse seminar presentation can be found in the first book mentioned. For the sake of clarity, explicit references are not always provided in the text.
In addition to objectives mentioned earlier, SET should be efficient and easy to implement and has minimal impacts on the merchant, acquirer and payment system infrastructure. From the TCP/IP-protocol stack point of view SET-protocol resides above HTTP-, FTP- and SMTP-protocol and is at the same level as PGP encryption protocol [21].
There are numerous business and technical objectives with SET. Many
of them are closely related to security aspects.
| SET | PGP | |
| HTTP | FTP | SMTP |
| TCP | ||
| IP |
Picture 1. SET Protocol in the TCP/IP protocol stack
Confidentiality: In electronic commerce the payment information
must be safe and confidential and accessible only by the intended recipients.
SET guarantees confidentiality by the use of message encryption.
Integrity: Integrity of data means that messages between different parties cannot be changed without been discovered. SET ensures the data integrity by the use of digital signatures.
Cardholder Authentication: There must be the mechanism for the merchant to ensure that a cardholder is a legitimate user of certain valid payment card account number. In SET cardholder account authentication is implemented by the use of digital signatures and cardholder certificates.
Merchant authentication: Also cardholders have to be confirmed that an identified merchant has a relationship with a financial institution allowing it to accept payment cards. Merchant authentication and identification are ensured by the use of digital signatures and merchant certificates.
Interoperability: SET protocol must be applicable on a variety of hardware and software platforms and any transport security implementation must not prevent SET to be used. Interoperability is ensured by the use of specific protocols and message formats.
Non-repudiation: "SET doesn't provide non-repudiation" [19].
In the following picture [22] all the different participants of the SET specification are introduced.
Picture 2. Participants of SET
There are different roles in the SET process and these roles may differ from nation to nation. A financial institution can also adopt many simultaneous roles in this chain of SET counterparts.
Cardholder is an authorized holder of a payment card supported and issued by an issuer. Cardholder uses a payment card to perform electronic commerce. SET ensures that the interactions the cardholder has with a merchant keep the payment card account information confidential.
The card issuer is the financial institution (e.g. Luottokunta in Finland) that establishes an account for a cardholder and issues the payment card. The issuer guarantees payment for authorized transactions using the payment card in accordance with payment card brand (e.g. VISA) rules.
A merchant offers goods or services for sale and accepts payments to be done electronically with card. Merchant that accepts payment cards must have a relationship with an acquirer.
An acquirer is the financial institution that establishes an account with a merchant and processes payment card authorizations and payments.
A payment gateway is a device operated by an acquirer or a designated third party that processes merchant payment messages.
Financial institutions have founded bankcard associations that protect and advertise the brand, establish and enforce rules for use and acceptance of their bankcards, and provide networks to interconnect the financial institutions. The brands combine the roles of Issuer and Acquirer in interactions with cardholders and merchants.
Certification authority (CA) is an agent of one or more payment card brands that provides for the creation and distribution of electronic certificates for cardholders, merchants and payment gateways. A CA digitally signed certificate ensures that a certain public key belongs to a certain claimed person or institution.
Below the variation of electronic shopping is briefly presented:
In the picture below [1] some SET relevant cryptographic issues are introduced. Numbers in the text refer numbers in the picture.
Alice's Computer Bob's Computer
Picture 3. Some SET relevant cryptographic terms
At first (1) Alice runs hashing algorithm against her property and produces a 160 bit unique value called Message Digest. This message digest is then (2) encrypted with sender's private signature key and the results is called Digital Signature.
This digital signature, property and copy of Alice's certificate (that contains Alice's public signature key) is then (3) encrypted with secret symmetric key generated by Alice.
This symmetric key is then (4) encrypted with Bob's public key-exchange key producing Digital Envelope. Bob's public key was included in Bob's certificate that was safely introduced to Alice somehow.
Finally (5) the message, that contains digital envelope and encrypted message, is transferred to Bob.
When Bob receives the message (6) the digital envelope is decrypted with Bob's Private Key-exchange key producing plain symmetric key generated by Alice. With this key encrypted message is decrypted (7) and original property, its digital signature and Alice's certificate are now available.
Obtained digital signature is then decrypted (8) with Alice's public signature key that produces original message digest.
Bob then (9) generates message digest from Alice's property and compares this digests.
Dual Signatures are used to link two messages that are sent to the different recipients: Message digest is produced for both of these messages, these digests are concatenated and the message digest of the result is computed. This final digest is then encrypted with sender's private signature key. Sender then includes the message digest of the other message and the "dual" digest so the recipient can verify the dual signature. The recipient generates the message digest of the message as usually, concatenates this with the digest supplied by sender, computes the message digest of the result and compares that with the received "dual" digest.
This dual signature is applied in Purchase request, Payment authorization and Payment capture messages that are introduced later.
SET uses RSA encryption algorithm for Digital signature and digital envelopes with common key size of 1024 bits. Signatures are based on the PKCS#7 RSA with SHA-1 algorithm. The default symmetric key algorithm used in SET is DES with effective key length of 56 bits. Another symmetric algorithm in SET is CDMF that is primarily used for tunneling acquirer-to-cardholder information through the merchant. SET uses X.509 version 3 certificates for PK signature and encryption [19].
Before recipients can use asymmetric cryptography, recipients must be authenticated. This authentication is done by Certificate Authorities (CA) through use of certificates. Certificates are means to thrustworthly connect public keys to their legal owners. SET certificates are verified through a hierarchy chain of trust. "Each certificate is linked to the signature certificate of the entity that digitally signed it.[1]" Certificates are valid only certain period of time. Because Certificates are large data structures a thumbprint mechanism is used for efficiency. "A thumbprint is a hash of certificate, CRL (Certificate Revocation List), or BCI (Brand CRL Identifier)" [19].
SET recipients have two key pairs (key-exchange keys and signature keys) and two certificates.
In the picture 4 the illustrative CA chain is presented. In this picture cardholder signature certificate is verified by the card issuer. Merchant signature and merchant key exchange certificates are linked back to the acquirer certificate. Issuer and acquirer certificates can be verified by (an optional) geo-political signature and further by association signature. Association signature can be verified by public key signature key of the root that is known to all SET software. Root signature is verified by root itself. All CA certificates are verified by traversing the trust chain to the root.
In Finland concrete CA infrastructure has not been created yet and there are still many possibilities how for example Visa / Luottokunta will implement this hierarchy and different roles of SET [23].
Picture 4. The chain of certificates
Cardholder certificates are issued to the cardholder upon approval of the cardholder's issuing financial institution. This certificate is transferred to merchants that can be sure that the account number has been approved by a card issuer. "In these specifications, cardholder certificates are optional at the payment card brand's discretion" [1].
"Merchant certificates are approved by the acquiring financial institution and provide assurance that the merchant holds a valid agreement with an acquirer." [1]
A merchant must have at least merchant signature and merchant key exchange certificates for each payment card brand that it accepts.
Luottokunta in Finland could for example be the CA for a merchant.
"Payment gateway certificates are obtained by acquirers or their processors for the system that process authorization and capture messages. The gateway's encryption key, which the cardholder gets from this certificate, is used to protect the cardholder's account information." [1]
"Payment gateway certificates are issued to the acquirer by the payment brand." [1]
"An Acquirer must have certificates in order to operate a Certificate Authority that can accept and process certificate request directly from merchants. Acquirers receive their certificates from the payment card brand." [1]
"An issuer must have certificates in order to operate a Certificate Authority that can accept and process certificate request directly from cardholders. "[1]
Issuers receive their certificates from the payment card brand.
In SET specification the following transactions are included:
In this presentation only five of the topmost transactions are covered, some of them however very roughly.
A merchant registration is a process between merchant's computer and CA's computer. The overview of this process is described below.
If cardholder has only e-mail like (e.g. SMTP) communication method it is still possible to do registration. This means that End Entity (EE, here cardholder) has registration form and CA certificate to encrypt Certification Request (CertReq). Cardholder registration needs two messages shown below. In this example it assumed that Certification Response (CertRes) message doesn't include secret information from cardholder, so only signature is needed. Otherwise the message back to the cardholder is encrypted [19].
CARDHOLDER CA
e.g.
ACQUIRER
<---SET----------->
-
- - - -NOT SET - -
1)--CertReq EncX{C,CA,{LID_EE,Chall_EE3,RegForm,[CaBackKeyData],PK_S},[AccInfo]}--->
2)<-CertRes <S(CA,{LID_EE,Chall_EE3,CertStatusCode, [EEMessage},[CertThumbs]})--------
The parameters are:
CA asks financial institution (e.g. acquirer) whether CertReq can be accepted or not. This method, however, doesn't belong to SET.
The most interesting issue for the individual card user is the purchasing
process. This process consists of a purchase request, a payment authorization
and a payment capture. These processes are presented below [1].
CARDHOLDER MERCHANT PAYMENT GATEWAY
<------->
<------->
CARDHOLDER:
MERCHANT:
CARDHOLDER:
MERCHANT:
CARDHOLDER:
Payment authorization was initialized by purchase request process described before. Payment authorization is accomplished between merchant and payment gateway. Process is presented below with details.
MERCHANT:
PAYMENT GATEWAY:
MERCHANT:
After perhaps a long time Merchant wants the payment. Merchant generates and digitally signs a capture request, which includes the final amount of transaction , its id etc. This along with the encrypted capture token mentioned above is then transferred to the payment gateway. Gateway decrypts symmetric key#4 with its own private key-exchange key and decrypts the capture token using the symmetric key #4. After this gateway ensures that there is the consistency between merchant capture request and the capture token. Gateway sends capture request through a financial network to cardholder's financial institution. Acquirer does the payment for Merchant.
In October 21 1996 [24] Visa EU board of directors announced the pilot for Secure Electronic Commerce (SEC) [3]. "SEC is Visa s programme for the implementation of the Secure Electronic Transaction (SET) specification, which enables payment card transactions to be made securely over open networks using encryption technology. The pilot will involve 38 Visa members in 16 European countries." [24]. It is planned that some banks are able to offer SET based service in six months. "Full commercial roll-out of the scheme is expected to begin following completion of the pilots in late 1997 or early 1998 [24]".There is also one bank in Singapore that starts SET-protocol in 1Q/97.
Visa is also participating a project called E2S (End-to-End Security over Internet) developed by ESPRIT ( European Strategic Programme of Research and Development in Information Technology). In this project it is examined how Internet could be utilized by companies that want to make business over this unsecure network [24].
It is obvious that SET protocol will evolve a "quite" error-free protocol with these pilot participants and Visa puts lots of efforts to push this specification as standard protocol as soon as possible. And it will apparently manage to do this. However, it will take years to broaden this new infrastructure over current Visa merchants and cardholders. This evolution will require investments for all SET participants and that amount of money will affect the pace. It seems obvious that SET capable browsers are not free in the future [18].
The security with default DES -algorithm with key size of 56 bits (or 40) is not perhaps good enough but there are certain US government rules that restrict to use more powerful key lengths. RSA with key size of 1024 bits or 2048 bits seems better. The infrastructure of CA's must also be solved somehow nation by nation bases.
There is also concerns about viruses in SET: "Because it's software, it's still virus sensitive" [ 25].
Electronic commerce is well suitable for selling and buying none material products like software in the whole world but if one buys goods there must be also a good and cheap delivery system for those goods to customers. For many families the shopping together is a social happening and a way to spend free time. And that cannot be replaced by "surfing" together over continents. There will still be room for conventional shopping.
[1] Secure Electronic Transaction (SET) Specification Book 1: Business Description, DRAFT for testing June 17, 1996
[2] OKOBANK-group Kultaraha -homebanking system
[3] Electronic Commerce at VISA home Page
[4] Visa Homepage
[5] MasterCard Homepage
[6] GTE CyberTrust Home Homepage
[7] IBM Homepage
[8] Microsoft Homepage
[9] Netscape Homepage
[10] SAIC Homepage
[11] Terisa Systems Homepage
[12] Verisign Homepage
[13] GTE at a glance via GTE Home Page
[14] RSA Home Page
[15] White Paper of Netscape's LivePayment product
[16] American Express Homepage
[17] Visa And MasterCard welcome American Express, press release Feb 29,1996
[18] Oksala, Pekka Maksutekniikka Oy. Maksaminen tietoverkoissa, Väliraportti 2.4.1996
[19] Secure Electronic Transaction (SET) Specification Book 2 :Programmer's Guide, DRAFT for testing, June 21,1996
[20] Secure Electronic Transaction (SET) Specification Book 3: Formal Protocol Definition, DRAFT for testing, June 24, 1996
[21] Geer Daniel, Rochlis Jon. 6th USENIX Security Symposium, July 22-25, 1996, Fairmont Hotel, San Jose, California
[22] Unidentified author. Presentation foils of SET Open Vendor Meeting (SETVPRES, PFD format) on August 29, 1996 in Foster City, CA
[23] Laitinen Ilkka Luottokunta. Discussions on 5.11.1996
[24] Visa launches Secure Electronic Commerce in Europe, Press Release, October 22, 1996
[25] The Forrester Report, Money & Technology, vol 2 # 2 October 1996, Forrester Research