1 / 19

Email Security

Email Security. CSIS 5857: Encoding and Encryption. Pretty Good Privacy. First comprehensive cryptosystem designed for use by private individuals Singlehandedly developed by Phillip Zimmermann Provides email confidentiality and authentication Solves many difficult problems:

sue
Download Presentation

Email Security

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 Security CSIS 5857: Encoding and Encryption

  2. Pretty Good Privacy • First comprehensive cryptosystem designed for use by private individuals • Singlehandedly developed by Phillip Zimmermann • Provides email confidentiality and authentication • Solves many difficult problems: • How can key management and security be implemented on simple PCs? • How trust about the correctness of public keys be established without certification authorities?

  3. PGP Message Contents Alice sends email to Bob containing: • Symmetric session key encrypted with Bob’s public key • Message (compressed for efficiency) encrypted with the session key • Message hashed to form a digest, signed with Alice’s private key, and encrypted with the session key • IDs to indicate which encryption algorithms used

  4. PGP Message Contents When Bob receives the message: • Determines which encryption algorithms Alice used • Uses his private key to decrypt the session key • Uses the session key to decrypt the message and digest • Uses Alice’s public key to decrypt the digest • Hashes the message to make sure it matches the digest

  5. PGP Algorithms

  6. PGP Key Management • Each user has: • Public key ring of other people’s public keys • Private key ring of own private keys • May use different keys to communicate with different people

  7. Private Key Ring • Indexed by user and key ID • Encrypted on user’s machine

  8. Public Key Ring • User ID = email of person whose key this is • Certificate containing public key • Trusts/Legitimacy determined by “web of trust”

  9. Key Use by Sender • Alice indicates private and public keys to use • PGP prompts for passphrase to access private key ring • Hash of passphrase used as decryption key • Alice hits keys to generate “random” session key

  10. Key Use by Recipient • Bob retrieves ID of private and public keys used from message • PGP looks up keys in Bob’s key ring • Prompts for passphrase to decrypt the private key

  11. Trust Levels in PGP • No central CA assumed in PGP • User indicates trust in a certificate based on: • Provider: entity who provided and/or signed the certificate • Other criteria, such as how certificate provided (in person, over phone, over email, etc.) • PGP Trust Levels: • Full • Partial • None

  12. Introducers and Trust Levels • Users can indicate trust level in certificate providers • That trust level automatically assigned to any certificates they provide Tina’s certificate Ted’s certificate Catbert’s certificate

  13. Key Legitimacy • Points for key legitimacy assigned based on trust level • Full = 1 point • Partial = ½ point • None = 0 points • A certificate must be fully trusted before use

  14. Key Legitimacy • Each signer adds to the trust level • A certificate signed by 2 partially trusted providers is fully trusted Ted’s certificate Ted’s certificate

  15. Alternative Trust Measures • User can directly assign certificate full trust if: • Signed by recognized CA • Provided in face to face meeting • Provided over phone • Must be able to recognize voice! • Difficult in practice since keys are long • Sent over email and digest verified over phone • Sender and recipient create short digest of key • 16 byte MD5  8 ASCII chars • 20 byte SHA-1  10 ASCII chars • Recipient calls sender to verify key • Chars in digest read over phone by sender

  16. PGP “Web of Trust” • “Networks” of trusted entities can form rapidly • The more providers you trust, the easier it is to build larger lists of trusted certificates

  17. Domain Keys Identified Mail • Proposed Internet Standard RFC 4871, has been widely adopted • Goal: Minimize fake email sent • Email purportedly from another user trusted by recipient • Spam, fraud, viruses, etc. • Signing/validation done at provider level • Individual users do not need to be involved in process

  18. Internet Mail Architecture Email sent to mail server of recipient’s ISP Mail client software sends email contents to sender’s ISP Recipient retrieves email from their ISP’s server Sender composes mail in mail client software

  19. DKIM Authentication • Sender submits email to their ISP’s server • Email signed by sending server using their public key • Receiving ISP requests certificate from sendingISP • Receiving ISP validatessignature using sender’s public key • Recipient only receivesvalidated email

More Related