MIME mail transfer

Document Sample
MIME mail transfer Powered By Docstoc
					          정보보호

06 암호의 응용 (2)
  - 전자우편 보안
           E-mail Security
 Introduction to E-mail
 Privacy Enhanced Mail (PEM)
 The Certification System
 Pretty Good Privacy (PGP)
 Secure Multipurpose Internet Mail
 Extensions (S/MIME)
       Introduction to E-mail
 E-mail is one of the most popular Internet
  applications
 Asynchronous (=> no session => no handshaking)
 Fast
 Easy to distribute
 Inexpensive
 Modern e-mail messages can include hyperlinks,
  HTML formatted text, images, sound, and even video
 Accessible from any host connected to the Internet
      A Typical E-mail Journey
1.   Starts its journey in the sender’s user agent
2.   Travels to the sender’s mail server
3.   Then travels to the recipient’s mail server
4.   Deposited in the recipient’s mailbox
5.   The recipient wants to access the messages in his
     mailbox
6.   The mail server containing his mailbox
     authenticates him (with user name and password)
7.   Then sends the message to the recipient’s user
     agent
Existing E-Mail System
Originator at a multiuser host
                                                 Recipient at a workstation

Editor                       User                             User
                             agent                            agent


                  Mail transfer
                  Agent (SMTP)




                          SMTP                             Retrieval (e.g.
                        (RFC 821)                             POP3)




                 Mail transfer                            Mail transfer
                                       SMTP
                    Agent                                    Agent
                                     (RFC 821)
                 (SMTP relay)                               (SMTP)



         Intermediate relay point                Recipient’s mailbox host
      The Simple Mail Transfer
          Protocol (SMTP)
 Defined in RFC 821 (dates back to 1982 )
 The principal application-layer protocol for
  the internet electronic mail
 Uses the reliable data transfer service of
  TCP at port 25
 Possess certain “archaic” characteristics
  (such as the 7-bit ASCII restriction)
                    Example to SMTP
S: 220 hamburger.edu                                   a client C, which its host
                                                        name is crepes.fr
C: HELO crepes.fr
                                                       a server S, which its host
S: 250 Hello crepes.fr, pleased to meet you             name is hamburger.edu
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr… Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu… Recipient ok
C: DATA
S: 354 Enter mail, end with “.” on a line by itself
C: Do you like ketchup?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamurger.edu closing connection
             Header Format
 Defined in RFC 822
 Headers containing peripheral information
  precedes the body of the message itself
 Specifies the exact format for mail header lines as
  well as their semantic interpretations
 After the message header, a blank line follows,
  then the message body in ASCII follows
 The message terminates with a line containing
  only a period
 Example to E-mail Message
From:    alice@cs.huji.ac.il
To:       bob@cs.huji.ac.il
Subject: Mail header format

Message body (in ASCII)
.
     Multipurpose Internet Mail
        Extensions (MIME)
 RFC 822 is not sufficiently rich enough for
  multimedia messages
 Include additional headers in the
  message, which are defined in RFC
  2045/2046
 This topic will be addressed later in the
  S/MIME section
          The Security Issue (1)
 Initial specification of internet e-mail did not address security
    issues
   In particular, security mechanisms to provide data
    confidentiality, authenticity, integrity and non-repudiation were
    missing
   E-mail service is asynchronous
   All the regular security protocols (such as IPSEC, SSL, etc.)
    are synchronous
   PEM, S/MIME and PGP come to help
   Each message is a one-time independent event with its own
    one-time symmetric key
      The Security Issue (2)
 Why not simply use the regular
 synchronous security protocols to protect
 the message while en route between
 intermediate stations ?
  Security services should be added between
   the two end users (no exposure in the middle)
  The secure services were build on an existing
   mail system (SMTP mail servers)
  Privacy Enhanced Mail (PEM)
          Introduction
 Primary goal of PEM is to add security
  services for e-mail users in the internet
  community
 Began in 1985 as an activity of the Privacy
  and Security Research Group (PSRG)
 Defined in RFCs 1421/1422/1423/1424
 Consists of extensions to existing
  message processing software plus a key
  management infrastructure
       PEM Security Services
 Integrity
    which ensures a message recipient that the message has
     not been modified en route.
 Authenticity
    which ensures a message recipient that a message was
     sent by the indicated originator.
 Non-repudiation
    which allows a message to be forwarded to a third party,
     who can verify the identity of the originator.
 Confidentiality (optional)
    which ensures a message originator that the message text
     will be disclosed only to the designated recipients.
            PEM Overview
 Compatible with RFC 822 message
  processing conventions
 Transparent to SMTP mail relays
 Uses symmetric cryptography to provide
  (optional) encryption of messages
 The RFCs strongly recommend the use of
  asymmetric cryptography (for digital
  signatures, certificates and encryption of the
  symmetric key) because of its ability to
  support vast distributed community of users
     PEM Overview (contd.)
 The use of X.509 certificates is the base
  for public key management in PEM
 This certification hierarchy supports
  universal authentication of PEM users
 PEM can be used in a wider range of
  messaging environments (other than RFC
  822 and SMTP)
Integration Of PEM Into Existing
          Mail System
   Originator at a multiuser host
                                                     Recipient at a workstation

   Editor                        User
                  PEM                                              User
                  filter         agent                             agent

                                                                 PEM
                      Mail transfer                              module
                      Agent (SMTP)




                              SMTP                               Retrieval (e.g.
                            (RFC 821)                               POP3)




                    Mail transfer                              Mail transfer
                       Agent               SMTP                  Agent
                    (SMTP relay)         (RFC 821)              (SMTP)



            Intermediate relay point                  Recipient’s mailbox host
          PEM Message Submission:
            Message Processing
User provides recipient
                                                                     Enclosing header
address and other data
                             Begin privacy enhanced message          RFC 822 header fields
