1 / 50

Mehrdad Nourani

Mehrdad Nourani. Data & Network Security. Electronic Mail Security. Session 16. Pretty Good Privacy (PGP). Email Security. email is one of the most widely used and regarded network services currently message contents are not secure emails are like postcards, anyone can look at it

kim-hinton
Download Presentation

Mehrdad Nourani

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. Mehrdad Nourani Data & Network Security

  2. Electronic Mail Security Session 16

  3. Pretty Good Privacy (PGP)

  4. Email Security • email is one of the most widely used and regarded network services • currently message contents are not secure • emails are like postcards, anyone can look at it • may be inspected either in transit • or by suitably privileged users on destination system

  5. Email Security Enhancements • confidentiality • protection from disclosure • authentication • of sender of message • message integrity • protection from modification • non-repudiation of origin • protection from denial by sender

  6. Pretty Good Privacy (PGP) • widely used de facto secure email • developed by Phil Zimmermann • selected best available crypto algorithms to use • integrated into a single program • available on Unix, PC, Macintosh and Amiga systems • originally free, now have commercial versions available also

  7. Summary of PGP Services

  8. PGP Operation – Authentication • sender creates a message • SHA-1 is used to generate 160-bit hash code of message • hash code is encrypted with RSA using the sender's private key, and the result is attached to message • receiver uses RSA or DSS with sender's public key to decrypt and recover hash code • receiver generates new hash code for message and compares with decrypted hash code, if match, message is accepted as authentic Compression using ZIP Public-Key Encryption Public-Key Decryption

  9. PGP Operation – Confidentiality • sender generates message and random 128-bit number to be used as session key for this message only • message is zipped and encrypted, using CAST-128 / IDEA/3DES with session key • session key is encrypted using RSA with recipient's public key, then attached to message • receiver uses RSA with its private key to decrypt and recover session key • session key is used to decrypt message EKUb[Ks] Symmetric Encryption Ks Symmetric Decryption

  10. PGP Operation–Confidentiality & Authentication • uses both services on same message • create signature & attach to message • encrypt both message & signature • attach RSA encrypted session key Ks

  11. PGP Operation – Compression • uses ZIP compression algorithm • by default PGP compresses message after signing but before encrypting • Encryption after compression strengthen cryptographic security. Because the compressed message has less redundancy than the original plaintext, cryptanalysis is more difficult.

  12. PGP Operation – Compression (cont.) • so can store uncompressed message & signature for later verification. • If one signs a compressed document, then it would be necessary either to store the compressed version of message or to recompress it for verification. • because compression is non deterministic. Various implementation of compression algorithm may produce different compressed forms. • This causes difficulty if we try to “recompress”. However, all these compression algorithms are interoperable because any version of algorithm can correctly decompress the output of any other version.

  13. Data Compression Using ZIP • ZIP and its variations (including PKZIP, gzip, zipit, etc.) is based on LZ77 developed in 1977 by Abraham Lempel and Jacob Ziv. • LZ77 exploits the fact that words and phrases within a text stream (or image patterns like in GIF) are likely to be repeated. And when repeated they can be replaced by a shorter code. • Process: • Each character is mapped into a 9-bit pattern (“1”+8-bit ASCII) • It looks for repetition. When happens, it continues to scan to find the maximum size of repetition. • The repetition sequence is replaced by (option, pointer, length). • Option: 00=8-bit pointer/4-bit length ; 01=12-bit pointer/6-bit length • Pointer: pointing to the prior sequence that match is found • Length: the length of sequence that matches

  14. LZ77 Example • Example: Original text needs 53 bytes (424 bits) and the compressed one needs 35 9-bit characters and two 14-bit codes, i.e. (35x9)+(2x14)=343 bits. • This means compression ratio of 424/343=1.24.

  15. LZ77 Implementation • Most implementations of LZ77 use sliding and look-ahead buffers. They try to scan and match sequences. • Drawback: For small windows, many possible match will not be noticed (characters are thrown out during scan). If large window is used, the algorithm needs large scan time and large pointers.

  16. PGP Operation – Email Compatibility • when using PGP will have binary data to send (encrypted message etc.) • however email was designed only for text • hence PGP must encode raw binary data into printable ASCII characters • uses radix-64 algorithm • maps 3 octets (bytes) to 4 printable characters • also appends a CRC • it may expand the message by 33% (ZIP reduces it by 50%, therefore overall compression will be about one third: 1.33 x 0.5=0.665) • PGP also segments messages if too big (many email facilities impose a maximum of 50000 bytes on emails and larger than that must be broken)

  17. Radix-64 Encoding

  18. PGP Operation – Summary

  19. PGP Session Keys • need a session key for each message • of varying sizes: 56-bit DES, 128-bit CAST or IDEA, 168-bit Triple-DES • generated using ANSI X12.17 mode • uses random inputs taken from previous uses and from keystroke information (timing and actual keys) by user • 16 octets K[0…15] contain the session key. K[16…23] contain an IV. (See details in Appendix 15C) 8 bytes 8 bytes 24 bytes

  20. PGP Public & Private Keys • since many public/private keys may be in use, need to identify which is actually used to encrypt session key in a message • could send full public-key with every message • but this is inefficient • rather use a key identifier based on key • is least significant 64-bits of the key • will very likely be unique • also use key ID in signatures

  21. PGP Key Rings • In PGP, each user is allowed to have multiple public/private keys (for different correspondence groups or to enhance security). To clarify which one is actually used: • Send public key with the message (works but wasteful) • Define a key ID for each public key and send only that. • In PGP, the key ID of a public key is its least significant 64 bits, i.e. key ID of KUa=KUa mod 264. • each PGP user has a pair of key rings: • public-key ring contains all the public-keys of other PGP users known to this user, indexed by key ID • private-key ring contains the public/private key pair(s) for this user, indexed by key ID & encrypted keyed from a hashed pass-phrase

  22. Format of PGP Message (from A to B)

  23. PGP Key Management • rather than relying on certificate authorities • in PGP every user is own CA • can sign keys for users they know directly • forms a “web of trust” • trust keys have signed • can trust keys others have signed if have a chain of signatures to them • key ring includes trust indicators • users can also revoke their keys

  24. Structure of Public/Private Key Rings Public/private key pair Typically user’s email • public-key ring contains all the public-keys of other PGP users known to this user, indexed by key ID • private-key ring contains the public/private key pair(s) for this user, indexed by key ID & encrypted keyed from a hashed pass-phrase

  25. Why Encrypting Private Key? • To make the value of private key as secure as possible, this key is encrypted using CAST-128 (or IDEA or 3DES). • The procedure: • User selects a passphrase • When the system generate a new public/private key pair using RSA, it asks user for the passphrase. Using SHA-1, a 160-bit hash code is generated from the passphrase and the passphrase is discarded. • The system encrypts the private key using CAST-128 with the 128 bits of the hash code as the key. The hash code is then discarded, and the encrypted private key is stored in the private-key ring. • When the user accesses the private-key ring to retrieve a private key he must supply the passphrase. PGP will retrieve the encrypted private key, generate the hash code of the passphrase and decrypt the encrypted private key using CAST-128 with the hash code.

  26. PGP Message Generation (from A to B) • Sign the message (a) PGP retrieves the sender’s private key from the private-key ring using your_userid as an index. If your_userid was not provided, the first private key is used. (b) PGP prompts the user for the pass-phrase to recover the unencrypted private key. (c) the signature component of the message is constructed • Encrypt the message: (a) PGP generates a session key and encrypt the message (b) PGP retrieves the recipient’s public key form the public-key ring using her_userid as an index (c) the session key component of the message is constructed.

  27. Z PGP Message Generation (from A to B)

  28. PGP Reception (from A to B) • Encrypt the message: • PGP retrieves the receiver’s private key from the private-key ring using the key ID in the session key component as an index. • PGP prompts the user for the pass-phrase to recover the unencrypted private key. • PGP recovers the session key and decrypt the message • Authenticate the message: • PGP retrieves the sender’s public key form the public-key ring using the key ID field in the signature key component of he message as an index • PGP recovers the transmission message digest (i.e. 160-bit SHA-1 digest) • PGP computes the message digest for the received message and compares it to the transmitted message digest for authentication

  29. Z-1 PGP Reception (from A to B)

  30. Additional Features • Public key management is still an issue. User A must build up a public-key ring. • If A gets B’s public key from a bulletin board that is already compromised by C, then A does not have the right public key. • See book for guidelines as to how manage the public-key ring. • PGP asks user for his assessment of the “trust” to be assigned to the owner of a key. Trust fields/flags can be ultimate trust or unknown user, etc. • If a user’s private key is compromised, he should disseminate a special certificate to all possible users as soon as possible that they change his key in their public-key ring. • To revoke a public key, user uses his private key to issue a normal signature certificate that includes a special indicator. This indicator says that the purpose of this certificate is to revoke the use of public key.

  31. Secure/Multipurpose Internet Mail Extensions (S/MIME)

  32. S/MIME • S/MIME (Secure/Multipurpose Internet Mail Extensions) • security enhancement to MIME email standard • original Internet RFC822 email was text only • MIME provided support for varying content types and multi-part messages • with encoding of binary data to textual form • S/MIME added security enhancements • have S/MIME support in various modern mail agents: MS Outlook, Netscape, etc. • It appears that S/MIME will become industry standard and PGP will be for personal email use

  33. SMTP vs. MIME • SMTP (Simple Mail Transfer Protocol) is the main format for email messages • RFC 822 defines a format for email text messages based on SMTP • Header (From, To, Subject, Date, cc, …) • Body (the content of email) • MIME is an extension of RFC822 to address some of limitations in SMTP that includes: • Cannot transfer binary files by email • Can work only with 7-bit ASCII (code values 0 through 127) not 8-bit codes (values 128 to 255 for national languages) • May reject large emails • Translation problem between ASCII and EBCDIC • Problems with carriage return, linefeed, truncating/wrapping lines, dealing with tabs and space characters, etc.

  34. Overview of MIME • Five new message headers are added to add new features for content formats, transfer encodings, etc.: • MIME Version • MIMIE-Version-1.0in the header means it conforms RFCs 2045 and 2046) • Content Type • information about the data in the body such that the receiving user system can pick the appropriate mechanism to represent data (or deal with it) • Content-Transfer Encoding • type of transformation used to represent the body • Content ID • identifies MIME entities in a unique way • Content Description • text description of the object in the body (when it is unreadable like audio data, etc.)

  35. MIME Content Types (RFC 2046) 15 subtypes (see text book for examples)

  36. MIME Transfer Encoding Nature of Data (No Encoding) Vendor-specific or application-specific encoding method Two conventional Encodings (See book for details)

  37. MIME Message Structure (RFC 2045)

  38. MIME Message Structure (cont.) Non-ASCII

  39. S/MIME Functions • enveloped data • encrypted content and associated keys • signed data • encoded message + signed digest (uses digital signature concept and base64 encoding. The message can be viewed only by a recipient with S/MIME capability) • clear-signed data • cleartext message + encoded signed digest (recipient without S/MIME can view the message but cannot verify the signature) • signed & enveloped data • nesting of signed & encrypted entities (encrypted data may be signed and signed data may be encrypted)

  40. S/MIME Cryptographic Algorithms • hash functions: • 160-bit SHA-1 • 128-bit (recommended) MD5 • digital signatures: • DSS • RSA • session key encryption: • ElGamal (a variant of Diffie-Hellman) • RSA • message encryption: • 3DES • 40-bit RC2 (not very secure but compliant with US control) • Others (have a procedure to decide which algorithms to use – see pp. 465 of book for details of procedure)

  41. S/MIME Cryptographic Algorithms (cont.)

  42. S/MIME Messages • There are a number of new MIME content types denoted by PKCS. • PKCS refers to a set of public-key cryptography specifications issued by RSA lab and made available for S/MIME. • PKCS object: MIME entity + security-related data like algorithm, certificate, signature, etc. + MIME header in clear

  43. Preparing EnvelopedData Entity • Generate a pseudorandom session key for a particular symmetric encryption algorithm • RC2/40 or 3DES • For each recipient, encrypt the session key with the recipient’s public RSA key • For each recipient, prepare a block known as RecipientInfo that contains: • an identifier of the recipient’s public key (e.g. X.509 certificate) • an identifier of the algorithm to encrypt the session key • the encrypted session key. • Encrypt the message content with the session key

  44. Preparing SignedData Entity • Select the message digest algorithm • SHA or MD5 • Compute the message digest, or hash function, of the content to be signed • Encrypt the message digest with the signer’s private key • Prepare the SignerInfo block that contains: • the signer’s public key certificate • an identifier of the message digest algorithm • an identifier of the algorithm used to encrypt the message digest • the encrypted message digest.

  45. Clear Signing • The message will be in clear. Thus, recipients with MIME capabilities (and not S/MIME capabilities) are able to read the incoming message. • A multipart/signed message has two parts: • 1. Any MIME type that is prepared so that it will not be altered during transfer from source to destination • E.g. if the first part is not 7-bit, then base64 or quoted printable should be used . • This part is then processed same as SignedData with an empty message content field. This is called a detached signature. • 2. The detached signature is transfer encoded using base64 to become the second part. The second part has a MIME content type of application and a subset of pkcs7-signature. • The receiver can verify the signature by taking the message digest of the first part and compare it to the message digest recovered from the signature in the second part.

  46. S/MIME Certificate Processing • S/MIME uses public-key certificate that conforms X.509 v3 certificates • managed using a hybrid of: • a strict X.509 CA hierarchy & • PGP’s web of trust • Like in PGP, each client has • a list of trusted CA’s certificates & • public/private key pairs & certificates • certificates must be signed by trusted CA’s

  47. Certificate Authorities • There are several well-known CA’s (e.g. Nortel, VeriSign, GTE, US postal service, etc.) • VeriSign one of most widely used • VeriSign issues several types of certificate (called VeriSign Digital IDs • At a minimum (mandatory part) each Digital ID contains: • Owner’s public key • Owner’s name or alias • Expiration data of Digital ID • Serial number of Digital ID • Name of the certificate authority that issued the Digital ID • Digital signature of the certification authority that issued the Digital ID

  48. Certificate Authorities (cont.) • Optional parts of Digital IDs contain other user-supplied information including • Address • Email address • Basic registration information (country, zip code, age, gender, etc.) • with increasing levels of checks & hence trust Class Identity Checks Usage 1 name/email check web browsing/email 2+ enroll/addr check email, subs, s/w validate 3+ ID documents e-banking/service access

  49. VeriSign Public-Key Certificate Classes Confirmation by postal address

  50. Summary • have considered: • secure email • PGP • S/MIME

More Related