7.1 Pretty Good Privacy - PowerPoint PPT Presentation

1 / 62
About This Presentation
Title:

7.1 Pretty Good Privacy

Description:

I did not find Stallings' description of SSH easy to follow, so I am using the ... Content Type: Change Cipher Spec (20) Version: TLS 1.0 (0x0301) Length: 1 ... – PowerPoint PPT presentation

Number of Views:109
Avg rating:3.0/5.0
Slides: 63
Provided by: AC6
Learn more at: http://www.cis.uab.edu
Category:

less

Transcript and Presenter's Notes

Title: 7.1 Pretty Good Privacy


1
Chapter 7 Electronic Mail Security
7.1 Pretty Good Privacy Phil Zimmerman (MIT)
1. Selected best available cryptographic
algorithms (Table 7.1)
2. Integrated them into a general-purpose
package
3. Made package and documentation readily
available (Freeware, June 1991)
4. Agreed for company to provide a commercial
version (Network Associates later
let the agreement expire)
2
Growth of PGP Reasons
1. readily available free versions
2. algorithms have survived public scrutiny
and are considered extremely secure
3. wide range of applicability
(different key lengths)
4. no government involvement (3-year
criminal investigation under Arms Export
Control Act abandoned in 1996 without
indictment)
5. Internet Standard (OpenPGP, RFCs
3156 and 4880 November, 2007)
3
Using PGP to Authenticate the Sender Recall
figure 3.2(b) for digital signatures
Alice
Bob
4
Alice
Bob
Alice
Bob
compression
Figure 7.1(a)
Decompression
There will be an extra step radix-64 encoding
5
Unlike a physical signature, a digital signature
does not need to be attached to the document.
Because of the properties of the hash function, a
given hash could apply to only one message (to a
high degree of confidence).
Although fig 7.1(a) shows the usual situation,
with the signature attached to the message,
detached signatures are supported by PGP
These can be useful ? to check that no changes
(viruses, etc.) have been made in an
executable program ? when several people,
possibly at different locations, need to
sign a document
Using PGP for confidentiality next slide
6
Recall Figure 3.9(a) for confidentiality
Alice
Bob
Session key not entire message
Bob
Alice
We discussed the basic idea in section 4.3 (page
116)
Figure 7.1(b)
Compress before encryption
7
What if we want both confidentiality and
authentication? 2 possibilities
On sending side (Alice) ? encryption before
digital signature (sign the ciphertext) ?
digital signature before encryption (sign the
plaintext)
On receiving side (Bob) ? with first option if
Bob wanted to retain evidence that Alice sent
the message, he would have to retain the
plaintext, the ciphertext and the
digital signature. ? with second option Bob
would have to retain only the plaintext
and the digital signature.

Second option
Figure 7.1(c)
8
Similarly, we sign the uncompressed file, not the
compressed file.
Compression
9
(No Transcript)
10
E-mail compatibility - Radix-64 conversion
11
Table 7.9 Radix-64 Encoding
12
Summary
13
Table 7.1 Summary of PGP Services
14
Cryptographic Keys and Key Rings PGP uses four
types of key
one-time "session" (conventional) key
public keys, private keys
passphrase-based symmetric keys
Preview of Requirements
1. Generate unpredictable session keys
(section session
key generation)
2. Accommodate multiple public/private key-pairs

(section key identifiers)
3. File of own public/private key pairs and
public keys of correspondents
(section key rings)
15
Session key generation
User types randomly into buffer (lab session 1)
16
Key identifiers Users must be able to have
multiple public/private key-pairs. Sender (Alice)
must be able to tell receiver (Bob) which
key-pair she is using. How to identify?
Use least-significant 64 bits of public key
(likely to be unique for user). PGP message
formats include the identifier of the key-pair
being used.
17
Sender Alice, receiver Bob
Format of transmitted message (assuming both
authentication and confidentiality)
18
Sequence of operations during sending.
Format of transmitted message (continued)
Sequence during receiving
19
Key rings We have seen how key IDs are critical
to the operation of PGP and that two key IDs are
included in any message that includes both
authentication and confidentiality.
Recall figure 3.9(a)
20
Private key ring (my key-pairs) information
Private key stored encrypted with passphrase
Private Key Ring also contains my public keys
ltbarnard_at_cis.uab.edugt ltbarnard_at_uab.edugt
21
Procedure for encrypting the private
keys 1. User selects the passphrase to be used
2. When system generates a new public/private
key-pair ? it asks user for the
passphrase ? using SHA-1, passphrase is
hashed ? passphrase itself is then
deleted (overwritten).

