S/MIME (Secure Multipurpose Internet Mail Extensions) allows users to securely send emails through encryption and digital signatures. It uses public key cryptography, with algorithms like RSA and ElGamal for encryption and DSS and RSA for digital signatures. S/MIME supports encrypting the message contents, digitally signing the message, or both. It defines new MIME types to implement these security features for email. Other technologies like PGP provide similar email security functionality to S/MIME.

1. 1
S/MIME(Secure/multipurpose internetmail extention)
S/MIME (Secure Multi-PurposeInternetMail Extensions) isasecure methodof sendinge-mailthatuses
the Rivest-Shamir-Adlemanencryptionsystem.
S/MIME, or Secure/Multipurpose InternetMail Extensions,isatechnologythatallowsyoutoencrypt
your emails.S/MIMEisbasedon asymmetriccryptographytoprotectyouremailsfromunwanted
access.It alsoallowsyouto digitallysignyouremailstoverifyyouasthe legitimatesenderof the
message,makingitaneffectiveweaponagainstmanyphishingattacksoutthere.
Email Format:
These RFCs define the way emailsthemselvesare structured.
 RFC 5322 — InternetMessage Format(basicformatof an email message),previouslyRFC822
and RFC 2822.
 RFC 2045 — Multipurpose InternetMail Extensions(MIME) PartOne:Formatof Internet
Message Bodies(extensiontothe email messageformattosupportattachmentsandnon-ASCII
data).
 RFC 2046 — Multipurpose InternetMail Extensions(MIME) PartTwo:Media Types.
 RFC 2047 — MIME (Multipurpose InternetMail Extensions) PartThree:Message Header
ExtensionsforNon-ASCIIText.
 RFC 2231 — MIME ParameterValue andEncodedWordExtensions:CharacterSets,Languages,
and Continuations
Limitationsof SMTP/RFC5322:
 SMTP cannot transmitbinaryfiles
 SMTP cannot transmittextthatincludesnational languagecharacters
 SMTP may rejectmailsovera certainsize
 SMTP mighthave translationproblemincharactercodes
 Some implementationsdonotfollow completelytothe SMTP standard
MIME Header:
The following headers are defined in MIME:
 MIME-Version

2. 2
 Content-Type
 Content-Transfer-Encoding
 Content-ID
 Content-Description
 Content-Disposition
MIME-Version is a required header indicating that this message is to use the rules of MIME.
"MIME-Version: 1.0" is the only currently defined MIME-Version header allowed.
Content-Type headers are used to specify the media type and subtype of data in the body of a
message and to fully specify the native representation of such data.
Content-Transfer-Encoding header used to show which method used to encode the message.
Content-ID headers are world-unique values that identify body parts, individually or as group.
Content-Description headers are optional and are often used to add descriptive text to non-
textual body parts
MIME Content Types:
text
textual information. The primary subtype, "plain", indicates plain (unformatted) text. No special software is
required to get the full meaning of the text, aside from support for the indicated character set. Subtypes
are to be used for enriched text in forms where application software may enhance the appearance of the
text, but such software must not be required in order to get the general idea of the content. Possible
subtypes thus include any readable word processor format. A very simple and portable subtype, richtext,
is defined in this document.
multipart
data consisting of multiple parts of independent data types. Four initial subtypes are defined, including
the primary "mixed" subtype, "alternative" for representing the same data in multiple formats, "parallel"
for parts intended to be viewed simultaneously, and "digest" for multipart entities in which each part is of
type "message".
message
an encapsulated message. A body of Content-Type "message" is itself a fully formatted RFC 822
conformant message which may contain its own different Content-Type header field. The primary subtype
is "rfc822". The "partial" subtype is defined for partial messages, to permit the fragmented transmission of
bodies that are thought to be too large to be passed through mail transport facilities. Another subtype,
"External-body", is defined for specifying large bodies by reference to an external data source.
image

3. 3
image data. Image requires a display device (such as a graphical display, a printer, or a FAX machine) to
view the information. Initial subtypes are defined for two widely-used image formats, jpeg and gif.
audio
audio data, with initial subtype "basic". Audio requires an audio output device (such as a speaker or a
telephone) to "display" the contents.
video
video data. Video requires the capability to display moving images, typically including specialized
hardware and software. The initial subtype is "mpeg".
application
some other kind of data, typically either uninterpreted binary data or information to be processed by a
mail-based application
MIIME Transfer Encodings:
Content-Transfer-Encoding:7bit: The 7bit is the most fundamental message encoding. Actually, 7bit is
not encoded; 7bit encoded files are files that use only 7-bit characters and have lines no longer than 1000
characters. 7bit encoded files need no encoding or decoding. This is the default.
Content-Transfer-Encoding:8bit: 8bit encoding has the same line-length limitations as the 7bit
encoding. It allows 8bit characters. No encoding or decoding is required for 8bit files. Since not all MTAs
can handle 8bit data, the 8bit encoding is not a valid encoding mechanism for Internet mail.
Content-Transfer-Encoding:base64: Base64 encoding is the scheme used to transmit binary data. Base64
processes data as 24-bit groups, mapping this data to four encoded characters. It is sometimes referred to
as 3-to-4 encoding
Content-Transfer-Encoding:binary: Binary encoding is simply unencoded binary data. It has no line-
length limitations. Binary encoded messages are not valid Internet messages.
Content-Transfer-Encoding:quoted-printable: Quoted-printable encoding is used where data is mostly
US-ASCII text. It allows for 8-bit characters to be represented as their hexadecimal values.
Content-Transfer-Encoding:X-token: Private or proprietary encoding schemes can be included in
messages by having specialized UAs or applications available to both the sender and the receiver, each
recognizing an agreed upon x-token and providing their own encoding mechanism. The x-token can be
any character string preceded by "x-" or "X-".
S/MIME Functionality

