S/MIME

sunflowerplateΤεχνίτη Νοημοσύνη και Ρομποτική

21 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

124 εμφανίσεις


S/MIME

S/MIME
-

Overview


After the development of PEM industry working group led by RSA
Security, Inc. started to develop another specification for conveying
digitally signed and/or encrypted and digitally enveloped data in
accordance to the MIME message formats.



S/MIME (
Secure/Multipurpose Internet Mail Extension
) is a
security enhancement to the MIME Internet e
-
mail format standard.



S/MIME is
not restricted to mail
; it can be used with any transport
mechanism that transports MIME data, such as HTTP.



S/MIME is
likely to emerge as the industry standard

for
commercial and organizational use, while PGP will remain the
choice for personal e
-
mail security for many.



S/MIME
-

Overview


S/MIME provides the following cryptography security services:


Authentication.


Message Integrity. By using digital signing


Non
-
repudiation of origin.


Privacy and data security. By using encryption



There are three versions of S/MIME:


S/MIME version
1 (1995)
-

was specified and officially published in 1995 by
RSA Security, Inc.



S/MIME version
2 (1998)
-

was specified in a pair of informational RFC
documents
-

RFC 2311 and RFC 2312
-

in March1998.



The work was continued in the IETF S/MIME Mail Security (SMIME) WG
and resulted in S/MIME

version
3
(1999)

specified in RFCs 2630 to
2634 in June 1999.


MIME
-

Overview


RFC 822 defines a format for text messages that are sent
using electronic mail.


SMTP/RFC822 scheme limitations:

1.
SMTP
cannot transmit executable

files or other binary files.

2.
SMTP
cannot transmit text data that includes national language

characters because these are represented by 8
-
bit codes with
values of 128 decimal or higher, and SMTP is limited to 7
-
bit
ASCII.

3.
SMTP
servers may reject mail message over a certain size.

4.
SMTP gateways that translate between ASCII to EBCDIC suffer
translation problems.

5.
Some SMTP
implementations do not adhere completely to the
SMTP standard

defined in RFC 822.


MIME (contd.)


MIME specification includes the following elements:

1.
Five new message header fields. These fields provide information about
the body of the message.

2.
A number of content formats are defined, thus standardizing
representations that supports multimedia e
-
mail.

3.
Transfer encodings are defined that enable that protect any content
format to be altered by the mail system.



MIME
provides
a standardized way of dealing with a wide variety of
information

representations in a multimedia environment
.





MIME (contd.)

Here is a summary of the different MIME content types:


Type


Subtype


Description


Text


Plain

Enriched


Unformatted text (ASCII or ISO
8859
).

Provides greater format flexibility.


Multipart


Mixed





Parallel

Alternative



Digest


The different parts are independent but are to be
transmitted together. Should be presented to the
receiver in their original order.

Differs from mixed only in that no order is defined.

The different parts are alternative versions of the
same information.

Similar to Mixed but the default type/subtype of
each part is message/rfc
822
.


Message


rfc822



Partial



External body


The body is itself an encapsulated message that
conforms to RFC
822
.

Used to allow fragmentation in a transparent way to
the recipient.

Contains a pointer to an object exists else where.


MIME (contd.)

Type


Subtype


Description


Image


Jpeg

gif


The image is in JPEG format.

The image is in GIF format.


Video


Mpeg


MPEG format.


Audio


Basic


Single
-
channel
8
-
bit ISDN mu
-
law encoding at a
sample rate of
8
kHz


Application


Postscript

Octet
-
stream


Adobe Postscirpt.

General binary data consisting of
8
-
bit bytes.


MIME (contd.)


The other major component of MIME is a definition of
transfer encodings for message contents:

Encoding


Description


7
bit


The data are all represented by short lines of ASCII
chars.


8bit


The lines are short, but there may be non
-
ASCII chars.


Binary


Not only may non
-
ASCII chars be presented but lines
are not necessarily short enough for SMTP transport.


Quoted
-
printable


Encodes the data in such a way that if the data being
encoded are mostly ASCII text, the encoded form of
the data remains largely recognizable by humans.


Base
64


Encodes data by mapping
6
-
bit blocks to
8
-
bit printable
ASCII characters blocks.


x
-
token


A nonstandard encoding.


MIME (contd.)


Canonical form is a format that is standardized for
use between systems.



