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

C. Ding - COMP364 - L27 1

S/MIME and SSH

Cunsheng Ding HKUST, Hong Kong, CHINA


Secure MIME


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.


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.


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


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


A Very Simple MIME Message

From: Hodapp, PhilTo: McFadden, MarkSubject: Examples of MIME MessagesContent-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

MessageHeader

MessageBody


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


Major Content Types

• Text– 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 EncryptedMessage

Encryption

HashFunction

MessageDigest

SigningDigital

Signature

MessageHeader

MIME Part

MIME Part

MIME PartSecret key Encryption

Private key

Public key

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

• 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

The SSH Architecture

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 (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 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: http://www.ssh.com

C. Ding - COMP364 - L27 39

Appendix A

For S/MIME

C. Ding - COMP364 - L27 40

6.10.2003/Andreas SteffenNDS_CRM_Security_4

Modul 3Technologie – Überblick

Seite 4 E-Security und Datenschutz

ZürcherHochschuleWinterthurMIME – Multipurpose Internet Mail Extension

--boundary1Content-Type: text/plain; charset=us-ascii

Dear Neo, please study the attached Word document.

--boundary1Content-Type: application/msword; name="Matrix.doc"Content-Transfer-Encoding: base64

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfH4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbTrfv=

--boundary1--

From: [email protected]: [email protected]: 1.0Content-Type: multipart/mixed; boundary=boundary1

C. Ding - COMP364 - L27 41




ZürcherHochschuleWinterthurS/MIME – Signed Message Format I

Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary1

--boundary1Content-Type: text/plain

This is a clear-signed message.

--boundary1Content-Type: application/pkcs7-signature; name=smime.p7sContent-Transfer-Encoding: base64Content-Disposition: attachment; filename=smime.p7s


--boundary1--

MIME entity to be signed

C. Ding - COMP364 - L27 42




ZürcherHochschuleWinterthurS/MIME – Signed Message comprising

Multiple Attachments

Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary1

--boundary1Content-Type: multipart/mixed; boundary=boundary2

... multipart message with various MIME-types ...

--boundary1Content-Type: application/pkcs7-signature; name=smime.p7sContent-Transfer-Encoding: base64Content-Disposition: attachment; filename=smime.p7s


--boundary1--

C. Ding - COMP364 - L27 43




ZürcherHochschuleWinterthurEncrypted Message with Multiple Recipients

Envelope using Symmetric Encryption

MIME Entity (single-part or multi-part)MIME Entity (single-part or multi-part)

RandomKey

RandomKey Symmetric Encryption AlgorithmSymmetric Encryption Algorithm

Encrypted MIME EntityEncrypted MIME Entity

EncryptedKey #n

EncryptedKey #n

Public Key#n

Public Key#n

EncryptedKey #2

EncryptedKey #2

Public Key#2

Public Key#2

EncryptedKey #1

EncryptedKey #1

Public Key#1

Public Key#1

Documents

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