The document discusses electronic mail security and Pretty Good Privacy (PGP). PGP provides encryption, authentication, integrity, and non-repudiation for email. It uses public/private key cryptography and symmetric encryption. PGP signs messages with the sender's private key and encrypts messages using a randomly generated symmetric session key. The session key is then encrypted with the recipient's public key and attached to the encrypted message. Recipients can authenticate messages and decrypt them using their private key to recover the session key. PGP forms a "web of trust" through key signatures rather than relying on certificate authorities. The document also discusses S/MIME, which provides similar security to PGP for email using X.509 certificates and a hybrid

1. Electronic Mail Security
1
Despite the refusal of VADM Poindexter and LtCol North to
appear, the Board's access to other sources of information
filled much of this gap. The FBI provided documents taken
from the files of the National Security Advisor and relevant
NSC staff members, including messages from the PROF system
between VADM Poindexter and LtCol North. The PROF
messages were conversations by computer, written at the
time events occurred and presumed by the writers to be
protected from disclosure. In this sense, they provide a first-
hand, contemporaneous account of events.
—The Tower Commission Report to President Reagan on the
Iran-Contra Affair, 1987

2. Email Security
2
• email is one of the most widely used and
regarded network services
• currently message contents are not secure
– may be inspected either in transit
– or by suitably privileged users on destination
system

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

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

6. PGP Operation – Authentication
6
1. sender creates message
2. make SHA-1 ,160-bit hash of message
3. attached RSA signed hash to message
4. receiver decrypts & recovers hash code
5. receiver verifies received message hash

9. PGP Operation – Confidentiality
9
1. sender forms 128-bit random session key
2. encrypts message with session key
3. attaches session key encrypted with RSA
4. receiver decrypts & recovers session key
5. session key is used to decrypt message

11. PGP Operation – Confidentiality &
Authentication
11
• can use both services on same message
– create signature & attach to message
– encrypt both message & signature
– attach RSA/ElGamal encrypted session key

13. PGP Operation – Compression
13
• by default PGP compresses message after
signing but before encrypting
– so can store uncompressed message & signature
for later verification
– & because compression is non deterministic
• uses ZIP compression algorithm

14. PGP Operation – Email Compatibility
14
• when using PGP will have binary data to
send (encrypted message etc)
• however email was designed only for
ASCII text
• hence PGP must encode raw binary data
into printable ASCII characters

15. •uses radix-64 algorithm
•maps 3 bytes to 4 printable chars
•also appends a CRC(A cyclic redundancy
check is an error-detecting code commonly
used in digital networks and storage devices to
detect accidental changes to raw data)
Segmentation and Reassembly
•Messages are restricted to a particular message
length.
•Eg internet impose a maximum length of 50,000
octets.
•PGP also segments messages if too big –each
which is mailed separately

16. PGP Operation – Summary
16

19. PGP Session Keys
19
• PGP makes use of four types of keys one-time
session symmetric keys, public keys, private
keys, and passphrase-based symmetric keys.
• need a session key for each message
– of varying sizes: 56-bit DES, 128-bit CAST or IDEA,
168-bit Triple-DES
• Random numbers generated using ANSI
X12.17 mode
• uses random inputs taken from previous uses
and from keystroke timing of user

20. PGP Public & Private Keys
20
• 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 ie Id is Pua
mod 2^64
–will very likely be unique
• A key ID is also required for PGP digital
signatures

21. PGP Message Format
21

22. • A message consists of three components:
• the message component,
• a signature (optional),
• and a session key component (optional).
• The 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.

23. • The signature component includes a
• timestamp,
• encrypted SHA-1 message digest,
• leading two digest octets for verification,
• and the Key ID of the sender’s public key.
• The session key component includes the
session key and the identifier of the
recipient's public key that was used by the
sender to encrypt the session key. The entire
block is usually encoded with radix-64
encoding.

