Chapter 5 Electronic mail security

Transcription

1 Chapter 5 Electronic mail security Dr. BHARGAVI H. GOSWAMI Department of Computer Science Christ University bhargavigoswami@gmail.com

2 Topic List 1. Pretty good privacy 2. S/MIME

3 Pretty Good Privacy Philip R. Zimmerman is the creator of PGP. PGP provides a confidentiality and authentication service that can be used for electronic mail and file storage applications.

4 Y named Pretty Good Privacy? Best available cryptographic algorithms. Integrated these algorithms into a generalpurpose application. Independent of operating system and processor. Easy to use commands. Made the package and its documentation, including the source code, freely available via the Internet, bulletin boards, and commercial networks such as AOL (America On Line). Entered into an agreement with a company (Viacrypt, now Network Associates) to provide a fully compatible, low-cost commercial version of PGP

5 Why Is PGP Popular? It is availiable free on a variety of platforms. Based on well known algorithms which are extremely secure. Wide range of applicability. Not developed or controlled by governmental or standards organizations. Internet Standardized RFC 3156.

6 Notations: Ks = Session Key in symmetric encryption. PRa = Private key of A. PUa = Public key of A. EP = public key encryption DP = public key decryption EC = Symmetric encryption DC = Symmetric decryption H = Hash function = Concatenation Z = Compression using ZIP algorithm R64 = Conversion to radix 64 ASCII format.

7 Operational Description Consist of five services: 1. Authentication 2. Confidentiality 3. Compression 4. compatibility 5. Segmentation

8

9

10 1. Authentication 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 prep ended 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. The combination of SHA-1 and RSA provides effective digital signature scheme. Alternative to above mentioned combination is DSS/SHA- 1.

11 2. Confidentiality 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 prep ended 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.

12 3. Compression PGP compresses the message after applying the signature but before encryption. Benefit of saving space both for transmission and for file storage. The placement of the compression algorithm is critical. The compression algorithm used is ZIP (described in appendix 5A). The signature is generated before compression for two reasons: one can store only the uncompressed message together with the signature for future verification. 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.

13 4. Compatibility The scheme used is radix-64 conversion (see appendix 5B). The use of radix-64 expands the message by 33%.

14 5. Segmentation and Reassembly Often restricted to a maximum message length of 50,000 octets. Longer messages must be broken up into segments. PGP automatically subdivides a message that is to large. The receiver strip off all headers and reassemble the block.

15

16 PGP makes use of four types of keys: one-time session symmetric keys, public keys, private keys, and Pass phrase-based symmetric keys Three separate requirements: 1. A means of generating unpredictable session keys is needed. 2. We would like to allow a user to have multiple public-key/private-key pairs. One reason is that the user may wish to change his or her key pair from time to time. 3. 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 Format of PGP Message

18 A message consists of three components: 1. message component, 2. signature (optional), and 3. session key component (optional). 1. Message Component: Includes the actual data to be stored or transmitted, as well as a filename and a timestamp that specifies the time of creation. 2. Session Key: Includes the session key and the identifier of the recipient s public key that was used by the sender to encrypt the session key.

19 3. Signature Component: includes the following: Timestamp: The time at which the signature was made. Message digest: The 160-bit SHA-1 digest encrypted with the sender s private signature key. Leading two octets of message digest: Enables the recipient to determine if the correct public key was used to decrypt the message digest for authentication by comparing this plaintext copy of the first two octets with the first two octets of the decrypted digest. These octets also serve as a 16-bit frame check sequence for the message. Key ID of sender s public key: Identifies the public key that should be used to decrypt the message digest and, hence, identifies the private key that was used to encrypt the message digest. The entire block is usually encoded with radix-64 encoding.

20 Key Rings Keys need to be stored and organized in a systematic way for efficient and effective use by all parties. For this PGP provide a pair of data structures at each node: Private-Key Ring : to store the public/private key pairs owned by that node and Public-Key Ring : one to store the public keys of other users known at this node.

21 Private Key Ring Each row represents one of the public/private key pairs owned by this user. Can be indexed by either User ID or Key ID. Private key is encrypted using CAST-128 (or IDEA or 3DES) and then stored. Each row contains the entries: Timestamp: The date/time when this key pair was generated. Key ID: The least significant 64 bits of the public key for this entry. Public key: The public-key portion of the pair. Private key: The private-key portion of the pair; this field is encrypted. User ID: Typically, this will be the user s address (e.g., stallings@acm.org). However, the user may choose to associate a different name with each pair (e.g., Stallings, WStallings, WilliamStallings, etc.) or to reuse the same User ID more than once.

