c. ding - comp364 - l271 s/mime and ssh cunsheng ding hkust, hong kong, china
Post on 20-Dec-2015
220 views
TRANSCRIPT
C. Ding - COMP364 - L27 1
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 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 5
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 - 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, 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
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– 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
6.10.2003/Andreas SteffenNDS_CRM_Security_4
Modul 3Technologie – Überblick
Seite 5 E-Security und Datenschutz
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
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfH4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbTrfv=
--boundary1--
MIME entity to be signed
C. Ding - COMP364 - L27 42
6.10.2003/Andreas SteffenNDS_CRM_Security_4
Modul 3Technologie – Überblick
Seite 6 E-Security und Datenschutz
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
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfH4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbTrfv=
--boundary1--
C. Ding - COMP364 - L27 43
6.10.2003/Andreas SteffenNDS_CRM_Security_4
Modul 3Technologie – Überblick
Seite 8 E-Security und Datenschutz
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