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