Cunsheng Ding HKUST, Hong Kong, CHINA S/MIME and SSH Cunsheng Ding HKUST, Hong Kong, CHINA C. Ding - COMP364 - L27

Secure MIME C. Ding - COMP364 - L27

Simple Mail Transfer Protocol (SMTP) Documented in RFC 821. Internet's standard host-to-host mail transport protocol and traditionally operates over TCP, port 25. SMTP uses a style of asymmetric request-response protocol popular in the early 1980s, and still seen occasionally, most often in mail protocols. SMTP is limited to text with hard line breaks. C. Ding - COMP364 - L27

MIME Multipurpose Internet Mail Extensions (MIME) is an official Internet standard that specifies how messages must be formatted so that they can be exchanged between different email systems. MIME is a very flexible format, permitting one to include virtually any type of file or document in an email message. C. Ding - COMP364 - L27

MIME MIME uses these RFC 822 headers Allows you to send Content-Type Content-Transfer-Encoding Allows you to send formatted text non-English character sets images, sounds, video and HTML C. Ding - COMP364 - L27

MIME Entities Basic unit of any MIME message Content-Type defines the type of object being sent allows for multi-part messages Transfer-Encoding allows non-ASCII data to be set through mail especially for image objects C. Ding - COMP364 - L27

A Very Simple MIME Message From: Hodapp, Phil To: McFadden, Mark Subject: Examples of MIME Messages Content-Type: text/plain Would you kindly make an effort to insure that your explanations are in English and not in that other language you occasionally drift into? Many Thanks. -Phil Message Header Message Body C. Ding - COMP364 - L27

Typical MIME Content Types text text/plain text/richtext message message/rfc822 image image/jpeg image/gif video video/mpeg application application/postscript application/octet-stream multipart multipart/mixed multipart/alternative C. Ding - COMP364 - L27

Major Content Types Text Image Audio Video Message Multipart legible text Image pictures and graphics Audio sound Video moving pictures Message messages or pieces of messages Multipart several different kinds of data in a single message Application “everything else” C. Ding - COMP364 - L27

What’s S/MIME Secure MIME A way to send and receive secure MIME data Based on MIME Very likely an Internet standard C. Ding - COMP364 - L27

Services Provided by S/MIME Authentication Message Integrity Non-repudiation of origin data confidentiality C. Ding - COMP364 - L27

How Does S/MIME Work? Uses encryption both symmetric and public key strategies Symmetric key is transmitted with the message Shared secret is encoded using public key of the recipient Uses digital signatures to protect against tampering and forgery C. Ding - COMP364 - L27

S/MIME Overview Message Public key Header MIME Part Secret key Encryption MIME Part Secret key Message Encryption Encrypted Message MIME Part Hash Function Private key Message Digest Signing Digital Signature MIME Part C. Ding - COMP364 - L27

Managing S/MIME Keys Keys for S/MIME require a PKI or directory service Applications using S/MIME can use a directory, key server or CA to get the public key of a recipient Recipients use the same mechanisms C. Ding - COMP364 - L27

S/MIME in the Marketplace Interoperability problems S/MIME is widely supported (Outlook, Outlook Express, Navigator, Eudora) Standardization is helping Continued dependence on effective public key infrastructure S/MIME is designed to use X.509 certificates C. Ding - COMP364 - L27

S/MIME Versions Version 2 Version 3 widely implemented but limited 40-bit keys (the RC2 algorithm) RSA-patented symmetric algorithms Version 3 currently in IETF draft uses Diffie-Hellman instead of RSA technology support for strong encryption C. Ding - COMP364 - L27

In Summary S/MIME is simply secure messaging using MIME formats Uses both public key and symmetric encryption Interoperability is still a problem Dependent upon certificate management C. Ding - COMP364 - L27

The Secure Shell (SSH) C. Ding - COMP364 - L27

Risks in Existing Access Mechanisms Authentication based on IP address Authentication based on reusable passwords Data travels in the clear format X protocols vulnerable to attack Intermediate hosts can hijack sessions C. Ding - COMP364 - L27

The Secure Shell Protocol SSH provides secure replacements for rsh, rlogin, rcp, ftp, and telnet, all of which transmit data over the network as clear text The SSH protocol was developed in 1995 to address the various security issues associated with the "r-commands" Developed by Tatu Ylönen, a researcher at the Helsinki University of Technology Motivated by a password-sniffing attack on the university network C. Ding - COMP364 - L27