24. PGP Key Rings
24
• 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 passphrase
• security of private keys thus depends on the
pass-phrase security

25. PGP Key Rings
25

26. PGP Message Generation
26

27. • The sending PGP entity performs the following
steps:
• 1. Signing 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 in
the command, the first private key on the ring
is retrieved.
• b. PGP prompts the user for the passphrase
to recover the unencrypted private key.
• c. The signature component of the message
is constructed.

28. • 2. Encrypting the message:
• a. PGP generates a session key and encrypts
the message.
• b. PGP retrieves the recipient's public key
from the public-key ring using her_userid as
an index.
• c. The session key component of the
message is constructed.

29. PGP Message Reception
29

30. • PGP crypto services (again ignoring
compression and radix-64 conversion for
simplicity). The receiving PGP entity performs
the following steps:
• 1. Decrypting the message:
• a. 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.
• b. PGP prompts the user for the passphrase
to recover the unencrypted private key.
•

31. • c. PGP then recovers the session key and
decrypts the message.
• 2. Authenticating the message:
• a. PGP retrieves the sender's public key from the
public-key ring, using the Key ID field in the
signature key component of the message as an
index.
• b. PGP recovers the transmitted message digest.
• c. PGP computes the message digest for the
received message and compares it to the
transmitted message digest to authenticate.

32. PGP Key Management
32
• 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

33. PGP Trust Model Example
33

34. S/MIME

35. S/MIME (Secure/Multipurpose Internet
Mail Extensions)
35
• security enhancement to MIME email
– 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 many mail agents
– eg MS Outlook, Mozilla, Mac Mail etc

38. 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
– ASCII to EBCDIC translation problems
– lines longer than a certain length (72 to 254
characters)
5-38

39. MIME
• defines new message header fields
• defines a number of content formats
(standardizing representation of multimedia
contents)
• defines transfer encodings that protects the
content from alteration by the mail system
39

40. Header fields in MIME
• MIME-Version: Must be “1.0” -> RFC 2045, RFC
2046
• Content-Type: More types being added by
developers (application/word)
• Content-Transfer-Encoding: How message has been
encoded (radix-64)
• Content-ID: Unique identifying character string.
• Content Description: Needed when content is not
readable text (e.g.,mpeg)
5-40

41. MIME - New header fields
• MIME-Version
• Content-Type
– describes the data contained in the body
– receiving agent can pick an appropriate method to
represent the content
• Content-Transfer-Encoding
– indicates the type of the transformation that has been
used to represent the body of the message
• Content-ID
• Content-Description
– description of the object in the body of the message
– useful when content is not readable (e.g., audio data)
41

42. MIME – Content types and subtypes
• text/plain, text/enriched
• image/jpeg, image/gif
• video/mpeg
• audio/basic
• application/postscript, application/octet-stream
• multipart/mixed, multipart/parallel,
multipart/alternative, multipart/digest (each part is
message/rfc822)
• message/rfc822, message/partial, message/external-
body
42

44. MIME – Example
44
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: Ned Freed <ned@innosoft.com>
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example
Content-Type: multipart/mixed; boundary=unique-boundary-1
This is the preamble area of a multipart message. Mail readers that
understand multipart format should ignore this preamble. If you are
reading this text, you might want to consider changing to a mail
reader that understands how to properly display multipart messages.
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
…

45. • Some text …
• --unique-boundary-1
• Content-Type: multipart/parallel; boundary=unique-boundary-2
• --unique-boundary-2
• Content-Type: audio/basic
• Content-Transfer-Encoding: base64
• ... base64-encoded 8000 Hz single-channel mu-law-format audio data goes
here ...
• --unique-boundary-2
• Content-Type: image/jpeg
• Content-Transfer-Encoding: base64
• ... base64-encoded image data goes here ...
• --unique-boundary-2--

