Electronic Mail Security

1
Electronic Mail Security

• Pretty Good Privacy
• S/MIME

2
Electronic Mail Security

• Electronic Mail
• the most heavily used network-based application
• the only distributed application that is widely
  used across
• all architectures and vendor platforms
• There grows a demand for authentication and
  confidentiality services
• Pretty Good Privacy(PGP)
• S/MIME

3
Introduction

• Largely the effort of a single person, Phil
  Zimmermann
• selected the best available cryptographic
  algorithms as building blocks
• integrated these algorithms into a
  general-purpose application
• made the package and its documentation, including
  the sourcecode, freely via the internet, bbs,
  and commercial networks
• entered into an agreement with a company to
  provide a fullycompatible, low-cost commercial
  version of PGP
• Provides a confidentiality and authentication.
• Used for electronic mail and file storage
  application.

4
Why PGP ?

• It is available free worldwide in versions that
  run on avariety of platforms
• It is based on algorithms that have survived
  extensivepublic review and are considered
  extremely secure
• public-key encryption RSA, DSS, Diffie-Hellman
• conventional encryption CAST-128, IDEA, 3-DES
• hash coding SHA-1
• It has a wide range of applicability
• It was not developed by, nor is it controlled by,
  any governmental or standards organization

5
Notation

• Ks session key
• Kra private key of user A
• Kua public key of user A
• EP public-key encryption
• DP public-key decryption
• EC conventional encryption
• DC conventional decryption
• H hash function
• concatenation
• Z compression using ZIP algorithm
• R64 conversion to radix 64 ASCII format

6
Operational Description(1/2)

• Digital signature(authentication)
• Message encryption(confidentiality)
• Compression
• Email compatibility
• Segmentation

7
Operational Description(2/2)
Summary of PGP Services
8
Authentication / Confidentiality

• Authentication only

• Confidentiality only

9
Authentication and Confidentiality
10
Compression

• PGP compresses the message
• after applying the signature
• can store only the uncompressed message together
  with the signature for future verification.
• generate dynamically a recompressed message for
  verification.
• but before encryption to strengthen cryptographic
  security
• the compressed message has less redundancy than
  the original plaintext
• cryptanalysis is more difficult

11
E-mail Compatibility(1/2)

• Part or all of the resulting block consists of a
  stream of arbitrary 8-bit octets
• Many E-mail systems only permit the use of blocks
  consisting of ASCII text
• Use radix-64 conversion(Appendix 12B)
• 3 octets of binary data -gt 4 ASCII characters
  CRC

Input Data
Binary representation
00100011 01011100 10010001
Radix-64 Encoding of Input Data
Character representation
I1yR
ASCII code(8bit,zero parity)
01001001 00110001 01111001 01010010
Hexadecimal representation
493179052
12
E-mail Compatibility(2/2)
13
Transmission and Reception
14
Segmentation and Reassembly

• E-mail facilities often are restricted to a
  maximum message length
• PGP automatically subdivides a message that is
  too large into segments that are small enough to
  send via e-mail
• The segmentation is done after all of the other
  processing
• the session key component and signature component
  appear only once, at the beginning of the first
  segment

15
Cryptographic Keys and Key Rings

• PGP makes use of four types of keys
• one-time session conventional keys
• public keys
• private keys
• passphrase-based conventional keys

• Three separate requirements can be identified
  with respect to these keys
• a means of generating unpredictable session key
  is needed
• multiple public-key/private-key pairs are allowed
• each PGP entity must maintain a file of its own
  KU/KR pairs as well as a file of public keys of
  correspondents

16
Session Key Generation

• Based on the one specified in ANSI X12.17
• Random 128-bit numbers are generated using
  CAST-128
• Using cipher feedback mode
• Two 64-bit cipher text block are concatenated to
  form the 128-bit session key

17
Key Identifiers

• Any given user may have multiple public/private
  key pairs
• The key ID of KUa KUa mod 264
• Very high probability, unique within a user ID
• Signature component includes Key ID of senders
  public key
• Session key component includes Key ID of
  recipients public key.

18
PGP Message Format (A to B)
19
Key Rings(1/4)

• The private-key ring store the public/private key
  pairs
