1 / 58

EEC 688/788 Secure and Dependable Computing

EEC 688/788 Secure and Dependable Computing. Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University wenbing@ieee.org. Outline. Reminder: Lab on secure shell: this Wed Lab on secure computing in Java: next Monday Authentication protocols

epippen
Download Presentation

EEC 688/788 Secure and Dependable Computing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EEC 688/788Secure and Dependable Computing Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University wenbing@ieee.org

  2. Outline • Reminder: • Lab on secure shell: this Wed • Lab on secure computing in Java: next Monday • Authentication protocols • Needham-Schroeder protocol • Authentication using public-key cryptography • Secure communication protocols • SSH, SSL/TLS

  3. Authentication Using a Key Distribution Center Each user has a single key shared with the KDC. Authentication and session key management now goes through the KDC The following protocol is subject to replay attack EEC688: Secure & Dependable Computing

  4. Needham-Schroeder Authentication Protocol Needham-Schroeder protocol: a multi-way challenge-response protocol To eliminate the possibility of replay attacks, have each party both generate a challenge and respond to one 10/29/2019 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  5. Needham-Schroeder Authentication Protocol Message 1: RA is a nonce Message 2: KB(A, KS) is ticket Alice will send to Bob RA: so that message 2 is not a replay B: so that if Trudy replaces B with her id in message 1, it will be detected Ticket is encrypted using Bob’s key KB so that Trudy cannot replace it with something else on the way back to Alice 10/29/2019 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  6. Needham-Schroeder Authentication Protocol Message 3: a new nonce RA2 is used Message 4: Bob sends back KS(RA2-1) instead of KS(RA2) so that Trudy cannot steal KS(RA2) from message 3 and replay it here Message 5: to convince Bob he is talking to Alice and no replays are being used 10/29/2019 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  7. Authentication Using Public-Key Cryptography 10/29/2019 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  8. Authentication Using Public-Key Cryptography • What can Trudy do to try to subvert this protocol? • She can fabricate message 3 and trick Bob into probing Alice, but Alice (from message 6) will see an RAthat she did not send and will not proceed further • Trudy cannot forge message 7 back to Bob because she does not know RBor KSand cannot determine them without Alice's private key 10/29/2019 EEC688/788: Secure & Dependable Computing Wenbing Zhao

  9. Secure Communication Protocols Application level protocols: SSH, Kerberos, PGP, S/MIME Transport level protocols: SSL/TLS Network level protocols: IPsec EEC688/788: Secure & Dependable Computing

  10. SSH: Secure Shell EEC688/788: Secure & Dependable Computing

  11. Secure Shell Overview Secure Shell (SSH) is a secure remote virtual terminal application Provides encrypted communication between untrusted hosts over an insecure network Intended to replace insecure programs such as rlogin, rsh, etc. Includes capability to securely transfer file such as scp sftp Includes ability to forward X11 connections and TCP ports securely Two versions: SSH1 and SSH2 EEC688/788: Secure & Dependable Computing

  12. Architecture of an SSH System EEC688/788: Secure & Dependable Computing

  13. SSH Protocol Suite Application software (e.g., ssh, sshd, scp, sftp, sftp-server) SSH Authentication Protocol Client authentication publickey password … SSH Connection Protocol Channel multiplexing Pseudo-terminals TCP port and X forwarding Authentication agent forwarding SSH File Transfer Protocol Remote filesystem access File transfer SSH Transport Protocol Algorithm negotiation Session key exchange Session id Sever authentication Privacy, integrity, data compression TCP EEC688/788: Secure & Dependable Computing

  14. SSH Transport Layer Protocol Provides server authentication, confidentiality, and integrity services It may also provide compression Runs on top of any reliable transport layer (e.g., TCP) All packets that follow the version string exchange is sent using the Binary Packet Protocol Client Server TCP connection setup SSH version string exchange SSH key exchange (includes algorithm negotiation) SSH data exchange termination of the TCP connection EEC688/788: Secure & Dependable Computing

  15. Binary Packet Protocol packet length: length of the packet not including the MAC and the packet length field padding length: length of padding payload: might be compressed max uncompressed payload size is 32768 random padding: 4 – 255 bytes total length of packet not including the MAC must be multiple of max(8, cipher block size) MAC: message authentication code MAC(key, sequence_number || unencrypted_packet) packet length (4) padding length (1) payload (may be compressed) random padding MAC EEC688/788: Secure & Dependable Computing

  16. Supported Algorithms Encryption: 3DES, Blowfish, Twofish, AES, Serpent, IDEA, CAST in CBC Arcfour (“believed” to be compatible with the “unpublished” RC4) none (not recommended) Integrity: HMAC with MD5 or SHA-1, none (not recommended) Key exchange: Diffie-Hellman with SHA-1 Public key: RSA, DSS (digital signature standard) Compression: none, zlib EEC688/788: Secure & Dependable Computing

  17. SSH Key Exchange Diffie-Hellman public key exchange algorithm must be supported by all SSH2 implementation Public key exchange algorithm: provides a shared secret between two parties over an insecure link without sharing any prior secret SSH key exchange algorithm has two outputs: A shared secret K: can not be determined by either party alone An exchange hash H: It should be unique to each session, and computed in such a way that neither side can force a particular value of hash EEC688/788: Secure & Dependable Computing

  18. SSH Key Exchange Server Client I_C (KEXINIT) V_S: Server’s version string V_C: Client’s version string I_S (KEXINIT) Generate x (1 < x < (p-1)/2) and compute e = gx mod p min || n || max p || g Compute: f = gy mod p K = ey mod p H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g ||e || f || K) e Verifies that KS really is hostkey KS || f || s K =fx mod p H = hash(V_C || V_S || … ) and verifies the signature s on H s = signature on H with its private host key EEC688/788: Secure & Dependable Computing

  19. SSH Key Exchange min || n || max: (minimal acceptable, preferred, maximal acceptable) group size in bits the client will accept V_S: Server’s version string V_C: Client’s version string KS: Server’s public host key I_C: Client’s KEXINIT message I_S: Server’s KEXINIT message EEC688/788: Secure & Dependable Computing

  20. SSH Key Exchange Claim: SSH Key Exchange does not suffer from “man-in-the-middle” attack The goal of a “man in the middle” attack is to gain access to confidential information Naive key exchange suffers from this attack Intruder can establish secrete key with both Alice and Bob EEC688/788: Secure & Dependable Computing

  21. SSH Key Exchange Key exchange ends by each side sending an SSH_MSG_NEWKEYS message This message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms When this message is received, the new keys and algorithms MUST be taken into use for receiving EEC688/788: Secure & Dependable Computing

  22. Output from Key Exchange The key exchange produces two values: A shared secret K, and An exchange hash H Session identifier: the exchange hash H from the first key exchange Once computed, the session identifier is not changed, even if keys are later re-exchanged EEC688/788: Secure & Dependable Computing

  23. Output from Key Exchange Encryption keys are computed as HASH of a known value and K as follows: Initial IV client to server: HASH(K || H || "A" || session_id) Initial IV server to client: HASH(K || H || "B" || session_id) Encryption key client to server: HASH(K || H || "C" || session_id) Encryption key server to client: HASH(K || H || "D" || session_id) Integrity key client to server: HASH(K || H || "E" || session_id) Integrity key server to client: HASH(K || H || "F" || session_id) Recall the guideline for good authentication protocols? Different keys are used to encrypt traffic from different direction EEC688/788: Secure & Dependable Computing

  24. SSH Server Authentication Based on the server’s public host key KS The client must check that KS is really the host key of the server Client has a local database that associates each host name with the corresponding public host key The host name – key association can be certified by a trusted CA and the server provides the necessary certificates or the client obtains them from elsewhere Common practice Accept host key without check when connecting the first time to the server, and save the host key in the local database Check against the saved key on all future connections to the same server EEC688/788: Secure & Dependable Computing

  25. SSH Authentication Protocol The protocol assumes that the underlying transport protocol provides integrity and confidentiality (e.g., SSH Transport Layer Protocol) The protocol has access to the session ID Three authentication methods are supported publickey password hostbased EEC688/788: Secure & Dependable Computing

  26. SSH Authentication Protocol Server Client Userauth_request Userauth_request: username, service, “publickey", Public key alg name Public key signature signature is: session identifier, Userauth_request encrypted with private key Userauth_success or failure Server checks whether the supplied key is acceptable for authentication, and if so, it checks whether the signature is correct request service if userauth_success EEC688/788: Secure & Dependable Computing

  27. SSH Connection Protocol Multiplexes the secure tunnel provided by the SSH Transport Layer and User Authentication Protocols into several logical channels These logical channels can be used for a wide range of purposes Secure interactive shell sessions Remote execution of commands Forwarded TCP/IP connections Forwarded X11 connections EEC688/788: Secure & Dependable Computing

  28. A Debugging Run of SSH bash-3.00$ ssh -v -l wenbing dcs.csuohio.edu OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Connecting to dcs.csuohio.edu [137.148.142.70] port 22. debug1: Connection established. debug1: identity file /home/wenbing/.ssh/identity type -1 debug1: identity file /home/wenbing/.ssh/id_rsa type 1 debug1: identity file /home/wenbing/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.1 debug1: match: OpenSSH_4.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received <=TCP connection setup <= SSH version string exchange <= start of key exchange EEC688/788: Secure & Dependable Computing

  29. A Debugging Run of SSH debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'dcs.csuohio.edu' is known and matches the RSA host key. debug1: Found key in /home/wenbing/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received <= algorithm negotiation <= DH key exchange <= server authentication <= end of key exchange EEC688/788: Secure & Dependable Computing

  30. A Debugging Run of SSH debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/wenbing/.ssh/identity debug1: Offering public key: /home/wenbing/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. Last login: Fri Feb 3 02:00:36 2006 from adsl-67-39-192-13.dsl.bcvloh.ameritech.net Have a lot of fun... Directory: /home/wenbing <= client authentication (publickey) <= requesting an interactive session EEC688/788: Secure & Dependable Computing

  31. SSH in Practice - Basic Use ssh ssh_server_name ssh –l user_name ssh_server_name ssh ssh_server_name command_to_run ssh –v ssh_server_name EEC688/788: Secure & Dependable Computing

  32. Securely Copying Files scp scp localfile user@rhost:/remotepath/file Can use –r option to recursively copy entire directory Can use –p option to preserve modification and access time Prompts for authentication if needed All traffic encrypted: replaces ftp, rcp EEC688/788: Secure & Dependable Computing

  33. Securely Copying Files sftp: ftp on ssh Multiple commands for file copying and manipulation can be invoked within a single sftp session, whereas scp opens a new session each time it is invoked EEC688/788: Secure & Dependable Computing

  34. SSH Public Key Based Authentication Password-based authentication: password stored on server, user supplied password compared to stored version Public key based authentication: private key kept on client, public key stored on server If an attacker gets the public key stored on the server, that public key cannot be used to get back into the server EEC688/788: Secure & Dependable Computing

  35. SSH Key Creation General command: ssh-keygen –t rsa –b 1024 –f ~/.ssh/id_rsa Assign a hard-to-guess passphrase to the private key during creation Key can be used for multiple servers To install the public key on the server, transfer the key to the server (using scp or sftp) and add the key entry in the ~/.ssh/authorized_keys file From now on, if you want to connect to the server using ssh/scp/sftp, you will be prompted for the passphrase, instead of password What’s the benefit for using a passphrase w.r.t. password? EEC688/788: Secure & Dependable Computing

  36. Port Forwarding – Real Server On Remote Machine I want to listen on port 6666 on this machine; all packets arriving here get sent to proxyserver, port 8888: ssh –L 6666:proxyserver:8888 proxyserver Can be used to tunnel insecure services in a secure manner EEC688/788: Secure & Dependable Computing

  37. SSH Port Forwarding Client Host Server Host Client thinks the server is running at localhost and listening at port 6666 Client App Server App Port 8888 Clear msg Port 6666 SSH Server SSH Client Encrypted msg Port 22 open EEC688/788: Secure & Dependable Computing

  38. Port Forwarding – Real Server On This Machine All web traffic to my firewall should be redirected to the web server running on port 8000 on my machine instead: ssh –R 80:MyMachine:8080 firewall EEC688/788: Secure & Dependable Computing

  39. X Windows forwarding ssh –X ssh_server_name Note the uppercase X No need to manually setup the DISPLAY Run the X Windows application in the terminal window. For example, xclock & The screen display shows up on your computer, and any keystrokes and mouse movements are sent back, all encrypted EEC688/788: Secure & Dependable Computing

  40. ssh-agent Other applications can ask ssh-agent to authenticate you automatically Start ssh-agent shell: > ssh-agent bash Add your private key to the agent: > ssh-addYou will be prompt for the passphrase If you now ssh to another host, you will not prompt for passphrase until you remove the private key To remove your private key:> ssh-add –d To exit ssh-agent shell> exit EEC688/788: Secure & Dependable Computing

  41. SSL: The Secure Sockets Layer SSL (Secure Sockets Layer): a security package for secure communication over Internet Introduced in 1995, Netscape Communications Corp SSL builds a secure connection between two sockets, including Parameter negotiation between client and server Mutual authentication of client and server Secret communication Data integrity protection EEC688/788: Secure & Dependable Computing

  42. Secure Sockets Layer Documentation The SSL Protocol version 3.0 Internet Draft:http://home.netscape.com/eng/ssl3/ssl-toc.html The TLS Protocol version 1.0 Internet Draft: http://www.ietf.org/rfc/rfc2246.txt "HTTP Over TLS" Information RFC: http://www.ietf.org/rfc/rfc2818.txt SSL and TLS: Designing and Building Secure Systems by Eric Rescorla. Addison Wesley Professional, 2000 Analysis of the SSL 3.0 Protocol, by David Wagner and Bruce Schneier, http://www.schneier.com/paper-ssl-revised.pdf EEC688/788: Secure & Dependable Computing

  43. SSL: The Secure Sockets Layer HTTPS (Secure HTTP): HTTP over SSL Sometimes it is available at a new port (443) instead of the standard port (80) Layers (and protocols) for home user using HTTPS EEC688/788: Secure & Dependable Computing

  44. SSL: The Secure Sockets Layer SSL consists of two main subprotocols: handshake protocol record protocol SSL supports multiple cryptographic algorithms The strongest one uses triple DES with three separate keys for encryption and SHA-1 for message integrity For ordinary e-commerce applications, RC4 is used with a 128-bit key for encryption and MD5 is used for message authentication EEC688/788: Secure & Dependable Computing

  45. SSL: The Secure Sockets Layer Application software SSL Change Cipher Spec Protocol Application Data SSL Handshake Protocol SSL Alert Protocol SSL Record Layer Protocol TCP EEC688/788: Secure & Dependable Computing

  46. SSL HandshakeProtocol ClientKeyEx EEC688/788: Secure & Dependable Computing

  47. SSL HandshakeProtocol Message #1: Client hello SSL version; Random structure (timestamp and nonce); Session id; CipherSuites; Compression methods Message #2: Server hello SSL version*; Random structure (timestamp and nonce); Session id; CipherSuite*; Compression method* * selection based on client’s preference by the server EEC688/788: Secure & Dependable Computing

  48. SSL HandshakeProtocol Message #3: Server certificate (server key exchange message would be sent if there is no certificate) Message #4: Server hello done To indicate the end of the server hello and associated messages EEC688/788: Secure & Dependable Computing

  49. SSL HandshakeProtocol Message #5: ClientKeyExchange - RSA encrypted premaster secret message 48-byte long (version number and random bytes), encrypted using server’s public key EEC688/788: Secure & Dependable Computing

  50. SSL HandshakeProtocol Message #6&8: Change cipher spec Sent by both client and server to notify receiving party that subsequent records will be protected under the new CipherSpec and keys The client sends a change cipher spec message following handshake key exchange and certificate verifymessages (if any) The server sends one after successfully processing the key exchange message it received from the client EEC688/788: Secure & Dependable Computing

More Related