4. 4
In terms of general functionality, S/MIME is very
similar to PGP. Both offer the ability to sign
and/or encrypt messages.
1. Functions
S/MIME provides the following functions:
· Enveloped data: This consists of encrypted content of any type and encrypted-content encryption
keys for one or more recipients.
· Signed data: A digital signature is formed by taking the message digest of the content to be signed
and then encrypting that with the private key of the signer. The content plus signature are then encoded
using base64 encoding. A signed data message can only be viewed by a recipient with S/MIME capability.
· Clear-signed data: As with signed data, a digital signature of the content is formed. However, in
this case, only the digital signature is encoded using base64. As a result, recipients without S/MIME
capability can view the message content, although they cannot verify the signature.
· Signed and enveloped data: Signed-only and encrypted-only entities may be nested, so that
encrypted data may be signed and signed data or clear-signed data may be encrypted.
2. Cryptographic Algorithms
· hash functions: SHA-1 & MD5
· digital signatures: DSS & RSA
· session key encryption: ElGamal & RSA
· message encryption: Triple-DES, RC2/40 and others
· have a procedure to decide which algorithms to use.
S/MIME uses the following terminology, taken from RFC 2119 to specify the requirement level:
· Must: The definition is an absolute requirement of the specification. An implementation must
include this feature or function to be in conformance with the specification.

5. 5
· 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.
The S/MIME specification includes a discussion of the procedure for deciding which content encryption
algorithm to use, based on the capabilities of all parties. To support this decision process, a sending agent
may announce its decrypting capabilities in order of preference any message that it sends out. A receiving
agent may store that information for future use. 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.

6. 6
S/MIME Certificate Processing
S/MIME uses public-key certificates that conform to version 3 of X.509 (see Chapter 4). The key-
management scheme used by S/MIME is in some ways a hybrid between a 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 with certificate revocation lists, needed to verify incoming signatures and to encrypt
outgoing messages. But certificates are signed by trusted certification authorities.
S/MIME Enhanced Security Services
The three enhanced security services have been proposed in an Internet draft, and may change or be
extended. The three services are:
• Signed receipts: may be requested in a SignedData object to provide proof of delivery to the originator
of a message and allows the originator to demonstrate to a third party that the recipient received the
message.
• Security labels: may be included in the authenticated attributes of a SignedData object, and is a set of
security information regarding the sensitivity of the content that is protected by S/MIME encapsulation.
They may be used for access control, indicating which users are permitted access to an object
• Secure mailing lists: When a user sends a message to multiple recipients, a certain amount of per-
recipient processing is required, including the use of each recipient's public key. The user can be relieved

7. 7
of this work by employing the services of an S/MIME Mail List Agent (MLA). An MLA can take a single
incoming message, perform recipient-specific encryption for each recipient, and forward the message. The
originator of a message need only send the message to the MLA, with encryption performed using the
MLA's public key.
DKIM:
DKIM (Domain Keys Identified Mail) is an email authentication technique that allows the receiver to check
that an email was indeed send and authorized by the owner of that domain. This is done by giving the
email a digital signature. This DKIM signature is a header that is added to the message and is secured with
encryption
Once receiver (or receiving system) determines that an email is signed with a valid DKIM signature, it’s
certain that parts of the email among which the message body and attachments haven’t been modified.
Usually, DKIM signatures are not visible to end-users, the validation is done on a server level.
Internet Mail Architecture:
At its most fundamental level, the Internet mail architecture consists of a user world in the form of
Message User Agents (MUA), and the transfer world, in the form of the Message Handling Service (MHS),
which is composed of Message Transfer Agents (MTA). A MUA is usually housed in the user's computer,
and referred to as a client email program, or on a local network email server. The MHS accepts a message
from one User and delivers it to one or more other users, creating a virtual MUA-to-MUA exchange
environment. The MSA accepts the message submitted by an MUA and enforces the policies of the
hosting domain and the requirements of Internet standards.
Email threats:
Motivating DomainKeys Identified Mail) describes the problem space being addressed by DKIM in terms
of the characteristics, capabilities, and location of potential attackers.
Ip security:
Ip security is a framework for a set of protocols for security at the network or packet processing layer of
network communication.
Ip security has a range of application specific security mechanisms .

8. 8
Example: S/MIME, PGP, SSL
It provides:
1. Authentication
2. Confidentiality
3. Key management
Benefits:
 can be transparent to end users
 can provide security for individual users
 secures routing architecture
 in a firewall/router provides strong security to all traffic crossing the perimeter
ip security services:
 Access control
 Connectionless integrity
 Data origin authentication
 Rejection of replayed packets

9. 9
 Confidentiality (encryption)
 Limited traffic flow confidentiality