• secring.pkr
• The public-key ring store the public keys of
  other users known
• pubring.pkr
• The private key is encrypted using CAST-128(or
  IDEA or 3DES)
• EH(Pi)KRi ( Pi passphrase)

20
Key Rings(2/4)
Private-Key Ring
Public-Key Ring
KeyLegitimacy
SignatureTrust(s)
Timestamp
Key ID
Public Key
Owner Trust
User ID
Signature(s)








User i
Ti
trust_flagi
trust_flagi
KUi mod 264
KUi








General Structure of Private- and Public-Key Rings
21
Key Rings(3/4)
Public KeyKUb
22
Key Rings(4/4)
Public KeyKUa
23
Approaches to Public-Key Management

• The essence of the problem
• Public-Key Management
• User A must build up a public-key ring containing
  the public keys of other users to interoperate
  with them using PGP
• If As key ring contains a public key attributed
  to B but that the key is owned by C
• C can forge Bs signature
• C can read encrypted message from A to B

24
Approaches to Public-Key Management

• Some approaches that could be used
• 1. Physically get the key from B
• 2. Verify a key or a digest of the key by
  telephone
• 3. Obtain Bs public key from a mutual trusted
  individual D
• 4. Obtain Bs public key from a trusted
  certifying authority

25
The Use of Trust(1/5)

• A owner trust field
• the degree to which this public key is trusted to
  sign other public-key certificates
• A signature trust field
• the degree to which this PGP user trusts the
  signer to certify public keys
• A key legitimacy field
• the extent to which PGP will trust that binding
  of this user ID to this key

26
The Use of Trust (2/5)
27
The Use of Trust (3/5)

• When A inserts a new public key on the public-key
  ring(owner trust field)
• If the owner is A, then a value of ultimate trust
  is automatically assigned
• Otherwise, A must enter the desired level
• When the new public key is entered(one or more
  signatures may be attached to it)(signature trust
  field)
• If the author of this signature is among the
  known public-key owners, OWNERTRUST -gt SIGTRUST
• If not, an unknown user value is assigned

28
The Use of Trust (4/5)

• The value of the key legitimacy field is
  calculated on the basis of the signature trust
  fields present in the entry
• If at one signature has a signature trust value
  of ultimate, then the key legitimacy value is set
  to complete
• Otherwise, PGP computes a weighted sum of the
  trust values

29
The Use of Trust (5/5)
30
Revoking Public Key

• Issues a key revocation certificate, signed by
  the owner
• Note that an opponent who has compromised the
  private key of an owner can also issue such a
  certificate.

31
PGP ??
32
PGP ??
33
PGP ??
(??? ???? ???/???? ?? ????? ? ?)
34
PGP ??
35
PGP ??
36
PGP ??
37
PGP ??
38
PGP ??
39
PGP ??
40
PGP Key ??
41
PGP Key ??
42
PGP Key ??
43
PGP Key ??
44
PGP Key ??
45
PGP Key ??
46
PGP Key ???? ??
47
PGP Key Ring
48
PGP Key ??
49
PGP Key ??(??)
50
PGP ?? ?? ??
51
PGP ??(E-Mail)
52
PGP ??(E-Mail)
53
PGP ??(E-Mail)
54
PGP ??(E-Mail)
55
PGP ??(?? ???)
56
PGP ??(?? ???)
57
PGP ??(?? ???)
58
PGP ??(?? ???)
59
PGP ??(?? ???)
60
S/MIME

• S/MIME(Secure/Multipurpose Internet Mail
  Extension)
• Security enhancement to the MIME, based on RSA
  data security
• IETF standard as well PGP
• Industry standard for commercial and
  organizational use, while PGP for personal e-mail
  security
• RFC 822
• Format for text message that are using e-mail
• The header and the body
• The header is separated from the body by a blank
  line
• A message is ASCII text
• Ex)
• Date Tue, 16 Jan 1998 103717
• From William Stallings ws_at_shore.net
• Subject The Syntax in RFC 822
• To Smith_at_other-host.com
• Cc Jones_at_another-host.com
• Hello. This section begins the actual message
  body, which is
• Delimited from the message heading by a blank line

61
MIME(1/5)