46. MIME – Example cont’d
46
--unique-boundary-1
Content-type: text/enriched
This is <bold><italic>enriched.</italic></bold><smaller>as
defined in RFC 1896</smaller>
Isn’t it <bigger><bigger>cool?</bigger></bigger>
--unique-boundary-1
Content-Type: message/rfc822
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
... Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--

47. MIME – Transfer encodings
• 7bit
– short lines of ASCII characters
• 8bit
– short lines of non-ASCII characters
• binary
– non-ASCII characters
– lines are not necessarily short
• quoted-printable
– non-ASCII characters are converted into hexa numbers
(e.g., =EF)
• base64 (radix 64)
– 3 8-bit blocks into 4 6-bit blocks
• x-token
– A named non-standard encoding
47

48. S/MIME Functions
• enveloped data
– encrypted content and associated keys
• signed data
– encoded message + signed digest
• clear-signed data
– cleartext message + encoded signed digest
• signed & enveloped data
– nesting of signed & encrypted entities
5-48

50. S/MIME Cryptographic Algorithms
50
• digital signatures: DSS & RSA
• hash functions: SHA-1 & MD5
• session key encryption: ElGamal & RSA
• message encryption: AES, Triple-DES, RC2/40
and others
• MAC: HMAC with SHA-1
• have process to decide which algs to use

51. S/MIME Messages
51
• S/MIME secures a MIME entity with a
signature, encryption, or both
• forming a MIME wrapped PKCS(public-key
cryptography specifications) object
• have a range of content-types:
– enveloped data
– signed data
– clear-signed data
– registration request
– certificate only message

52. S/MIME Certificate Processing
52
• S/MIME uses X.509 v3 certificates
• managed using a hybrid of a strict X.509 CA
hierarchy & PGP’s web of trust
• each client has a list of trusted CA’s certs
• and own public/private key pairs & certs
• certificates must be signed by trusted CA’s

53. S/MIME Content Types

54. Securing a MIME Entity
• S/MIME secures a MIME entity with a
signature, encryption, or both
• The MIME entity is prepared according to the
normal rules for MIME message preparation
– The MIME entity plus some security-related data,
such as algorithm identifiers and certificates, are
processed by S/MIME to produce what is known
as a PKCS object
– A PKCS object is then treated as message content
and wrapped in MIME

55. EnvelopedData
• The steps for preparing an envelopedData MIME are:

56. SignedData
• The steps for preparing a
signedData MIME are:

57. Clear Signing
• Achieved using the multipart content type
with a signed subtype
• This signing process does not involve
transforming the message to be signed
• Recipients with MIME capability but not
S/MIME capability are able to read the
incoming message

58. Certificate Authorities
58
• have several well-known CA’s
• Verisign one of most widely used
• Verisign issues several types of Digital IDs
• 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

59. S/MIME Enhanced Security Services
59
• 3 proposed enhanced security services:
–signed receipts: Incoming signed or encrypted
messages might include S/MIME receipt requests.
– S/MIME receipts provide confirmation that
messages are received unaltered, and can include
information about who opened the message and
when it was opened.
– Can be verified by trusted third party.

60. –security labels: Security labels are an optional
security service for S/MIME.
– A security label is a set of security information
regarding the sensitivity of the content that is
protected by S/MIME encapsulation.
– A security label can be included in the signed
attributes of any SignedData object.
– Can be used for access control by indicating which
users are permitted to access to an object.

61. ➢ Secure mailing lists : Mail list agent(M LA)
➢ While sending the message to multiple recipients –it
will be an overload for the sender.
➢ So that responsibility can be given to MLA –who can
receive one message and does all the cryptographic
operations using its public key and forward the
message .

62. Security services for Electronic mail
• Privacy
• Authentication
• Integrity
• Non-repudiation
• Proof of submission
• Proof of delivery
• Message flow confidentiality
• anonymity

63. • containment
• Audit
• Accounting
• self destruct
• Message sequence integraty