The SSH Architecture SSH protocol is based on a client/server architecture A user who wants to connect to a remote host will execute the ssh command (the client) on his local machine It will connect to the remote computer's ssh daemon (the server) There are two primary versions of the SSH protocol SSH-1 SSH-2 C. Ding - COMP364 - L27

SSH Protocol – details The following layers (protocols) exist: Transport layer (over TCP/IP or other): Server authentication, data confidentiality, data integrity, compression (optional) User authentication layer Connection layer multiplexes the secure tunnel provided by the Transport layer and user authentication layer into several logical channels. These logical channels can be used for a wide range of purposes: secure interactive shell sessions, TCP port forwarding, carrying X11 connections C. Ding - COMP364 - L27

SSH Transport Layer C. Ding - COMP364 - L27

SSH Transport layer Works over TCP/IP or other reliable protocol Initiated by the client Initialization Sides exchange a message in the form “SSH-protoversion-softwareversion comments” “protoversion” determines what version of the protocol will be used. We will concentrate on version 2.0 C. Ding - COMP364 - L27

SSH Transport layer Negotiation of the encryption and hash algorithms and compression Data flow directions client->server and server->client are independent, may use different algorithms (i.e. 3DES+SHA1 and Blowfish+MD5) If compression is enabled, the data is first compressed and only then encrypted Exchange lists of supported algorithms C. Ding - COMP364 - L27

Transport Layer: key exchange In particular, server gives the list of available host key algorithms: Diffie-Hellman, RSA etc. There are certain issues with DH, so RSA is recommended Determine an algorithm/key acceptable for both parties – first algo listed by each side is regarded as the preferred by it The actual key exchange C. Ding - COMP364 - L27

Key Exchange (cont.) A server may include a digital certificate, signed by a CA that is known to the client Client may have a public key of the server (based on server’s host name) In neither case – what do we do? The authenticity of host ‘gw (10.0.0.10)' can't be established. RSA key fingerprint is 81:f5:da:26:77:31:fc:51:64:3f:97:ec:d7:e9:97:ab. Are you sure you want to continue connecting (yes/no)? C. Ding - COMP364 - L27

Key exchange (cont.) Key exchange gives a shared secret K, and a hash H (also serves as session id at the start) from which we compute: Server IV and client IV (for CBC encrypt.) Encryption keys C->S and S->C Signature (integrity) keys C->S and S->C From here on every message exchanged should be encrypted/signed by an appropriate key (MAC signatures) C. Ding - COMP364 - L27

Key Exchange (done) After the key exchange: client requests a service; server satisfies it or rejects. Services are defined as higher-level protocols on top of transport layer: User authentication protocol Connection protocol File transfer and so on C. Ding - COMP364 - L27

User Authentication Layer C. Ding - COMP364 - L27

User Authentication Layer Runs atop of transport layer Relies on data privacy and integrity, provided by the transport layer Service ID: “ssh-userauth” Has access to the shared secret session id from transport layer Many authentication methods are available and they are negotiated C. Ding - COMP364 - L27

Authentication Layer (cont.) Client requests service “ssh-userauth” Server responds with the list of available authentication methods. More than one authentication may be required Methods: Public key Password hostbased C. Ding - COMP364 - L27

SSH Connection Layer C. Ding - COMP364 - L27

SSH Connection Layer Runs over the transport layer, utilizes the authentication layer Multiplexes the encrypted tunnel provided by the transport layer into several logical channels Provides Interactive sessions Remote command execution X11 forwarding TCP/IP port forwarding C. Ding - COMP364 - L27

SSH Connection Layer (cont.) Channels – can be opened by either side To open a new channel Allocate a channel number Send a request to the other side, giving channel type The other side either rejects or accepts and returns its channel number Therefore a channel is identified by two numbers C. Ding - COMP364 - L27

File Transfer Protocol (sftp) C. Ding - COMP364 - L27

File Transfer Protocol (sftp) Runs on top of Connection Layer Provides file transfer Provides general file system access Driven by commands similar to FTP C. Ding - COMP364 - L27

Implementations For Unix: open source (utilize OpenSSL) and commercial For Windows: servers commercial, clients: both A free Windows client: http://www.ssh.com C. Ding - COMP364 - L27

Appendix A For S/MIME C. Ding - COMP364 - L27

C. Ding - COMP364 - L27

C. Ding - COMP364 - L27

C. Ding - COMP364 - L27

C. Ding - COMP364 - L27