Electronic Mail Security: PGP, SMIME and PEM - PowerPoint PPT Presentation

1 / 69
About This Presentation
Title:

Electronic Mail Security: PGP, SMIME and PEM

Description:

PGP converts an arbitrary binary stream into a stream of printable ASCII characters ... quoted-printable. non-ASCII characters are converted into hexa numbers ... – PowerPoint PPT presentation

Number of Views:1239
Avg rating:3.0/5.0
Slides: 70
Provided by: BIL129
Category:

less

Transcript and Presenter's Notes

Title: Electronic Mail Security: PGP, SMIME and PEM


1
Electronic Mail Security PGP, S/MIME and PEM
Cmpe 526 Operating System and Network Security
  • 2004721025
  • Bilge BASKELES

2
Email Security
  • currently message contents are not secure
  • may be inspected either in transit
  • or by suitably privileged users on destination
    system
  • Spam
  • Secure email PGP, S/MIME, PEM

3
Outline
  • PGP
  • S/MIME
  • PEM

4
PGPWhat is PGP?
  • PGP - Pretty Good Privacy
  • general purpose application to protect (encrypt
    and/or sign) files
  • can be used to protect e-mail messages
  • can be used by corporations as well as
    individuals
  • based on strong cryptographic algorithms (IDEA,
    RSA, SHA-1)
  • available free of charge at http//www.pgpi.org
  • first version developed by Phil Zimmermann
  • can be embedded in MS Outlook, Netscape
    Communicator etc.
  • PGP is now on an Internet standards track (RFC
    3156)

5
PGPEmail Security Enhancements
  • authentication
  • of sender of message or reciever of message in
    some cases
  • Certification mechanisms
  • confidentiality
  • protection from disclosure (against replay
    attacks)
  • message integrity
  • protection from modification
  • available in public-key encryption
  • non-repudiation of origin
  • protection from denial by sender
  • available in public-key encryption

6
PGPPGP Services
  • messages
  • authentication
  • confidentiality
  • compression
  • E-mail compatibility
  • segmentation and reassembly
  • non-repudiation of origin
  • key management
  • generation, distribution, and revocation of
    public/private keys
  • generation and transport of session keys

7
PGPAuthentication
  • based on digital signatures
  • message is hashed and 128-bit output is added to
    message packet
  • supported algorithms RSA/SHA and DSS/SHA
    (unrecoverable)
  • distributed certification mechanism where every
    sender/reciever is a certificate authority

8
PGPAuthentication
9
PGPConfidentiality
  • Solved by symmetric key message encryption with a
    random, single-use session key
  • 128-bit session key is encrypted with the public
    key of the receiver
  • supported algorithms
  • symmetric CAST, IDEA, 3DES, Twofish
  • asymmetric RSA, ElGamal

10
PGPConfidentiality
11
PGPCompression
  • Applied after the signature
  • enough to store clear message and signature for
    later verification
  • it would be possible to dynamically compress
    messages before signature verification, but
  • then all PGP implementations should use the same
    compression algorithm
  • however, different PGP versions use slightly
    different compression algorithms
  • applied before encryption
  • compression reduces redundancy makes
    cryptanalysis harder
  • less bandwidth usage
  • Useful against decryption attacks where the
    frequency of letters are used
  • supported algorithm ZIP

12
PGPEmail compatibility
  • encrypted messages and signatures may contain
    arbitrary octets
  • most e-mail systems support only ASCII characters
  • text file processing is different on different
    OSs, PGP message packet may optionally include OS
    information
  • PGP converts an arbitrary binary stream into a
    stream of printable ASCII characters

13
PGPEmail compatibility
  • radix 64 conversion 3 8-bit blocks 4 6-bit
    blocks (increases the file size 33.3)

14
PGP
15
PGPPacket Structure
  • Message packet, signature packet and session key
    packet
  • PGP can produce only message packet session key
    packet or signature packet (compression optional)
  • Timestamp is included to overcome attacks by
    intruders who steals the whole packet and sends
    again (e.g. Money transfer)