• Limitations of the SMTP/822 scheme
• Cannot transmit executable files or other binary
  objects
• Cannot transmit text data that includes national
  language characters(8-bit codes), 822 is limited
  to 7-bit ASCII
• SMTP servers may reject mail message over a
  certain size
• SMTP gateways has a translate problem between
  ASCII and the character code EBCDIC
• SMTP gateways to X.400 electronic mail networks
  cannot handle nontextual data included in X.400
  messages
• Some SMTP implementations do not adhere
  completely to the SMTP standards
• MIME is intended to resolve these problems
• An extension to the RFC 822 framework
• The specification is provided in RFCs 2045 2049
• Five new message header fields are defined
• A number of content format are defined
• Transfer encodings are defined

62
MIME(2/5)

• Five header fields
• MIME-Version Must have the parameter value 1.0
• Content-Type Describes the data contained in
  the body
• Content-Transfer-Encoding Indicates the type of
  transformation that has been used to represent
  the body of the message in a way that is
  acceptable for mail transport
• Content-ID Used to identify MIME entities
• Content-Description A text description of the
  object with the body
• MIME Content Types
• Provides standardized ways of dealing with a wide
  variety of information representations in a
  multimedia environment
• Ex)
• From Nathaniel Borenstein ltnsb_at_bellcore.comgt
• To Smith_at_other-host.com
• Subject Sample message
• MIME-Version 1.0
• Content-type multipart/alternativeboundarybound
  ary42
• --boundary42
• Content-type text/plain charsetus-ascii
• --boundary42

63
MIME(3/5)

• MIME Content Types

64
MIME(4/5)

• MIME Transfer Encodings
• A definition of transfer encodings for message
  bodies
• Provide reliable delivery across the largest
  range of environments

65
MIME(5/5)

• Canonical Form
• Appropriate to the content type, that is
  standardized for use between systems
• Contrast to native form, which is a format that
  may be peculiar to a particular system.
• Table 12.5 Native and Canonical Form

66
S/MIME

• Standard establishment
• 1995, RSA Data Security co., Development
• IETF_S/MIME Working Group
• http//www.ietf.org/html.charters/smime-charter.ht
  ml
• S/MIME Standard
• S/MIME V2(1998.03)
• S/MIME V3(1999.06)
• Application-layer protocol

SMIME
Telnet
FTP
SMTP
HTTP
NNTP
TCP
IP/IPSec
67
S/MIME Functionality

• Enveloped data
• Consists of encrypted content of any type and
  encrypted-content encryption keys for one or more
  recipients.
• Signed data
• A digital signature is formed by taking the
  message digest of the content to be signed and
  then encrypting that with the private key of the
  signer
• The content plus signature are then encoded using
  base64 encoding
• A signed data message can only be viewed by a
  recipient with S/MIME capability
• Clear-signed data
• Only the digital signature is encoded using
  base64
• Recipients without S/MIME capability can view the
  message content, although they cannot verify the
  signature
• Signed and enveloped data
• Signed-only and encrypted-only entities may be
  nested
• Encrypted data may be signed and signed data or
  clear-signed data may be encrypted

68
S/MIME Cryptographic Algorithms(1/2)
69
S/MIME Cryptographic Algorithms(2/2)

• Following rule should be followed by a sending
  agent
• 1.SA(sending agent) checks a list of preferred
  decrypting capabilities from the recipient
• choose the highest preference capability
• 2. If SA has no such list of capabilities from
  the recipient
• But, has received one or more messages from the
  recipient
• The outgoing message SHOULD use the same
  encryption algorithm as was used on the last
  signed and encrypted message
• 3. If SA has no knowledge about the decryption
  capabilities of the recipient
• Willing to risk that the recipient may not be
  able to decrypt the message, SA SHOULD use triple
  DES
• Not willing to risk that the recipient may not be
  able to decrypt the message, SA MUST use RC2/40

70
S/MIME Message(1/9)

• Securing a MIME Entity

71
S/MIME Message(2/9)

• Represented in BER(Basic Encoding Rules)
• ITU-T Recommendation X.209
• Arbitrary octet string
• Transfer encoded with base64 in the outer MIME
  message
• S/MIME Message