22

23 Public Key Ring Store public keys of other users. Public-key ring can be indexed by either User ID or Key ID. Each row contains the entries: Timestamp: The date/time when this entry was generated. Key ID: The least significant 64 bits of the public key for this entry. Public Key: The public key for this entry. User ID: Identifies the owner of this key. Multiple user IDs may be associated with a single public key.

24 Trust Flag byte of Public key Ring Key legitimacy field:indicates the extent to which PGP will trust that this is a valid public key for this user; the higher the level of trust, the stronger is the binding of this user ID to this key. This field is computed by PGP. Signature trust field: indicates the degree to which this PGP user trusts the signer to certify public keys. Owner trust field: indicates the degree to which this public key is trusted to sign other public-key certificates; this level of trust is assigned by the user. Now the question arise, how these rings are used in message transmission and reception?

25

26 PGP Steps: Message Generation: 1. Signing the message. 2. Encrypting the message Message Reception: 1. Decrypting the message. 2. Authenticating the message.

27 PGP Message Generation: 1. Signing the message: 1. PGP retrieves the sender s private key from the private-key ring using your_userid as an index. If your_userid was not provided in the command, the first private key on the ring is retrieved. 2. PGP prompts the user for the passphrase to recover the unencrypted private key. 3. The signature component of the message is constructed. 2. Encrypting the message: 1. PGP generates a session key and encrypts the message. 2. PGP retrieves the recipient s public key from the public-key ring using her_userid as an index. 3. The session key component of the message is constructed.

28

29 PGP Message Reception 1. Decrypting the message: 1. PGP retrieves the receiver s private key from the private-key ring using the Key ID field in the session key component of the message as an index. 2. PGP prompts the user for the passphrase to recover the unencrypted private key. 3. PGP then recovers the session key and decrypts the message. 2. Authenticating the message: 1. PGP retrieves the sender s public key from the publickey ring using the Key ID field in the signature key component of the message as an index. 2. PGP recovers the transmitted message digest. 3. PGP computes the message digest for the received message and compares it to the transmitted message digest to authenticate.

30

31

32 Public Key Management: PGP contains clever, efficient, interlocking set of functions & formats to provide an effective confidentiality & authentication service. Public Key Certificate: Has following fields. Key legitimacy field: Extent to which PGP trust validity of key. Signature trust field: Degree to which PGP trust signer to certify public key. Owner trust field: Degree to which PGP trust signer to certify other certificates.

33 PUBLIC KEY RING: The figure shows the structure of a public-key ring. The user has acquired a number of public keys some directly from their owners and some from a third party such as a key server. The user (you) always trust D,E,F,L. User partially trust A & B. Tree structure indicate which key is signed by which user. Question mark indicate signatory is unknown to this user. E s key is already signed by F, user chose to sign directly. Partially trusted signatories are enough to certify key. See H partially trusted by A and B. N s key is legitimate because it is signed by E but N is not trusted to sign other keys. Although R s key is signed by N, PGP does not consider R s key legitimate. Detached orphan node S, with two unknown signatures may be acquired by key server.

34

35 Revoking Public Keys The owner issue a key revocation certificate. Normal signature certificate with a revote indicator. Corresponding private key is used to sign the certificate.

36 S/MIME

37 S/MIME: Introduction Secure/Multipurpose Internet Mail Extension. Security enhancement to the MIME Internet format standard. S/MIME will probably emerge as the industry standard whereas, PGP for personal security. To understand S/MIME we need to learn RFC822 and MIME.

38 RFC 822/5322 Defines format of text message that is sent using electronic mail. Here, messages are viewed as having an envelope and contents. Envelop contains information for transmission and delivery. Contents compose of the object to be delivered. RFC 5322 standard applies only to the contents. Has parts: Header Body Msg ID (optional) The header is separated from the body by a blank line. The most frequently used keywords are From, To, Subject, and Date. A header line usually consists of a keyword, followed by a colon, followed by the keyword s arguments. One more optional field is Message-ID. This field contains a unique identifier associated with this message. Lets take one example.

39 Example: Date: October 8, :15:49 PM EDT From: William Stallings Subject: The Syntax in RFC 5322 To: Cc: Hello. This section begins the actual message body, which is delimited from the message heading by a blank line.

40 MIME Multipurpose Internet Mail Extension (MIME). Is an extension to the RFC 5322 framework. Address some of the problems and limitations of the use of Simple Mail Transfer Protocol (SMTP). What are limitations of SMTP?

