Chapter 5 Electronic mail security 1 Outline

Chapter 5 Electronic mail security 1

Outline • Pretty good privacy • S/MIME • Recommended web sites 2

q Secure e-mail Alice wants to send confidential e-mail, m, to Bob. KS m KS K (. ) S + . K B( ) K+ B KS(m ) + + KB(KS ) . K S( ) - Internet + KB(KS ) m KS - . K B( ) KB Alice: q q 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. 3

q Secure e-mail Alice wants to send confidential e-mail, m, to Bob. KS m KS K (. ) S + . K B( ) K+ B KS(m ) + + KB(KS ) . K S( ) - Internet + KB(KS ) m KS - . K B( ) KB Bob: q uses his private key to decrypt and recover K S q uses KS to decrypt KS(m) to recover m 4

Secure e-mail (continued) • Alice wants to provide sender authentication message integrity. m H(. ) KA - . K A( ) - - KA(H(m)) + + KA Internet m m + . K A( ) H(m ) compare . H( ) H(m ) • Alice digitally signs message. • sends both message (in the clear) and digital signature. 5

Secure e-mail (continued) • Alice wants to provide secrecy, sender authentication, message integrity. m . H( ) KA - . K A( ) - KA(H(m)) + . K S( ) m KS KS + . K B( ) K+ B + Internet + KB(KS ) Alice uses three keys: her private key, Bob’s public key, newly created symmetric key 6

Pretty good privacy (PGP) A PGP signed message: • Internet e-mail ---BEGIN PGP SIGNED MESSAGE-encryption scheme, de- Hash: SHA 1 facto standard. • uses symmetric key Bob: My husband is out of town tonight. Passionately cryptography, public yours, Alice key cryptography, hash function, and digital ---BEGIN PGP SIGNATURE--signature as described. Version: PGP 5. 0 Charset: noconv • provides secrecy, yh. HJRHh. GJGhgg/12 Ep. J+lo 8 g. E 4 v. B 3 mq. Jh. FEv. ZP 9 t 6 n 7 G 6 m 5 Gw 2 sender authentication, ---END PGP SIGNATURE--integrity. 7

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

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 9

Operational Description • Consist of five services: – – – Authentication Confidentiality Compression E-mail compatibility Segmentation 10

11

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 5 A) 12

E-mail Compatibility • The scheme used is radix-64 conversion (see appendix 5 B). • The use of radix-64 expands the message by 33%. 13

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

Summary of PGP Services 15

16

Format of PGP Message 17

18

19

20

The Use of Trust • Key legitimacy field • Signature trust field • Owner trust field See Table 5. 2 (W. Stallings) 21

22

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

S/MIME • Secure/Multipurpose Internet Mail Extension • S/MIME will probably emerge as the industry standard. • PGP for personal e-mail security 24

Electronic Mail 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 outgoing message queue user mailbox user agent mail server SMTP mail server user agent SMTP user agent mail server user agent 25

Electronic Mail: mail servers Mail Servers user agent • mailbox contains incoming messages for mail server user • message queue of SMTP outgoing (to be sent) mail messages SMTP • SMTP protocol between SMTP mail servers to send mail email messages server – client: sending mail user server agent user – “server”: receiving agent mail server user agent 26

SMTP [RFC 2821] • 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 27

Mail message format SMTP: protocol for exchanging email msgs RFC 822: standard for text message format: • header lines, e. g. , – To: – From: – Subject: different from SMTP commands! header blank line body • body – the “message”, ASCII characters only 28

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) 29

Multimedia extensions • MIME: multimedia mail extension, RFC 2045, 2056 • additional lines in msg header declare MIME content type MIME version method used to encode data multimedia data type, subtype, parameter declaration encoded data From: alice@crepes. fr To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version: 1. 0 Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data 30

MIME types Content-Type: type/subtype; parameters Text • example subtypes: plain, html Image • example subtypes: jpeg, gif Audio • example subtypes: basic (8 -bit mu-law encoded), 32 kadpcm (32 kbps coding) Video • example subtypes: mpeg, quicktime Application • other data that must be processed by reader before “viewable” • example subtypes: msword, octet-stream 31

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: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data --98766789 -- 32

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) 33

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

Algorithms Used • Message Digesting: SHA-1 and MD 5 • Digital Signatures: DSS • Secret-Key Encryption: Triple-DES, RC 2/40 (exportable) • Public-Private Key Encryption: RSA with key sizes of 512 and 1024 bits, and Diffie. Hellman (for session keys). 35

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 RC 2/40 36

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 37

S/MIME Messages • • • Enveloped. Data Signed. Data Clear Signing Registration Request Certification-Only messages 38

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 Agent. Functions: – Key Generation - Diffie-Hellman, DSS, and RSA key-pairs. – Registration - Public keys must be registered with X. 509 CA. – Certificate Storage and retrieval- Local (as in browser application) for different services. – Signed and Enveloped Data - Various orderings for encrypting and signing. 39

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 40

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

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 42

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 43