Presentation is loading. Please wait.

Presentation is loading. Please wait.

ECE-6612 Prof. John A. Copeland 404 894-5177 fax 404 894-0035 Office: Klaus 3362.

Similar presentations


Presentation on theme: "ECE-6612 Prof. John A. Copeland 404 894-5177 fax 404 894-0035 Office: Klaus 3362."— Presentation transcript:

1 ECE-6612 http://www.csc.gatech.edu/copeland/jac/6612/ Prof. John A. Copeland john.copeland@ece.gatech.edu 404 894-5177 fax 404 894-0035 Office: Klaus 3362 email or call for office visit, 404 894-5177 Chapter 7a - Secure Socket Layer (SSL) and Secure Electronic Transactions (SET)

2 2 Application Transport Layer (TCP,UDP) Network Layer (IP) E'net Data Link Layer Ethernet Phys. Layer Network Layer E'net Data Link Layer E'net Phys. Layer Network Layer Process Router Buffers Packets that need to be forwarded (based on IP address). Application Transport Layer (TCP,UDP) Network Layer (IP) Token Ring Data-Link Layer Token Ring Phys. Layer Token Ring Data Link Layer Token Ring Phys. Layer IPsec SSL

3 TLS is Transport Layer Security (is not “ IPsec Transport Level Security ” ) TLS is used for email (SMTP/TLS or POP/TLS or IMAP/TLS) SSL is used for secure Web access (HTTPS) (now uses TLS v.3) Secure Shell, SSH, is Telnet + SSL + other features Secure Copy, SCP, copies files using SSH (SFTP has FTP functions) 3 The combinations are called: HTTPS SFTP ESMTP SSH SSL and TLS are above the TCP Socket, so it is part of the Application Layer (a “shim”)

4 HTTPS is HTTP with SSL (Secure Socket Layer). HTTPS uses the TLS/SSL default TCP port, port 443 4 Encrypt HTTPS :"Network Security Essentials: Applications and Standards," Prentice Hall, by Wm. Stallings (ECE6612) Web Browser or Web Server

5 Fig. 7.3 SSL Record Protocol Operation 5 Record Header

6 SSL Handshake - First Part Time Gray areas are optional in some circumstances. 6

7 SSL Handshake - Second Part Time Gray areas are optional in some circumstances. 7 Client Server

8 WireShark* View of HTTPS (TLS = SSL) Connection *Capture Filter: ether host 00:30:65:1e:8a:8c

9 NAME [from UNIX “ #man ssl ” ] SSL - OpenSSL SSL/TLS library DESCRIPTION The OpenSSL ssl library implements the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1.0, v1.1, v1.2) protocols. It provides a rich API which is documented here. [Only TLS v.1.2 is safe today] At first the library must be initialized; see SSL_library_init(3). [(3) ->use #man 3...] Then an SSL_CTX object is created as a framework to establish TLS/SSL enabled connections (see SSL_CTX_new(3)). Various options regarding certificates, algorithms etc. can be set in this object. When a network connection has been created, it can be assigned to an SSL object. After the SSL object has been created using SSL_new(3), SSL_set_fd(3) or SSL_set_bio(3) can be used to associate the network connection with the object. Then the TLS/SSL handshake is performed using SSL_accept(3) or SSL_con- nect(3) respectively. SSL_read(3) and SSL_write(3) are used to read and write data on the TLS/SSL connection. SSL_shutdown(3) can be used to shut down the TLS/SSL connection. Programming with SSL 9

10 10 SET (Secure Electronic Transactions) Provides a secure communications channel among all the parties involved in a transaction: Customer, Seller, Customer ’ s credit provider, Seller ’ s bank. Provides trust by the use of X.509v3 certificates. Ensures privacy because information is only made available to the parties that need it. * Cardholder account authentication to the Merchant (Cardholder must have a Certificate issued by the credit company). Merchant may issue a temporary Certificate to issue the session is not hijacked). * Verifies Merchant's relationship with financial institution. * Integrity of data customer sends to Merchant (order info tied to funds transfer).

11 11 SET - Steps in a Transaction 1. Customer opens account with credit company or bank. 2. Bank issues X.509 cert. to the Customer with RSA Keys. 3. Merchant has two certificates, signing and key exchange. ---- 4. Customer places an order. 5. The Merchant sends the customer a copy of his certificate. 6. The Customer sends Order Information (OI) encrypted so the Merchant can read it, and Payment Information (PI) encrypted so the Merchant can not read it. --- 7. Merchant requests payment by sending PI to the “ Payment Gateway ” (who can decrypt it) and verifies Customer ’ s credit. 8. Merchant confirms the order to the Customer. 9. Merchant ships goods to Customer. 10. Merchant sends request for payment to the Payment Gateway which handles transfer of funds.

12 12 Secure Electronic Transactions (SET)

13 13 SET - Dual Signature The Dual signature allows proof that: 1. Merchant has received Order Information. 2. Bank has received Payment Information and verified the Customer signature. 3. Customer has linked OI and PI and can prove later that PI was not related to a different purchase. Dual-Sig = E cus-private [ H( H(PI) || H(OI) ) ] Bob orders a book and a TV from Scam, Inc. Scam, Inc ships Bob the book, and then sends the PI for the TV joined with the OI for the book to the Bank. How does Bob prove to the Bank that he did not order a book with a TV price, when Scam, Inc shows the Bank the OI for the book?

14 14

15 Customer ’ s Purchase Request 15 Encrypted with Bank’s Public Key

16 16

17 Threats to the Net Host Control (botnets) All of the above, spamming, DDoS, … Anti-malware, out- and in- bound firewalls, network IDS. (incomplete, and always will be)


Download ppt "ECE-6612 Prof. John A. Copeland 404 894-5177 fax 404 894-0035 Office: Klaus 3362."

Similar presentations


Ads by Google