It is about the SET that how it was launched and what were the problems which it faced after launched and what was new after it as a solution of the problems as the security experts found.
6. Background
Alternative Shopping Method in 1996
Cryptography as a magic-pill
PKC (Public Key Cryptography)
Encryption
Digital Signature
Entity Authentication
7. SET ?
Invented by GTE, IBM, MasterCard, Microsoft, Netscape, SAIC, Terisa
Systems, VeriSign, and Visa.
Symmetric & Asymmetric Cryptography
3-DES & 1024-bit RSA
Fill security issues of SSL / TLS
Software and Hardware
Public Key Certificates
Digital Signatures
8. SET Participants
• Authorized holder of a payment card that
has been issued by an issuer.
Card Holder
• A person or organization with goods or
services to sell to the cardholder.
Merchant
• Financial institution that provides the
cardholder with the payment card.
Issuer
• Financial institution that establishes an account
with a merchant and processes payment card
authorizations and payments.
Acquirer
9. SET Participants
• Function interface between SET and the
existing bankcard payment networks or
authorization and payment functions.
Payment Gateway
• An entity that is trusted to issue X.509v3
public‐key certificates for cardholders,
merchants, and payment gateways.
Certificate
Authority
10. Important Features
• 3-DESConfidentiality
• RSA digital Signature, using SHA-1 hash
Code
Integrity
• X.509v3 digital certificates with RSA
signatures to legitimate the
Cardholder Account.
Cardholder
Authentication
• X.509v3 digital certificates with RSA
signatures to legitimate the Merchant
Account.
Merchant
Authentication
14. Mandatory Digital Certificates
CA issues Digital Certificates to
the Issuing Bank or ‘The Issuer’ (CERTISS = Sign(SKCA)[PKISS])
the Acquiring Bank or ‘The Acquirer’ (CERTACC = Sign(SKCA)[PKACC])
Customer gets its own Digital Certificate from the Issuing Bank
CERTCUS = Sign(SKISS)[PKCUS]
Merchant gets its own Digital Certificate from the Acquiring bank
CERTMER = Sign(SKISS)[PKMER]
15. Mandatory Digital Certificates Process
Asymmetric key pair for the customer must be generated.
E-consumer’s public key must be sent to the customer’s bank (‘the issuer’).
Generates a public key certificate for the customer using the issuer’s
private signature key.
System “root” public key along with customer’s public key.
Customer’s private key is saved to Digital Wallet with password protected.
16. Dual Signature
To link two messages that are going to different recipients.
Order Information (OI): Customer to Merchant
Payment Information (PI): Customer to Bank
The customer needs to send OI and PI to merchant and bank
respectively.
The merchant does not need to know the customers credit card
number.
The bank does not need to know what the customer is buying.
17. Dual Signature
The operation for dual signature is as follows:
Take the hash (SHA-1) of the payment and order information.
These two hash values are concatenated [H(PI) || H(OI)] and then the result is hashed.
Customer encrypts the final hash with a private key creating the dual signature.
DS = EKRC [ H(H(PI) || H(OI)) ]
18. DS Verification by Merchant
The merchant has the public key of the customer obtained from the
customer’s certificate.
Now, the merchant can compute two values:
H(PIMD || H(OI))
DKUC[DS]
Should be equal!
19. DS Verification by Bank
The bank is in possession of DS, PI, the message digest for OI (OIMD), and
the customer’s public key, then the bank can compute the following:
H(H(PI) || OIMD)
DKUC [ DS ]
20. Digital Wallet
For Customer’s self Authentication.
By Password
Private key is gotten
Transmits OI and PI
Encrypted with separate public keys to Merchant
Sign(SKCUS) {E(PKMER)[OI]|E(PKACC)[PI]}
Merchant sent it to
The issuing bank and the acquiring bank to verify
21. SET Process
The customer opens an account with a card issuer.
MasterCard, Visa, etc.
The customer receives a X.509 V3 certificate signed by a bank.
X.509 V3
A merchant who accepts a certain brand of card must possess two
X.509 V3 certificates.
One for signing & one for key exchange
The customer places an order for a product or service with a
merchant’s website.
The merchant sends a copy of its certificate for verification.
22. SET Process
The customer sends order and payment information to the merchant.
The merchant requests payment authorization from the payment gateway
prior to shipment.
The merchant confirms order to the customer.
The merchant provides the goods or service to the customer.
The merchant requests payment from the payment gateway.
24. Complexity of SET
“Magic Pill” became “Toxic Pill”.
PKI and registration process is a massive overhead (By Bellis).
PKI is not compatible with the infrastructure(1990s) because Merchants
can’t see Credit Card Numbers (By Treese and Stewart).
Overhead for obtaining the digital certificates and Special software must
be installed on both sides (C-M) and Private key is stored in Digital Wallet
with Password Protected but Password Protection on system is not secure
(By Lieb).
e-commerce transactions slow (By Whinnet)
Users sometimes interrupted the transactions.
25. ATTEMPTED SOLUTIONS TO SET
PROBLEMS
Included in SET
PIN
Chip
Server Based Digital Wallet
27. SET / EMV
PIN and Chip
To the secrecy of private keys
PIN extensions provided authentication process.
Magnetic Strips were replaced by IC Cards
Used without separate merchant terminals
No need to generate key pairs and certificates for consumers
Already in IC Cards
No longer Private Key in PC
IC Card
28. SET / EMV Problems
Required an additional
IC Card Reader with Consumer PC
Complex Cryptographic mechanisms
POS (Point of Sale) for Merchants to communicate
from Cardholder
With Payment Gateway (installed on acquiring bank’s servers)
29. 3-D SET
Server-based wallet extensions
based on three-domain (3D) architecture
Digital wallet software and the digital certificate on issuer’s server
Enabled the payment gateway and merchant certificates to be kept at an
acquirer server
3D SET was built upon the relationships between three ‘domains’ :
acquirer (the relationship between the merchant and the acquiring’s bank)
Issuer (the relationship between the cardholder/consumer and the issuer)
Interoperability (the acquirer and issuer domains are supported by the inter-
operability domain)
30. 3-D SET
Complex cryptographic mechanisms
Did not require an additional device
31. Conclusion
SET was not rejected if
It had the same architecture like 3-D SET
3-D SET was the new Design as a Magic Pill
32. References
[1] S. Farrell and M. Zolotarev, “XML and PKI-what’s the story?”
Network Security, vol. 2001, pp. 7-10, September 2001.
[2] F. Piper, “Some trends in research in cryptography and security
mechanisms,” Computers and Security, vol. 22, pp. 22-25, January
2003.
[3] L. Loeb, Secure Electronic Transactions: Introduction and Technical
Reference, Boston: Artech House, 1998.
[4] M. S. Merkow, J. Breithaupt, and K. L. Wheeler, Building SET
Applications for Secure Transactions, John Wiley and Sons, New York,
1998.
[5] Secure Electronic Transaction LLC (SETCo), SET Secure Electronic
Transaction Specification, version 1.0 ed., May 1997.
33. References
[6] K. Chen, H. Lee, and B. Mayer, “The impact of security control on
business-to-consumer electronic commerce,” Human Systems
Management, vol. 20, no. 2, pp. 139,147, 2001.
[7] D. Birch, “Secure electronic commerce – i: The certificate business
public key infrastructure will be big business,” Computer Law &
Security Review, vol. 13, no. 6, pp. 454-456, 1997.
[8] http://www.informit.com/articles/article.aspx?p=26857
[9] http://www.slideshare.net/HARRY-MEHTA/secure-electronics-transaction
[10] E. Bellis, Beautiful Security, ch. Beautiful Trade: Rethinking
E-Commerce Security, Sebastopol: O’Reilly, 2009.
34. References
[11] G. W. Treese and L. C. Stewart, Designing Systems for Internet
Commerce, Massachusetts: Addison-Wesley, 1998.
[12] J. Lieb, “Getting secure online-an overview,” Commerce Net-The
Strategies Report, vol. 1, pp. 1-4, July 1999.
[13] Ford and M. S. Baum, Secure Electronic Commerce, Prentice Hall,
2001.
[14] Secure Electronic Transaction LLC (SETCo), Common Chip Extension- Application for
SETCo Approval, version 1.0 ed., September 1999.
[15] Secure Electronic Transaction LLC (SETCo), Online PIN Extensions
to SET Secure Electronic Transaction, version 1.0 ed., May 1999.
35. References
[16] P. Jarupunphol and C. J. Mitchell, “Measuring SSL and SET against
e-commerce consumer requirements,” in Proceedings of the
International Network Conference (INC 2002), Plymouth University
Press, pp. 323-330, July 2002.
[17] P. Jarupunphol and C. J. Mitchell, “The future of SET,” in Proceedings of UKAIS 2002, Leeds
Metropolitan University, pp. 9-17, April 2002.
[18] IBM e-business, Internet Wallet Choices and Answers for Business and Technical Managers, 1999
[19] P. Jarupunphol, “A critical analysis of 3-D Secure,” in Proceedings of
the 3rd Electronic Commerce Research and Development (E-COM-03),
Gdansk, Poland, pp. 87-94, October 2003.
[20] R. Anderson, Security Engineering-A Guide to Building Dependable
Distributed Systems. John Wiley and Sons, 2001.
36. References
[21] K. Wrona, M. Schuba, and G. Zavagli, “Mobile payment- state of the art
and open problems,” in Proceedings of 2nd International Workshop
IACSIT International Journal ofEngineering and Technology, Vol. 5, No. 2,
April 2013 WELCOM(L. Fiege, G. Mühl, and U. G. Wilhelm, eds.), Lecture
Notes in Computer Science, Springer-Verlag, Berlin, vol. 2232, pp. 88-100,
2001.
[22] http://www.slideshare.net/Slyoldawg/jlfrank-sinatra
[23] Network Security Essentials: Applications and Standards By William
Stalling
Editor's Notes
A digital certificate is an electronic "passport" that allows a person, computer or organization to exchange information securely over the Internet using the public key infrastructure (PKI). A digital certificate may also be referred to as a public key certificate.
Just like a passport, a digital certificate provides identifying information, is forgery resistant and can be verified because it was issued by an official, trusted agency. The certificate contains the name of the certificate holder, a serial number, expiration dates, a copy of the certificate holder's public key (used for encrypting messages and digital signatures) and the digital signature of the certificate-issuing authority (CA) so that a recipient can verify that the certificate is real.
To provide evidence that a certificate is genuine and valid, it is digitally signed by a root certificate belonging to a trusted certificate authority. Operating systems and browsers maintain lists of trusted CA root certificates so they can easily verify certificates that the CAs have issued and signed. When PKI is deployed internally, digital certificates can be self-signed.
Digital Signature :
A digital signature (not to be confused with a digital certificate) is a mathematical technique used to validate the authenticity and integrity of a message, software or digital document.
DS = Hash + Asymmetric key
Digital signatures are based on public key cryptography, also known as asymmetric cryptography. Using a public key algorithm such as RSA, one can generate two keys that are mathematically linked: one private and one public. To create a digital signature, signing software (such as an email program) creates a one-way hash of the electronic data to be signed. The private key is then used to encrypt the hash. The encrypted hash -- along with other information, such as the hashing algorithm -- is the digital signature. The reason for encrypting the hash instead of the entire message or document is that a hash function can convert an arbitrary input into a fixed length value, which is usually much shorter. This saves time since hashing is much faster than signing.
The value of the hash is unique to the hashed data. Any change in the data, even changing or deleting a single character, results in a different value. This attribute enables others to validate the integrity of the data by using the signer's public key to decrypt the hash. If the decrypted hash matches a second computed hash of the same data, it proves that the data hasn't changed since it was signed. If the two hashes don't match, the data has either been tampered with in some way (integrity) or the signature was created with a private key that doesn't correspond to the public key presented by the signer (authentication).
A digital signature can be used with any kind of message -- whether it is encrypted or not -- simply so the receiver can be sure of the sender's identity and that the message arrived intact. Digital signatures make it difficult for the signer to deny having signed something (non-repudiation) -- assuming their private key has not been compromised -- as the digital signature is unique to both the document and the signer, and it binds them together. A digital certificate, an electronic document that contains the digital signature of the certificate-issuing authority, binds together a public key with an identity and can be used to verify a public key belongs to a particular person or entity.
Most modern email programs support the use of digital signatures and digital certificates, making it easy to sign any outgoing emails and validate digitally signed incoming messages. Digital signatures are also used extensively to provide proof of authenticity, data integrity and non-repudiation of communications and transactions conducted over the Internet.
PKI :
A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify the identity of the other party.
Without PKI, sensitive information can still be encrypted (ensuring confidentiality) and exchanged, but there would be no assurance of the identity (authentication) of the other party. Any form of sensitive data exchanged over the Internet is reliant on PKI for security.
A typical PKI consists of hardware, software, policies and standards to manage the creation, administration, distribution and revocation of keys and digital certificates. Digital certificates are at the heart of PKI as they affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate.
A typical PKI includes the following key elements:
A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities
A registration authority, often called a subordinate CA, certified by a root CA to issue certificates for specific uses permitted by the root
A certificate database, which stores certificate requests and issues and revokes certificates
A certificate store, which resides on a local computer as a place to store issued certificates and private keys
A CA issues digital certificates to entities and individuals after verifying their identity. It signs these certificates using its private key; its public key is made available to all interested parties in a self-signed CA certificate. CAs use this trusted root certificate to create a "chain of trust" -- many root certificates are embedded in Web browsers so they have built-in trust of those CAs. Web servers, email clients, smartphones and many other types of hardware and software also support PKI and contain trusted root certificates from the major CAs.
Along with an entity’s or individual’s public key, digital certificates contain information about the algorithm used to create the signature, the person or entity identified, the digital signature of the CA that verified the subject data and issued the certificate, the purpose of the public key encryption, signature and certificate signing, as well as a date range during which the certificate can be considered valid.