BAIT1103 Chapter 5
- 1. Chapter 5 Electronic Mail Security
- 2. objectives • Present an overview of the operation of PGP (Pretty Good Privacy). • Present an overview of MIME (Multipurpose Internet Mail Extension). • Understand the functionality of S/MIME (Secure/Multipurpose Internet Mail Extension) and the security threats it addresses.
- 3. Pretty Good Privacy (PGP) • Provides a confidentiality and authentication service that can be used for electronic mail and file storage applications • Developed by Phil Zimmermann • Selected the best available cryptographic algorithms as building blocks • Integrated these algorithms into a general-purpose application that is independent of operating system and processor and that is based on a small set of easy-to-use commands • Made the package and its documentation, including the source code, freely available via the Internet, bulletin boards, and commercial networks • Entered into an agreement with a company to provide a fully compatible, low-cost commercial version of PGP
- 4. PGP Growth It is available free worldwide in versions that run on a variety of platforms The commercial version satisfies users who want a product that comes with vendor support It is based on algorithms that have survived extensive public review and are considered extremely secure It has a wide range of applicability It was not developed by, nor is it controlled by, any governmental or standards organization Is now on an Internet standards track, however it still has an aura of an antiestablishment endeavor
- 5. Table 8.1 Summary of PGP Services The actual operation of PGP, as opposed to the management of keys, consists of four services: authentication, confidentiality, compression, and e-mail compatibility
- 7. PGP Authentication • Combination of SHA-1 and RSA provides an effective digital signature scheme • Because of the strength of RSA the recipient is assured that only the possessor of the matching private key can generate the signature • Because of the strength of SHA-1 the recipient is assured that no one else could generate a new message that matches the hash code • As an alternative, signatures can be generated using DSS/SHA-1 • Detached signatures are supported • Each person’s signature is independent and therefore applied only to the document
- 8. 1. The sender creates a message. 2. SHA-1 is used to generate a 160-bit hash code of the message. 3. The hash code is encrypted with RSA using the sender’s private key, and the result is prepended to the message. 4. The receiver uses RSA with the sender’s public key to decrypt and recover the hash code. 5. The receiver generates a new hash code for the message and compares it with the decrypted hash code. If the two match, the message is accepted as authentic.
- 9. PGP Confidentiality • Provided by encrypting messages to be transmitted or to be stored locally as files • In both cases the symmetric encryption algorithm CAST-128 may be used • Alternatively IDEA or 3DES may be used • The 64-bit cipher feedback (CFB) mode is used In PGP each symmetric key is used only once • Although referred to as a session key, it is in reality a one-time key • Session key is bound to the message and transmitted with it • To protect the key, it is encrypted with the receiver’s public key • As an alternative to the use of RSA for key encryption, PGP uses ElGamal, a variant of Diffie-Hellman that provides encryption/decryption
- 10. 1. The sender generates a message and a random 128-bit number to be used as a session key for this message only. 2. The message is encrypted using CAST-128 (or IDEA or 3DES) with the session key. 3. The session key is encrypted with RSA using the recipient’s public key and is prepended to the message. 4. The receiver uses RSA with its private key to decrypt and recover the session key. 5. The session key is used to decrypt the message.
- 11. PGP Confidentiality and Authentication • Both services may be used for the same message • Create signature and attach to message • Encrypt both message and signature • Attach RSA (or ElGamal) encrypted session key • When both services are used: The sender first signs the message with its own private key Then encrypts the message with a session key And finally encrypts the session key with the recipient’s public key
- 12. 1. 2. A signature is generated for the 1. plaintext message and prepended to the message The plaintext message plus 2. signature is encrypted using CAST-128 (or IDEA or 3DES) and the session key is encrypted 3. using RSA (or ElGamal) Encrypting the message and then generate a signature for the encrypted message. It is generally more convenient to store a signature with plaintext message. If the signature is performed first, 3rd party need not concerned with the symmetric key when verifying the signature.
- 13. PGP Compression • As a default, PGP compresses the message after applying the signature but before encryption • This has the benefit of saving space both for e-mail transmission and for file storage • The placement of the compression algorithm is critical • Applying the hash function and signature after compression would constrain all PGP implementations to the same version of the compression algorithm • Message encryption is applied after compression to strengthen cryptographic security • The compression algorithm used is ZIP
- 14. PGP E-mail Compatibility • Many electronic mail systems only permit the use of blocks consisting of ASCII text • To accommodate this restriction, PGP provides the service of converting the raw 8-bit binary stream to a stream of printable ASCII characters • The scheme used for this purpose is radix-64 conversion • Each group of three octets of binary data is mapped into four ASCII characters • This format also appends a CRC to detect transmission errors • PGP also segments messages if it is too big.
- 16. PGP OPERATION – SUMMARY
- 17. 1. On transmission (if it is required), a signature is generated using a hash code of the uncompressed plaintext. 2. Then the plaintext (plus signature if present) is compressed. 3. Next, if confidentiality is required, the block (compressed plaintext or compressed signature plus plaintext) is encrypted and prepended with the publickeyencrypted symmetric encryption key. 4. Finally, the entire block is converted to radix-64 format.
- 18. 1. On reception, the incoming block is first converted back from radix64 format to binary. 2. Then, if the message is encrypted, the recipient recovers the session key and decrypts the message. 3. The resulting block is then decompressed. 4. If the message is signed, the recipient recovers the transmitted hash code and compares it to its own calculation of the hash code.
- 19. Secure/Multipurpose Internet Mail Extension (S/MIME) • A security enhancement to the MIME Internet e-mail format standard based on technology from RSA Data Security • Defined in: • RFCs 3370, 3850, 3851, 3852 • To understand S/MIME, first to have a general understanding of the underlying e-mail format that it uses, namely MIME.
- 20. RFC 5322 internet message format • Defines a format for text messages that are sent using electronic mail • Messages are viewed as having an envelope and contents • The envelope contains whatever information is needed to accomplish transmission and delivery • The contents compose the object to be delivered to the recipient • RFC 5322 standard applies only to the contents • The content standard includes a set of header fields that may be used by the mail system to create the envelope
- 21. Multipurpose Internet Mail Extensions (MIME) • An extension to the RFC 5322 framework that is intended to address some of the problems and limitations of the use of Simple Mail Transfer Protocol (SMTP) • Is intended to resolve these problems in a manner that is compatible with existing RFC 5322 implementations • The specification is provided in RFCs 2045 through 2049 MIME specification includes the following elements: Five new message header fields are defined, which may be included in an RFC 5322 header; these fields provide information about the body of the message Transfer encodings are defined that enable the conversion of any content format into a form that is protected from alteration by the mail system A number of content formats are defined, thus standardizing representations that support multimedia electronic mail
- 22. Limitation of smtp • SMTP cannot transmit executable files or other binary objects. • SMTP cannot transmit text data that includes national language characters. • SMTP servers may reject mail message over a certain size. • SMTP gateways that translate between ASCII and the character code EBCDIC do not use a consistent set of mappings, resulting in translation problems. • SMTP gateways to X.400 electronic mail networks cannot handle nontextual data included in X.400 messages. • Some SMTP implementations do not adhere completely to the SMTP standards defined in RFC 821.
- 23. The Five Header Fields Defined in MIME MIME-Version • Must have the parameter value 1.0 • This field indicates that the message conforms to RFCs 2045 and 2046 Content-Type • Describes the data contained in the body with sufficient detail that the receiving user agent can pick an appropriate agent or mechanism to represent the data to the user or otherwise deal with the data in an appropriate manner Content-Transfer-Encoding • Indicates the type of transformation that has been used to represent the body of the message in a way that is acceptable for mail transport Content-ID • Used to identify MIME entities uniquely in multiple contexts Content-Description • A text description of the object with the body; this is useful when the object is not readable
- 24. S/MIME Functionality Enveloped data • 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 S/MIME Clear-signed data • 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
- 26. S/MIME Certificate Processing • S/MIME uses public-key certificates that conform to version 3 of X.509 • 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 • The responsibility is local for maintaining the certificates needed to verify incoming signatures and to encrypt outgoing messages • The certificates are signed by certification authorities
- 27. User Agent Role • An S/MIME user has several key-management functions to perform: Key generation Registration The user of some related administrative utility must be capable of generating separate Diffie-Hellman and DSS key pairs and should be capable of generating RSA key pairs A user’s public key must be registered with a certification authority in order to receive an X.509 public-key certificate A user agent should generate RSA key pairs with a length in the range of 768 to 1024 bits and must not generate a length of less than 512 bits Certificate storage and retrieval A user requires access to a local list of certificates in order to verify incoming signatures and to encrypt outgoing messages
- 28. VeriSign Certificates • VeriSign provides a certification authority (CA) service that is intended to be compatible with S/MIME and a variety of other applications • Issues X.509 certificates with the product name VeriSign Digital ID • At a minimum, each Digital ID contains: • • • • • • Owner’s public key Owner’s name or alias Expiration date of the Digital ID Serial number of the Digital ID Name of the certification authority that issued the Digital ID Digital signature of the certification authority that issued the Digital ID
- 29. VeriSign Certificates • Provide 3 classes(levels) of security for public-key certificates. • Example: Verisign (www.verisign.com) • 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.
- 30. Table 8.7 VeriSign Public-Key Certificate Classes IA CA PCA PIN LRAA Issuing Authority Certification Authority VeriSign public primary certification authority Personal Identification Number Local Registration Authority Administrator
- 31. Summary • Pretty good privacy • Notation • Operational description • S/MIME • RFC 5322 • Multipurpose Internet mail extensions • S/MIME functionality • S/MIME certification processing