(e.g. “Subject”) for
enclosing header
                                   Encapsulated header:              Encapsulated message
User provides address      Contains authentication, integrity, and
information needed to     (optional) encryption control fields and
perform encryption                  related information              All data between the
                                        Blank line                   privacy enhanced
                                                                     message boundaries is
                                     Encapsulated text:              represented here, and
                                        (Encrypted)                  may be interspersed
 Plaintext of
                               User message text and optional        with unprotected
 user message
                                  Replicated header fields           plaintext
 requiring
 privacy
 enhancement                  End privacy enhanced message
PEM Message Processing
                     Plaintext message


Step 1           “SMTP” canonicalization



Step 2   MIC calculation and (optional) encryption


Step 3     6-bit encoding and line length limiting


                     Processed message
 PEM Message Processing – Step 1

 Uses the canonicalization specified by
  SMTP to ensure a uniform presentation
  syntax among a heterogeneous collection
  of computer systems .
 The shortcoming is that it restricts the
  input to 7-bit ASCII .
 The reason is that the Internet e-mail
  imposes the same restrictions.
 PEM Message Processing – Step 2

 A MIC is calculated over the canonicalized
  message to permit uniform verification in the
  heterogeneous environments .
 The canonical (padded as required) message
  text is then (optionally) encrypted using a per-
  message symmetric key .
 The encryption action is performed only if the
  message is of type ENCRYPTED .
 PEM Message Processing – Step 3

 Renders an ENCRYPTED or MIC-ONLY
  message into a printable form suitable for
  transmission via SMTP.
 This encoding step transforms the
  (optionally encrypted) message text into a
  restricted 6-bit alphabet.
 A MIC-CLEAR messages are not subject
  to any portion of the third processing step.
       PEM Message Types
 ENCRYPTED is a signed, encrypted and
  encoded (in step 3) message .
 MIC-ONLY is a signed , but not encrypted,
  encoded message .
 MIC-CLEAR is a signed, but not encrypted,
  and message that is not encoded .
   Specially so it can be sent to a mixed set of
    recipients, some of whom use PEM and some do
    not.
      PEM Message Submission: Header
             Construction (1)
From:       alice@cs.huji.ac.il
To:        bob@cs.huji.ac.il                         Standard RFC 822 Header

Subject:    Encrypted PEM message
--------BEGIN PRIVACY-ENHANCED MESSAGE------------
Proc-Type: 4, ENCRYPTED                              Version & type

Content-Domain: RFC822                               Conforms to
DEK-Info: DES-CBC, BGFA799HTS347KGKL0                Msg encryption params
Originator-Certificate:                              (for example, IV)
yhtrwhhj57jw5jw6w7u6juj6uu45yjj5645w4y4y5yqy3        Originator certificate
Issuer-Certificate:
Eth46u5kw57kwuw3jwjw465iw6uw57uw6u4q6jj6646          Issuer certificate
 PEM Message Submission: Header
        Construction (2)

MIC-Info: RSA-MD5, RSA,                           MIC & Dig.Sig algo
Sdhdsh453hwe5yyh5ywjuhs5yahhaehjue78iok67k        Digital signature
Recipient-ID-Asymmetric:
Agw56ywjq45y2jqhj4yuq4hjq4yq3yy3yewghew5y3        Recipient’s id
Key-Info: RSA,                                    Public key algo
Adshw45w5j7w57j5u46yu5yq46ju46juqyuq4u5y35hj      Encrypted message key

                                                  Blank line
Dfghj56er656uw6u64uu45yw46u5wjwu5i56u57i5wuiw5u
                                                  Encrypted message
W46uw56uueueri5u6w56uw46u5wu56uw56u56u5
------END PRIVACY-ENHANCED MESSAGE------------
       PEM Message Delivery
          Processing (1)
 Recipient receives a PEM message
 Scans the PEM header for the version and the
  type (ENCRYPTED, MIC-ONLY, MIC-CLEAR)
 If ENCRYPTED or MIC-ONLY then decode the 6-
  bit encoding back to ciphertext or canonical
  plaintext form
 If ENCRYPTED then decrypt the symmetric
  message key using the private component of his
  public key pair and decrypt the message using
  the symmetric message key
       PEM Message Delivery
          Processing (2)
 Validate the public key of the sender by
  validating a chain of certificates
 Validate the digital signature using the
  public component of the public key of the
  sender
 The canonical form is translated into the
  local representation and presented to the
  recipient
      The Certification System
 A public key X.509 certificate
    is a digitally signed data structure used to securely bind a
     public key to a name and to specify who vouches for the
     binding
 The signature to the certificate applied by the issuer
    using the private component of his public key pair and
     appended after the certificate fields
 One validates a certificate by computing the one-way hash
  function over the certificate,
    uses the public key of the issuer to decrypt the value in the
      appended signature and compare the two resulting values
                       X.509 Certificate

Certificate: = SIGNED SEQUENCE {
                                                    Uniquely identifies this
version[0]              Version DEFAULT v1988,      certificate
serialNumber             CertificateSerialNumber,
                                                    Dig.sig & hash func
signature                AlgorithmIdentifier,       algo & params

issuer                   Name,                      Issuer ID
validity                Validity,                   Start & end valid
                                                    times
subject                  Name,
subjectPublicKeyInfo    SubjectPublicKeyInfo }      Subject name

                                                    Public key of the
                                                    subject, algo ID &
                                                    params
The Internet Certification System (1)

 The user need to possess the public key of
  the issuer of the certificate in order to validate
  the certificate
 The issuer will also have a certificate, and
  thus the process of certificate validation is
  recursive and implicitly defines a directed
  certification graph
 X.509 defines a Certification Authority (CA)
  as “an authority trusted by one or more users
  to create and assign certificates”
