Data & Network Security
Mehrdad Nourani
1
Session 16
Electronic Mail Security
2
Pretty Good Privacy (PGP)
3
Email Security
• email is one of the most widely used and
regarded network services
• currently message contents are not secure
—emails are like postcards, anyone can look at it
—may be inspected either in transit
—or by suitably privileged users on destination system
4
Email Security Enhancements
• confidentiality
—protection from disclosure
• authentication
—of sender of message
• message integrity
—protection from modification
• non-repudiation of origin
—protection from denial by sender
5
Pretty Good Privacy (PGP)
•
•
•
•
•
widely used de facto secure email
developed by Phil Zimmermann
selected best available crypto algorithms to use
integrated into a single program
available on Unix, PC, Macintosh and Amiga
systems
• originally free, now have commercial versions
available also
6
Summary of PGP Services
7
PGP Operation – Authentication
1. sender creates a message
2. SHA-1 is used to generate 160-bit hash code of message
3. hash code is encrypted with RSA using the sender's private
key, and the result is attached to message
4. receiver uses RSA or DSS with sender's public key to
decrypt and recover hash code
5. receiver generates new hash code for message and
compares with decrypted hash code, if match, message is
accepted as authentic
Public-Key
Encryption
Compression
using ZIP
Public-Key
Decryption
8
PGP Operation – Confidentiality
1. sender generates message and random 128-bit number
to be used as session key for this message only
2. message is zipped and encrypted, using CAST-128 /
IDEA/3DES with session key
3. session key is encrypted using RSA with recipient's
public key, then attached to message
4. receiver uses RSA with its private key to decrypt and
recover session key
5. session key is used to decrypt message
EKUb[Ks]
Symmetric
Encryption
Ks
Symmetric
Decryption
9
PGP Operation–Confidentiality & Authentication
• uses both services on same message
—create signature & attach to message
—encrypt both message & signature
—attach RSA encrypted session key
Ks
10
PGP Operation – Compression
• uses ZIP compression algorithm
• by default PGP compresses message after
signing but before encrypting
—Encryption after compression strengthen
cryptographic security. Because the compressed
message has less redundancy than the original
plaintext, cryptanalysis is more difficult.
11
PGP Operation – Compression (cont.)
—so can store uncompressed message & signature
for later verification.
– If one signs a compressed document, then it
would be necessary either to store the
compressed version of message or to recompress
it for verification.
—because compression is non deterministic.
Various implementation of compression algorithm
may produce different compressed forms.
– This causes difficulty if we try to “recompress”.
However, all these compression algorithms are
interoperable because any version of algorithm
can correctly decompress the output of any other
version.
12
Data Compression Using ZIP
• ZIP and its variations (including PKZIP, gzip, zipit, etc.) is
based on LZ77 developed in 1977 by Abraham Lempel and
Jacob Ziv.
• LZ77 exploits the fact that words and phrases within a text
stream (or image patterns like in GIF) are likely to be
repeated. And when repeated they can be replaced by a
shorter code.
• Process:
— Each character is mapped into a 9-bit pattern (“1”+8-bit
ASCII)
— It looks for repetition. When happens, it continues to scan to
find the maximum size of repetition.
— The repetition sequence is replaced by (option, pointer,
length).
– Option: 00=8-bit pointer/4-bit length ; 01=12-bit pointer/6-bit length
– Pointer: pointing to the prior sequence that match is found
– Length: the length of sequence that matches
13
LZ77 Example
• Example: Original text needs 53 bytes (424 bits)
and the compressed one needs 35 9-bit
characters and two 14-bit codes, i.e.
(35x9)+(2x14)=343 bits.
• This means compression ratio of 424/343=1.24.
14
LZ77 Implementation
• Most implementations of LZ77 use sliding and lookahead buffers. They try to scan and match sequences.
• Drawback: For small windows, many possible match will
not be noticed (characters are thrown out during scan).
If large window is used, the algorithm needs large scan
time and large pointers.
15
PGP Operation – Email Compatibility
• when using PGP will have binary data to send
(encrypted message etc.)
• however email was designed only for text
• hence PGP must encode raw binary data into
printable ASCII characters
• uses radix-64 algorithm
—maps 3 octets (bytes) to 4 printable characters
—also appends a CRC
—it may expand the message by 33% (ZIP reduces it by
50%, therefore overall compression will be about one
third: 1.33 x 0.5=0.665)
• PGP also segments messages if too big (many
email facilities impose a maximum of 50000 bytes
on emails and larger than that must be broken)
16
Radix-64 Encoding
17
PGP Operation – Summary
18
PGP Session Keys
• need a session key for each message
— of varying sizes: 56-bit DES, 128-bit CAST or IDEA, 168-bit
Triple-DES
• generated using ANSI X12.17 mode
• uses random inputs taken from previous uses and from
keystroke information (timing and actual keys) by user
• 16 octets K[0…15] contain the session key. K[16…23]
contain an IV. (See details in Appendix 15C)
8 bytes
8 bytes
24 bytes
19
PGP Public & Private Keys
• since many public/private keys may be in use,
need to identify which is actually used to
encrypt session key in a message
—could send full public-key with every message
—but this is inefficient
• rather use a key identifier based on key
—is least significant 64-bits of the key
—will very likely be unique
• also use key ID in signatures
20
PGP Key Rings
• In PGP, each user is allowed to have multiple
public/private keys (for different correspondence
groups or to enhance security). To clarify which
one is actually used:
—Send public key with the message (works but wasteful)
—Define a key ID for each public key and send only that.
— In PGP, the key ID of a public key is its least
significant 64 bits, i.e. key ID of KUa=KUa mod 264.
• each PGP user has a pair of key rings:
—public-key ring contains all the public-keys of other
PGP users known to this user, indexed by key ID
—private-key ring contains the public/private key
pair(s) for this user, indexed by key ID & encrypted
keyed from a hashed pass-phrase
21
Format of PGP Message (from A to B)
22
PGP Key Management
• rather than relying on certificate authorities
• in PGP every user is own CA
—can sign keys for users they know directly
• forms a “web of trust”
—trust keys have signed
—can trust keys others have signed if have a chain of
signatures to them
• key ring includes trust indicators
• users can also revoke their keys
23
Structure of Public/Private Key Rings
Public/private
key pair
•
•
Typically
user’s email
public-key ring contains all the public-keys of other PGP users known to
this user, indexed by key ID
private-key ring contains the public/private key pair(s) for this user,
indexed by key ID & encrypted keyed from a hashed pass-phrase
24
Why Encrypting Private Key?
•
•
To make the value of private key as secure as possible,
this key is encrypted using CAST-128 (or IDEA or 3DES).
The procedure:
1. User selects a passphrase
2. When the system generate a new public/private key pair
using RSA, it asks user for the passphrase. Using SHA-1, a
160-bit hash code is generated from the passphrase and
the passphrase is discarded.
3. The system encrypts the private key using CAST-128 with
the 128 bits of the hash code as the key. The hash code is
then discarded, and the encrypted private key is stored in
the private-key ring.
•
When the user accesses the private-key ring to retrieve a
private key he must supply the passphrase. PGP will
retrieve the encrypted private key, generate the hash
code of the passphrase and decrypt the encrypted private
25
key using CAST-128 with the hash code.
PGP Message Generation (from A to B)
1. Sign the message
(a) PGP retrieves the sender’s private key from the
private-key ring using your_userid as an index. If
your_userid was not provided, the first private key is
used.
(b) PGP prompts the user for the pass-phrase to recover
the unencrypted private key.
(c) the signature component of the message is
constructed
2. Encrypt the message:
(a) PGP generates a session key and encrypt the message
(b) PGP retrieves the recipient’s public key form the
public-key ring using her_userid as an index
(c) the session key component of the message is
26
constructed.
PGP Message Generation (from A to B)
Z
27
PGP Reception (from A to B)
1. Encrypt the message:
(a) PGP retrieves the receiver’s private key from the private-key
ring using the key ID in the session key component as an
index.
(b) PGP prompts the user for the pass-phrase to recover the
unencrypted private key.
(c) PGP recovers the session key and decrypt the message
2. Authenticate the message:
(a) PGP retrieves the sender’s public key form the public-key
ring using the key ID field in the signature key component
of he message as an index
(b) PGP recovers the transmission message digest (i.e. 160-bit
SHA-1 digest)
(c) PGP computes the message digest for the received
message and compares it to the transmitted message
digest for authentication
28
PGP Reception (from A to B)
Z-1
29
Additional Features
• Public key management is still an issue. User A must
build up a public-key ring.
— If A gets B’s public key from a bulletin board that is already
compromised by C, then A does not have the right public key.
— See book for guidelines as to how manage the public-key ring.
• PGP asks user for his assessment of the “trust” to be
assigned to the owner of a key. Trust fields/flags can be
ultimate trust or unknown user, etc.
• If a user’s private key is compromised, he should
disseminate a special certificate to all possible users as
soon as possible that they change his key in their publickey ring.
— To revoke a public key, user uses his private key to issue a
normal signature certificate that includes a special indicator. This
indicator says that the purpose of this certificate is to revoke the
use of public key.
30
Secure/Multipurpose Internet Mail
Extensions (S/MIME)
31
S/MIME
• S/MIME (Secure/Multipurpose Internet Mail
Extensions)
• security enhancement to MIME email standard
—original Internet RFC822 email was text only
—MIME provided support for varying content types and
multi-part messages
—with encoding of binary data to textual form
—S/MIME added security enhancements
• have S/MIME support in various modern mail
agents: MS Outlook, Netscape, etc.
• It appears that S/MIME will become industry
standard and PGP will be for personal email use
32
SMTP vs. MIME
• SMTP (Simple Mail Transfer Protocol) is the main format
for email messages
• RFC 822 defines a format for email text messages based
on SMTP
— Header (From, To, Subject, Date, cc, …)
— Body (the content of email)
• MIME is an extension of RFC822 to address some of
limitations in SMTP that includes:
— Cannot transfer binary files by email
— Can work only with 7-bit ASCII (code values 0 through 127) not
8-bit codes (values 128 to 255 for national languages)
— May reject large emails
— Translation problem between ASCII and EBCDIC
— Problems with carriage return, linefeed, truncating/wrapping lines,
dealing with tabs and space characters, etc.
33
Overview of MIME
•
Five new message headers are added to add new
features for content formats, transfer encodings, etc.:
1. MIME Version
—
MIMIE-Version-1.0 in the header means it conforms RFCs
2045 and 2046)
2. Content Type
— information about the data in the body such that the receiving
user system can pick the appropriate mechanism to represent data
(or deal with it)
3. Content-Transfer Encoding
— type of transformation used to represent the body
4. Content ID
— identifies MIME entities in a unique way
5. Content Description
— text description of the object in the body (when it is unreadable
like audio data, etc.)
34
MIME Content Types (RFC 2046)
15 subtypes
(see text book for examples)
35
MIME Transfer Encoding
Nature of Data (No Encoding)
Two conventional Encodings (See
book for details)
Vendor-specific or applicationspecific encoding method
36
MIME Message Structure (RFC 2045)
37
MIME Message Structure (cont.)
Non-ASCII
38
S/MIME Functions
• enveloped data
— encrypted content and associated keys
• signed data
— encoded message + signed digest (uses digital signature
concept and base64 encoding. The message can be
viewed only by a recipient with S/MIME capability)
• clear-signed data
— cleartext message + encoded signed digest (recipient
without S/MIME can view the message but cannot verify
the signature)
• signed & enveloped data
— nesting of signed & encrypted entities (encrypted data
may be signed and signed data may be encrypted)
39
S/MIME Cryptographic Algorithms
• hash functions:
— 160-bit SHA-1
— 128-bit (recommended) MD5
• digital signatures:
— DSS
— RSA
• session key encryption:
— ElGamal (a variant of Diffie-Hellman)
— RSA
• message encryption:
— 3DES
— 40-bit RC2 (not very secure but compliant with US control)
— Others (have a procedure to decide which algorithms to use –
see pp. 465 of book for details of procedure)
40
S/MIME Cryptographic Algorithms (cont.)
41
S/MIME Messages
• There are a number of new MIME content types denoted by PKCS.
— PKCS refers to a set of public-key cryptography specifications issued
by RSA lab and made available for S/MIME.
— PKCS object: MIME entity + security-related data like algorithm,
certificate, signature, etc. + MIME header in clear
42
Preparing EnvelopedData Entity
1. Generate a pseudorandom session key for a
particular symmetric encryption algorithm
•
RC2/40 or 3DES
2. For each recipient, encrypt the session key with
the recipient’s public RSA key
3. For each recipient, prepare a block known as
RecipientInfo that contains:
•
•
•
an identifier of the recipient’s public key (e.g. X.509
certificate)
an identifier of the algorithm to encrypt the session key
the encrypted session key.
4. Encrypt the message content with the session key
43
Preparing SignedData Entity
1. Select the message digest algorithm
•
SHA or MD5
2. Compute the message digest, or hash function,
of the content to be signed
3. Encrypt the message digest with the signer’s
private key
4. Prepare the SignerInfo block that contains:
•
•
•
•
the signer’s public key certificate
an identifier of the message digest algorithm
an identifier of the algorithm used to encrypt the
message digest
the encrypted message digest.
44
Clear Signing
•
•
The message will be in clear. Thus, recipients with
MIME capabilities (and not S/MIME capabilities) are
able to read the incoming message.
A multipart/signed message has two parts:
— 1. Any MIME type that is prepared so that it will not be altered
during transfer from source to destination
–
–
E.g. if the first part is not 7-bit, then base64 or quoted printable
should be used .
This part is then processed same as SignedData with an empty
message content field. This is called a detached signature.
— 2. The detached signature is transfer encoded using base64 to
become the second part. The second part has a MIME content
type of application and a subset of pkcs7-signature.
•
The receiver can verify the signature by taking the
message digest of the first part and compare it to the
message digest recovered from the signature in the
second part.
45
S/MIME Certificate Processing
• S/MIME uses public-key certificate that
conforms X.509 v3 certificates
• managed using a hybrid of:
— a strict X.509 CA hierarchy &
— PGP’s web of trust
• Like in PGP, each client has
—a list of trusted CA’s certificates &
—public/private key pairs & certificates
• certificates must be signed by trusted CA’s
46
Certificate Authorities
• There are several well-known CA’s (e.g. Nortel, VeriSign,
GTE, US postal service, etc.)
• VeriSign one of most widely used
• VeriSign issues several types of certificate (called VeriSign
Digital IDs
• At a minimum (mandatory part) each Digital ID contains:
— Owner’s public key
— Owner’s name or alias
— Expiration data of Digital ID
— Serial number of Digital ID
— Name of the certificate authority that issued the Digital ID
— Digital signature of the certification authority that issued the
Digital ID
47
Certificate Authorities (cont.)
• Optional parts of Digital IDs contain other user-supplied
information including
— Address
— Email address
— Basic registration information (country, zip code, age, gender,
etc.)
• with increasing levels of checks & hence trust
Class
1
2+
3+
Identity Checks
name/email check
enroll/addr check
ID documents
Usage
web browsing/email
email, subs, s/w validate
e-banking/service access
48
VeriSign Public-Key Certificate Classes
Confirmation by postal address
49
Summary
• have considered:
—secure email
—PGP
—S/MIME
50
Descargar

Network Security - University of Tehran