41 Simple Mail Transfer Protocol (SMTP, RFC 822) SMTP Limitations - Can not transmit, or has a problem with: executable files, or other binary files (jpeg image) national language characters (non-ascii) messages over a certain size not allowed. ASCII to EBCDIC translation problems. lines longer than a certain length (72 to 254 characters) not accommodated. Can not handle non textual data included in X.400. SMTP to RFC 821 conversion has following problems: Deletion, addition or reordering of carriage. Truncating or wrapping more than 76 char. Removal of trailing white space. Padding of lines. Converting tab to space. Solution? MIME.

42 MIME Multipurpose Internet Mail Extension. Extension to RFC 822 framework. Address some limitations of SMTP (Simple Mail Transfer Protocol). MIME Elements: Header Fields (Info about body) Content Formats (standard representation & multimedia). Transfer Encodings (conversion & security).

43 Header fields in MIME MIME-Version: Must be 1.0 as parameter value. Confirms RFC 2045, RFC 2046 Content-Type: Describes data contained mechanism & agents. More types are being added by developers (application/word) Content-Transfer-Encoding: Indicate type of transformation used to represent body of msg. How message has been encoded (radix-64). Content-ID: Unique identifying character string. Content Description: Text descriptor of object. Needed when content is not readable text (e.g.,mpeg).

44 MIME Content Types: Dealing with wide variety of information representations in multimedia environment. Lets see its types, subtypes and Description.

45

46 Example:

47

48 MIME Transfer Encoding: Objective: Provide reliable delivery across largest range of environment. Content-Transfer-Encoding field can actually take on 6 values, out of which 3 values (7bit, 8bit, binary) indicate no encoding done. MIME Transfer Encoding Types:

49

50 Native v/s Canonical form The body to be transmitted is created in system s Native format. Body may be unix style text file. Native character set is used and local end of line conversations are used. Un-standardized. Peculiar to particular system. Entire body include out of band information & file attribute information. Body may be rich text word file. Character set conversion, transformation of audio data compression are used. Standardized. Appropriate for all content type.

51 SMIME: Sub Topic List: a) S/MIME Functionality b) Cryptographic Algorithm c) S/MIME Message d) Certificate Processing

52 a) S/MIME Functions Similar to PGP. Offer ability to sign and/or encrypt message. Functions: 1. Enveloped Data: Encrypted content and encrypted session keys for recipients. 2. Signed Data: Message Digest encrypted with private key of signer. 3. Clear-Signed Data: Signed but not encrypted. 4. Signed and Enveloped Data: Various orderings for encrypting and signing.

53 b) Cryptographic Algorithms: Two Imp Terms need to be understood before moving forward: MUST: Absolute requirement of specification must include feature in implementation. SHOULD: May ignore in particular circumstances. Recommended to include feature in implementation.

54

55 c) S/MIME Message: Lets have a look over general procedures for S/MIME message preparation: 1. Securing a MIME Entity. 2. Enveloped Data. 3. Signed Data. 4. Clear Signing. 5. Registration Request. 6. Certificates-Only Message.

56 1. Securing MIME Entity: S/MIME secure MIME entity using encryption and/or signature. Step 1: With normal rules, MIME entity is prepared. Step 2: Then over that algorithm identifiers and certificates are processed by SMIME producing PKCS objects (Public Key Cryptographic Specification). Step 3: PKCS is treated as message content, wrapped around in MIME (adding headers) and sent after converting to canonical form.

57 2. Enveloped Data Object is represented in form BER (Basic Encoding Rules). Step1: Generate a pseudorandom session key for a particular symmetric encryption algorithm (RC2/40 or triple DES). Step2: encrypt the session key with the recipient s public RSA key. Step 3: prepare a block known as RecipientInfo that contains an identifier of the recipient s public-key certificate,3 an identifier of the algorithm used to encrypt the session key, and the encrypted session key. Step4: Encrypt the message content with the session key. The RecipientInfo blocks followed by the encrypted content constitute the envelopeddata. This information is then encoded into base64.

58 Eg: Content-Type: application/pkcs7-mime; smimetype=envelopeddata; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m rfvbnj756tbbghyhhhuujhjhjh77n8hhgt9hg4v QpfyF467GhIGfHfYT67n8HHGghyHhHUujhJh 4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9 Hf8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhI GfHfYT6ghyHhHUujpfyF40GhIGfHfQbnj756Y T64V