Conclusions:


MIME is a necessity in today

s Internet and e
-
mail traffic
requirements
.



The

Object Oriented


structure of the MIME message enhances its
capability to serve as multipurpose standard.



The MIME is capable of transferring data between two distinct
systems which uses different formats



S/MIME
-

Functions



S/MIME is based on the Cryptographic Message Syntax


(CMS) specified in RFC
2630
.


Enveloped data:



This consists of
encrypted content

of any type and
encrypted content
encryption keys

for one or more
users. This functions provides privacy and data security.



Signed data:



A digital signature is formed by
signing the message
digest and then encrypting that with the signer private
key
. The content and the signature are then encoded
using base
64
encoding.


This function provides authenticity, message integrity
and non
-
repudiation of origin.



SignerInfo:

allows the inclusion of unsigned and
signed attributes to be included along with a
signature.


signingTime


sMIMECapabilities


sMIMEEncryptionKeyPreference

S/MIME
-

Functions

S/MIME
-

Functions


Clear signed data:



In this case a digital signature of the content is formed,
However only the signature is encoded with base64.



Signed and enveloped data:



Because of S/MIME encapsulating capability (multipart
type), signed only and encrypted only entities may be
nested, so that encrypted data may be signed and
signed data may be encrypted.

S/MIME
-

Cryptography

Definitions:


MUST
:

The definition is an absolute requirement of the
specification.


SHOULD
:

There may exist valid reasons in particular
circumstances to ignore this feature or function, but it is
recommended that an implementation include the feature or
function.



Be liberal in what you receive and
conservative in what you send.

S/MIME
-

Cryptography


Used Algorithms:


Function


Requirement


Creation of a
message digest.


MUST

support SHA
-
1.
SHOULD

use sha
-
1.

Receiving agents
SHOULD

support MD5 for
the purpose of providing backward
compatibility with S/MIME v2.


A message digest
encryption to form a
digital signature.


Both sending and receiving agents
MUST

support
DSS
.

Receiving agents
SHOULD

support
verification of RSA signatures with key sizes
512
bits to
1024
bits. Note that S/MIME v
2
clients are only capable of verifying digital
signatures using RSA.



S/MIME
-

Cryptography

Function


Requirement


A session key encryption
for transmission with the
message.


Both sending and receiving agents
MUST

support Diffie
-
Hellman.

Sending agents
SHOULD

support RSA
encryption with key sizes
512
to
1024
bits.

Receiving agents
SHOULD

support RSA
decryption.

A message Encryption
for transmission with
one
-
time session key.


Sending an receiving agent MUST support
Encryption/Decryption with 3DES.

Receiving agents
SHOULD

support
decryption with RC2/40.

(S/MIME V 2.
-

Sending agents
SHOULD

support RSA encryption with 3DES

and RC2/40. Receiving agents
MUST

support decryption with RC2/40.)




S/MIME
-

Cryptography

Algorithm use decision procedure:




Preferred decrypting capabilities:

SHOULD choose the first
(highest preference) capability on the list.



No list of capabilities but has received message/s:



SHOULD use the same encryption algorithm as was used on the last
signed and encrypted message.



No knowledge & Willing to risk:


willing to risk that the recipient may not be able to decrypt the
message, then the sending agent SHOULD use
3
DES.



No knowledge & Not willing to risk:


sending agent MUST use RC
2
/
40
.








A possible problem:


A multiple recipients message
:



Performance



Security



The Solution:


This problem is solved using an Enhanced Security service
called S/MIME Mail List Agent (MLA).


An MLA perform the recipient
-
specific encryption for each
recipient, and forward the message.




S/MIME
-

Cryptography

S/MIME
-

Message

MIME bodies + CMS.




Algorithm
Identifiers

Canonical
MIME

Certificates

CMS

CMS object

MIME

Encoding + Canonical form

S/MIME
-

Message


S/MIME makes use of a number of new MIME content types:


Description

S/MIME
parameter

Subtype

Type

A clear message in tow

parts:

One is the message and

the other is the signature.

Signed

Multipart

A signed S/MIE entity.


An encrypted S/MIME entity.


multipart/signed message.


A certificate registration

request message.

signedData


envelopedData


--


--

pkcs7
-
mime


pkcs7
-
mime


Pkcs7
-
signature


pkcs10
-
mime

Application

S/MIME
-

