SMIME and SSH Cunsheng Ding HKUST Hong Kong

S/MIME and SSH Cunsheng Ding HKUST, Hong Kong, CHINA C. Ding - COMP 364 - L 27 1

Secure MIME C. Ding - COMP 364 - L 27 2

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 requestresponse protocol popular in the early 1980 s, and still seen occasionally, most often in mail protocols. • SMTP is limited to text with hard line breaks. C. Ding - COMP 364 - L 27 3

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 - COMP 364 - L 27 4

MIME • MIME uses these RFC 822 headers – Content-Type – Content-Transfer-Encoding • Allows you to send – formatted text – non-English character sets – images, sounds, video and HTML C. Ding - COMP 364 - L 27 5

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 - COMP 364 - L 27 6

A Very Simple MIME Message From: Hodapp, Phil To: Mc. Fadden, Mark Subject: Examples of MIME Messages Content-Type: text/plain Message Header 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. Message Body -Phil C. Ding - COMP 364 - L 27 7

Typical MIME Content Types • text • video – text/plain – text/richtext • message – video/mpeg • application – message/rfc 822 • image – image/jpeg – image/gif – application/postscript – application/octetstream • multipart – multipart/mixed – multipart/alternative C. Ding - COMP 364 - L 27 8

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

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 - COMP 364 - L 27 10

Services Provided by S/MIME • • Authentication Message Integrity Non-repudiation of origin data confidentiality C. Ding - COMP 364 - L 27 11

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 - COMP 364 - L 27 12

S/MIME Overview Secret key Message Encryption Hash Function Private key Message Digest Signing Public key Message Header Encryption MIME Part Encrypted Message MIME Part Digital Signature MIME Part C. Ding - COMP 364 - L 27 13

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 - COMP 364 - L 27 14

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 - COMP 364 - L 27 15

S/MIME Versions • Version 2 – widely implemented but limited • 40 -bit keys (the RC 2 algorithm) • RSA-patented symmetric algorithms • Version 3 – currently in IETF draft • uses Diffie-Hellman instead of RSA technology • support for strong encryption C. Ding - COMP 364 - L 27 16

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 - COMP 364 - L 27 17

The Secure Shell (SSH) C. Ding - COMP 364 - L 27 18

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 - COMP 364 - L 27 19

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 "rcommands" • 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 - COMP 364 - L 27 20

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 - COMP 364 - L 27 21

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 X 11 connections C. Ding - COMP 364 - L 27 22

SSH Transport Layer C. Ding - COMP 364 - L 27 23

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 - COMP 364 - L 27 24

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. 3 DES+SHA 1 and Blowfish+MD 5) • If compression is enabled, the data is first compressed and only then encrypted • Exchange lists of supported algorithms C. Ding - COMP 364 - L 27 25

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 - COMP 364 - L 27 26

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: f 5: da: 26: 77: 31: fc: 51: 64: 3 f: 97: ec: d 7: e 9: 97: ab. Are you sure you want to continue connecting (yes/no)? C. Ding - COMP 364 - L 27 27

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 - COMP 364 - L 27 28

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 - COMP 364 - L 27 29

User Authentication Layer C. Ding - COMP 364 - L 27 30

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 - COMP 364 - L 27 31

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 - COMP 364 - L 27 32

SSH Connection Layer C. Ding - COMP 364 - L 27 33

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 X 11 forwarding TCP/IP port forwarding C. Ding - COMP 364 - L 27 34

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 - COMP 364 - L 27 35

File Transfer Protocol (sftp) C. Ding - COMP 364 - L 27 36

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 - COMP 364 - L 27 37

Implementations • For Unix: open source (utilize Open. SSL) and commercial • For Windows: servers commercial, clients: both • A free Windows client: http: //www. ssh. com C. Ding - COMP 364 - L 27 38

Appendix A For S/MIME C. Ding - COMP 364 - L 27 39

C. Ding - COMP 364 - L 27 40

C. Ding - COMP 364 - L 27 41

C. Ding - COMP 364 - L 27 42

C. Ding - COMP 364 - L 27 43