16
PGPMessage Format
17
PGPKey ID
  • a user may have several public key private key
    pairs
  • which private key to use to decrypt the session
    key?
  • which public key to use to verify a signature?
  • transmitting the whole public key would be
    wasteful
  • associating a random ID to a public key would
    result in management burden
  • PGP key ID least significant 64 bits of the
    public key
  • unique within a user with very high probability

18
PGPRandom number generators
  • true random numbers
  • used to generate public key private key pairs
    (512-2048 bit)
  • provide the initial seed for the pseudo-random
    number generator (PRNG)
  • provide additional input during pseudo-random
    number generation
  • pseudo-random numbers
  • used to generate session keys

19
PGPTrue random numbers
  • PGP maintains a 256-byte buffer of random bits
  • each time PGP expects a keystroke from the user,
    it records
  • the time when it starts waiting (32 bits)
  • the time when the key was pressed (32 bits)
  • the value of the key stroke (8 bits)
  • the recorded information is used to generate a
    key
  • the generated key is used to encrypt the current
    value of the random-bit buffer

20
PGPPrivate key ring
  • used to store the public key private key pairs
    owned by a given user
  • should be stored on portable storage (floppy,USB
    disks)
  • essentially a table, where each row contains the
    following entries
  • timestamp
  • key ID (indexed)
  • public key
  • encrypted private key ( MD5(pwd)IDEA )
  • user ID (indexed)

21
PGPPublic key ring
  • used to store public keys of other users
  • a table, where each row contains the following
    entries
  • timestamp
  • key ID (indexed)
  • public key
  • user ID (indexed)
  • owner trust
  • signature(s)
  • signature trust(s)
  • key legitimacy

22
PGPTrust models
  • Direct trust
  • a user trusts that a key is valid because he or
    she knows where it came from
  • Hierarchical trust
  • Tree structured trust where there are roots and
    leaves
  • Web of trust (PGP model of trust)
  • A graph structure where a certificate might be
    trusted directly, or trusted in some chain going
    back to a directly trusted root certificate.
    Everyone is a certificate authority.

23
PGPTrust management
  • owner trust
  • assigned by the user
  • possible values
  • unknown user
  • usually not trusted to sign
  • usually trusted to sign
  • always trusted to sign
  • ultimately trusted (own key, present in private
    key ring)
  • signature trust
  • assigned by the PGP system
  • if the corresponding public key is already in the
    public-key ring, then its owner trust entry is
    copied into signature trust
  • otherwise, signature trust is set to unknown user

24
PGPKey Legitimacy
  • computed by the PGP system
  • if at least one signature trust is ultimate, then
    the key legitimacy is 1 (complete)
  • otherwise, a weighted sum of the signature trust
    values is computed
  • always trusted signatures has a weight of 1/X
  • usually trusted signatures has a weight of 1/Y
  • X, Y are user-configurable parameters
  • example X2, Y4
  • 1 ultimately trusted, or
  • 2 always trusted, or
  • 1 always trusted and 2 usually trusted, or
  • 4 usually trusted signatures are needed to obtain
    full legitimacy

25
PGPKey Legitimacy
K
26
PGPPublic key distribution
  • Public key servers
  • independent of PGP
  • store public-key certificate pairs
  • do not guarantee the validity of keys
  • consistent among themselves
  • require authorisation for revoking the public-key
    from servers, problem how to delete invalid
    keys from public-key ring files of users
  • Wrong public keys
  • Get the public key from a centralized Certificate
    Authority (supported by latest versions of PGP)
  • Ask the public key owner if the public key is
    valid before sending message

27
PGPPublic-key revocation
  • why to revoke a public key?
  • suspected to be compromised (private key got
    known by someone)
  • re-keying
  • the owner issues a revocation certificate
  • has a similar format to normal public-key
    certificates
  • contains the public key to be revoked
  • signed with the corresponding private key
  • and disseminates it as widely and quickly as
    possible
  • if a key is compromised
  • e.g., Bob knows the private key of Alice
  • Bob can issue a revocation certificate to revoke
    the public key of Alice
  • even better for Alice