The Internet Certification System (2)
 Different CAs can issue certificates under different policies, for
    example, varying degrees of assurance in vouching for
    certificates
   The root of the certification graph is the Internet PCA
    Registration Authority (IPRA)
   The IPRA is a reference point from which all certificates can
    be validated
   The IPRA issues certificates to a second layer of entities
    called Policy Certification Authorities (PCA), which, in turn,
    issue certificates to CAs
   CAs can issue certificates to (subordinate) CAs or directly to
    users
       Example to a Typical Internet
          Certification Hierarchy
                                             IPRA




             High              Residential          Mid-level                 Persona
           assurance                                assurance




           BBN     Louisiana       New York         MIT                HUJI        Persona




User     BBNCD     New Orleans     User      User    LCS        User      User     User      User




  User    User   User    User      User      User    User       User
             PEM Summery
 PEM represents a major effort to provide security
  for an application that touches a vast number of
  users within the Internet and beyond
 PEM was designed to have backward compatibility
  with existing mail system
 PEM depends on a successful establishment of
  the certification hierarchy that underlies
  asymmetric key management
 Problem : PEM does not support security services
  to multimedia files (MIME)
       Next :
Pretty Good Privacy
   What are we going to do ?
 Background & Concept
  Why Is PGP Popular?
  PGP’s algorithms
 Operational Description
  Inside look on operations
 Key Management
  The problem & Solution
 Web Of Trust
          Pretty Good Privacy
 First released in 1991, developed by Phil Zimmerman,
  provoked export control and patent infringement
  controversy.
 PGP provides a confidentiality and authentication
  service
    can be used for electronic mail and file storage
     applications.
 Available as plug-in for popular e-mail clients, can also
  be used as stand-alone software.
    microsoft exchange
    outlook
          Why Is PGP Popular?
 Based on well known algorithms - “The main idea”
    These algorithm have survived extensive public review and are
     considered extremely secure.
    Integrated these algorithms into a general-purpose application
 It is availiable free on a variety of platforms (Windows, UNIX,
  Macintosh, etc.)
    Open and free code.
 Wide range of applicability from corporations that wish to
  select and enforce a standerized secure to individuals
 Independent – meaning Not developed or controlled by
  governmental or standards organizations
    Based on mutual trust between clients
      Operational Description
 Actual operations of PGP consist of five services:
    Authentication
        DSS/SHA or RSA/SHA
    Confidentiality
        CAST or IDEA or RSA or 3DES
    Compression
        A message may be compressed, for storage or transmission using ZIP
    E-mail compatibility
        To provide transparency for e-mail applications, an encrypted message
            may be converted to an ASCII using Radix-64

    Segmentation
        To accommodate maximum message size limitations.
Authentication/Digital Signature
 Sender creates a message
 Sender generates a hash code of the message
    uses SHA-1 algorithm in order to generates 160-bit hash code
 Hash code encrypted with RSA (sender’s private key)
    the result is prepended to the message
 Receiver recover the hash code
    uses RSA with the sender’s public key
 Receiver generates new hash code of the message and
  compares the two codes.
 If the two match, the message is accepted as authentic.
 Note:
    PGP only encryptes the hash-code of the message:
       more efficient in running time and in transfer time
   Authentication/Digital signature

              Source A                           Destination B


              Private key                                Public key
                 KRa                                       KRb




Message                                                     DP
  M       H       EP        ||   ZIP   UNZIP
                                               Message
                                                 M                    Compare



                                                                 H
          PGP Signed Message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is simply the text of the message.
It has not been encrypted, simply signed

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use
<http://www.pgp.com>

iEYEARECAAYFAj5Ha6AACgkQ99/KQPj2cRNHsQCffKf64LwWQMfRIiKU
fs6QrokB7twAnR5gDobzGapPgyLKQ0gLklj1WIIp=gXad
-----END PGP SIGNATURE-----
     Confidentiality/Encryption
   Sender generates message and also a session key
        The session key is a random 128-bit number to be used as a session key for this message only
   Sender encryptes the message
        Uses CAST-128 (IDEA or 3DES) algorithm with the session key
   Sender encryptes the Session key with RSA and prepended to the message
   Receiver decrypt the session key
        uses RSA with its private key
   Receiver decrypt the message with the Session key
   Note:
      PGP does not simply using RSA to encrypt the message directly.
      Using CAST128 force us to share a key - using public-key algorithm solves the session key
       distrinution problem.
      Given “Store-and-forward” nature of e-mail, the use of handshaking to assure that both sides
       have the same session key is not practical.
      The use of on-time conventional keys strengthens what is already a strong conventional
   encryption approach. only a small amount of plaintext is encrypted with each key and
    there is no relationship among keys.
     Confidentiality/Encryption

          Source A                           Destination B
                        Public key
                          KUb
                                                 Private key
                                                    KRb
              Session key
                  Ks        EP                       DP

Messa   ZIP       EC        ||                   Session key
                                                     Ks
 ge                                  Messa                     Messa
 M
                                      ge            DC UNZIP    ge
                                      M                         M
                           Confidentiality &
                            Authentication
            Source A                                           Destination B
                                           Public key
                                                             Private                  Public key
                                             KUb
                                                              key
                                                                                        KRb
                                                              KRb

                             Session key
                                 Ks          EP                 DP
        Private key                                                                       DP
           KRa                                              Session key                         Compare
                                                                Ks                M
    H     EP          ||    ZIP   EC          ||        M