59 3. Signed Data Can be used with one or more signers. We consider single digital signature. Step 1: Select a message digest algorithm (SHA or MD5). Step 2: Compute the message digest (hash function) of the content to be signed. Step 3: Encrypt the message digest with the signer s private key. Step 4: Prepare a block known as SignerInfo that contains the signer s publickey certificate, an identifier of the message digest algorithm, an identifier of the algorithm used to encrypt the message digest, and the encrypted message digest.

60 Eg: Content-Type: application/pkcs7-mime; smimetype=signeddata; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJh jh776tbb9hg4vqbnj777n8hhgt9hg4vqpfyf 467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhj HHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6j H7756tbB9H7n8HHGghyHh6YT64V0GhIGfHfQ bnj75

61 4. Clear Signing: achieved using the multipart content type with a signed subtype. recipients with MIME capability but not S/MIME capability are able to read the incoming message. Two Parts: MIME type but must be prepared so that it will not be altered during transfer. Second part has a MIME content type of application and a subtype of pkcs7- signature.

62 Eg: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 boundary42 Content-Type: text/plain This is a clear-signed message. boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyhhhuujhjhjh77n8hhgtrfvbnj756tbb9hg4vqpfyf467ghi GfHfYT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJ h756tbb9hgtrfvbnjn8hhgtrfvhjhjh776tbb9hg4vqbnj75 67GhIGfHfYT6ghyHhHUujpfyF47GhIGfHfYT64VQbnj756 boundary42

63 5. Registration Request: an application or user will apply to a certification authority for a public-key certificate. The certification request includes Certification RequestInfo block, followed by an identifier of the public-key encryption algorithm, followed by the signature of the certificationrequestinfo block made using the sender s private key. certificationrequestinfo block includes a name of the certificate subject (the entity whose public key is to be certified) and a bit-string representation of the user s public key. 6. Certificates Only Message: A message containing only certificates or a certificate revocation list (CRL) can be sent in response to a registration request. The steps involved are the same as those for creating a signeddata message.

64 c) S/MIME Message: S/MIME secure MIME entity using encryption and/or signature. Step 1: With normal rules, MIME entity is prepared. Step 2: Then over that algorithm identifiers and certificates are processed by SMIME producing PKCS objects (Public Key Cryptographic Specification). Step 3: PKCS is treated as message content, wrapped around in MIME (adding headers) and sent after converting to canonical form.

65

66 6. S/MIME Certificate Processing: S/MIME uses public key certificates that confirm to version 3 of X.509. S/MIME managers and users must configure each client with a list of trusted keys with CRL(certificate revocation list). Sub topics: User Agent Role VeriSign Certificates Enhanced Security Services

67 Algorithms Used Message Digesting: SHA-1 and MDS Digital Signatures: DSS Secret-Key Encryption: Triple-DES, RC2/40 (exportable) Public-Private Key Encryption: RSA with key sizes of 512 and 1024 bits, and Diffie- Hellman (for session keys).

68 User Agent Role Functions: Key Generation - Diffie-Hellman, DSS, and RSA key-pairs. Registration - Public keys must be registered with X.509 CA. Certificate Storage - Local (as in browser application) for different services. Signed and Enveloped Data - Various orderings for encrypting and signing.

69 VeriSign Certificates: There are several companies that provide certification authority (CA) services compatible with S/MIME. VeriSign issues X.509 certificates with the product name VeriSign Digital ID. Over 35,000 commercial Web sites were using VeriSign Server Digital Ids in 1998.

70 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 Digital IDs can also contain other usersupplied information, including Address address Basic registration information (country, zip code, age, and gender)

71 Procedures followed: Class-1: Buyer s address confirmed by ing 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. Lets see the difference between them each three class. Remember following terms: IA = Issuing Authority CA = Certification Authority PCA = VeriSign public primary certification authority PIN = Personal Identification Number LRAA = Local Registration Authority Administrator

72

73 Enhanced Security Services: 3 enhanced security services have been proposed in an Internet draft: Signed receipt: A signed receipt may be requested in a SignedData object. Returning a signed receipt provides proof of delivery to the originator of a message. Security labels: included in SignedData object. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation. Secure mailing lists: When a user sends a message to multiple recipients, a certain amount of per-recipient processing is required. S/MIME Mail List Agent (MLA). An MLA can take a single incoming message, perform the recipient-specific encryption for each recipient, and forward the message.

74 Chapter 5/7 Ends Here So remain ready with the assignments and test. Its high time, start preparing for Network Security and other subjects. Also learn current technology like Android, Iphone, PHP,.NET.