S/MIME.

Slides:



Advertisements
Similar presentations
TOPIC : MIME (Multipurpose Internet Mail Extensions ) By: Cecilia Gomes COSC 541,DATA COMMUNICATION SYSTEMS & NETWORKS Instructor: Prof. Anvari (SEU)
Advertisements

Spring 2012: CS419 Computer Security Vinod Ganapathy SSL, etc.
Cryptography and Network Security Sixth Edition by William Stallings.
Cryptography Chapter 7 Part 4 Pages 833 to 874. PKI Public Key Infrastructure Framework for Public Key Cryptography and for Secret key exchange.
Lecture 5: security: PGP Anish Arora CSE 5473 Introduction to Network Security.
Lecture 5: security: PGP Anish Arora CIS694K Introduction to Network Security.
DESIGNING A PUBLIC KEY INFRASTRUCTURE
Cryptography and Network Security Third Edition by William Stallings Lecture slides by Lawrie Brown.
Security Overview Hofstra University University College for Continuing Education - Advanced Java Programming Lecturer: Engin Yalt May 24, 2006.
Chapter 5 Electronic mail security. Outline Pretty good privacy S/MIME Recommended web sites.
1 Pertemuan 12 Security Matakuliah: H0242 / Keamanan Jaringan Tahun: 2006 Versi: 1.
NS-H / Security. NS-H / Security is one of the most widely used and regarded network services currently message.
Electronic mail security
Henric Johnson1 Electronic mail security Henric Johnson Blekinge Institute of Technology, Sweden
Cryptography and Network Security Chapter 15 Fourth Edition by William Stallings Lecture slides by Lawrie Brown.
ITA, , 7-Secure .pptx 1 Internet Security 1 (IntSi1) Prof. Dr. Andreas Steffen Institute for Internet Technologies and Applications (ITA)
Cryptography 101 Frank Hecker
Secure Data Transmission EDI-INT AS1, AS2, AS3 Kevin Grant.
Digital Certificates With Chuck Easttom. Digital Signatures  Digital Signature is usually the encryption of a message or message digest with the sender's.
Electronic Mail Security
S/MIME and CMS Presentation for CSE712 By Yi Wen Instructor: Dr. Aidong Zhang.
Application Layer Protocols Simple Mail Transfer Protocol.
1 Chapter 5 Electronic mail security. 2 Outline Pretty good privacy S/MIME Recommended web sites.
Chapter 15 Electronic Mail Security – Part II Data & Network Security Spring 2006 Dr. Jalili.
16.1 Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 16 Security at the Application Layer: PGP and.
Electronic mail security. Outline Pretty good privacy S/MIME.
Chapter 9: Using and Managing Keys Security+ Guide to Network Security Fundamentals Second Edition.
Network Security Essentials Chapter 7 Fourth Edition by William Stallings (Based on Lecture slides by Lawrie Brown)
Chapter 6 Electronic Mail Security MSc. NGUYEN CAO DAT Dr. TRAN VAN HOAI 1.
Certificate-Based Operations. Module Objectives By the end of this module participants will be able to: Define how cryptography is used to secure information.
1 Electronic mail security Ola Flygt Växjö University, Sweden
Cryptography and Network Security (CS435) Part Twelve (Electronic Mail Security)
1 Electronic Mail Security Outline Pretty good privacy S/MIME Based on slides by Dr. Lawrie Brown of the Australian Defence Force Academy, University College,
1 Chapter 5 Electronic mail security. 2 Outline Pretty good privacy S/MIME Recommended web sites.
CSCE 815 Network Security Lecture 11 Security PGP February 25, 2003.
SECURITY – Chapter 15 SECURITY – Chapter 15 ….for authentication and confidentiality PGP 1.Uses best algorithms as building blocks 2.General.
NETWORK SECURITY.
X.509 Topics PGP S/MIME Kerberos. Directory Authentication Framework X.509 is part of the ISO X.500 directory standard. used by S/MIME, SSL, IPSec, and.
ECE-8813 / CS Prof. John A. Copeland fax Office:
Security fundamentals Topic 5 Using a Public Key Infrastructure.
PGP & IP Security  Pretty Good Privacy – PGP Pretty Good Privacy  IP Security. IP Security.
S/MIME (Secure/Multipurpose Internet Mail Extensions) security enhancement to MIME – original Internet RFC822 was text only – MIME provided.
Electronic Mail Security Prepared by Dr. Lamiaa Elshenawy
2/19/2016clicktechsolution.com Security. 2/19/2016clicktechsolution.com Threats Threats to the security of itself –Loss of confidentiality.
Security SMIME IT352 | Network Security |Najwa AlGhamdi 1.
Secure Socket Layer SSL and TLS. SSL Protocol Peer negotiation for algorithm support Public key encryptionPublic key encryption -based key exchange and.
By Marwan Al-Namari & Hafezah Ben Othman Author: William Stallings College of Computer Science at Al-Qunfudah Umm Al-Qura University, KSA, Makkah 1.
Security By Meenal Mandalia. What is ? stands for Electronic Mail. much the same as a letter, only that it is exchanged in a different.
Prof. Wenguo Wang Network Information Security Prof. Wenguo Wang Tel College of Computer Science QUFU NORMAL UNIVERSITY.
1 CNLab/University of Ulsan Chapter 16 Electronic Mail Security  PGP (Pretty Good Privacy)  S/MIME.
Lecture 8 (Chapter 18) Electronic Mail Security Prepared by Dr. Lamiaa M. Elshenawy 1.
第五章 电子邮件安全. Security is one of the most widely used and regarded network services currently message contents are not secure –may be inspected.
Electronic mail security. Outline Pretty good privacy S/MIME.
Electronic mail security
K. U. Khimani Asst. Prof. IT Dept. VVP Engineering College
Security is one of the most widely used and regarded network services
Security Pretty Good Privacy (PGP)
Selected Research Topics Electronic Mail Security
Electronic Mail Security
S/MIME T ANANDHAN.
MAIL AND SECURITY PERTEMUAN 13
Security at the Application Layer: PGP and S/MIME
ELECTRONIC MAIL SECURITY
ELECTRONIC MAIL SECURITY
Network Security Essentials
Cryptography and Network Security
Presentation transcript:

