eec 688/788 secure and dependable computing

EEC 688/788EEC 688/788Secure and Dependable ComputingSecure and Dependable Computing

Lecture 8Lecture 8

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

Cleveland State UniversityCleveland State University

[email protected]@ieee.org

22

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

ComputingComputing Wenbing ZhaoWenbing Zhao

OutlineOutline

• Secure Shell

33



Secure Communication ProtocolsSecure Communication Protocols

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

• Transport level protocols: – SSL/TLS

• Network level protocols: – IPsec

44



SSH: Secure ShellSSH: Secure Shell

SSH, the Secure Shell, 2nd Edition

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

55



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

66



Architecture of an SSH System Architecture of an SSH System

77



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)

88



SSH Transport Layer ProtocolSSH 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

99



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)

1010



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

1111



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

1212



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

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

1313



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• K_S: Server’s public host key• I_C: Client’s KEXINIT message• I_S: Server’s KEXINIT message

1414



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

1515



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

1616



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

1717



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

1818



SSH Server AuthenticationSSH Server Authentication• Based on the server’s public host key K_S• The client must check that K_S 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

1919



SSH Server AuthenticationSSH Server Authentication

• Common practice – Accept host key without check when connecting the

first time to the server– Save the host key in the local database, and – Check against the saved key on all future connections

to the same server

2020



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

2121



SSH Authentication ProtocolSSH Authentication ProtocolClient

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

2222



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

2323



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

2424



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

2525



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)

2626



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

2727



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

2828



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

2929



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

3030



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?

3131



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

3232



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

3333



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

3434



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

3535



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

eec 688/788 secure and dependable computing

Documents

secure shellssh

dependable computing

com0596008953 eec688788

ssh system eec688788

bytestotal length of

packetpacket length

length of paddingpayload

smimetransport level