1 EEC 688/788 Secure and Dependable Computing Lecture 4 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University [email protected]

1

EEC 688/788EEC 688/788Secure and Dependable Secure and Dependable ComputingComputing

Lecture 4Lecture 4

Wenbing ZhaoWenbing ZhaoDepartment of Electrical and Computer EngineeringDepartment of Electrical and Computer Engineering

Cleveland State UniversityCleveland State University

[email protected]@ieee.org

04/20/23EEC688: Secure & Dependable

Computing 1

Outline Reminder:

Wed 6/3: Labs on secure shell and on secure computing in Java

Monday 6/8: Mid-term exam Authentication protocols Secure communication protocols

Application level protocols: SSH, Kerberos, PGP, S/MIME

Transport level protocols: SSL/TLS

Network level protocols: Ipsec (omitted)

304/20/2304/20/23 EEC688: Secure & Dependable ComputingEEC688: Secure & Dependable Computing Wenbing ZhaoWenbing Zhao

Authentication Using Authentication Using a Key Distribution Centera 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


Needham-Schroeder Needham-Schroeder Authentication ProtocolAuthentication 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


Needham-Schroeder Needham-Schroeder Authentication ProtocolAuthentication 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


Needham-Schroeder Needham-Schroeder Authentication ProtocolAuthentication 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


Authentication Using Authentication Using Public-Key CryptographyPublic-Key Cryptography

8

Authentication Using Authentication Using Public-Key CryptographyPublic-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 RA that she did not send and will not proceed further

Trudy cannot forge message 7 back to Bob because she does not know RB or KS and cannot determine them without Alice's private key

04/20/2304/20/23 EEC688: Secure & Dependable ComputingEEC688: Secure & Dependable Computing

04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable

ComputingComputing Wenbing ZhaoWenbing Zhao

SSH: Secure ShellSSH: Secure ShellSSH, the Secure Shell, 2nd Edition

By Daniel J. Barrett, Robert G. Byrnes, Richard E. Silvermanhttp://proquest.safaribooksonline.com/0596008953



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

securely Two versions: SSH1 and SSH2



Architecture of an SSH System Architecture of an SSH System



SSH Protocol SuiteSSH Protocol Suite

TCP

SSH Transport Protocol

Algorithm negotiationSession key exchange

Session idSever authentication

Privacy, integrity, data compression

SSH Authentication Protocol

Client authenticationpublickeypassword…

SSH Connection Protocol

Channel multiplexingPseudo-terminalsTCP port and X forwardingAuthentication agent forwarding

SSH File Transfer Protocol

Remote filesystem accessFile transfer

Application software (e.g., ssh, sshd, scp, sftp, sftp-server)



SSH Transport Layer SSH Transport Layer ProtocolProtocol

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



Binary Packet ProtocolBinary 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)

random padding

MAC

payload(may be

compressed)



Supported AlgorithmsSupported 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



SSH Key ExchangeSSH 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



SSH Key ExchangeSSH Key ExchangeClient

Generate x (1 < x < (p-1)/2) and compute e = gx mod p Compute:

f = gy mod p K = ey mod pH = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g ||e || f || K)

Verifies that KS really is host key

K = fx mod pH = hash(V_C || V_S || … ) and verifies the signature s on H

ServerI_C (KEXINIT)

p || g

e

KS || f || s

min || n || max

I_S (KEXINIT)V_S: Server’s version stringV_C: Client’s version string

s = signature on H with its private host key



SSH Key ExchangeSSH 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



SSH Key ExchangeSSH 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 Not so for SSH key exchange



SSH Key ExchangeSSH 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



Output from Key ExchangeOutput 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



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 server



SSH Authentication ProtocolSSH 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



SSH Authentication SSH Authentication ProtocolProtocol

Client

Userauth_request:username, service, “publickey", Public key alg namePublic key signature

signature is:session identifier, Userauth_request encrypted with private key

Server checks whether the supplied key is acceptable for authentication, and if so, it checks whether the signature is correct