Message

Enveloped Data:



Pseudorandom

session key



(
3
DES or RC
2
/
40
)


ׁ


ׁ

Certificate

RecipientInfo

M

enveloped
-
data


+

Encrypt the session key


Diffie
-
Hellman / RSA

Recipient

s public key

S/MIME
-

Message

SignedData
:


M

Hash function



SHA
-
1
or MD
5

Encryption

Sender

s private key

Certificate

SignerInfo

Base
64
encoding

S/MIME
-

Message

Clear signing
:


Clear signing is achieved using the multipart
content type with a signed sub
-
type .


Two parts:


Clear text (or any MIME type) encoded in base
64
.


SignedData.


S/MIME
-

Message

Content
-
Type: multipart/signed;

protocol=

application/pkcs
7
-
signature

;

micalg=sha
1
; boundary=boundary
42



--
boundary
42




Content
-
Type: text/plain






This is a clear
-
signed message.






--
boundary
42




Content
-
Type: application/pkcs
7
-
signature;



name=smime.p
7
s



Content
-
Transfer
-
Encoding: base
64



Content
-
Disposition: attachment; filename=smime.p
7
s





ghyHhHUujhJhjH
77
n
8
HHGTrfvbnj
756
tbB
9
HG
4
VQpfyF
467
GhIGfHfYT
6




4
VQpfyF
467
GhIGfHfYT
6
jH
77
n
8
HHGghyHhHUujhJh
756
tbB
9
HGTrfvbnj




n
8
HHGTrfvhJhjH
776
tbB
9
HG
4
VQbnj
7567
GhIGfHfYT
6
ghyHhHUujpfyF
4




--
boundary
42
--



This parameter indicates
that this is a two part clear
-
signed entity.

This parameter indicates the
type of message digest used.

SignerInfo

Header

Unsigned
Data

S/MIME
-

Message

Certificate
-
only message:


Used to transport certificates.



contains only certificates or a certificate revocation
list (CRL).




Sent in response to a registration request.



The message is an application/pkcs
7
-
mime
type/subtype.


S/MIME
-

Message

Creating a Certificates
-
only Message:

Step
1
:


The certificates are made available to the CMS

generating process which creates a CMS object of

type signedData.



Step
2
:


The CMS signedData object is enclosed in an

application/pkcs
7
-
mime MIME entity.





The smime
-
type parameter for a certs
-
only message
is "certs
-
only".




The file extension for this type of message is ".p
7
c".

S/MIME
-

Message

Registration request:


A message signer MUST have a certificate for the
signature so that the receiving agent can verify
the signature.



Exchange with CA, hardware token, diskette etc.



S/MIME v
3
-

does not specify how to request a
certification.



S/MIME v
2
-

request by applying to a CA using
the application/pkcs
10
S/MIME entity.



A typical app. Only needs to send certification
request.

S/MIME
-

Message

Registration request:

+

Subject’s name

Public
-
key in bit
-
string representation

010111010011


CertificationRequestInfo

User

s
private key

Public
-
key ID

?

PKCS
10

CA

S/MIME
-

Certificates


S/MIME uses public
-
key certificates that conform
to version
3
of X.
509
.



A hybrid between a strict X.
509
certification
hierarchy and PGP's web of trust.



A receiving agent MUST provide some certificate
retrieval mechanism.



Receiving and sending agents SHOULD also
provide a mechanism to allow a user to "store
and protect" certificates


S/MIME
-

Certificates



Public key certificates are required


to protect the authenticity and


integrity of public keys, thus protecting


against man
-
in
-
the
-
middle attack.




A certificate chain must be verified until


a root CA is reached


S/MIME
-

Certificates


a certificate can only be trusted if
:


every certificate in the chain is successfully verified.


every CA in the certificate chain is trusted
.



In practice, certificate chains are short and
seldom verified for trustworthiness.




Also, the concept of cross
-
certification is of low
practical value and seldom used between
certification service providers.



S/MIME
-

Certificates


S/MIME
-

User role


Key generation
:


MUST be capable of generating separate Diffie
-
Hellman and DSS key pairs.


SHOULD be capable of generating RSA key pairs.


good source of non
-
deterministic random.


protected in a secure fashion.



Registration
:


A user's public key must be registered with a certification
authority in order to receive an X.
509
public
-
key certificate.