M                                                                                           H
                                                                DC        UNZIP



        •PGP first signs the message and then encrypts it:
         - more convenient to store a signature with a plaintext version of a
            message
         - for purposes of third party verification
                          Compression
 Saving space both for e-mail transmission and for file storage
 PGP uses ZIP to compress the message
 PGP compress the message after applying the signature but before
  message encryption:
      Signature                     Zip              Encryption
     One can store only the uncompressed message with the signature for future
       verification. In case the order was opposite:
          it would be necessary either to store a compressed version of the message or to
            recompress the message each time when verification is required
     Compression algorithms are different – the algorithm is not deterministic.
        sign after compress will would constrain all PGP implementations to the same
         compression algorithm
     Encryption is applied after compression to strengthen cryptographic security
        compressed message has less redundancy than original plaintext
Example of ZIP (LZ77) Scheme

  The brown fox jumped over the brown foxy jumping frog
                                            13            5
    26

                     27
  The brown fox jumped over             0b26d13d    y 0b27d5ding frog

•The main assumption is that words and phrases within a text
 stream (image patterns I the case of GIF) are likely to be repeated
• When a repetition occurs, the repeated sequence can be replaced by a
short one
• Over time, codes are reused to capture new sequences
          E-mail Compatibility
 When PGP is used, At least part of the block to be
  transmitted is encrypted
    The resulting block will consist of a stream of arbitraty 8-bit
     octets
    Many electronic mail systems only permit the use of blocks
     consisting of ASCII text
 To provide transparency for e-mail applications, an
  encrypted message may be converted to an ASCII string
  using radix 64 conversion
 The use of Radix-64 expands a message by 33%
    In fact, the compression should be more than enough to
     compensate for the radix-64 expansion
    Encoding Binary Data into
        Radix-64 Format




 The scheme used is radix-64 conversion, which expands the
  message by 33%.
 Radix-64 blindly converts the input stream to radix-64 format
  regardless of content, even if the input happens to be ASCII text.
     certain level of confidentiality - if the message is signed but not encrypted,
       the output will be unreadable to the casual observer
 Radix-64 Conversion Table
            Radix-64 Encoding
6-bit   Character   6-bit   Character   6-bit   Character   6-bit   Character
Value   Encoding    Value   Encoding    Value   Encoding    Value   encoding

 0         A         16        Q         32        g         48        w
 1         B         17        R         33        h         49        x
 2         C         18        S         34        i         50        y
 3         D         19        T         35        j         51        z
 4         E         20        U         36        k         52        0
 5         F         21        V         37        l         53        1
 6         G         22        W         38        m         54        2
 7         H         23        X         39        n         55        3
 8         I         24        Y         40        o         56        4
 9         J         25        Z         41        p         57        5
 10        K         26        a         42        q         58        6
 11        L         27        b         43        r         59        7
 12        M         28        c         44        s         60        8
 13        N         29        d         45        t         61        9
 14        O         30        e         46        u         62        +
 15        P         31        f         47        v         63        /
                                                            (pad)      =
  Segmentation and Reassembly
 E-mail facilities are often restricted to a maximum message length
    for example 50,000 octets.
 Longer messages must be broken up into segments, which will be
  mailed separately.
 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, including
  the Raidx-64 conversion.
     thus, the session key component and signature component appear only
      once
 The receiver strips off all e-mail headers and reassemble the block.
               Key Requirements
 PGP makes use of four types of keys:
    one-time session conventional keys,
    public keys,
    private keys,
    passphrase-based conventional keys
 Three seperate requirements:
    A means of generating unpredictable session keys is needed
    Any user may have multiple public-key/private-key pairs
         may wish to change his key pair from time to time
         in order to interact with different groups
         simply to enhance security by limiting tha anount material encrypted with any
          one key
     some means is needed for identifying particular keys
 Each PGP entity must maintain data base of:
    a file of its own key pairs
    a file of public keys of correspondents
       Session Key Generation
 The Problem : generating unpredictable session keys
 Session keys are generated using CAST-128 itself:
    This is a PGP specific random number generation technique
    getting as input:
        two 64-bit blocks that are treated as plaintext to be encrypted.
            based on keystroke stream generated by the user
        128-bit key
            random input that also combined with previous session key   output
             from CAST-128.



    The result, scrambling of CAST-128, is to produce a sequence
     of session keys that is effectively unpredictable
                     Key Identifiers
 The Problem: user may have multiple public-key/private-key pairs
 One simple solution would be to transmit the public key with the
  message.
    Would work but an RSA key may be three hundreds of decimal digits
      in length (1024 bits)
 PGP solution associate a short identifier with each public key that
  is unique.
    then only the much shorter key ID would need to be
      transmitted.
 The key ID associated with each public key consists of its least
  significant 64 bits
    That is the ID of KU is (KU mod 264)
  Format of PGP Message

Session Key   Key Id of Recipients Public Key
Component
                Session Key                     EKUb
                       Timestamp

                 Key Id of Senders Public Key

Signature        Leading Two Octets
                  of Message Digest

                     Message Digest             EKRa
                                                         Eks   R64
                         Filename                  ZIP

 Message          Time Stamp

                        Data
               PGP Key Rings
 The problem: must maintain a database in order
  to supports multiple public/private keys.
 The Solution : Keys stored locally in a PGP Key
  Ring – essentially a database of keys.
    Two rings:
       Private-key ring: stores the public/private key pairs owned
        by that node
       Public-key ring: stores the public keys of other users known
        at this node
 Private keys stored in encrypted form; decryption
  key determined by user-entered passphrase.
                       Key Rings
                          Private-Key Ring

Timestamp    Key ID*      Public Key    Encrypted    User ID*
                                       Private Key


    •            •             •            •            •

    •            •             •            •            •

    •            •             •            •            •




   Ti       KUi mod 264      KUi       EH(Pi)[KRi]    User i


    •            •             •            •            •

    •            •             •            •            •

    •            •             •            •            •
                            Key Rings

                                  Public-Key Ring