3. System encrypts private key using
CAST-128 with 128 bits of the
hash as key ? hash then deleted
(overwritten).
Whenever the user wishes to use the private key,
(s)he must provide the passphrase.
22
Public key ring
Defer discussion
Defer
The owners public key(s) appear on both key rings
23
How key rings are used by Alice in generating a
message to Bob
24
Bob receives the PGP message from Alice
25
Public-key management What if Darth creates his
own public/private key-pair, then convinces Alice
that his (Darths) public key is Bobs?
Darth can send messages to Alice, signed with his
private key, pretending they are from Bob. When
Alice checks signature, it will appear to be
OK. Similarly, if Alice sends an encrypted
message to Bob, Darth can intercept and read it
(Bob cannot read it).
The whole business of protecting public keys
from tampering is the single most difficult
problem in practical public-key applications. It
is the Achilles heel of public-key
cryptography, and a lot of software complexity is
tied up in solving this one problem.
PGP does not require a rigid public-key
management scheme. In contrast, we shall see that
S/MIME requires X.509 public-key certificates.
26
Approaches to Public-Key Management How can Alice
get Bobs key and be sure it really is his?
1. Alice can physically meet Bob and receive his
key on a USB drive.
2. If Alice can recognize Bobs voice over the
phone, she can ask him to dictate his public key
in radix-64 form (or he can e-mail the public
key, Alice can compute the hash and call Bob to
confirm the hash).
3. Alice can obtain a signed copy of Bobs public
key from a mutually- trusted friend
(the introducer).
4. Alice can obtain Bobs public key from a
certificate issued by a CA (in this
case the CA serves as the introducer).
For cases 3 and 4, Alice would already have a
copy of the introducers public key and trust
that this key is valid. Ultimately, it is up to
Alice to assign a degree of trust to anyone who
is to act as an introducer.
27
Use of Trust PGP provides a convenient means of
using trust. Recall the public key ring
Earlier, when Alice entered a new key in her
public-key ring, PGP asked her to assign a level
of trust to the owner of this key (if its her
own public key, value is ultimate trust). This
was entered in the Owner Trust field and will be
used if Alice later receives keys signed by this
person.
28
When Alice enters another new public key, one or
more signatures may be attached (in the
Signature(s) field). Alices PGP will search her
public-key ring to see if the author of this
signature is already on her key ring. If so PGP
will copy her earlier assessment of this persons
trust into the Signature Trust field for this
person (otherwise the value of this field will be
unknown user).
PGP will compute the weighted average of the
Signature Trust values and assign this to the Key
Legitimacy field. This field summarized the
confidence that Alice can have that this public
key actually belongs to the person in the UserID
field.
29
Possible values of the various trust fields.
Table 7.2 Contents of Trust Flag Byte
30
PGP Web of Trust The idea behind the various
trust fields in the public key ring is to
establish a Web of Trust among a community of
users.

