CP3397 ECommerce

Today’s Lecture Authentication using passwords SSL / TLS SET

Secure protocols used over the web Security can be applied at several layers of the TCP model and we look at these and see how they are especially used in web buying S/MIME PGP SET HTTP FTP SMTP TCP IP Secure email Pretty Good Privacy Secure transfer of data Application layer HTTP FTP SMTP TCP IP/IPSec HTTP FTP SMTP SSL/TSL TCP IP Network Layer Transport Layer

Overview of SLS/TLS Encryption Transport Secure Layer protocol 1.0 has grown out of the Secure Sockets layer protocol 3.1 SSL/TLS is primarily used to encrypt confidential data sent over an insecure network such as the Internet. In the HTTPS protocol, the types of data encrypted include the URL, the HTTP header, cookies, and data submitted through forms.

The SSL/TLS protocol can be divided into two layers. Handshake Protocol Layer - consists of three sub-protocols: the Handshake Protocol, the Change Cipher Spec Protocol, and the Alert protocol. Record Protocol Layer. Application Layer HTTP FTP Telnet etc Handshake Change cipher text Alert Handshake Layer SSL/TSL Record Record Layer Transport layer TCP/IP

The Handshake Layer consists of 3 sub-protocols: Handshake sub protocol - used to negotiate session information between the client and the server. The session information consists session ID; peer certificates, the cipher spec to be used, the compression algorithm to be used, and a shared secret that is used to generate keys. The Change Cipher Spec - used to change the keying material used for encryption between the client and server. Keying material is raw data that is used to create keys for cryptographic use.

The Change Cipher Spec sub-protocol consists of a single message to tell other party in the SSL/TLS session, who is also known is the peer, that the sender wants to change to a new set of keys. The key is computed from the information exchanged by the Handshake sub-protocol. Alert messages - used to indicate a change in status or an error condition to the peer. There are a wide variety of alerts to notify the peer of both normal and error conditions. See RFC 2246 . Alerts are commonly sent when the connection is closed, an invalid message is received, a message cannot be decrypted, or the user cancels the operation.

HTTPS Authentication For authentication purposes, the Handshake Protocol uses an X.509 certificate to provide strong evidence to a second party that helps prove the identity of the party that holds the certificate and the corresponding private key.

HTTPS Encryption SSL/TLS uses both symmetric key and asymmetric key encryption. Symmetric Key - often used for encrypting large amounts of data because it is computationally faster than asymmetric cryptography. Typical algorithms include DES (Data Encryption Standard), 3-DES (Triple DES), RC2, RC4, AES (Advanced Encryption Standard). Asymmetric encryption - most common algorithm is RSA (Rivest, Shamir & Adleman). SSL/TLS uses Asymmetric encryption to authenticate the server to the client, and optionally the client to the server. Asymmetric cryptography is also used to establish a session key. The session key is used in symmetric algorithms to encrypt the bulk of the data. This combines the benefit of asymmetric encryption for authentication with the faster, less processor-intensive symmetric key encryption for the bulk data.

Purchasing on the web The growth in web purchases makes this most common use of cryptography through digital signatures and encryption Data transmitted over web is insecure as it passes through many routers, links computers etc – encryption solves this Web store uses SSL – secure layer encrypts traffic between store and customer Has high overhead – so only credit card details and delivery info encrypted Most risk comes from an attack on the merchant and their database of credit card details

ECommerce authentication Thief poses as legit company web site Authentication solves this – trusted authorities (Verisign, Thawte) give public keys to your browser and sign the public keys of web stores Each vendor has public/private key pair – RSA key in SSL/TSL – signing authority signs these along with a digital certificate with the shops name and address Their key/certificate identifies them Your key identifies you with credit numbers from visit to visit

The encryption will ensure secure transmission of credit card details and authentication process. To authenticate the shopper – must set up an account with a username and password - hence future authentication can take place

Electronic transactions over the web Credit card purchases over the web are invariably performed using a protocol called SET Protocol designed for credit card transactions used by Mastercard and Visa – features Confidential Encryption of account and payment details across network Cardholders account and card number hidden from shop

SET Integrity Shopper authentication Shop authentication Based on digital signatures and details of message cannot be changed in transit Shopper authentication Shop can verify that the client has legitimate card and is based on X509 certificates Shop authentication Shopper can authenticate and verify the shop is authorised to accept credit cards – based on X509 certificates

Digital Certificates Extension of an individuals public key Has extra info that reinforces authenticity of key Verified by a trusted third party X509.3 are now the standard for device authentication and cornerstone of PKI It is a system that binds together identity with a public key

The structure of a X.509 v3 digital certificate is as follows: Version Serial Number Algorithm ID Issuer Validity Not Before Not After Subject Subject Public Key Info Public Key Algorithm Subject Public Key Issuer Unique Identifier (Optional) Subject Unique Identifier (Optional) Extensions (Optional) ... Certificate Signature Algorithm Certificate Signature Issuer and subject unique identifiers were introduced in Version 2, Extensions in Version 3.

What is the PKI? A system of managing certificates Consist of certificate authorities that issue certificates There is a hierarchy somewhat like DNS’s May be based on geography or because the system is flexible may fit to the companies business rules There is also Certificate Revocation List CRL used to notify when a certificate may become invalid i.e. a subjects private key becomes compromised Or some info in certificate changes i.e. issuers details change It is important that user checks with the CRL to ensure a certificate they have is valid – lots of issues with this

Verisign introduced the concept of three classes of digital certificates: Class 1 for individuals, intended for email; Class 2 for organizations, for which proof of identity is required; and Class 3 for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority (CA).

How it works The customer opens a Mastercard or Visa bank account. Any issuer of a credit card is some kind of bank. The customer receives a digital certificate. This electronic file functions as a credit card for online purchases or other transactions. It includes a public key with an expiration date. It has been digitally signed by the bank to ensure its validity. Third-party merchants also receive certificates from the bank. These certificates include the merchant's public key and the bank's public key. The customer places an order over a Web page, The customer's browser receives and confirms from the merchant's certificate that the merchant is valid.

The browser sends the order information The browser sends the order information. This message is encrypted with the merchant's public key, the payment information, which is encrypted with the bank's public key (which can't be read by the merchant), and information that ensures the payment can only be used with this particular order. The merchant verifies the customer by checking the digital signature on the customer's certificate. This may be done by referring the certificate to the bank or to a third-party verifier. The merchant sends the order message along to the bank. This includes the bank's public key, the customer's payment information (which the merchant can't decode), and the merchant's certificate.

The bank verifies the merchant and the message The bank verifies the merchant and the message. The bank uses the digital signature on the certificate with the message and verifies the payment part of the message. The bank digitally signs and sends authorization to the merchant, who can then fill the order.

SET Order Info + payment instruction Shopper Shop Ask and receive authorisation Authorisation System Submit Transaction for settlement Merchants Acquirer bank Shoppers Bank Settlement system

SET participants Customer Shop Acquirer Bank Authorisation system Owner of a payment card and wants to buy something Shop Sells products via web and has relationship with acquirer Acquirer Bank Maintains accounts for merchants Processes payment card authorisations and payments Transfers money to the merchant account Authorisation system Interface between the internet and existing bankcard payment system network for authorisation and payment functions