430 likes | 562 Views
Chapter 5. Electronic mail security. Outline. Pretty good privacy S/MIME Recommended web sites. K S ( ). K S ( ). +. +. +. -. K B (K S ). K B (K S ). K B. K B. +. -. K S. K S (m ). K S (m ). m. m. K S. Internet. K S. +. -. K B ( ). K B ( ). Secure e-mail.
E N D
Chapter 5 Electronic mail security
Outline • Pretty good privacy • S/MIME • Recommended web sites
. . KS( ) KS( ) + + + - KB(KS ) KB(KS ) KB KB + - KS KS(m ) KS(m ) m m KS Internet KS . . + - KB( ) KB( ) Secure e-mail • Alice wants to send confidential e-mail, m, to Bob. • Alice: • generates random symmetric private key, KS. • encrypts message with KS (for efficiency) • also encrypts KS with Bob’s public key. • sends both KS(m) and KB(KS) to Bob.
. . KS( ) KS( ) + + + - KB(KS ) KB(KS ) KB KB + - KS KS(m ) KS(m ) m m KS Internet KS . . + - KB( ) KB( ) Secure e-mail • Alice wants to send confidential e-mail, m, to Bob. • Bob: • uses his private key to decrypt and recover KS • uses KS to decrypt KS(m) to recover m
+ - KA KA + - . . + - KA( ) KA( ) . . - - KA(H(m)) KA(H(m)) H(m ) m H( ) H( ) compare Internet m H(m ) m Secure e-mail (continued) • Alice wants to provide sender authentication message integrity. • Alice digitally signs message. • sends both message (in the clear) and digital signature.
. KS( ) + + - KB(KS ) KA KB + + KS m . - KA( ) . - KA(H(m)) H( ) m Internet KS . + KB( ) Secure e-mail (continued) • Alice wants to provide secrecy, sender authentication, message integrity. Alice uses three keys: her private key, Bob’s public key, newly created symmetric key
Internet e-mail encryption scheme, de-facto standard. uses symmetric key cryptography, public key cryptography, hash function, and digital signature as described. provides secrecy, sender authentication, integrity. ---BEGIN PGP SIGNED MESSAGE--- Hash: SHA1 Bob:My husband is out of town tonight.Passionately yours, Alice ---BEGIN PGP SIGNATURE--- Version: PGP 5.0 Charset: noconv yhHJRHhGJGhgg/12EpJ+lo8gE4vB3mqJhFEvZP9t6n7G6m5Gw2 ---END PGP SIGNATURE--- Pretty good privacy (PGP) A PGP signed message:
Pretty Good Privacy • Philip R. Zimmerman, the creator of PGP, was target of 3-year federal investigation • PGP provides a confidentiality and authentication service that can be used for electronic mail and file storage applications.
Why Is PGP Popular? • It is availiable free on a variety of platforms. • Based on well known algorithms. • Wide range of applicability • Not developed or controlled by governmental or standards organizations
Operational Description • Consist of five services: • Authentication • Confidentiality • Compression • E-mail compatibility • Segmentation
Compression • PGP compresses the message after applying the signature but before encryption • The placement of the compression algorithm is critical. • The compression algorithm used is ZIP (described in appendix 5A)
E-mail Compatibility • The scheme used is radix-64 conversion (see appendix 5B). • The use of radix-64 expands the message by 33%.
Segmentation and Reassembly • Often restricted to a maximum message length of 50,000 octets. • Longer messages must be broken up into segments. • PGP automatically subdivides a message that is too large. • The receiver strip of all e-mail headers and reassemble the block.
The Use of Trust • Key legitimacy field • Signature trust field • Owner trust field See Table 5.2 (W. Stallings)
Revoking Public Keys • The owner issue a key revocation certificate. • Normal signature certificate with a revoke indicator. • Corresponding private key is used to sign the certificate.
S/MIME • Secure/Multipurpose Internet Mail Extension • S/MIME will probably emerge as the industry standard. • PGP for personal e-mail security
Three major components: user agents mail servers simple mail transfer protocol: SMTP User Agent a.k.a. “mail reader” composing, editing, reading mail messages e.g., Eudora, outgoing, incoming messages stored on server user agent user agent user agent user agent user agent user agent SMTP SMTP SMTP mail server mail server mail server outgoing message queue user mailbox Electronic Mail
Mail Servers mailbox contains incoming messages for user messagequeue of outgoing (to be sent) mail messages SMTP protocol between mail servers to send email messages client: sending mail server “server”: receiving mail server user agent user agent user agent user agent user agent user agent SMTP SMTP SMTP mail server mail server mail server Electronic Mail: mail servers
uses TCP to reliably transfer email message from client to server, port 25 direct transfer: sending server to receiving server three phases of transfer handshaking (greeting) transfer of messages closure command/response interaction commands: ASCII text response: status code and phrase messages must be in 7-bit ASCII SMTP [RFC 2821]
SMTP: protocol for exchanging email msgs RFC 822: standard for text message format: header lines, e.g., To: From: Subject: differentfrom SMTP commands! body the “message”, ASCII characters only Mail message format header blank line body
SMTP, RFC 822 • SMTP Limitations - Can not transmit, or has a problem with: • executable files, or other binary files (jpeg image) • “national language” characters (non-ASCII) • messages over a certain size • ASCII to EBCDIC translation problems • lines longer than a certain length (72 to 254 characters)
MIME: multimedia mail extension, RFC 2045, 2056 additional lines in msg header declare MIME content type From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data Multimedia extensions MIME version method used to encode data multimedia data type, subtype, parameter declaration encoded data
Text example subtypes: plain, html Image example subtypes: jpeg, gif Audio example subtypes: basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding) Video example subtypes: mpeg, quicktime Application other data that must be processed by reader before “viewable” example subtypes: msword, octet-stream MIME typesContent-Type: type/subtype; parameters
Multipart Type From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. --98766789 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789--
Header fields in MIME • MIME-Version: Must be “1.0” -> RFC 2045, RFC 2046 • Content-Type: More types being added by developers (application/word) • Content-Transfer-Encoding: How message has been encoded (radix-64) • Content-ID: Unique identifying character string. • Content Description: Needed when content is not readable text (e.g.,mpeg)
S/MIME Functions • Enveloped Data: Encrypted content and encrypted session keys for recipients. • Signed Data: Message Digest encrypted with private key of “signer.” • Clear-Signed Data: Signed but not encrypted. • Signed and Enveloped Data: Various orderings for encrypting and signing.
Algorithms Used • Message Digesting: SHA-1 and MD5 • Digital Signatures: DSS • Secret-Key Encryption: Triple-DES, RC2/40 (exportable) • Public-Private Key Encryption: RSA with key sizes of 512 and 1024 bits, and Diffie-Hellman (for session keys).
Negotiation between sending and receiving agents • both may announce their decrypting capabilities • sending agent should select from the recipient capabilities list the highest capability of decryption • if there is no such a list the sending agent should use the same algorithm which was used in messages received from the recipient • if there are no messages from the recipient and the sender is willing to risk that the recipient will not be able to decrypt the message, it should use triple DES • if the sender is not willing to risk, then it must use RC2/40
Securing a MIME Entity • S/MIME secures a MIME entity with a signature, encryption or both. • The MIME entity is prepared according to normal rules. • Then the entity plus some security-related data are processed by S/MIME to produce PKCS object. • The PKCS object is then treated as message content and wrapped in MIME. • The message to be sent is converted to canonical form
S/MIME Messages • EnvelopedData • SignedData • Clear Signing • Registration Request • Certification-Only messages
S/MIME Certificate processing • S/MIME uses Public-Key Certificates - X.509 version 3 mixed with a PGP kind of web of trust. The certificates are signed by CA • User AgentFunctions: • Key Generation - Diffie-Hellman, DSS, and RSA key-pairs. • Registration - Public keys must be registered with X.509 CA. • Certificate Storageand retrieval- Local (as in browser application) for different services. • Signed and Enveloped Data - Various orderings for encrypting and signing.
Verisign - Digital ID Contents • Owner’s public key • Owner’s name or alias • Expiration date • serial number • name of the CA that issued Digital ID • digital signature of that CA • sometimes : • user supplied address • e-mail address • basic registration info
Classes of Verisign security for public-key certificates • Class-1: Buyer’s email address confirmed by emailing vital info. • Class-2: Postal address is confirmed as well, and data checked against directories. • Class-3: Buyer must appear in person, or send notarized documents.
Future Enhanced Security Services • Signed receipts - for proof of delivery • Security labels - to specify access restriction, sensitivity of the message contents, • secure mailing lists - using the services of an S/MIME Mail List Agent for encryption
Recommended Web Sites • PGP home page: www.pgp.com • International PGP: www.pgpi.org • MIT distribution site for PGP • Gnu Privacy Guard: www.gnupg.org • www.cosc.brocku.ca/Docs/GPG • S/MIME Central: RSA Inc.’s Web Site