If Alice trusts only Abe to sign certificates,
then she wont believe certificates from Martha
or Emily are genuine. If she also trusts Bobs
judgment about signing certificates, she can
trust Emilys certificate if she also trusts
Carl, she can trust everyones certificate.
31
This may be OK for informal use, but clearly
corporate use requires something more formal
this led to the development of S/MIME, which can
be viewed as a formalization of PGP, requiring
use of X.509 certificates.
32
7.2 S/MIME - preliminary material on RFC822/MIME
Recall from CS x34 Internet E-mail standards
were published in two parts in 1982 RFC 822
STANDARD FOR THE FORMAT OF ARPA INTERNET
TEXT MESSAGES by David H. Crocker RFC
821 SIMPLE MAIL TRANSFER PROTOCOL by
Jonathan B. Postel (Updated as RFC 2822 and
2821 (April, 2001))
Overview of E-mail The message is constructed
under RFC 822, then passed to SMTP (RFC 821) for
transmission.
S/MIME includes a secure development of RFC
822/MIME
33
Message Formats RFC 822 messages consist of
lines of ASCII text, ending with ltCRgt ltLFgt
maximum 1000 characters
There are three sections header fields a
blank line (a line with nothing except ltCRgtltLFgt
optionally, the message body.
34
Headers contain readable text (ASCII) are
divided into lines each line of form ltkeywordgt
ltvaluegt
Keywords To and From are required, others optional
35
RFC 822 states that the message can consist only
of ASCII text.
MIME Multipurpose Internet Mail Extensions (RFC
1521, 1993) In the body of the message we would
like to be able to include items such as
messages in languages with accents Messages in
non-Latin alphabets (Arabic, Russian, Hebrew)
Messages in languages without alphabets (Chinese
and Japanese) Messages not containing any kind
of text (audio and video) Such material may
contain an arbitrary bit string.
Sender must disguise non-ASCII information as
ASCII This will be reversed by the receiver, to
give the bit string.
36
From point of view of receiver
If you receive this ASCII message how do you know
what it is?
MIME header to the rescue!
Example Content-Transfer-Encoding says
radix-64 conversion
Now you know that the message is a bit string
that the sender has converted to radix-64 you
can recover the bit string, but you still dont
know what it is (image? Audio?)
MIME header Content-Type says
image/jpeg which tells you how to process the
received message.
37
(No Transcript)
38

S/MIME will add new subtypes to Application and
Multipart
39
(No Transcript)
40
End of preliminary material on MIME.
Recall that with PGP we had ability to ?
encrypt data for confidentiality ?
digitally-sign data for authentication ? do
both together
S/MIME has equivalent functionality.
41
S/MIME Functionality
? Enveloped data encrypted content and
encryption keys (can be interpreted only
by recipient with S/MIME capability,
because it uses a new S/MIME content/subtype
p252)
? Signed data message plus digital signature
(can be interpreted only by recipient with
S/MIME capability, because it uses a new
S/MIME content/subtype)
? Clear-signed data message ASCII only,
signature radix-64 (recipients without
S/MIME can view message, but
cannot verify the signature it uses a new
S/MIME content/subtype)
? Signed and enveloped data nested entities as
in PGP
42
S/MIME Functionality - continued ? Enveloped
data encrypted content plus encryption keys
PGP equivalent Figure 7.1(b) plus radix-64
conversion
Radix-64 conversion
43
S/MIME Functionality - continued ? Signed data
message plus digital signature (can
be viewed only by recipient with S/MIME
capability)
PGP equivalent figure 7.1(a), plus radix-64
conversion

Radix-64 conversion after compression
? Clear-signed data function only the digital
signature is converted to radix-64 the message
is in the clear
44
S/MIME Functionality - continued
? Signed and enveloped data
PGP equivalent figure 7.1(c)
45
Table 7.6 Cryptographic Algorithms Used in S/MIME
(El Gamal)
Sending
46
S/MIME Messages S/MIME makes use of a number of
new MIME subtypes. Most of the new subtypes use
the designation PKCS public key cryptographic
specifications issued by RSA Labs and
contributed to the S/MIME effort.
Table 7.7 S/MIME Content Types
MIME
S/MIME




To participate fully in S/MIME, sender and
receiver must understand the new S/MIME subtypes
47
EnvelopedData - preliminary Recall PGP figure
7.1(b) sending side
48
envelopedData

In preparing this, the sender
1. Generates a pseudorandom session key Ks for
the chosen symmetric encryption
algorithm.
2. For each recipient, encrypts the session key
with the recipients public RSA key PUb
3. For each recipient prepares the RecipientInfo
block that contains ? an identifier of the
recipients public-key certificate ? an
identifier of the algorithm used to encrypt the
session key ? the encrypted session key
4. Encrypts the message content with the session
key.
49
RecipientInfo/ Identifier of recipients
public-key certificate
Identifier
This will be taken from an X.509 certificate.
50
(No Transcript)
51
(No Transcript)
52
Again recall PGP figure 7.1(b) - receiving side


To recover the encrypted message, the PGP
recipient
1. Strips off the radix-64 conversion (not shown
above)
2. Uses his/her private key to decrypt the
session key
3. Decrypts the message, using the session key.
S/MIME receiver does same things (top page 253)
53
signedData preliminary Recall PGP figure
7.1(a) sending side
54
signedData
Similarly, the steps for preparing a signedData
MIME entity are
1. Select a message digest algorithm (SHA or MD5)
2. Compute the message digest of the content to
be signed
3. Encrypt the message digest with the signers
private key PRa
4. Prepare the SignerInfo block, containing ?
the signers public-key certificate (?
Identifier?) ? an identifier of the message
digest algorithm ? an identifier of the
algorithm used to encrypt the message
digest ? the encrypted message digest.
55
signedData - continued
56
signedData - continued
For receiver, first task is to reverse the base64
encoding
57
SignedData continued Recall PGP figure 7.1(a)
receiving side
To recover the signed message, and verify the
signature, the PGP recipient
1. Strips off the base64 conversion (not shown
above)
2. Uses the signers public key to decrypt the
message digest
3. Recomputes the message digest to verify the
signature.
Again, the S/MIME recipient does the same things
(page 253).
58
S/MIME Functionality Clear-signed Data
The message is sent as a MIME multipart message,
with the text in the clear in the first part
and the signature in the second part this is a
detached signature.
Recipients without S/MIME capability can view
message, but cannot verify
the signature.
59

The second part is a detached signature
60
S/MIME Certificate Processing S/MIME uses X.509
version 3
Hybrid between a strict X.509 hierarchy and
PGPs web of trust. S/MIME does not set up a
global system like the Domain Name System, to
retrieve public-key certificates with minimal
effort. Rather, each user, or user group, takes
responsibility for obtaining the certificates of
individuals with whom they want to correspond
securely.
User Agent Role ? key-pair generation ?
registration of public key with a CA,
which will issue
X.509 certificate (figure 4.4) ? certificate
storage and retrieval
(equivalent of PGP public
key ring)
61
VeriSign Public-Key Certificate Classes
Table 7.8 Verisign Public-Key Certificate Classes
62
Omit Section 7.3 Domainkeys Identified Mail
End of Chapter 7
Write a Comment
User Comments (0)
About PowerShow.com