? CMS Cryptographic Message Syntax(signed-data,
enveloped-data)
72
S/MIME Message(3/9)

• Enveloped Data
• Application/pkcs7-mime, envelopedData
• For the confidentiality
• 1. Generate a random session key for RC2/40 or
  triple DES
• 2. For each recipient, the encrypt session key
  with the recipients public RSA key
• 3. For each recipient, prepare a RecipientInfo
  that contains
• Senders public-key certificate
• Identifier of the algorithm used to encrypt the
  session key
• Encrypted session key
• 4. Encrypt the message content with the session
  key

73
S/MIME Message(4/9)

• Enveloped only Data

? ASN.1(Abstract Syntax Notation,X.208) Include
BER
74
S/MIME Message(5/9)

• Signed Data
• Application/pkcs7-mime,signedData
• For the integrity, originality
• 1. Select a message digest algorithm (SHA or MD5)
• 2. Compute the message digest, or hash function,
  of the content to be signed
• 3. Encrypt the message digest with the signers
  private key
• 4. Prepare a SignerInfo that contains
• Signers public-key certificate
• Identifier of the message digest algorithm
• Identifier of the algorithm used to encrypt the
  message digest
• Encrypted message digest

75
S/MIME Message(6/9)

• Signed only Data

76
S/MIME Message(7/9)

• Clear-signed Data
• Multipart/Signed, Application/pkcs7-signature
• Multipart/signed message has two parts
• The first part is processed in the same manner as
  signedData
• Content field is an empty message
• The second part is a signature of the first part
• Transfer encoded using base64
• Uses application/pkcs7-signature content type
• Receiver can verify the signature by taking
• The message digest of the first part
• The message digest recovered from the signature
  in the second part
• And compare these

77
S/MIME Message(8/9)

• Clear-signed Data

78
S/MIME Message(9/9)

• Registration(Certificate) Request
• Application/pkcs10-mime content type
• Transfer a certification request includes
  certificationRequestInfo
• Identifier of the public key encryption algorithm
• Signature of the certificationRequestInfo block,
  made using the senders private key
• Includes a name of the certificate subject and a
  bit-string representation of the users public
  key
• Certificates-Only Message(Certificate
  transmission)
• A message containing only certificates or a CRL
  can be sent in response to a registration request
• Application/pkcs7-mime type/subtype with an
  degenerate parameter
• The steps involved are the same as those for
  creating signedData message
• Except that no message content and
• SignerInfo field is empty

79
S/MIME Certificate Processing

• Certificate Processing
• Conforms to X.509 v3
• Key-management scheme is a hybrid between a
  strict X.509 certification hierarchy and PGPs
  web of trust
• As with the PGP model, S/MIME managers and/or
  users must configure each client with a list of
  trusted keys and with CRL
• The responsibility is local for maintaining the
  certificates
• The certificates are signed by certification
  authorities
• User Agent Role
• Key generation
• Administrator MUST be capable of generating DH
  and DSS key pairs and SHOULD be capable of
  generating RSA key pairs
• User agent SHOULD generate RSA key pairs with
  length in the range of 768 to 1024 bits
• Registration
• users public key must be registered with CA
• Certificate storage and retrieval
• A local list of certificates could be maintained
  by the user or by some local administrative
  entity

80
VeriSign Certificates(1/2)

• Internet-based CA, the most widely used
• Issues X.509 certificates with the product name
  VeriSign Digital ID
• Owners public key
• Owners 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
• User-supplied information
• Address
• E-mail address
• Basic registration information

81
VeriSign Certificates(2/2)
82
Enhanced Security Services

• S/MIMEv3 supports four important features that
  were not available in S/MIMEv2
• Signed receipts
• May be requested in a SignedData object
• Provides proof of delivery to the originator of a
  message
• Recipient signs the entire original message plus
  original senders signature and appends the new
  signature to form a new S/MIME msg
• Security labels
• The labels may be used for access control by
  indicating which users are permitted access to an
  object
• Other uses include priority or role based
• Secure mailing lists
• Sending message to multiple recipients
• S/MIME Mail List Agent(MLA)
• Originator of a message need only send the
  message to the MLA
• Recipient-specific encryption