Unit 8 email security

  • 479 views
Uploaded on

Information security

Information security

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
479
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Prof . Chintan Patel MEFGI,Rajkot Information security
  • 2. Topics…. • IP Security  IP Security overview  Architecture  Authentication Header  Encapsulating Security payload  Combining security Associations  Key management • E-mail Security  Pretty Good Privacy  S/MIME and Privacy
  • 3. • Pretty Good Privacy  Notations  Operational description  Cryptographic keys and key rings  Public key management. • S/MIME  MIME  S/MIME Functionality  S/MIME messages  S/MIME Certificate processing  Enhanced security terms
  • 4. • After web browsing, e-mail is the most widely used network-reliant application. • Mail servers, after web servers, are the most often attacked Internet hosts. • Basic e-mail offers little security, counter to public perception. • Good technical solutions are available, but not widely used.  If we understand why this is so, we might understand something about why security is ‘hard’.
  • 5. • Loss of confidentiality. • E-mails are sent in clear over open networks. • E-mails stored on potentially insecure clients and mail servers. • Loss of integrity. • No integrity protection on e-mails; anybody be altered in transit or on mail server. • Lack of data origin authentication. • Is this e-mail really from the person named in the From:field? • Lack of non-repudiation. •Can I rely and act on the content? (integrity) •If so, can the sender later deny having sent it? Who is liable if I have acted? • Lack of notification of receipt. •Has the intended recipient received my e-mail and acted on it? •A message locally marked as ‘sent’ may not have been delivered.
  • 6. • Open source freely available software package for e-mail security.  Provides authentication through digital signature  Provides Encryption of digital signature using public key cryptography  Provides confidentiality through Symmetric block encryption. EX. DES  Provides compression using ZIP Algorithm  E-Mail compatibility using radix-64 encoding scheme  Segmentation and reassembly to accommodate long e-mails.
  • 7. • Developed by Phil Zimmermann. • Provides confidentiality and authentication service that can be used for E-Mail and file storage application. • Reasons why PGP Is growing fast….  Available free world wide in version that runs on various platform  Based on algorithms which have survived extensive public review.  RSA ,DSS And diffie-hellman for public key encryption  CAST-128 ,IDEA , and 3-DES for symmetric encryption  SHA-1 For hash coding  Wide range of applicability like encryption and individual communication
  • 8. • Ks = Session key used in symmetric encryption • PRa = Private key of user A , used in Asymmetric encryption • PUa = Public key of user A , used in Asymmetric encryption • EP = Public key encryption • DP = Public key decryption • EC = Symmetric encryption • DC = Symmetric decryption • H = Hash function • || = Concatenation • Z = Compression using ZIP Algorithms • R64 = Convert to radix 64 ASCII Format.
  • 9. Digital signature DSS/SHA or RSA/SHA A hash code of a message is created using SHA-1. This message digest is encrypted using DSS or RSA with the sender's private key and included with the message. Message encryption CAST or IDEA or Three-key Triple DES with Diffie- Hellman or RSA A message is encrypted using CAST-128 or IDEA or 3DES with a one-time session key generated by the sender. The session key is encrypted using Diffie-Hellman or RSA with the recipient's public key and included with the message.
  • 10. Compression ZIP A message may be compressed, for storage or transmission, using ZIP. Email compatibility Radix 64 conversion To provide transparency for email applications, an encrypted message may be converted to an ASCII string using radix 64 conversion. Segmentation To accommodate maximum message size limitations, PGP performs segmentation and reassembly.
  • 11. • Sender creates message • SHA-1 Used for to create 160 bit hash code • Hash code is encrypted with RSA using sender’s private key and result is concatenated with message. • Receiver uses RSA with sender’s public key to decrypt and recover the hash code. • Receiver generates new hash code and compare it • Z is zip function • radix-64 conversion is done after zip at sender, before Z-1 at receiver
  • 12. • CAST-128 , IDEA , 3-DES May be used • One-time Randomly generated session key of 128 bit, Ks • Message is encrypted using CAST-128 With the session key. • The session key is encrypted with RSA , using public key and concatenated with message. • Receiver uses RSA with its Private key to decrypt and recover the session key. • Session key is used to decrypt the message. E[PUb, Ks] E[PUb, Ks]
  • 13. • uses both services on same message  create signature and attach to message  compress and encrypt both message & signature  attach encrypted session key  radix-64 conversion is for everything at the end
  • 14. • Encrypted text and signatures create binary output • however email was designed only for text  hence PGP must encode raw binary data into printable ASCII characters • uses radix-64 algorithm (See appendix 18A)  maps 3 bytes to 4 printable chars
  • 15. • Internet imposes maximum length of 50000 octets at a time. • PGP Automatically subdivides message into segments that are small enough to send via emails • After all other processing including radix-64 conversion
  • 16. • PGP Makes use of four types of Keys :  One time session symmetric keys  Public keys  Private keys  Password-based symmetric keys. • Requirements :  Generating Unpredictable session key is needed.  We would like to allow user can have multiple private and public key pairs.  Each PGP Entity must maintain a file of its own public/private key pairs as well as a file of public keys of correspondents
  • 17. • Ex. If CAST-128 Algorithm is used . Random 128 bit session key is generated using:  128 bit key and two 64 bit blocks that are plaintext.
  • 18. • “WE WANT TO ALLOW USER THAT IT MAY HAVE MULTIPLE PUBLIC/PRIVATE KEY PAIRS ” • IF YES, QUESTION : “HOW RECEIVER WILL KNOW WHICH PUBLIC KEY WAS USED TO ENCRYPT A SESSION KEY” • Solutions : 1. Also Transmit a message from sender like : “ This X public key is used” 2. To associate an identifier with each public key that is unique at least within user.  Combination of User ID and Key ID is sufficient to identify a key uniquely.
  • 19. • Solution used in PGP is : • Assign a Key ID to each public key that is very high probability that its unique within user ID. • Key ID of public key PUa is “PUa Mod 264 ”. • Key ID is also required for PGP Digital signature :  Cause sender encrypts the message digest using one of its private key ,Recipient must know which public key will be used.
  • 20. • Message component : Includes original data , file name and time stamp(Time at which file was created) • Signature component :  Time stamp : Time at which signature was created  Message Digest : 160 bit message digest , encrypted with private key of sender.  Leading two octets of Message digest : To enable receiver to determine that correct public key was used to decrypt the message digest for authentication.  Key ID of sender’s public keys. • Session key component :  Session key , identifier of the recipient’s public key.
  • 21. • Keys Must be stored in and organized in a symmetric way for efficient and effective use by all parties. • Scheme used in PGP is to provide  Pair of data structure to store the public key and private key pairs owned by that node called “Private key ring”.  Pair of data structure to store public keys of other users known at each node called “Public key Rings”.
  • 22. • Time stamp : date/time when key pair was generated • Key ID : least significant 64 bits of public key • Public key • Private key : Encrypted field of private keys. • User id : User’s email address.
  • 23. • Encrypted using CAST-128 or IDEA or 3DES. • 1. User selects passphrase(Longer password) to be used for encrypting private keys. • 2. When the system generated a new public/private key pairs using RSA. It asks the user for passphrase.  160 bit hash code is generated using passphrase and passphrase is discarded. • 3. System encrypts the private key using CAST-128 with 128 bit of hash code as key. hash code is then discarded.
  • 24. • Time stamp : date/time when entry was generated. • Key ID : least significant 64 bit • Public key • User ID
  • 25. • Ignore Compression and Radix-64 Conversion • The sending PGP entity performs the following steps:  Signs the message:  PGP gets sender’s private key from key ring using its user id as an index.  PGP prompts user for passphrase to decrypt private key.  PGP constructs the signature component of the message.  Encrypts the message:  PGP generates a session key and encrypts the message.  PGP retrieves the receiver public key from the key ring using its user id as an index.  PGP constructs session component of message
  • 26. • The receiving PGP entity performs the following steps:  Decrypting the message:  PGP get private key from private-key ring using Key ID field in session key component of message as an index.  PGP prompts user for passphrase to decrypt private key.  PGP recovers the session key and decrypts the message.  Authenticating the message:  PGP retrieves the sender’s public key from the public-key ring using the Key ID field in the signature key component as index.  PGP recovers the transmitted message digest.  PGP computes the message for the received message and compares it to the transmitted version for authentication.
  • 27. • From PGP documentation: “This whole business of protecting public keys from tampering is the most difficult problem in practical public key applications” • You have to make sure about the legitimacy of the public key of your party  exchange public-keys manually (using CDs, USB sticks, etc.)  verify fingerprint of a public key over the phone  trust another individual who signs public keys  public key signatures
  • 28. • Public keys could be signed by  Certification Authorities (CA)  trusted entities  the mechanism of S/MIME, not in PGP  in PGP each user is a CA  everybody can sign keys of users they know directly  other users’ key signatures can also be used, if those users are trusted • The only ultimately trusted entity is yourself  all other keys should either be directly signed by you or there should be a trusted path of key signatures  you reflect your own trust assessment in your public key ring (no system enforcement)  key ring includes trust indicators  “web of trust”
  • 29. • A trusted signature on a public key means that  the key really belongs to its owner • But does not mean that key owner is trusted to sign other keys  key owner can sign other keys, but their trustworthiness is determined by the verifier (the owner of the pubkey ring) • Making sure about the legitimacy of a key and trusting the key owner to find out other keys are two different concepts • Keys and signatures on them are generally obtained from PGP public keyservers  there might be several signatures on a single key
  • 30. A public key ring owned by “you” These are assigned by you
  • 31. • Defines format for text messages that are sent using E-Mail….. • Two part (1) Envelope(Contains information needed for transmission) (2) Content (Contains the header plus body part of message) • RFC 822 Applies to only content part.
  • 32. • SMTP Can not transmit executable files and binary objects. • SMTP Can not transmit text with national language characters. • SMTP limited to 7 bit ASCII and as per rule national language must be represented using 8 bit codes. • SMTP Server may rejects mail message over certain size. • SMTP gateway used for to translate ASCII and character code results in translation mapping • MIME resolves all above problem that is compatible with RFC 822 Implementation.
  • 33. • Five Header Fields in MIME :  MIME-Version : Value 1.0 indicates valid version  Content Type : Any of MIME Content types  Content transfer encoding : types of transformation that is used to represent body part  Content ID : Used to identify MIME entities uniquely.  Content-description : Text description of the object with the data. Useful when data is not readable(Ex. Audio data)
  • 34. • MIME-Version: 1.0 • To: User2@examples.com • From: aliceDss@examples.com • Subject: Example 4.8 • Message-Id: <020906002550300.249@examples.com> • Date: Fri, 06 Sep 2002 00:25:21 -0300 • Content-Type: multipart/signed; • micalg=SHA1; • boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21"; • protocol="application/pkcs7-signature" • This is a multi-part message in MIME format.------ =_NextBoundry____Fri,_06_Sep_2002_00:25:21 • This is some sample content. • ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 • Content-Type: application/pkcs7-signature; name=smime.p7s • Content-Transfer-Encoding: base64
  • 35. • Enveloped data : • Encrypted content of any type(using session key) • Encrypted session keys (using receivers public key) • Signed Data : • Encrypted Signed message digest(using private key of sender) • Content and signature encoded using base64 encoding. • Clear Signed Data : • Only Digital Signature encoded using base64 encoding. • Recipients without S/MIME capability can view the message contents but can not verify the signature • Signed and Enveloped Data : • Nested signed and encrypted entities
  • 36. • hash functions: SHA-1 & MD5 • digital signatures: DSS & RSA • session key encryption: ElGamal & RSA • message encryption: Triple-DES, AES and others • sender should know the capabilities of the receiving entity (public announcement or previously received messages from receiver)  otherwise sender takes a risk
  • 37. • For message encryption • Similar to PGP  create a random session key, encrypt the message with that key and a conventional crypto, encrypt the session key with recipient’s public key • Unlike PGP, recipient’s public key comes from an X.509 certificate  trust management is different
  • 38. S/MIME - Message Enveloped Data: Pseudorandom session key (3DES or RC2/40) ׁׁ Certificate RecipientInfo M enveloped-data + Encrypt the session key Diffie-Hellman / RSA Recipient’s public key
  • 39. • For signed message  both message and signature are encoded so that the recipient only sees some ASCII characters if he does not use an email client with S/MIME support • Similar to PGP  first message is hashed, then the hash is encrypted using sender’s private key • Message, signature, identifiers of algorithms and the sender’s certificate are packed together  again difference between S/MIME and PGP in trust management
  • 40. S/MIME - Message SignedData: M Hash function SHA-1 or MD5 Encryption Sender’s private key Certificate SignerInfo Base64 encoding
  • 41. • Another mechanism for signature  but the message is not encoded, so an email client with no S/MIME support could also view the message  of course the signature will not be verified and will be seen as a meaningless attachment • multipart/signed content type  2 parts  Clear text message  Signature
  • 42. • S/MIME uses X.509 v3 certificates  Certification Authorities (CAs) issue certificates  unlike PGP, a user cannot be a CA • each client has a list of trusted CA certificates • Our textbook says “S/MIME key management is a hybrid of a strict X.509 CA hierarchy and PGP’s web of trust”  But it is very hard for an average user to maintain the list of trusted CAs
  • 43. • One should obtain a certificate from a CA in order to send signed messages • Certificates classes (common practice by most CAs)  Class 1  Class 2  Class 3 • CA certification policies (Certificate Practice Statement)  ID-control practices  Class 1: only email address check  Class 2: class1 + against third party database / fax documents  Class 3: class1 + apply in person and submit picture IDs and/or paper documents Stronger identity validation Easier to issue