XII. Electronic Mail Security - PowerPoint PPT Presentation

1 / 59
About This Presentation
Title:

XII. Electronic Mail Security

Description:

R64 = conversion to radix 64 ASCII format. Cryptography & Network ... use radix-64 conversion(Appendix 12B) 3 octets of binary data - 4 ASCII characters CRC ... – PowerPoint PPT presentation

Number of Views:110
Avg rating:3.0/5.0
Slides: 60
Provided by: emfrozu
Category:

less

Transcript and Presenter's Notes

Title: XII. Electronic Mail Security


1
XII. Electronic Mail Security
  • Pretty Good Privacy(PGP)
  • S/MIME

2
CONTENTS
  • PGP
  • S/MIME

3
1.PGPPretty Good Privacy
  • Largely the effort of a single person, Phil
    Zimmermann
  • Provides a confidentiality and authentication.
  • Used for electronic mail and file storage
    application.

4
1.PGPPretty Good Privacy
  • Notation(1)
  • 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

5
1.PGPPretty Good Privacy
  • Notation(2)
  • DC conventional decryption
  • H hash function
  • concatenation
  • Z compression using ZIP algorithm
  • R64 conversion to radix 64 ASCII format

6
1.PGPPretty Good Privacy
  • Operational Description
  • Digital signature
  • Message encryption
  • Compression
  • Email compatibility
  • Segmentation

7
1.PGPPretty Good Privacy
  • Operational Description -Authentication
  • Sequence(1)(Figure 12.1)
  • 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 unsing the
    senders private key, and the result is prepended
    to the message.

8
1.PGPPretty Good Privacy
  • Operational Description -Authentication
  • Sequence(2)(Figure 12.1)
  • 4.The receiver uses RSA with the senders 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.

9
1.PGPPretty Good Privacy
  • Operational Description - Authentication
  • SRA/SHA-1, DSS/SHA-1
  • Attached signatures, Detached signatures

10
1.PGPPretty Good Privacy
  • Operational Description - Confidentiality
  • Sequence(1)(Figure 12.1)
  • 1.The sender generats 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

11
1.PGPPretty Good Privacy
  • Operational Description - Confidentiality
  • Sequence(2)
  • 3.The session key is encrypted with RSA, using
    the recipients public key, and is prepended 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
1.PGPPretty Good Privacy
  • Operational Description - Confidentiality
  • CAST-128, IDEA, 3DS
  • RSA, ElGamal(a variant of Diffie-Hellman)

13
1.PGPPretty Good Privacy
  • Operational Description - Confidentiality and
    Authentication
  • Sequence(1)(Figure 12.1)
  • 1.The sender first signs the message with its own
    private key.
  • 2.The sender encrypts the message with a session
    key.
  • 3.The sender encrypts the session key with the
    recipients public key.

14
1.PGPPretty Good Privacy
  • Operational Description - Confidentiality and
    Authentication
  • Sequence(2)(Figure 12.1)
  • 4.The receiver decrypts the session key with its
    own private key.
  • 5.The session key is used to decrypt the message.
  • 6.The receiver check the digital signature in
    that message.

15
1.PGPPretty Good Privacy
  • Operational Description Compression
  • The signature is generated before
    compression.(Figure 12.1)
  • can store only the uncompressed message together
    with the signature for future verification.
  • generate dynamically a recompressed message for
    verification.

16
1.PGPPretty Good Privacy
  • Operational Description - Compression
  • Message encryption is applied after compression
    to strengthen cryptographic security.(Figure
    12.1)
  • Because the the compressed message has less
    redundancy than the original plaintext.

17
1.PGPPretty Good Privacy
18
1.PGPPretty Good Privacy
  • Operational Description - E-mail Compatibility
  • 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

19
1.PGPPretty Good Privacy
20
1.PGPPretty Good Privacy
  • Operational Description - 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.

21
1.PGPPretty Good Privacy
  • 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

22
1.PGPPretty Good Privacy
  • Cryptographic Keys and Key Rings
  • 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 publi keys of
    correspondents.

23
1.PGPPretty Good Privacy
  • Cryptographic Keys and Key Rings - Session Key
    Generation(CAST-128)
  • 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 ciphter text block are concatenated to
    form the 128-bit session key

24
1.PGPPretty Good Privacy
  • Cryptographic Keys and Key Ring - Key Identifiers
  • Any given user may have multiple pulblic/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.

25
1.PGPPretty Good Privacy
26
1.PGPPretty Good Privacy
  • Cryptographic Keys and Key Ring Key Rings
  • The private-key ring store the public/private key
    pairs
  • The public-key ring store the public keys of
    other users known
  • The private key is encrypted using CAST-128(or
    IDEA or 3DES)

27
1.PGPPretty Good Privacy
  • Figure 12.4

28
1.PGPPretty Good Privacy
  • Cryptographic Keys and Key Ring Key Rings

29
1.PGPPretty Good Privacy
  • Public-Key Management Approaches to Public-Key
    Management
  • The essence of the problem User A must build up
    a public-key ring containing the public keys of
    other users to interoperate with tem 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 can read encrypted
    message from A to B

30
1.PGPPretty Good Privacy
  • Public-Key Management 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 cerifying
    authority.

31
1.PGPPretty Good Privacy
  • Public-Key Management The Use of Trust
  • A key legitimacy field
  • The extent to which PGP will trust that binding
    of this user ID to this key
  • A signature trust field
  • The degree to which this PGP user trusts the
    signer to certify public keys
  • A owner trust field
  • The degree to which this public key is trusted to
    sign other public-key certificates

32
1.PGPPretty Good Privacy
33
1.PGPPretty Good Privacy
  • Public-Key management The use of Trust
  • 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

