Presentation is loading. Please wait.

Presentation is loading. Please wait.

Cunsheng Ding HKUST, Hong Kong, CHINA

Similar presentations

Presentation on theme: "Cunsheng Ding HKUST, Hong Kong, CHINA"— Presentation transcript:

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

2 Secure MIME C. Ding - COMP364 - L27

3 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

4 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 systems. MIME is a very flexible format, permitting one to include virtually any type of file or document in an message. C. Ding - COMP364 - L27

5 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

6 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

7 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

8 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

9 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

10 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

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

12 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

13 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

14 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

15 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

16 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

17 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

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

19 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

20 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

21 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

22 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

23 SSH Transport Layer C. Ding - COMP364 - L27

24 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

25 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

26 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

27 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 ( )' 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

28 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

29 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

30 User Authentication Layer
C. Ding - COMP364 - L27

31 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

32 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

33 SSH Connection Layer C. Ding - COMP364 - L27

34 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

35 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

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

37 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

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

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

40 C. Ding - COMP364 - L27

41 C. Ding - COMP364 - L27

42 C. Ding - COMP364 - L27

43 C. Ding - COMP364 - L27

Download ppt "Cunsheng Ding HKUST, Hong Kong, CHINA"

Similar presentations

Ads by Google