S/MIME
-

User role


Certificate storage and retrieval:


access to a local list of certificates in order to
verify incoming signatures and encrypt
outgoing messages.



maintained by the user local administrative
entity on behalf of number of users.




S
-
MIME
-
Attacks

Certificate Management in S/MIME
:


CA
-
centered.



CA certificates come with the client software.



An ordinary user is not aware of the CAs that
he/she trusts.



Certificates are sent along with the signed
messages.


S
-
MIME
-
Attacks


Certificates classes (common practice by most CAs)



Class
1



Class
2



Class
3



CA certification policies



ID
-
control practices



Class
1
: only email address



Class
2
: against third party database



Class
3
: apply in person and submit picture IDs


and/or hard documentation



How to determine user




by name?




by e
-
mail address?


Tighter identity

validation

Easier to

issue

S
-
MIME
-
Attacks

Attack
1
: Class
1
Certificate Attack


No identity check during registration.



Binding between public key and e
-
mail address.



It is possible to enroll under a different name.

-
Name spoofing is possible in signed messages



E
-
mail clients do not make this fact explicit to
average users.


S
-
MIME
-
Attacks

Attack
1
: Class
1
Certificate Attack




Step
1
: Get an e
-
mail address that implies the


person you want to imitate.




Step
2
: Register for a certificate with that


bogus name and e
-
mail address.




Step
3
: Step up an outgoing e
-
mail account


at your favorite e
-
mail client software


with that bogus name.




Step
4
: Send bogus signed messages


S/MIME
-

Attacks

Step
2
-

Registration

S/MIME
-

Attacks


S/MIME
-

Attacks

S/MIME
-

Attacks

shlomo@hotmail.com

S/MIME
-

Attacks

S/MIME
-
Attacks

S/MIME
-
Attacks

Step
3


Setup local account

S/MIME
-
Attacks

Step
4


Send signed but bogus msgs.

S/MIME
-
Attacks


Consequences:


Loose control for Class
1
certificates.



The system becomes less secure for the name of
security.





S/MIME
-
Attacks

Attack
2
:

Use one

s certificate to send
emails under another name.



Step
1
: Set up another e
-
mail account at
local client.



Same e
-
mail address



But a different name




Step
2
: Send bogus signed messages


S/MIME
-

Attacks

Step
1
-

setup another account

S/MIME
-

Attacks

Step
2
-

Send bogus signed msg.

S/MIME
-
Attacks

Consequences:


During verification, e
-
mail client does not


match the name in certificate with the name


in e
-
mail.



Only e
-
mail addresses are matched (as mentioned



in RFC
2632
(S/MIME Certificate Handling).




Verifier

s manual check is needed.



Not a specific problem of class
-
1
certificates

-
Same attack is possible using class
-
2
and class
-
3


certificates.

-
E
-
mail clients are not concerned with certificate


classes.


S/MIME
-
Attacks

Attack
3
:

Forging the header


The scope of a S/MIME signature does not include


the e
-
mail header.





from, to, cc, subject, date



Indeed, the mail header is modified without
changing the verification status.



Problem of all classes of certificates.


What should be done?



Class
1
certificates should be discontinued.



E
-
mail clients must be aware of certificate classes and issue
appropriate warnings to the verifiers.



It is up to you whether to believe a digital signature is valid
or not





Use your reasoning, not your e
-
mail client

s.



Try to identify people by their e
-
mail addresses.







S/MIME
-
Attacks

What should be done (
2
)?



Examine the details of certificate of the other
party.



Do not trust Class
1
certificates.



Ask the sender to put all sensitive information
within the message



Sender

s identity



Subject



Date



Don

t let subject say all!




S/MIME
-
Attacks

S/MIME
-

Summery


In summary, S/MIME provides a thoroughly
designed and widely deployed technological



approach to provide basic message protection


services for the Internet.



S/MIME makes use of a hierarchical trust model


based on ITU
-
T X.
509
.



Most importantly, S/MIME is strongly supported by


all major vendors of UA products.



It very likely that S/MIME will become the
predominant technology for secure messaging on
the Internet.



In contrast to PGP S/MIME cannot be used by
user agent which don't support MIME.



There are problems in the

stiches


(certificate
handling).



With the release of S/MIME v
3
, standardization


activities have slowed down.



S/MIME
-

Summery

S/MIME


The End.