Learning Center
Plans & pricing Sign in
Sign Out



                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
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
                                 Unformatted text (ASCII or ISO 8859).
                                 Provides greater format flexibility.

Multipart        Mixed           The different parts are independent but are to be
                                 transmitted together. Should be presented to the
                                 receiver in their original order.
                 Parallel        Differs from mixed only in that no order is defined.
                 Alternative     The different parts are alternative versions of the
                                 same information.
                 Digest          Similar to Mixed but the default type/subtype of
                                 each part is message/rfc822.

Message          rfc822          The body is itself an encapsulated message that
                                 conforms to RFC822.
                 Partial         Used to allow fragmentation in a transparent way to
                                 the recipient.
                 External body   Contains a pointer to an object exists else where.
              MIME (contd.)
Type          Subtype        Description

Image         Jpeg
                             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 8kHz

Application   Postscript
                             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
7bit               The data are all represented by short lines of ASCII
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.
Base64              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

     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 base64 encoding.
    This function provides authenticity, message integrity
    and non-repudiation of origin.
            S/MIME - Functions
   SignerInfo: allows the inclusion of unsigned and
    signed attributes to be included along with a
     signingTime
     sMIMECapabilities
     sMIMEEncryptionKeyPreference
             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
Be liberal in what you receive and
conservative in what you send.
   MUST: The definition is an absolute requirement of the
   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
     S/MIME - Cryptography
            Used Algorithms:
     Function                          Requirement

Creation of a          MUST support SHA-1. SHOULD use sha-1.
message digest.        Receiving agents SHOULD support MD5 for
                       the purpose of providing backward
                       compatibility with S/MIME v2.

A message digest       Both sending and receiving agents MUST
encryption to form a   support DSS.
digital signature.     Receiving agents SHOULD support
                       verification of RSA signatures with key sizes
                       512 bits to 1024 bits. Note that S/MIME v2
                       clients are only capable of verifying digital
                       signatures using RSA.
     S/MIME - Cryptography
       Function                            Requirement
A session key encryption    Both sending and receiving agents MUST
for transmission with the   support Diffie-Hellman.
message.                    Sending agents SHOULD support RSA
                            encryption with key sizes 512 to 1024 bits.
                            Receiving agents SHOULD support RSA
A message Encryption        Sending an receiving agent MUST support
for transmission with       Encryption/Decryption with 3DES.
one-time session key.       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 3DES.

   No knowledge & Not willing to risk:
    sending agent MUST use RC2/40.
        S/MIME - Cryptography
   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 - Message

MIME bodies + CMS.

                      CMS object

                         MIME       Encoding + Canonical form
               S/MIME - Message
   S/MIME makes use of a number of new MIME content types:
    Type        Subtype          S/MIME                 Description
Multipart   Signed                            A clear message in tow
                                              One is the message and
                                              the other is the signature.
Application pkcs7-mime         signedData     A signed S/MIE entity.

            pkcs7-mime        envelopedData   An encrypted S/MIME entity.

                                              multipart/signed message.
            Pkcs7-signature        --
                                              A certificate registration
            pkcs10-mime            --         request message.
            S/MIME - Message
Enveloped Data:                Recipient’s public key
                               Diffie-Hellman / RSA

                            Encrypt the session key
    session key

    (3DES or RC2/40)ׁׁ


        S/MIME - Message
                                     Sender’s private key

      Hash function               Encryption

      SHA-1 or MD5


                               Base64 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 base64.
   SignedData.
                    S/MIME - Message
                                                                  This parameter indicates
   Content-Type: multipart/signed;                                that this is a two part clear-
                      protocol=“application/pkcs7-signature”;     signed entity.
                      micalg=sha1; boundary=boundary42

            --boundary42                                This parameter indicates the
                                                        type of message digest used.
Unsigned    Content-Type: text/plain
                      This is a clear-signed message.

            Content-Type: application/pkcs7-signature;                        Header
            Content-Transfer-Encoding: base64
            Content-Disposition: attachment; filename=smime.p7s


              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/pkcs7-mime
              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/pkcs7-mime MIME entity.

   The smime-type parameter for a certs-only message
    is "certs-only".
   The file extension for this type of message is ".p7c".
            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 v3- does not specify how to request a

   S/MIME v2- request by applying to a CA using
    the application/pkcs10 S/MIME entity.

   A typical app. Only needs to send certification
             S/MIME - Message
Registration request:

                        Subject’s name

Public-key in bit-
string representation
                            +            CertificationRequestInfo

Public-key ID              ?
 CA                                                      User’s
                                                         private key
         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
                  S-MIME -Attacks
   Certificates classes (common practice by most CAs)
     – Class 1
     – Class 2         Tighter identity Easier to
     – Class 3         validation       issue

   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?
              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
S/MIME- Attacks
Step 3 – Setup local account
Step 4 – Send signed but bogus msgs.

 Loose control for Class 1 certificates.

   The system becomes less secure for the name of
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.
 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
    -E-mail clients are not concerned with certificate
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.
What should be done (2)?

   Examine the details of certificate of the other

   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 - 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.
            S/MIME - Summery
   In contrast to PGP S/MIME cannot be used by
    user agent which don't support MIME.

   There are problems in the “stiches” (certificate

   With the release of S/MIME v3, standardization
    activities have slowed down.

The End.

To top