EEC 688/788 EEC 688/788 Secure and Dependable Secure and Dependable Computing Computing Lecture 5 Lecture 5 Wenbing Zhao Wenbing Zhao Department of Electrical and Computer Department of Electrical and Computer Engineering Engineering Cleveland State University Cleveland State University [email protected][email protected]
55
Embed
EEC 688/788 Secure and Dependable Computing Lecture 5 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University [email protected].
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
EEC 688/788EEC 688/788Secure and Dependable Secure and Dependable ComputingComputing
Lecture 5Lecture 5
Wenbing ZhaoWenbing ZhaoDepartment of Electrical and Computer EngineeringDepartment of Electrical and Computer Engineering
Cleveland State UniversityCleveland State University
Secure Shell OverviewSecure 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
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
Output from Key ExchangeOutput 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
SSH Server AuthenticationSSH 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
SSH Connection ProtocolSSH 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
A Debugging Run of SSHA 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
A Debugging Run of SSHA 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
A Debugging Run of SSHA 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
SSL: The Secure Sockets SSL: The Secure Sockets LayerLayer 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
The Change cipher spec message is an independent SSL Protocol content type, and is not actually an SSL handshake message This is designed as a performance improvement This message cannot be combined with the finished message
(change cipher spec is unencrypted [or encrypted using the previous session key] and the finished message is encrypted using the new session key)
Session keys, MAC secrets, and IVs: the master secret is used as an entropy source, and the random values provide unencrypted salt material and IVs for exportable ciphers
SSL and TLSSSL and TLS In 1996, Netscape Communications Corp. turned
SSL over to IETF for standardization. The result was TLS (Transport Layer Security) It is described in RFC 2246 The changes made to SSL were relatively small, but just
enough that SSL version 3 and TLS cannot interoperate The TLS version is also known as SSL version 3.1
OpenSSL Heartblead Bug(From: http://heartbleed.com/) The bug is reported in 2014. It exists in the popular
OpenSSL library The Heartbleed bug allows anyone on the Internet to
read the memory of the systems using the vulnerable versions of the OpenSSL
It compromises the private keys used for server’s X.509 certificates, user names and passwords, and the actual content communicated
Bug is in the OpenSSL's implementation of the TLS heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server
Recall that the following authentication protocol is vulnerable to the reflection attack. Make one change to the protocol so that it is no longer vulnerable to the reflection attack.
Considering the following way of producing a digital signature using message digests. If the one-way hash function used is not robust and one can easily find the collision on the hash. Which requirement (or requirements) of the digital signature would be violated?