Timestamp   Key    Public   Owner   User      Key       Signature(s)   Signature
            ID*     Key     Trust   ID*    Legitimacy                   Trust(s)

    •         •       •       •       •        •             •             •

    •         •       •       •       •        •             •             •

    •         •       •       •       •        •             •             •




   Ti       KUi     KUi             User
            mod                      i
             264
    •         •       •       •       •        •             •             •

    •         •       •       •       •        •             •             •

    •         •       •       •       •        •             •             •
                   Message Generation
                                                                                     Public-Key ring
                 Passphase                       H

               Private-Key ring                                         Select
                                                                IDb
      Select
IDa                               Encrypted
                                  Private key   DC

                                     Key
                                     ID
                                                                                             Public key
                                            Private key                                          KRb
                                                KRa
                                                                          RNG
                        Message
                         digest                                        Session key
                    H               EP                ||                   Ks
                                                           Signature                              EP           Output
Message                                                                                                   ||

  M                               Message                  + message
                                                                                           Encrypted
                                                                          EC               Signature
                                                                                           + message
                             Reception
                   Passphase                       H                   Public-Key ring

                  Private-Key ring                           Select

         Select                      Encrypted
                                     Private key
                                                   DC




                                              Private key                     Public key
                                                   KRb
                                                                                  KRb

Receiver's
  key ID                                           DP
 Encrypted
                                                            Sender’s
Session key
                                                             Key ID
                                             Session key
                                                   Ks       Encrypte
Encrypted                                                      d
                                                                                   DP
Message +                                                    Digest
Signature                                          DC
                                                                                           Compare
                                                            Message

                                                                                    H
Public Key Management Problem
 The Problem: A’s key ring contains a
  public key attributed to B but that the key
  is, in fact, owned by C
 Two threats now exist:
  C can send messages to A and fake B’s
   signature, so that A will accept the message
   as coming from B !
  Any encrypted message from A to B can be
   read by C !
Public Key Management Problem
            (cont.)
 Possible solutions:
    Physically get the key from B
    Verify a key by telephone
    Obtain B’s public key from a mutual trusted individual
    Obtains B’s public key from a trusted certifying authority
 That would violate PGP’s spirit as an E-mail security
  scheme for the masses:
    It should be possible for people to exchange keys
     electronically with others whom they have never met and
     may not even know
    Every one who uses this scheme trusts the central
     authority
         PGP Key Management
 PGP Solution: adopts a different trust model – the “web of
  trust”
 No centralised authority like a root of trust !
 The concept of the web of trust:
    The concept: Individuals sign one another’s public keys and
     create an interconnected community of public-key users.
    These “certificates” are stored along with keys in key rings
        A signature testifies that the User ID associated with this public key is
         valid
        A signature is formed using the private key of the signer
    PGP computes a trust level for each public key in key ring.
    Users take part in the assignment of the trust level
      Trust in Public Key Ring
 Each user collects signed keys and stores these in the public-
  key ring.
 Each entry in the ring has:
    Key legitimacy field
        Measures the degree to which this PGP user trusts that the key is valid
         for its user. The higher the level of trust, the stronger is the binding of
         this user ID to this key
    Signature trust field
        Measures how far the PGP user trusts the signer to certify public keys.
         (The key legitimacy field for an entry derives from the signature trust
         fields.)
    Owner trust field
        Indicates the degree to which this PGP user trusts the key's owner to
         sign other public-key certificates. PGP doesn't compute this level of
         trust; the PGP user assigns it. You can think of a signature trust field as
         a cached copy of the owner trust field from another entry.
          Trust in Public Key Ring
      Key Legitimacy Field (computed by PGP)
      Signature Trust Field (copies of OTF)
      Owner Trust Field (assigned by the user)
                               Public-Key Ring
Timestamp   Key   Public   Owner User         Key          Signature(s)   Signature
            ID*   Key      Trust ID*          Legitimacy                  Trust(s)


•           •     •        •       •          •            •              •

•           •     •        •       •          •            •              •

•           •     •        •       •          •            •              •




Ti          KUi KUi        Trust   User   i   Trust
            mod            flagi              flagi
            264
•           •     •        •       •          •            •              •

•           •     •        •       •          •            •              •

•           •     •        •       •          •            •              •
     Adding a new public key to your
            public-key ring:
 Owner trust field:            (signed other keys)
     If you own the key - ultimate trust is automatically assigned.
     If you don’t own the key - PGP asks the user:
          unknown, untrusted, marginally trusted, or completely trusted
 Signature trust field:        (trusts the signer)
     PGP searches the public-key ring to see if the author of this signature is among the
      known public-key owners.
     If so, the owner trust value for this owner is assigned to the signature trust field for this
      signature.
          OWNERTRUST                   SIGTRUST
     If not, an unknown-user value is assigned.
 key-legitimacy:               (the key is valid for its user)
     On the basis of the signature trust fields present in this entry.
     If at least one signature has a value of ultimate trust, then the key legitimacy
      value is set to complete
     Otherwise, PGP computes a weighted sum of the trust values.
          1/X is given to signatures that are always trusted
          1/Y is given to signatures that are usually trusted
          X and Y are user-configurable parameters.
PGP Trust Model Example
         Revoking Public Keys
 When exposure suspects or simply avoiding the use of the same
  key for an extended period
 The owner issue a key revocation certificate
    Signed by the owner , with the corresponding private key
    Same form of normal signature certificate but includes an indicator that
      the purpose of this certificate is to revoke the use of this public key
 The owner should disseminate this certificate as widely and as
  quickly as possible opponent
 NOTE:
    An opponent who has compromised the private-key of an owner can
      also issue such a certificate. However, this would deny the opponent as
      well as the legitimate owner the use of the public Key – seems much
      less likely threat.
             PEM과 PGP 비교

            PEM                        PGP