28
PGPPrivate-key splitting
  • In cases, where private-key must be known by more
    than one person, key might be splitted to assure
    that more than one person must be present to
    enter a password to access the private key (e.g.
    Locks in a bank)

29
PGPVulnerabilities
  • Compromised passphrase and private key
    (publishing them)
  • Public key tampering (get public key directly
    from owner)
  • Not quite deleted files (OS issue)
  • Viruses and Trojan horses
  • Swap files or virtual memory (OS issue)
  • Physical security breach (Server Key Mode, in
    Universal PGP)
  • Tempest attacks (electromagnetic signal)
  • Protecting against bogus timestamps (trusted
    third party, message timestamp)
  • Exposure on multi-user systems (network sniffers)
  • Traffic analysis (no protection)
  • Cryptanalysis (expensive)

30
PGPSecuring PGP
  • Store the private key on portable disk and always
    backup
  • Choose the password that is used to encrypt the
    private key as long as possible and easy to
    remember but hard to guess
  • Obey the certificate rules strictly or ask for a
    confirmation of public key
  • Let PGP delete the message permanently after
    creating, if the message is important (OS)

31
S/MIMEWhat is S/MIME?
  • Secure / Multipurpose Internet Mail Extension
  • a security enhancement to MIME
  • provides similar services to PGP
  • based on technology from RSA Security
  • Uses PKCS7 (Public Key Cryptography Standard)
  • industry standard for commercial and
    organizational use
  • is compatible with CMS (Cryptographic Message
    Syntax)
  • is contained in MS Outlook, Netscape Communicator
    etc.
  • RFC 2630, 2632, 2633

32
S/MIMEProblems
  • Problems with RFC822 and SMTP
  • executable files must be converted into ASCII
  • various schemes exist (e.g., Unix UUencode)
  • a standard is needed
  • text data that includes special characters (e.g.,
    Hungarian text)
  • some servers
  • reject messages over a certain size
  • delete, add, or reorder CR and LF characters
  • truncate or wrap lines longer than 76 characters
  • remove trailing white space (tabs and spaces)
  • pad lines in a message to the same length
  • convert tab characters into multiple spaces

33
S/MIMEMIME
  • defines a format for text messages to be sent
    using e-mail
  • Internet standard
  • structure of RFC 822 compliant messages
  • header lines (e.g., from , to , cc )
  • blank line
  • body (the text to be sent)
  • example
  • Date Tue, 16 Jan 2005 103717 (EST)
  • From Alice Ally ltally_at_boun.edu.trgt
  • Subject Test
  • To afriend_at_boun.edu.tr
  • Blablabla

34
S/MIMEMIME
  • defines new message header fields
  • defines a number of content formats
    (standardizing representation of multimedia
    contents)
  • defines transfer encodings that protects the
    content from alteration by the mail system

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

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

37
S/MIMEMIME Transfer encodings
  • 7bit
  • short lines of ASCII characters (NVT ASCII)
  • 8bit
  • short lines of non-ASCII characters
  • binary
  • non-ASCII characters
  • lines are not necessarily short
  • quoted-printable
  • non-ASCII characters are converted into hexa
    numbers (e.g., EF)
  • base64 (radix 64)
  • 3 8-bit blocks into 4 6-bit blocks
  • x-token
  • non-standard encoding

38
S/MIMEMIME Transform Functions
39
S/MIMES/MIME services
  • enveloped data (application/pkcs7-mime
    smime-type enveloped-data)
  • standard digital envelop (against replay attacks)
  • signed data (application/pkcs7-mime smime-type
    signed-data)
  • standard digital signature (hash and sign)
  • content signature is encoded using base64
    encoding
  • clear-signed data (multipart/signed)
  • standard digital signature
  • only the signature is encoded using base64
  • recipient without S/MIME capability can read the
    message but cannot verify the signature
  • signed and enveloped data
  • signed and encrypted entities may be nested in
    any order

40
S/MIMECryptographic algorithms
  • hash functions SHA-1 (MD5 in older versions)
  • digital signatures DSS RSA
  • session key encryption ElGamal RSA
  • message encryption Triple-DES, RC2/40 and others
  • have a procedure to decide which algorithms to
    use

