Electronic Mail Security - PowerPoint PPT Presentation

1 / 82
About This Presentation
Title:

Electronic Mail Security

Description:

R64 = conversion to radix 64 ASCII format. 6. Electronic Mail Security ... Use radix-64 conversion(Appendix 12B) 3 octets of binary data - 4 ASCII characters CRC ... – PowerPoint PPT presentation

Number of Views:213
Avg rating:3.0/5.0
Slides: 83
Provided by: hyo5
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com