•   IETF                   •   Phil Zimmerman
•   Internet 표준안           •   응용 프로그램
•   이론 중심                  •   실세계 중심
•   중앙집중화된 키 인증            •   분산화된 키 인증
•   구현이 어렵다                •   구현이 용이함
•   익명의 메세지를 허용치 않음        •   익명의 메세지를 허용함
•   높은 보안성 (군사용, 은행 시스템)   •   일반 용도의 보안성
•   많이 사용되지 않음             •   많이 사용
 Next :
S/MIME
             S/MIME - Overview
 After the development of PEM industry working group led by RSA
  Security, Inc. started to develop another specification for conveying
  digitally signed and/or encrypted and digitally enveloped data in
  accordance to the MIME message formats.
 S/MIME (Secure/Multipurpose Internet Mail Extension) is a security
  enhancement to the MIME Internet e-mail format standard.
 S/MIME is not restricted to mail; it can be used with any transport
  mechanism that transports MIME data, such as HTTP.
 S/MIME is likely to emerge as the industry standard for commercial
  and organizational use, while PGP will remain the choice for
  personal e-mail security for many.
              S/MIME - Overview
 S/MIME provides the following cryptography security services:
    Authentication.
    Message Integrity.                 By using digital signing
    Non-repudiation of origin.
    Privacy and data security. By using encryption


 There are three versions of S/MIME:
    S/MIME version 1 (1995) - was specified and officially published in 1995
     by RSA Security, Inc.
    S/MIME version 2 (1998) - was specified in a pair of informational RFC
     documents - RFC 2311 and RFC 2312 - in March1998.
    The work was continued in the IETF S/MIME Mail Security (SMIME)
     WG and resulted in S/MIME version 3 (1999) specified in RFCs 2630 to
     2634 in June 1999.
                            MIME
 RFC 822 defines a format for text messages that are sent
  using electronic mail.
 SMTP/RFC822 scheme limitations:
    SMTP cannot transmit executable files or other binary files.
    SMTP cannot transmit text data that includes national language
     characters because these are represented by 8-bit codes with
     values of 128 decimal or higher, and SMTP is limited to 7-bit
     ASCII.
    SMTP servers may reject mail message over a certain size.
    SMTP gateways that translate between ASCII to EBCDIC suffer
     translation problems.
    Some SMTP implementations do not adhere completely to the
     SMTP standard defined in RFC 822.
                   MIME (contd.)
 MIME specification includes the following elements:
   Five new message header fields.
        These fields provide information about the body of the message.
    A number of content formats are defined,
       thus standardizing representations that supports multimedia e-
        mail.
    Transfer encodings are defined
       that enable that protect any content format to be altered by the
        mail system.
 MIME provides a standardized way of dealing with a
  wide variety of information representations in a
  multimedia environment.
                   MIME (contd.)
 Here is a summary of the different MIME content types:

           Type      Subtype                                       Description

            Text
                             Plain             Unformatted text (ASCII or ISO 8859).
                         Enriched                  Provides greater format flexibility.



       Multipart
                            Mixed       The different parts are independent but are to
                                        be transmitted together. Should be presented
                                                  to the receiver in their original order.
                           Parallel         Differs from mixed only in that no order is
                       Alternative                                               defined.
                                         The different parts are alternative versions of
                            Digest                                the same information.
                                      Similar to Mixed but the default type/subtype of
                                                           each part is message/rfc822.

       Message
                            rfc822    The body is itself an encapsulated message that
                                                                 conforms to RFC822.
                            Partial      Used to allow fragmentation in a transparent
                                                                  way to the recipient.
                     External body         Contains a pointer to an object exists else
                                                                               where.
              MIME (contd.)

       Type    Subtype                                   Description

    Image               Jpeg                  The image is in JPEG format.
                          gif                  The image is in GIF format.



     Video             Mpeg                                  MPEG format.



     Audio             Basic    Single-channel 8-bit ISDN mu-law encoding
                                                   at a sample rate of 8kHz



Application        Postscript                             Adobe Postscirpt.
                Octet-stream         General binary data consisting of 8-bit
                                                                     bytes.
                        MIME (contd.)
 The other major component of MIME is a definition of
  transfer encodings for message contents:
       Encoding                                                           Description
                 7bit            The data are all represented by short lines of ASCII chars.

                 8bit               The lines are short, but there may be non-ASCII chars.

              Binary         Not only may non-ASCII chars be presented but lines are not
                                           necessarily short enough for SMTP transport.

     Quoted-printable     Encodes the data in such a way that if the data being encoded are
                           mostly ASCII text, the encoded form of the data remains largely
                                                                   recognizable by humans.
              Base64        Encodes data by mapping 6-bit blocks to 8-bit printable ASCII
                                                                       characters blocks.
             x-token                                              A nonstandard encoding.
             MIME (contd.)
 Canonical form is a format that is
  standardized for use between systems.
 Conclusions:
   MIME is a necessity in today’s Internet and e-mail
    traffic requirements.
   The “Object Oriented” structure of the MIME
    message enhances its capability to serve as
    multipurpose standard.
   The MIME is capable of transferring data
    between two distinct systems which uses different
    formats
            S/MIME - Functions
 S/MIME is based on the Cryptographic Message Syntax
  (CMS) specified in RFC 2630.
 Enveloped data:
     This consists of encrypted content of any type and encrypted
      content encryption keys for one or more users. This functions
      provides privacy and data security.
 Signed data:
    A digital signature is formed by signing the message digest and
     then encrypting that with the signer private key. The content and
     the signature are then encoded using base64 encoding.
    This function provides authenticity, message integrity and non-
     repudiation of origin.
        S/MIME - Functions
 SignerInfo: allows the inclusion of
 unsigned and signed attributes to be
 included along with a signature.
  signingTime
  sMIMECapabilities
  sMIMEEncryptionKeyPreference
         S/MIME - Functions
 Clear signed data:
  In this case a digital signature of the content
    is formed, However only the signature is
    encoded with base64.
 Signed and enveloped data:
  Because of S/MIME encapsulating capability
    (multipart type), signed only and encrypted
    only entities may be nested, so that encrypted
    data may be signed and signed data may be
    encrypted.
      S/MIME - Cryptography
  Be liberal in what you receive and
     conservative in what you send.
 Definitions:
   MUST: The definition is an absolute requirement
    of the specification.
   SHOULD: There may exist valid reasons in
    particular circumstances to ignore this feature or
    function, but it is recommended that an
    implementation include the feature or function.
       S/MIME - Cryptography
    Function                          Requirement

      Creation of a     MUST support SHA-1. SHOULD use sha-1.
    message digest.     Receiving agents SHOULD support MD5 for
                                 the purpose of providing backward
                                      compatibility with S/MIME v2.


  A message digest        Both sending and receiving agents MUST