41
S/MIMECryptographic algorithms
42
S/MIMEEnveloped Data
  • Generate a pseudorandom session key for RC2/40 or
    DES
  • For each recipient, encrypt the session key with
    the recipients public key
  • For each recipient, prepare a RecipientInfo Block
    which consists of senders public-key
    certificate, an algorithm identifier used to
    encrypt the session key, encrypted session key
  • Encrypt the message with session key

43
S/MIMEPKCS7 enveloped data
44
S/MIMESigned Data
  • Select a message digest algorithm
  • Compute the hash of the content to be signed
  • Encrypt the digest with signers private key
  • Prepare a SignerInfo block containing the
    signers public key certificate, an identifier of
    the MD algorithm, an identifier of the algorithm
    used to envrypt the MD, and the encrypted MD

45
S/MIMEPKCS7 signed data
46
S/MIMECMS
  • CMS allows for a wide variety of options in
    content and algorithm support.
  • DigestAlgorithmIdentifier
  • SignatureAlgorithmIdentifier
  • KeyEncryptionAlgorithmIdentifier
  • CMS defines multiple content types
  • Data content type
  • Signed-data content type
  • Enveloped-data content type
  • Digested-data content type
  • Encrypted-data content type

47
S/MIMECertificate Processing
  • S/MIME uses X.509 v3 certificates to validate
    public keys
  • the PKCS 12 standard specifies the format for
    certificate export and import.
  • managed using a hybrid of a strict X.509 CA
    hierarchy PGPs web of trust
  • each client has a list of trusted CAs certs
  • and own public/private key pairs certs
  • certificates must be signed by trusted CAs e.g.
    VeriSign
  • Using CRLs(Certificate Revocation List)
    retrieved periodically from CAs
  • Using Attribute certificate A subject may have
    multiple X.509 ACs associated with each of its
    certificates. Each X.509 AC binds one or more
    attributes with one of the subjects certificates

48
S/MIMECertification
49
S/MIMECRL
  • X.509 states that it is a CA's responsibility to
    maintain "a time- stamped list of the
    certificates it issued which have been revoked.
  • Two reasons for a CA to revoke a certificate
  • suspected compromise of a private component
    (invalidating the corresponding public component)
  • or change of user affiliation (invalidating the
    DN).
  • A CRL component includes the fields
  • signature (signature algorithm ID and parameters)
  • issuer
  • last update
  • next update
  • revoked certificates

50
S/MIMESecuring a MIME entity
  • MIME entity is prepared according to the normal
    rules for MIME message preparation
  • prepared MIME entity is processed by S/MIME to
    produce a PKCS object
  • the PKCS object is treated as message content and
    wrapped in MIME

51
S/MIMEEnhanced Security Services
  • Signed receipts
  • The recipient signs the original message with
    senders signature and appends his signature
  • Security labels
  • A set of security information about the
    sensitivity of content of S/MIME protected
    message (secret, confidential, restricted ..)
  • Secure mailing lists
  • Used when multiple recievers for a single message
  • These features interact
  • Mail List Agents (MLAs) enforce access controls
    based on security labels
  • MLAs can override the message originators
    requests for signed receipts

52
S/MIMEUsage
  • To use S/MIME,
  • You have to get an ID from vendors such as
    Thawte(free) and VeriSign(15 per year)
  • In Windows, Outlook will automatically adopt
    public-key private key pair on the same machine

53
S/MIMESecurity
  • Public-key tampering can be detected using
    trusted CAs
  • Most replay attacks can be eliminated using
    timestamps
  • Signing, or the authentication of sender with
    digital signatures
  • Interoperability with other S/MIME-compliant
    software (using PKCS12)
  • Cross-platform messaging
  • S/MIME v3 handles the problem of multiple e-mail
    addresses with one common name -gt attribute
    certificate assigning one e-mail address per
    certificate binding email addresses with entitys
    public key certificate