S/MIME

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 There are three versions of S/MIME: 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: SMTP cannot transmit executable files or other binary files. 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 ASCII. SMTP servers may reject mail message over a certain size. SMTP gateways that translate between ASCII to EBCDIC suffer translation problems. Some SMTP implementations do not adhere completely to the SMTP standard defined in RFC 822.

MIME (contd.) MIME specification includes the following elements: Five new message header fields. These fields provide information about the body of the message. A number of content formats are defined, thus standardizing representations that supports multimedia e-mail. 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: Subtype Description Text Plain Enriched Unformatted text (ASCII or ISO 8859). Provides greater format flexibility. Multipart Mixed   Parallel Alternative Digest The different parts are independent but are to be transmitted together. Should be presented to the receiver in their original order. Differs from mixed only in that no order is defined. The different parts are alternative versions of the same information. Similar to Mixed but the default type/subtype of each part is message/rfc822. Message rfc822   Partial External body The body is itself an encapsulated message that conforms to RFC822. Used to allow fragmentation in a transparent way to the recipient. Contains a pointer to an object exists else where.

MIME (contd.) Type Subtype Description Image Video Audio Application Jpeg gif 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 Octet-stream 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 chars. 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 requirements. 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 signature. 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. Definitions: MUST: The definition is an absolute requirement of the specification. 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.

S/MIME - Cryptography Used Algorithms: Function Requirement Creation of a message digest. MUST support SHA-1. SHOULD use sha-1. Receiving agents SHOULD support MD5 for the purpose of providing backward compatibility with S/MIME v2. A message digest encryption to form a digital signature. Both sending and receiving agents MUST support DSS. 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 for transmission with the message. Both sending and receiving agents MUST support Diffie-Hellman. Sending agents SHOULD support RSA encryption with key sizes 512 to 1024 bits. Receiving agents SHOULD support RSA decryption. A message Encryption for transmission with one-time session key. Sending an receiving agent MUST support Encryption/Decryption with 3DES. 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 Canonical MIME Algorithm Identifiers Certificates CMS MIME bodies + CMS. CMS object MIME Encoding + Canonical form

S/MIME - Message S/MIME makes use of a number of new MIME content types: Description S/MIME parameter Subtype Type A clear message in tow parts: One is the message and the other is the signature. Signed Multipart A signed S/MIE entity. An encrypted S/MIME entity. multipart/signed message. A certificate registration request message. signedData envelopedData -- pkcs7-mime Pkcs7-signature pkcs10-mime Application

S/MIME - Message M + Enveloped Data: Recipient’s public key Encrypt the session key Diffie-Hellman / RSA Recipient’s public key Pseudorandom session key (3DES or RC2/40)ׁׁ Certificate RecipientInfo M enveloped-data +

S/MIME - Message M SignedData: Sender’s private key Hash function Encryption Sender’s private key Certificate M Hash function SHA-1 or MD5 SignerInfo 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 Unsigned Data This parameter indicates that this is a two part clear-signed entity. Content-Type: multipart/signed; protocol=“application/pkcs7-signature”; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message. Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 --boundary42-- This parameter indicates the type of message digest used. Unsigned Data SignerInfo Header

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 type/subtype.

S/MIME - Message The CMS signedData object is enclosed in an 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 certification. S/MIME v2- request by applying to a CA using the application/pkcs10 S/MIME entity. A typical app. Only needs to send certification request.

S/MIME - Message ? CA + Registration request: Subject’s name Public-key in bit-string representation 010111010011… CertificationRequestInfo Public-key ID User’s private key ? PKCS10 CA

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 to protect the authenticity and 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 messages.

S-MIME -Attacks How to determine user Certificates classes (common practice by most CAs) – Class 1 – Class 2 – Class 3 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? Tighter identity validation Easier to issue

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 shlomo@hotmail.com

S/MIME- Attacks

S/MIME-Attacks

S/MIME-Attacks Step 3 – Setup local account

S/MIME-Attacks Step 4 – Send signed but bogus msgs.

S/MIME-Attacks Consequences: Loose control for Class 1 certificates. The system becomes less secure for the name of security.

S/MIME-Attacks 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.

S/MIME-Attacks Consequences: 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 certificates. -E-mail clients are not concerned with certificate classes.

S/MIME-Attacks 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.

S/MIME-Attacks 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.

S/MIME-Attacks What should be done (2)? Examine the details of certificate of the other party. 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 handling). With the release of S/MIME v3, standardization activities have slowed down.

S/MIME The End.