Pretty Good Privacy - PowerPoint PPT Presentation

Loading...

PPT – Pretty Good Privacy PowerPoint presentation | free to download - id: 27112-OWE5N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Pretty Good Privacy

Description:

Pretty Good Privacy 'To PGP or not to PGP? ' Phil ... Pretty Good Privacy. First released in 1991, developed by Phil Zimmerman, provoked export control and ... – PowerPoint PPT presentation

Number of Views:144
Avg rating:3.0/5.0
Slides: 36
Provided by: guya9
Learn more at: http://www.cs.huji.ac.il
Category:
Tags: good | pretty | privacy

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Pretty Good Privacy


1
Pretty Good Privacy
  • To PGP or not to PGP?
  • Phil Zimmermann

2
What are we going to do ?
  • Background Concept
  • Why Is PGP Popular?
  • PGPs algorithms
  • Operational Description
  • Inside look on operations
  • Key Management
  • The problem Solution
  • Web Of Trust

3
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

4
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

5
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.

6
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 (senders private
    key)
  • - the result is prepended to the message
  • Receiver recover the hash code
  • - uses RSA with the senders 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

7
Authentication/Digital signature
Source A
Destination B
Public key KRb
Private key KRa
Message M
DP
H
EP

ZIP
UNZIP
Compare
H
8
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
  • iEYEARECAAYFAj5Ha6AACgkQ99/KQPj2cRNHsQCffKf64LwWQM
    fRIiKUfs6QrokB7twAnR5gDobzGapPgyLKQ0gLklj1WIIpgXa
    d
  • -----END PGP SIGNATURE-----

9
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.

10
Confidentiality/Encryption
Source A
Destination B
Public key KUb
Private key KRb
Session key Ks
EP
DP
Message M
Message M
Session key Ks
EC

ZIP
UNZIP
DC
11
Confidentiality Authentication
Source A
Destination B
Public key KUb
Private key KRb
Public key KRb
Session key Ks
DP
EP
Private key KRa
DP
Session key Ks
Compare
M
H

EP
ZIP
EC

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

12
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

13
Example of ZIP (LZ77) Scheme
The brown fox jumped over the brown foxy jumping
frog The brown fox jumped over 0b26d13d
y 0b27d5ding frog
13
5
26
27
  • 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

14
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

15
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

16
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.

17
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

18
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

19
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)

20
Format of PGP Message
Session Key Component
Key Id of Recipients Public Key
Session Key
EKUb
Timestamp
Key Id of Senders Public Key
Signature
Leading Two Octets of Message Digest
EKRa
Message Digest
Eks
R64
ZIP
Filename
Time Stamp
Message
Data
21
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.

22
Key Rings
Private-Key Ring
23
Key Rings
Public-Key Ring
24
Message Generation
Public-Key ring
Passphase
H
Select
Private-Key ring
IDb
Select
IDa
Encrypted Private key
DC
Key ID
Public key KRb
Private key KRa
RNG
Message digest
Session key Ks
Message M
H
EP

Output
Signature message
EP

Message
Encrypted Signature message
EC
25
Reception
Public-Key ring
Passphase
H
Private-Key ring
Select
Select
Encrypted Private key
DC
Private key KRb
Public key KRb
DP
Session key Ks
DP
DC
Compare
H
26
Public Key Management Problem
  • The Problem As 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 Bs signature,
    so that A will accept the message as coming from
    B !
  • Any encrypted message from A to B can be read by
    C !

27
Public Key Management Problem (cont.)
  • Possible solutions
  • Physically get the key from B
  • Verify a key by telephone
  • Obtain Bs public key from a mutual trusted
    individual
  • Obtains Bs public key from a trusted certifying
    authority
  • That would violate PGPs 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

28
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 anothers
    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

29
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.

30
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
31
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 dont 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.

32
PGP Trust Model Example
33
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.

34
  • Next S/MIME

35
Radix-64 Conversion Table
Radix-64 Encoding
About PowerShow.com