S/MIME Overview

Secure Multipurpose Internet Mail

Extension (S/MIME)
• Introduction
• RFC 822
• MIME
• S/MIME Functionality
Cryptography and Network Security
• Cryptographic Algorithms
• Content Types
• Entities
• User Agent Roles
• VeriSign Certificates
• Enhanced Security Services

S/MIME Introduction RFC 822

 Secure Multipurpose Internet Mail  Defines a format for text messages that are
Extension (S/MIME) is a security sent using electronic mail.
enhancement to the MIME Internet e-mail  Messages are viewed as having an
envelope and contents.
format standard.
– Envelope contains all the information needed to
 Based on technology from RSA. accomplish transmission and delivery.
– Contents comprise the objects to be delivered to the
 Prerequisites to understanding S/MIME:
recipient.
– Traditional email format standard RFC 822.
 The RFC 822 standard applies only to the
 Still in common use.
contents.
– Underlying email format – MIME. – Also contains a set of header fields that can be used to
create the envelope.

RFC 822 RFC 822 Limitations

 Overall structure of a message that  Cannot transmit executable files or other binary
conforms to the standard: objects.
– May use some scheme to convert binary files into text
– Header – separated from body by a blank form.
line. – No agreed standard –e.g. UNIX UUencode/UUdecode.
– Body – unrestricted ASCII text.  Cannot transmit text data that contains
 Most frequently used key words include: national language characters.
From To Subject Date Message-ID – These normally use 8-bit codes with values 128 decimal
or higher.
 Message-ID contains a unique – Limited to 7-bit ASCII codes.
identifier associated with the
 SMTP servers may reject mail message over
message. a certain size.
1
RFC 822 Limitations MIME

 SMTP getaways that translate between  An extension of RFC 822 intended to

ASCII and EBCDIC do not use consistent address problems and limitations of
set of mappings. mail transfer protocols such as
SMTP.
 SMTP getaways to X.400 email
 Includes the following elements:
networks cannot handle non-textual
1. Five new message header fields that
data included in X.400 messages. provide information about the body of
 Some SMTP implementations do not the message.
adhere completely to the SMTP 2. A number of content formats are defined thus
standardising representations that support
standards defined in RFC 821.
multimedia.
3. Transfer encodings defined to enable
conversion of content to formats that are
protected from alterations.

MIME Header Fields MIME Header Fields

 MIME-Version  Content-Transfer-Encoding
– Must have value 1.0. – Indicates the transformation used to
– Indicates that message conforms to RFCs represent the body of the message.
2045 and 2046.  Content-ID
 Content-Type – Identify MIME entities uniquely in multiple
– Describes data contained in the body contexts.
to ensure appropriate action by the  Content-Description
receiving user agent. – A text description of the object with the
body.
– Useful when the object is not readable.

MIME Content S/MIME Functionality

Types
 Enveloped data
– Consists of encrypted content and
encryption keys for one or more recipients.
 Signed data
– Digital signature formed by taking message
digest of content to be signed and
encrypting it with private key of signer.
– Content + signature encoded using base64
 encoding. – Message can only be viewed by recipient
with S/MIME capability.

2
 SHOULD use the same encryption
algorithm as was used in the last signed
and encrypted message received from the
intended recipient.
S/MIME Functionality

 Clear-signed data
– Only the digital signature is encoded using
base64.
– Hence recipients without S/MIME capability
can view the message content (but cannot
verify the signature).
 Signed and enveloped data
– Signed-only and encrypted-only entities may be
nested.
– Implies that encrypted data may be signed
and signed or clear-signed data may be
encrypted.

S/MIME Cryptographic Algorithms

 Terminology taken from RFC 2119 to

specify the requirement level:
– MUST: An absolute requirement of the
specification.
– SHOULD: There may exist valid reasons to
ignore this feature or function, but it is
recommended that an implementation
includes it.
 S/MIME incorporates three public-key
algorithms:
– DSS is the preferred algorithm for digital
signatures.
– Diffie-Hellman (ElGamal) is the preferred
algorithm for encrypting session keys.
 RSA can be used as an alternative for
signatures and session key encryption.

S/MIME Cryptographic Algorithms

 Rules to be followed by sending agent:

1. If it has a list of preferred decrypting
capabilities from intended recipient, it
SHOULD choose the highest preference
capability.
2. If sending agent has no list of capabilities
but has received one or more messages
from recipient, the outgoing message
 restrictions).
 Decision process required:
– Sending agent must determine if receiving agent is
capable of decrypting using a given encryption
S/MIME Cryptographic Algorithms algorithm.
– If receiving agent is capable of receiving only
weakly encrypted content, sending agent must
decide if it is acceptable to send using weak
encryption.

S/MIME Cryptographic Algorithms

3. If sending agent has no knowledge about the

decryption capabilities of the intended recipient and
is willing to risk that the recipient may not be able
to decrypt the message, the sending agent SHOULD
use tripleDES.
4. If sending agent has no knowledge about decrypting
S/MIME Cryptographic Algorithms capabilities of the intended recipient and is not
willing to risk that the recipient may not be able to
decrypt the message, the sending agent MUST use
RC2/40.
– 160-bit SHA-1 for the hash function used to
 If message is to be sent to multiple
create digital signatures.
recipients and there is no common
 Support for 128-bit MD5 for backward