encryption to form a                                   support DSS.
   digital signature.             Receiving agents SHOULD support
                        verification of RSA signatures with key sizes
                         512 bits to 1024 bits. Note that S/MIME v2
                          clients are only capable of verifying digital
                                               signatures using RSA.
       S/MIME - Cryptography
       Function                          Requirement
A session key encryption     Both sending and receiving agents MUST
for transmission with the                       support Diffie-Hellman.
                message.        Sending agents SHOULD support RSA
                            encryption with key sizes 512 to 1024 bits.
                               Receiving agents SHOULD support RSA
                                                            decryption.
  A message Encryption       Sending an receiving agent MUST support
   for transmission with             Encryption/Decryption with 3DES.
  one-time session key.            Receiving agents SHOULD support
                                               decryption with RC2/40.
                              (S/MIME V 2. - Sending agents SHOULD
                                    support RSA encryption with 3DES
                                  and RC2/40. Receiving agents MUST
                                      support decryption with RC2/40.)
       S/MIME - Cryptography
 Algorithm use decision procedure:
   Preferred decrypting capabilities: SHOULD choose
     the first (highest preference) capability on the list.
   No list of capabilities but has received message/s:
        SHOULD use the same encryption algorithm as was used on
         the last signed and encrypted message.
    No knowledge & Willing to risk:
        willing to risk that the recipient may not be able to decrypt the
         message, then the sending agent SHOULD use 3DES.
    No knowledge & Not willing to risk:
        sending agent MUST use RC2/40.
      S/MIME - Cryptography
 A possible problem:
   A multiple recipients message:
       Performance
       Security


 The Solution:
   This problem is solved using an Enhanced
    Security service called S/MIME Mail List Agent
    (MLA).
   An MLA perform the recipient-specific encryption
    for each recipient, and forward the message.
             S/MIME - Message
                      Canonical
                        MIME
                                           Algorithm
  Certificates
                                          Identifiers


                       CMS
MIME bodies + CMS.



                     CMS object


                       MIME       Encoding + Canonical
                                                 form
                S/MIME - Message

   Type           Subtype          S/MIME                 Description
                                   parameter
Multipart     Signed                            A clear message in tow
                                                parts:
                                                One is the message and
                                                the other is the signature.
Application   pkcs7-mime         signedData     A signed S/MIE entity.

              pkcs7-mime        envelopedData   An encrypted S/MIME entity.

                                                multipart/signed message.
              Pkcs7-signature        --
                                                A certificate registration
              pkcs10-mime            --         request message.
        S/MIME - Message
                                 Recipient’s public key
 Enveloped Data:                   Diffie-Hellman /
                                                 RSA
                                Encrypt the session key
      Pseudorandom
         session key

       ׁׁ(3DES or RC2/40)



         Certificate
                       RecipientInfo

            M
                                           enveloped-data
                            +
    S/MIME - Message
                                     Sender’s private key



    Hash function                                 Encryption

M
    SHA-1 or MD5


          Certificate
                        SignerInfo




                           Base64 encoding
         S/MIME - Message
 Clear signing:
  Clear signing is achieved using the multipart
    content type with a signed sub-type .
 Two parts:
   Clear text (or any MIME type) encoded in
    base64.
   SignedData.
                     S/MIME - Message
                                                                               This parameter indicates
 Content-Type: multipart/signed;                                            that this is a two part clear-
                        protocol=“application/pkcs7-signature”;                             signed entity.
                        micalg=sha1; boundary=boundary42

           --boundary42
                                                                   This parameter indicates the
             Content-Type: text/plain                             type of message digest used.
Unsigned
   Data                   This is a clear-signed message.

             --boundary42

             Content-Type: application/pkcs7-signature;
             name=smime.p7s                                                             SignerInfo
             Content-Transfer-Encoding: base64                                             Header
             Content-Disposition: attachment; filename=smime.p7s

             ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
             4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
             n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4

             --boundary42--
         S/MIME - Message
 Certificate-only message:
  Used to transport certificates.
  contains only certificates or a certificate
   revocation list (CRL).
   Sent in response to a registration request.
  The message is an application/pkcs7-mime
   type/subtype.
             S/MIME - Message
 Creating a Certificates-only Message:
   Step 1:
        The certificates are made available to the CMS generating
         process which creates a CMS object of type signedData.
    Step 2:
       The CMS signedData object is enclosed in an application/pkcs7-
        mime MIME entity.
 The smime-type parameter for a certs-only message is
  "certs-only".
 The file extension for this type of message is ".p7c".
          S/MIME - Message
 Registration request:
   A message signer MUST have a certificate for the
    signature so that the receiving agent can verify
    the signature.
   Exchange with CA, hardware token, diskette etc.
   S/MIME v3- does not specify how to request a
    certification.
   S/MIME v2- request by applying to a CA using the
    application/pkcs10 S/MIME entity.
   A typical app. Only needs to send certification
    request.
                 S/MIME - Message
