1 / 23

Email Security Pretty Good Privacy (PGP)

Email Security Pretty Good Privacy (PGP). Introduction. Email is one of the most heavily used network-based application. There are two widely used schemes for providing authentication and confidentiality for email security, PGP and S/MIME. SMTP

clashbrook
Download Presentation

Email Security Pretty Good Privacy (PGP)

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Email SecurityPretty Good Privacy (PGP)

  2. Introduction • Email is one of the most heavily used network-based application. • There are two widely used schemes for providing authentication and confidentiality for email security, PGP and S/MIME. SMTP • Internet email is originally based on SMPT-protocol (Simple Mail Transfer Protocol) • SMPT transfers a message consisting of header lines and a body (all ASCII) using a packet relay network. • SMPT does not have any security services. The messages can easily be read or modified. Also the senders address of routing information is easy to change. MIME • ”Multipurpose Internet Mail Extensions” is an extension to solve many limitations of using text-based messages and SMPT. • MIME does not have security sercvices either.

  3. PGP • PGP - confidentiality and authentication services - used for file storage and electronic mail applications. • developed by Phil Zimmermann in 1991. • free versions of PGP over the Internet for non-commercial use., latest (Jan. 2000) current version is 6.5. • At the close of 1999, Network Associates, Inc. - full license by the U.S. Government to export PGP world-wide. • PGP enables - make our own public and secret key pairs. • PGP public keys are distributed and certified via an informal network called "the web of trust".

  4. PGP • PGP - very secure if used correctly. • based on RSA, DSS, Diffie-Hellman in the public encryption side • CAST.128, IDEA, 3DES for conventional encryption. • Hash coding is done with SHA-1. • wide range of applicability from corprorations to individuals for secure communication over the interent.

  5. PGP – Operational description • PGP consists of five services: authentication, confidentiality, compression, e-mail compatibility and segmentation Authenticaiton • The digital signature service • EC is used for conventional encryption, DC for decryption, and EP and DP correspondingly for public key encryption and decryption. • The algorithms used are SHA-1 and RSA. • Digital signatures can be generated using DSS/SHA-1. • Normally digital signatures are attached to the files they sign, but there are exceptions • a detached signature can be used to detect a virus infection of an executable program. • sometimes more than one party must sign the document. • a separate signature log of all messages is maintained

  6. PGP – Operational description Confidentiality • for storing files locally or transmitting them over insecure channel. • The algorithms used are CAST-128 or alternatively IDEA or 3DES. The ciphers run in CFB mode. • Each conventional key is used only once. • new key - a random 128-bit number for each message. • encrypted with the receivers public key (RSA) and attached to the message. • alternative to using RSA - ELGamal, a variant of Diffie-Hellman providing also encryption/decryption, can be used. • The use of conventional encryption is fast compared to encryption the whole message with RSA. • The use of public key algorithm solves the use session key distribution problem.

  7. PGP – Operational description Confidentiality and authentication • Firs a signature is generated for the message and prepended to the message. Then conventional enctryption is applied to message and signature. Finally the session key is encrypted using RSA. • The order of operations is important: the signature must be computed from the plaintext message. Otherwise a third party would need the session key to verify the signature.

  8. PGP – Operational description Compression • As a default PGP compresses the message after the signature but before encryption • The signature is generated before compression for two reasons • it now suffices to store only the plaintext version plus signature for later verification. • PGP’s compression algorithm is not deterministic; various implementations of the algorithm achieve different tradeoff in running speed and compression rate. Thus recompression for the verification would not work if the signature was generated from the compressed message.

  9. PGP – Operational description E-mail compatibility • Encrypted parts of the message form a stream of 8-bit octets. PGP uses aradix-64 conversion to convert this stream into printable ASCII characters. • The length of the converted part of the message increases by 33%. • As an option, radix-64 conversion can be applien only to the signature if the message is in plaintext. This enables a non-PGP recipient to read the message. Segmentation and reassembly • PGP automatically subdivides messages into segments that are small enough to be sent via email. In the receiving end, the reassembly is also automatic.

  10. S/MIME • de-facto industry standard for secure mail over the Internet. • MIME is an extension to the RFC 822 • addresses many limitations of SMTP. • MIME specification includes • new message headers • a number of content formats supproting multimedia electronic mail • transfer encodings

  11. SMTP limitations • Cannot transmit executable files • Cannot transmit national language text (8 bit representation) • Reject messages over certain size • Gateway translation problem between ASCII and EBCDIC • Cannot handle non textual messages in X.400 E-Mail • Common problems like deletion, truncation, linefeed, padding – not adhered in standard

  12. S/MIMIE Header Fields

  13. MIME Transfer Encoding

  14. S/MIME Functionality (messages) • ability to sign and/or encrypt messages. S/MIME Functions • Enveloped data - encrypted content and encryption keyys for one or more receipients. • Signed data: digital signature and then encryption with the private key. The content plus signature are then encoded using base64 encoding, only be viewed by a recipient with S/MIME capability. • Clear-signed data: a digital signature of the content, encoded using base 64. recipients without S/MIME capability can view the message content, but cannot verify the signature. • Signed and enveloped data: Signed-only and encrypted-only entities may be nested, encrypted data may be signed and signed data or clear-signed data may be encrypted.

  15. S/MIME – cryptographic algorithms • two requirement levels: • MUST - an absolute requirement in order to be in conformance with the specification. • SHOULD – an implementation to ignore this feature for valid reasons. • incorporates three public-key algorithms • DSS is recommended. • ElGamal (a varition of D-H that allows also encryption) or RSA as alternatives • recommended hash-function - SHA-1. alternative MD5. • For message encryption, three-key triple DES , All compliant implementations must support RC2 using a key of only 40 bits, (a weak encryption algorithm)

  16. S/MIME Content Types

  17. S/MIME – Certificate Processing • uses public key certificates that conform to X.509v3 directory services. • public key management scheme - hybrid between the strict X.509 certification hierarchy and PGP’s ”web of trust”. • administrators/users must configure each client with a list of trusted keys and certificate revocation lists.

  18. S/MIME – Certificate Processing User’s role • An S/MIME user has several key-management functions to perform • Key generation: the user MUST be able to generate DSS and D-H key pairs and SHOULD be able to generate RSA key pairs. • Registration: a user’s public key must be registered with a CA in order to receive an X.509 certificate. • Certificate storage and retrieval: a list of certificates can be maintained by the user or some local administrative entity.

More Related