ServerUserauth_request

Userauth_success or failure

request service if userauth_success



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

<=TCP connection setup

<= SSH version string exchange

<= start of key exchange



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

<= algorithm negotiation

<= DH key exchange

<= server authentication

<= end of key exchange



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

<= requesting an interactive session

<= client authentication(publickey)



SSH in Practice - Basic UseSSH 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



Securely Copying FilesSecurely 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



Securely Copying FilesSecurely 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



SSH Public Key Based SSH Public Key Based AuthenticationAuthentication 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



SSH Key CreationSSH 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?



Port Forwarding – Port Forwarding – Real Server On Remote Real Server On Remote MachineMachine 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



SSH Port ForwardingSSH Port Forwarding

Client Host

SSH Client

Client App

Server Host

SSH Server

Server App

Port 22 open

Port 8888

Port 6666

Client thinks the server is running at localhost and listening at port 6666

Clear msg

Encrypted msg



Port Forwarding – Port Forwarding – Real Server On This MachineReal 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



X Windows forwardingX 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



ssh-agentssh-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



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



Secure Sockets Layer Secure Sockets Layer DocumentationDocumentation 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



SSL: The Secure Sockets SSL: The Secure Sockets LayerLayer 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



SSL: The Secure Sockets SSL: The Secure Sockets LayerLayer 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



SSL: The Secure Sockets SSL: The Secure Sockets LayerLayer

TCP

SSL Record Layer Protocol

Application Data

SSL Handshake

Protocol

SSL Alert

Protocol

Application software

SSL Change Cipher

Spec Protocol



SSL HandshakeSSL Handshake ProtocolProtocol

ClientKeyEx




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




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




Message #5: ClientKeyExchange - RSA encrypted premaster secret message 48-byte long (version number and random bytes), encrypted

using server’s public key




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 verify messages (if any) The server sends one after successfully processing the key exchange

message it received from the client




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)




Message #7&9: Finished Sent immediately after a change cipher specs msg The finished message is the first protected with the just-

negotiated algorithms, keys, and secrets No acknowledgment of the finished message is required;

parties may begin sending confidential data immediately after sending the finished message



SSL HandshakeSSL Handshake Protocol Protocol OutputOutput

Pre-masterSecret

ClientRandom

ServerRandom

MasterSecret

Key Block

ClientMAC

ServerMAC

ClientWrite

ServerWrite

ClientIV

ServerIV



SSL HandshakeSSL Handshake Protocol Protocol OutputOutput

Master secret: computed based on the premaster secret and the nonces proposed by the client and the server

master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret +

ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('BB' + pre_master_secret +

ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('CCC' + pre_master_secret +

ClientHello.random + ServerHello.random));

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 HandshakeSSL Handshake Protocol Protocol OutputOutput To generate the key material, compute

key_block = MD5(master_secret + SHA('A' + master_secret +

ServerHello.random + ClientHello.random)) + MD5(master_secret + SHA('BB' + master_secret +

ServerHello.random + ClientHello.random)) + MD5(master_secret + SHA('CCC' + master_secret +

ServerHello.random + ClientHello.random)) + [...];

until enough output has been generated



SSL HandshakeSSL Handshake Protocol Protocol OutputOutput Then the key_block is partitioned as follows:

client_write_MAC_secret[CipherSpec.hash_size] server_write_MAC_secret[CipherSpec.hash_size] client_write_key[CipherSpec.key_material] server_write_key[CipherSPec.key_material] client_write_IV[CipherSpec.IV_size] /* non-export ciphers */ server_write_IV[CipherSpec.IV_size] /* non-export ciphers */



SSL Record ProtocolSSL Record Protocol

MAC = hash(MAC_write_secret + pad_2 + hash(MAC_write_secret + pad_1 + seq_num + length + content));

<= 16 KB each

Why?



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 Hearblead 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

Documents

1 EEC 688/788 Secure and Dependable Computing Lecture 4 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University [email protected]