Registration request:

                              Subject’s name


   Public-key in bit-string
           representation
                                  +            CertificationRequestInfo
         010111010011…




     Public-key ID
                                 ?

                                PKCS10
      CA                                                       User’s private key
       S/MIME - Certificates
 S/MIME uses public-key certificates that
  conform to version 3 of X.509.
 A hybrid between a strict X.509 certification
  hierarchy and PGP's web of trust.
 A receiving agent MUST provide some
  certificate retrieval mechanism.
 Receiving and sending agents SHOULD also
  provide a mechanism to allow a user to "store
  and protect" certificates
        S/MIME - Certificates
 Public key certificates are
  required to protect the
  authenticity and integrity of
  public keys, thus protecting
  against man-in-the-middle
  attack.
 A certificate chain must be
  verified until a root CA is
  reached
         S/MIME - Certificates
 a certificate can only be trusted if:
    every certificate in the chain is successfully
     verified.
    every CA in the certificate chain is trusted.
 In practice, certificate chains are short and
  seldom verified for trustworthiness.
 Also, the concept of cross-certification is of
  low practical value and seldom used between
  certification service providers.
S/MIME - Certificates
           S/MIME - User role
 Key generation:
   MUST be capable of generating separate Diffie-
    Hellman and DSS key pairs.
      SHOULD be capable of generating RSA key pairs.
      good source of non-deterministic random.
      protected in a secure fashion.

 Registration:
   A user's public key must be registered with a
    certification authority in order to receive an X.509
    public-key certificate.
          S/MIME - User role
 Certificate storage and retrieval:
  access to a local list of certificates in order to
   verify incoming signatures and encrypt
   outgoing messages.
  maintained by the user local administrative
   entity on behalf of number of users.
           S-MIME - Attacks
 Certificate Management in S/MIME:
  CA-centered.
  CA certificates come with the client software.
  An ordinary user is not aware of the CAs that
   he/she trusts.
  Certificates are sent along with the signed
   messages.
               S-MIME - Attacks
 Certificates classes (common practice by most CAs)
    Class 1
    Class 2        Tighter identity      Easier to
    Class 3              validation         issue


 CA certification policies
    ID-control practices
        Class 1: only email address
        Class 2: against third party database
        Class 3: apply in person and submit picture IDs and/or hard
         documentation

 How to determine user
    by name?
    by e-mail address?
           S-MIME - Attacks
 Attack 1: Class 1 Certificate Attack
  No identity check during registration.
  Binding between public key and e-mail
    address.
  It is possible to enroll under a different name.
     Name spoofing is possible in signed messages
  E-mail clients do not make this fact explicit to
    average users.
          S-MIME - Attacks
 Attack 1: Class 1 Certificate Attack
  Step 1: Get an e-mail address that implies the
    person you want to imitate.
  Step 2: Register for a certificate with that
    bogus name and e-mail address.
  Step 3: Step up an outgoing e-mail account
    at your favorite e-mail client software
    with that bogus name.
  Step 4: Send bogus signed messages
 S/MIME - Attacks
Step 2- Registration
S/MIME - Attacks
S/MIME - Attacks
S/MIME - Attacks

shlomo@hotmail.com
S/MIME - Attacks
S/MIME - Attacks
S/MIME - Attacks
Step 3 – Setup local account
     S/MIME - Attacks
Step 4 – Send signed but bogus msgs.
          S/MIME - Attacks
 Consequences:
  Loose control for Class 1 certificates.
  The system becomes less secure for the
   name of security.
              S/MIME - Attacks
 Attack 2: Use one’s certificate to send
 emails under another name.
  Step 1: Set up another e-mail account at local
    client.
         Same e-mail address
         But a different name

  Step 2: Send bogus signed messages
 S/MIME - Attacks
Step 1- setup another account
  S/MIME - Attacks
Step 2- Send bogus signed msg.
             S/MIME - Attacks
 Consequences:
   During verification, e-mail client does not match
    the name in certificate with the name in e-mail.
      Only e-mail addresses are matched (as mentioned in
       RFC 2632 (S/MIME Certificate Handling).
    Verifier’s manual check is needed.
    Not a specific problem of class-1 certificates
      Same attack is possible using class-2 and class-3
       certificates.
      E-mail clients are not concerned with certificate
       classes.
           S/MIME - Attacks
 Attack 3: Forging the header
  The scope of a S/MIME signature does not
    include the e-mail header.
     from, to, cc, subject, date
  Indeed, the mail header is modified without
   changing the verification status.
  Problem of all classes of certificates.
           S/MIME - Attacks
 What should be done?
  Class 1 certificates should be discontinued.
  E-mail clients must be aware of certificate
   classes and issue appropriate warnings to the
   verifiers.
  It is up to you whether to believe a digital
   signature is valid or not
     Use your reasoning, not your e-mail client’s.
  Try to identify people by their e-mail
    addresses.
              S/MIME - Attacks
 What should be done (2)?
   Examine the details of certificate of the other
    party.
   Do not trust Class 1 certificates.
   Ask the sender to put all sensitive information
    within the message
      Sender’s identity
      Subject
      Date
    Don’t let subject say all!
         S/MIME - Summery
 In summary, S/MIME provides a thoroughly
  designed and widely deployed technological
  approach to provide basic message protection
  services for the Internet.
 S/MIME makes use of a hierarchical trust model
  based on ITU-T X.509.
 Most importantly, S/MIME is strongly supported by
  all major vendors of UA products.
 It very likely that S/MIME will become the
  predominant technology for secure messaging on
  the Internet.
        S/MIME - Summery
 In contrast to PGP S/MIME cannot be
  used by user agent which don't support
  MIME.
 There are problems in the “stiches”
  (certificate handling).
 With the release of S/MIME v3,
  standardization activities have slowed
  down.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:10/1/2012
language:Unknown
pages:123