54
S/MIMEHybrid Methods
  • MIME with OpenPGP
  • Message and certificate format based on PGP
  • Uses Triple-DES for symmetric encryption,
    El-Gamal for signature, SHA-1 for hash
  • MIME encapsulation of signed data is
    multipart/signed with ASCII
  • MIME encapsulation of encrypted data is
    multipart/encrypted

55
PEMWhats PEM?
  • Privacy Enhanced Mail
  • Similar to PGP except
  • Uses DES instead of IDEA
  • Uses a hiearchical certificate management scheme
  • Handles line termination characters differently
  • RFC 1421, RFC 1422, RFC 1423, RFC 1424

56
PEMSecurity Enhancements
  • Confidentiality
  • Only sender and recipient(s) can read message
  • Origin authentication
  • Identify the sender precisely
  • Data integrity
  • Any changes in message are easy to detect
  • Non-repudiation of origin
  • Whenever possible

57
PEMKeys
  • Interchange keys tied to sender, recipients and
    is static (for some set of messages)
  • Like a public/private key pair
  • Must be available before messages sent
  • Data exchange keys generated for each message
  • Like a session key, session being the message

58
PEMConfidentiality
  • m message
  • ks data exchange key
  • kB Bobs interchange key

m ks ks kB
Alice
Bob
59
PEMIntegrity and authentication
  • m message
  • h(m) hash of message m Message Integrity Check
    (MIC)
  • kA Alices interchange key

m h(m) kA
Alice
Bob
Non-repudiation if kA is Alices private key,
this establishes that Alices private key was
used to sign the message
60
PEMConfidentiality, integrity, authentication
  • If kA is private key, get non-repudiation too

m ks h(m) kA ks kB
Alice
Bob
61
PEMTrust-Model and Certification Structure
  • Rooted tree certification structure
  • Based on X.509 additional restrictions which
    allow for automated validation procedures
  • Distinguishes between Policy CAs and
    Organizational CAs
  • Name Subordination
  • CRL (Certificate Revocation Lists) Procedures

62
PEMCRL Procedures
  • X.509 states that it is a CA's responsibility to
    maintain "a time- stamped list of the
    certificates it issued which have been revoked.
  • Two reasons for a CA to revoke a certificate
  • suspected compromise of a private component
    (invalidating the corresponding public component)
  • or change of user affiliation (invalidating the
    DN).
  • A CRL component includes the fields
  • signature (signature algorithm ID and parameters)
  • issuer
  • last update
  • next update
  • revoked certificates

63
PEMCertification authorities
64
PEMCertification
  • PEM public key certificates are digitally signed
    by a certification authority.
  • The PEM user trusts a certification authority to
    provide public key certificates.
  • Certification authorities are certifed by a
    policy certication authority.
  • Every CA needs own certificate to identify itself
    (certificate-gtX.509 name, public key, digital
    signature ).

65
PEMCertification
  • The certification authorities can also cross
    certify public key certificates from another
    certification authority.
  • The certification authorities are distributed in
    a hierarchical structure with the Internet Policy
    Registration Authority (IPRA) at the top.
  • The IPRA will certify the certification
    authorities. The IPRA is a non-government,
    private agency and may or may not be trusted by
    an organization.

66
PEMSecurity
  • Everything mentioned in PGP applies here except
    for public-key tampering
  • Attacks that modify the implementation of PEM, no
    way to prevent it

67
PEMImplementations
  • TIS/PEM (Trusted Information Systems)
  • RIPEM (written by M. Riordan) not used anymore

68
References
  • Bishop 2002 M. Bishop, Computer Security Art
    and Science, Addison Wesley, 2002
  • Rhee 2003 M. Y. Rhee, Internet Security,
    Cryptographic Principles, Algorithms and
    Protocols, John Wiley Sons, 2003
  • Schneier 1996 B. Schneier, Applied
    Cryptography, John Wiley Sons, 1996
  • Stallings 1999 W. Stallings, Cryptography and
    Network Security, Prentice Hall, 1999
  • Zimmermann 2004 P. Zimmermann, PGP
    Introduction to Cryptography, 2004

69
End of Presentation
  • Any Questions
  • ?
Write a Comment
User Comments (0)
About PowerShow.com