encryption algorithm, the sending agent will
compatibility with older versions of S/MIME.
need to send two messages.
– Message encryption: tripleDES.
– Security of the message is compromised by lower
 Must also support 40-bit RC2 (US export
security algorithm.

3
 Securing a MIME
S/MIME Content Types Entity

• S/MIME secures a MIME entity with a

signature, encryption or both.
• MIME entity is prepared according to the
normal rules of MIME message preparation.
• MIME entity plus security-related data are
processed by S/MIME to produce a PKCS
object.
• PKCS object is wrapped in MIME with the
appropriate MIME headers.
• In all cases, the message is converted to canonical form.
– A format, appropriate to the content type,
standardised for use between systems.

EnvelopedData MIME Entity EnvelopedData MIME Entity

1. Generate a pseudo-random session key.  To recover the encrypted message:

 For RC2/40 or tripleDES.
– Strip off base64 encoding.
2. For each recipient encrypt the session – Use the recipient's private key to recover
key with the recipient’s public RSA key. the session key.
3. For each recipient prepare a RecipientInfo – Decrypt message using the session key.
that contains an identifier of the recipient’s
public key certificate, an identifier of the
algorithm used to encrypt the key and the
encrypted session key.
4. Encrypt the message content with the session
key.
5. Encode using base64.
of the algorithm used to encrypt the
message digest and the encrypted
message digest.

SignedData MIME Entity

1. Select message digest algorithm ( SHA

or MD5).
2. Compute the message digest, or hash
function, of the content to be signed.
3. Encrypt message digest with the
signer’s private key.
4. Prepare SignerInfo block that contains
the signer’s PKC, an identifier of the
message digest algorithm, an identifier
  The SignedData entity consists of a
series of blocks, including a
message digest algorithm identifier,
the message being signed and
SignerInfo.
 It may also include a set of public-key
certificates sufficient to constitute a
chain from a recognised root or top-
SignedData MIME Entity level certification authority to the
signer.
 This info in then encoded using base64.

4
SignedData MIME Entity Clear Signing MIME Entity

 To recover the signed message and  Achieved by using the multipart content type
with a signed subtype.
verify the signature:
 A multipart/signed message has two parts:
– Recipient strips off the base64 encoding. – Any MIME type but must be prepared such as it is
– Signers public key used to decrypt the not alterable during transfer from source to
destination.
message digest.
 Encoded using base64 or quoted-printable, if
– Recipient independently computes message required.
digest and compares it to decrypted – An application type MIME part with sub-type pkcs7-
message digest to verify signature. signature.
 This is the result of processing the first part as
SignedData.
 The object with SignedData format is created
with an empty message content field.
 This object is a detached signature.
 It is encoded using base64.

Clear Signing MIME Entity Registration Request Message

 The receiver can verify the signature by  An application/user will apply to a CA for a
taking the message digest of the first public key certificate.
part and comparing this to the message  An application/pkcs10 -mime S/MIME entity
is used to transfer a certification request.
digest recovered from the signature in
 The request includes a
the second part.
CertificationRequestInfo block, an identifier of
the public key encryption algorithm and
signature of the CertificationRequestInfo
block made using the sender’s private key.
 The CertificationRequestInfo block
includes a name of certificate subject and
user’s public key.

message, except that there is no message

content and the SignerInfo field is empty.

Certificates-Only Message

 A message containing only

certificates or a certificate
revocation list (CRL) can be sent in
response to a registration request.
 The message is an application/pkcs7
S/MIME entity with a smime-type
parameter of degenerate.
– Steps involved same as for a SignedData
  Uses v3 X.509 public key certificates.
 Key management scheme is a hybrid
between strict X.509 certification
hierarchy and PGP´s web of trust.
 S/MIME managers and/or users must
configure each client with a list of
trusted keys and Certificate
Revocation Lists.
S/MIME Certificate Processing – Responsibility is local.
– Certificates are signed by CAs.

5
User Agent Roles VeriSign Certificates

 Key generation  Provides Certification Authority

– Administrator MUST be capable of generating Diffie- services that are compatible with
Hellman and DSS key pairs. S/MIME.
– SHOULD be capable of generating RSA key pairs with
 At minimum a Digital ID will contain:
768-1024 bits. MUST not generate a length of less
than 512 bits. – Owner’s public key.
– Owner’s name or alias.
 Registration
– Expiration date of the Digital ID.
– Users PK must be registered with a CA to receive an
X.509 public-key certificate. – Serial number of the Digital ID.
– Name of the CA.
 Certificate storage and retrieval
– Digital signature of the CA.
– User requires access to local lists of certificates to
verify incoming signatures and to encrypt outgoing  May also contain other user-supplied
messages. info such as: address, e-mail, country,
– Maintained by user or local administrative entity. age, gender…

VeriSign Certificates Enhanced Security Services

 Signed Receipts
– Provides proof of delivery to the originator of a
message.
 Security Labels
– Is a set of security information regarding the
sensitivity of the content.
– The labels may provide access control indicating
which users are permitted access to an object.
 Secure Mailing Lists
– Some sort of per recipient processing required
when user sends message to multiple recipients.
VeriSign Levels of Security
– User relieved of the task by employing S/MIME
Mailing List Agent (MLA).
– Performs recipient specific encryption and
forwards the message.

References

 Most of the material in the previous slides was taken from:

– Cryptography and Network Security by Stallings, 4 Ed
6