34
1.PGPPretty Good Privacy
  • Public-Key management The use of Trust
  • 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

35
1.PGPPretty Good Privacy
  • Public-Key management The use of Trust

36
1.PGPPretty Good Privacy
  • Public-Key management Revoking Public Key
  • issues a key revocation cerificate, signed by the
    owner.
  • Note that an opponent who has copromised the
    private key of an owner can also issue such a
    certificate.

37
2.S/MIME
  • A security enhancement to the MIME Internet
    e-mail format standard.

38
2.S/MIME
  • RFC 822
  • Define a format for text messages that are sent
    using electronic mail.
  • Apply only to the contents.
  • A message consists of some number of header
    lines(the header) followed by unrestricted
    text(the body).
  • The header is separated from the body by a blank
    line.
  • The most frequently used keywords are From, To,
    Subject, and Date.

39
2.S/MIME
  • Multipurpose Internet Mail Extensions
  • Limitations of the SMTP/822 scheme
  • SMTP cannot transmit binary objects.
  • SMTP cannot transmit text data that includes
    national language characters.
  • SMTP servers may reject mail over a certain size.
  • SMTP gateways that translate between ASCII and
    EBCDIC do not use a consistent set of mappings.
  • 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 defined in RFC
    821.
  • MIME is an extension to the RFC 822 framework.

40
2.S/MIME
  • Multipurpose Internet Mail Extensions Overview
  • The MIME specification
  • 1.Five new message header fields are defined,
    which may be included in an RFC 822 header.
  • 2.A number of content formats are
    defined.-support multimedia e-mail.
  • 3.Transfer encodings are defined.

41
2.S/MIME
  • Multipurpose Internet Mail Extensions Overview
  • The five message header fields.- appear in a
    normal RFC 822 header
  • MIME-version
  • Content-type
  • Content-Transfer-Encoding
  • Content-ID(optional)
  • Content-Description (optional)

42
2.S/MIME
  • Multipurpose Internet Mail Extensions MIME
    Content Types(Table 12.2)

43
2.S/MIME
  • Multipurpose Internet Mail Extensions MIME
    Transfer Encodings

44
2.S/MIME
  • Multipurpose Internet Mail Extensions Canonical
    Form

45
2.S/MIME
  • S/MIME Functionality Functions
  • Enveloped data
  • Signed data
  • Clear-singed data
  • Signed and enveloped data Signed only and
    encrypted-only entities may be nested.

46
2.S/MIME
  • S/MIME Functionality Cryptographic Algorithms

47
2.S/MIME
  • S/MIME Messages
  • S/MIME makes use of a number of new MIME content
    types

48
2.S/MIME
  • S/MIME Functionality Functions
  • Enveloped data
  • Signed data
  • Clear-singed data
  • Signed and enveloped data Signed only and
    encrypted-only entities may be nested.

49
2.S/MIME
  • S/MIME Functionality Cryptographic Algorithms

50
2.S/MIME
  • S/MIME Messages
  • S/MIME makes use of a number of new MIME content
    types(Table 12.7)

51
2.S/MIME
  • S/MIME Messages Securing a MIME Entity
  • 1.The MIME entity is prepared according to the
    normal rules for MIME message preparation.
  • 2.The MIME entity plus some security-related data
    are processed by S/MIME to produce what is known
    as a PKCS object.
  • 3.A PKCS object is then treated as message
    content and wrapped in MIME.

52
2.S/MIME
  • S/MIME Messages Enveloped Data
  • 1.Generate a pseudorandom session key for a
    particular symmetric encryption algorithm(RC2/40
    or tripleDES)
  • 2.For each recipient, encrypt the session key
    with the recipients public RSA key.
  • 3.For each recipient, prepare a block known as
    RecipientInfo that contains the senders
    public-key certificate, an identifier of the
    algorithm used to encrypt the session key, and
    the encrypted session key.
  • 4.Encrypt the message content with the session
    key.

53
2.S/MIME
  • S/MIME Messages SignedData
  • 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 block known as SignerInfo that
    contains the signers public-key certificate, an
    identifier of the message digest algorithm, an
    identifier of the algorithm used to encrypt the
    message digest, and the encrypted message digest.

54
2.S/MIME
  • S/MIME Messages Clear Signing
  • Using the multipart content type with a signed
    subtype.
  • S/MIME Message registration Request
  • The application/pkcs10 S/MIME entity is used
  • The CertificationRequestInfo block is included.
  • The certificationRequestInfo block include a anme
    of the certificate subject and a bit-string
    representation of the users public key.

55
2.S/MIME
  • S/MIME message Certificates-Only Message
  • A message containing only certificates of a
    certificate revocation list(CRL) can be sent in
    response to a registration request.
  • An application/pkcs7-mime type/subtype with an
    smime-type parameter of degenerate.

56
2.S/MIME
  • S/MIME Certificate Processing
  • S/MIME uses public-key certificates that conform
    to version 3 of X.509
  • The key-management scheme used by S?MIME is in
    some ways a hybrid between a strict X.509
    certification and PGPs web of trust.

57
2.S/MIME
  • S/MIME Certificate Processing User Agent Role
  • Key generation
  • Registration
  • Certificate storage and retrieval
  • S/MIME Certificate Processing VeriSign
    Certificates
  • The most widely used CA services.
  • VeriSign issues X.509 certificates with the
    product name VeriSign Digital ID.

58
2.S/MIME
  • S/MIME Certificate Processing VeriSign
    Certificates
  • Digital ID contains
  • 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 cerification authority
    that issued the Digital ID
  • Other user-supplied information.
  • Verisign provides three levels of security.

59
2.S/MIME
  • Enhanced Security Services
  • Signed receipts
  • Security labels
  • Secure mailing lists
Write a Comment
User Comments (0)
About PowerShow.com