Scribd
Upload
5 views20 pages

Module 4 Part-3

The document outlines procedures for secure email communication using S/MIME, focusing on clear signing and encryption methods. It details the steps for preparing MIME entities, including the selection of encryption algorithms based on recipient capabilities and the creation of PKCS objects. Additionally, it describes the process for enveloped data, including session key generation and encryption with public RSA keys.

Uploaded by

1rn22cy036.shreyaacharya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views20 pages

Module 4 Part-3

The document outlines procedures for secure email communication using S/MIME, focusing on clear signing and encryption methods. It details the steps for preparing MIME entities, including the selection of encryption algorithms based on recipient capabilities and the creation of PKCS objects. Additionally, it describes the process for enveloped data, including session key generation and encryption with public RSA keys.

Uploaded by

1rn22cy036.shreyaacharya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

EMAIL THREATS AND COMPREHENSIVE

EMAIL SECURITY
The Data content type is also used for a procedure known as clear signing. For clear signing, a digital signature is calculated
for a MIME-encoded message and the two parts, the message and signature, form a multipart MIME message. Unlike
SignedData, which involves encapsulating the message and signature in a special format, clear-signed messages can be
read and their signatures verified by email entities that do not implement S/MIME.

The following rules, in the following order, should be followed by a sending agent.
1. If the sending agent has a list of preferred decrypting capabilities from an intended recipient, it SHOULD choose the
first (highest preference) capabil ity on the list that it is capable of using.
2. If the sending agent has no such list of capabilities from an intended recipient but has received one or more messages
from the recipient, then the outgoing message SHOULD use the same encryption algorithm as was used on the last signed
and encrypted message received from that intended recipient.

3. If the 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, then the sending agent SHOULD use triple DES.

4. If the sending agent has no knowledge about the decryption capabilities of the intended recipient and is not willing to
risk that the recipient may not be able to decrypt the message, then the sending agent MUST use RC2/40.

If a message is to be sent to multiple recipients and a common encryption algorithm cannot be selected for all, then the
sending agent will need to send two messages. However, in that case, it is important to note that the security of the
message is made vulnerable by the transmission of one copy with lower security
S/MIME Messages S/MIME makes use of a number of new MIME content types. All of the new application types use the
designation PKCS.
This refers to a set of public-key cryptography specifications issued by RSA Laboratories and made available for the S/MIME
effort.
GENERAL PROCEDURES FOR S/MIME PREPARATION
Securing a MIME ENTITY S/MIME secures a MIME entity with a signature, encryption, or both. A MIME entity may be an entire
message (except for the RFC 5322 headers), or if the MIME content type is multipart, then a MIME entity is one or more of the
subparts of the message.
The MIME entity is prepared according to the normal rules for MIME message preparation. Then the MIME entity plus some
security-related data, such as algorithm identifiers and certificates, are processed by S/MIME to produce what is known as a
PKCS object. A PKCS object is then treated as message content and wrapped in MIME (provided with appropriate MIME
headers).
This process should become clear as we look at specific objects and provide examples. In all cases, the message to be sent is
converted to canonical form. In particular, for a given type and subtype, the appropriate canonical form is used for the message
content. For a multipart message, the appropriate canonical form is used for each subpart. The use of transfer encoding
requires special attention. For most cases, the result of applying the security algorithm will be to produce an object that is
partially or totally represented in arbitrary binary data. This will then be wrapped in an outer MIME message and transfer
encoding can be applied at that point, typically base64. However, in the case of a multipart signed message (described in more
detail later), the message content in one of the subparts is unchanged by the security process. Unless that content is 7 bit, it
should be transfer encoded using base64 or quoted printable so that there is no danger of altering the content to which the
signature was applied.
SECURE MIME CONTENT TYPES

ENVELOPED DATA
An application/pkcs7-mime subtype is used for one of four categories of S/MIME processing, each with a unique smime-
type parameter.
In all cases, the resulting entity, (referred to as an object) is represented in a form known as Basic Encoding Rules (BER),
which is defined in ITU-T Recommendation X.209.
The BER format consists of arbitrary octet strings and is therefore binary data. Such an object should be transfer encoded
with base64 in the outer MIME message.

The steps for preparing an enveloped Data MIME entity are: -


1. Generate a pseudorandom session key for a particular symmetric encryption algorithm (RC2/40 or triple DES).
2. For each recipient, encrypt the session key with the recipient’s public RSA key.
3. For each recipient, prepare a block known as RecipientInfo that contains an identifier of the recipient’s public-key
certificate,1 an identifier of the algorithm used to encrypt the session key, and the encrypted session key.
4. Encrypt the message content with the session key. The RecipientInfo blocks followed by the encrypted content
constitute the envelopedData. This information is then encoded into base64

You might also like