Chapter 15
Download
1 / 27

Chapter 15 - PowerPoint PPT Presentation


  • 96 Views
  • Uploaded on

نعمتان مجهولتان: الصحة و الامان. Chapter 15. Electronic Mail Security – Part II. Data & Network Security Spring 2006 Dr. Jalili. Agenda. In the previous session, we’ve studied PGP. In this session, other email security standards will be studied. PEM S/MIME RFC 822 MIME. Phil’s feelings.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Chapter 15' - hugh


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Chapter 15

نعمتان مجهولتان: الصحة و الامان

Chapter 15

Electronic Mail Security – Part II

Data & Network Security

Spring 2006

Dr. Jalili


Agenda
Agenda

  • In the previous session, we’ve studied PGP. In this session, other email security standards will be studied.

  • PEM

  • S/MIME

    • RFC 822

    • MIME


Phil s feelings
Phil’s feelings

  • …a week before PGP's first release, I discovered the existence of another email encryption standard called Privacy Enhanced Mail (PEM), which was backed by several big companies, as well as RSA Data Security.

  • I didn't like PEM's design, for several reasons…


Why not pem
Why not PEM?!

  • PEM used 56-bit DES to encrypt messages, which I did not regard as strong cryptography.

  • PEM absolutely required every message to be signed, and revealed the signature outside the encryption envelope, so that the message did not have to be decrypted to reveal who signed it.

Not an issue today


Pem standard
PEM Standard

  • PEM is described in RFCs 1421-1424: Privacy Enhancement for Internet Electronic Mail (1993):

    • Part I: Message Encryption and Authentication Procedures;

    • Part II: Certificate-Based Key Management;

    • Part III: Algorithms, Modes, and Identifiers;

    • Part IV: Key Certification and Related Services.


Summary of transformations
Summary of Transformations

  • The incoming/outgoing message undergoes (a subset of) the four-phase transformation:

Printable Encoding

Authentication & Encryption

RFC 822 compatible

Message in the system's native character set


Pem encapsulation
PEM Encapsulation

  • Adopted from RFC 934 encapsulation mechanism.

  • Uses Encapsulation Boundaries (EBs):

    -----BEGIN PRIVACY-ENHANCED MESSAGE-----

    -----END PRIVACY-ENHANCED MESSAGE-----


Encapsulation format
Encapsulation Format

Encapsulated Message

-----BEGIN PRIVACY-ENHANCED MESSAGE-----

Encapsulated Header Portion

Blank Line

Encapsulated Text Portion

-----END PRIVACY-ENHANCED MESSAGE-----

Pre-Encapsulation Boundary (Pre-EB)

Separates Header & Body

Contains encryption control fields

Post-Encapsulation Boundary (Post-EB)

Result of four-phase transformation



Proc type field
Proc-Type Field

  • Identifies the type of processing performed on the transmitted message:

    • ENCRYPTED;

    • MIC-ONLY;

    • MIC-CLEAR;

    • CRL;

    • Content-Domain Field;

    • DEK-Info Field;

MIC:

Message Integrity

Check

DEK:

Data Encrypting

Keys



Pem today
PEM, Today

  • Today, PEM is not used as a mail security/privacy tool anymore.

  • But, as stated in RFC 2315 (PKCS #7: Cryptographic Message Syntax v1.5), PEM & PKCS #7 are totally compatible. PKCS#7 messages can be converted into PEM messages without any cryptographic operations.


S mime
S/MIME

  • Before studying S/MIME, one must first understand what RFC 822 & MIME are.

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

  • Consists of envelope & contents.

  • The content includes a set of header fields that may be used by the mail system to create the envelope.


Rfc 822 message format
RFC 822 Message Format

Date: Tue, 9 May 2006 10:37:17 (EST)

From: “Mahmood Ahmadinejad” <[email protected]>

Subject: no subject

To: [email protected]

Cc:

Mr. George Bush, president of the United States of America

For some time now, I have been thinking, how one can justify the undeniable contradictions that exist in the international arena -- which are being constantly debated, especially in political forums and amongst university students. Many questions remain unanswered. Those have prompted me to discuss some of the contradictions and questions, in the hopes that it might bring about an opportunity to redress them…

Blank Line


Rfc 822 smtp limitations
RFC 822 SMTP limitations

  • Binary object transfer;

  • Non-ASCII-7 encoding;

  • Message size limitations;

  • ASCII-to-EBCDIC translation;

  • SMTP gateways to X.400 email networks can’t handle non-textual X.400 messages;

  • Some SMTP implementations inconsistent with RFC 821 SMTP.

  • Handling CRLF;

  • 76-Character lines;

  • Trailing white spaces;

  • Padding of lines;

  • Handling Tab characters.


MIME

  • RFCs 2821-2822 obsolete RFCs 821-822.

  • MIME =Multipurpose Internet Mail Extensions.

  • An extension to the RFC 822 framework.

  • Intended to address some of the problems and limitations of the use of SMTP.


Mime rfcs
MIME RFCs

  • MIME is discussed in RFCs 2045-2049:

    • 2045: Format of Internet Message Bodies;

    • 2046: Media Types;

    • 2047: Message Header Extensions for Non-ASCII Text;

    • 2048: Registration Procedures;

    • 2049: Conformance Criteria and Examples;


Mime specification
MIME Specification

  • Five new message header fields are defined, which may be included in an RFC 822 header.

  • A number of content formats for multimedia electronic mail are defined.

  • Transfer encodings are defined that enable the conversion of any content format into a form that is protected from alteration by the mail system.


New message headers
New Message Headers

Always 1.0

RFCs 2045-2046

  • MIME-Version;

  • Content-Type;

  • Content-Transfer-Encoding;

  • Content-ID;

  • Content-Description.

e.g.

video/quicktime

e.g.

binary

Used to identify MIME entities uniquely in multiple contexts.

Like <alt> tags



Sample mime message
Sample MIME Message

From: “Mahmood Ahmadinejad” <[email protected]>

To: “George W. Bush” <[email protected]>

Subject: no subject

MIME-Version: 1.0

Content-type: multipart/mixed; boundary=“Mr. President”

Preamble

--Mr. President

You might know that I am a teacher. My students ask me how can these actions be reconciled with the values…

--Mr. President

Content-type: text/plain; charset=us-ascii

I am sure you know how -- and at what cost -- Israel was established…

--Mr. President--

Epilogue

Blank Line



Canonical form
Canonical Form

  • An important concept in MIME and S/MIME.

  • Canonical form is a format, appropriate to the content type, that is standardized for use between systems.

  • May involve character set and EOL conversion, transformation of audio data, compression, etc.


S mime1
S/MIME

  • Secure MIME (RFCs 2632-2634).

  • Provides four functions:

    • Enveloped data;

    • Signed data;

    • Clear-Signed data;

    • Signed & Enveloped data.

Both message & signature are encoded using Base64.

Only signature is encoded using Base64.


S mime algorithms
S/MIME Algorithms

  • DSS: preferred for digital signature.

  • DH (ElGamal): preferred for session key encryption.

  • RSA: signing and/or encryption.

  • 3DES/RC2 (40 bits): message encryption.

  • SHA-1/MD5: digest.

  • There are some RULES for algorithm selection (MUST/SHOULD).

RFC 2119



S mime certificate processing
S/MIME Certificate Processing

  • S/MIME uses public-key certificates that conform to X.509v3.

  • 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.

  • PGP is suitable for personal use, while S/MIME is appropriate for commercial use.


ad