1. Data & Network Security
4/16/2017
Data & Network Security
Mehrdad Nourani

2. Electronic Mail Security
4/16/2017
Session 16
Electronic Mail Security

3. Pretty Good Privacy (PGP)
4/16/2017
Pretty Good Privacy (PGP)

4. email is one of the most widely used and regarded network services
4/16/2017
Security
is one of the most widely used and regarded network services
currently message contents are not secure
s are like postcards, anyone can look at it
may be inspected either in transit
or by suitably privileged users on destination system
Current services are roughly like "postcards". Anyone who wants could pick it up and have a look as its in transit or sitting in the recipients mailbox.

5. Email Security Enhancements
4/16/2017
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
What we want is something more akin to standard mail (contents protected inside an envelope) if not registered mail (have confidence about the sender of the mail and its contents).

6. Pretty Good Privacy (PGP)
4/16/2017
Pretty Good Privacy (PGP)
widely used de facto secure
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
De facto=practically

7. Summary of PGP Services

8. PGP Operation – Authentication
sender creates a message
SHA-1 is used to generate 160-bit hash code of message
hash code is encrypted with RSA using the sender's private key, and the result is attached to message
receiver uses RSA or DSS with sender's public key to decrypt and recover hash code
receiver generates new hash code for message and compares with decrypted hash code, if match, message is accepted as authentic
Compression
using ZIP
Public-Key
Encryption
Public-Key
Decryption

9. PGP Operation – Confidentiality
sender generates message and random 128-bit number to be used as session key for this message only
message is zipped and encrypted, using CAST-128 / IDEA/3DES with session key
session key is encrypted using RSA with recipient's public key, then attached to message
receiver uses RSA with its private key to decrypt and recover session key
session key is used to decrypt message
EKUb[Ks]
Symmetric
Encryption Ks
Symmetric
Decryption

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

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

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

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

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

15. LZ77 Implementation
Most implementations of LZ77 use sliding and look-ahead 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.

16. PGP Operation – Email Compatibility
when using PGP will have binary data to send (encrypted message etc.)
however 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 facilities impose a maximum of bytes on s and larger than that must be broken)

17. 4/16/2017
Radix-64 Encoding
Stallings Fig 15-2.

18. PGP Operation – Summary
4/16/2017
PGP Operation – Summary
Stallings Fig 15-2.

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

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

21. each PGP user has a pair of key rings:
4/16/2017
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
This perhaps is the most innovative point in PGP. Instead of a KDC center each user can generate as many keys (public and private) and keep them for future reference.

22. Format of PGP Message (from A to B)

23. rather than relying on certificate authorities
4/16/2017
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
This perhaps is the most innovative point in PGP. Instead of a KDC center each user can generate as many keys (public and private) and keep them for future reference.

24. Structure of Public/Private Key Rings
Public/private key pair
Typically user’s
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

25. 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:
User selects a passphrase
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.
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 key using CAST-128 with the hash code.

26. PGP Message Generation (from A to B)
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
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 constructed.

27. PGP Message Generation (from A to B)Z

28. PGP Reception (from A to B)
Encrypt the message:
PGP retrieves the receiver’s private key from the private-key ring using the key ID in the session key component as an index.
PGP prompts the user for the pass-phrase to recover the unencrypted private key.
PGP recovers the session key and decrypt the message
Authenticate the message:
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
PGP recovers the transmission message digest (i.e. 160-bit SHA-1 digest)
PGP computes the message digest for the received message and compares it to the transmitted message digest for authentication

29. PGP Reception (from A to B)
Z-1

30. 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 public-key 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.

31. Secure/Multipurpose Internet Mail Extensions (S/MIME)
4/16/2017
Secure/Multipurpose Internet Mail Extensions (S/MIME)

32. security enhancement to MIME email standard
S/MIME
S/MIME (Secure/Multipurpose Internet Mail Extensions)
security enhancement to MIME standard
original Internet RFC822 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 use

33. SMTP vs. MIME
SMTP (Simple Mail Transfer Protocol) is the main format for messages
RFC 822 defines a format for text messages based on SMTP
Header (From, To, Subject, Date, cc, …)
Body (the content of )
MIME is an extension of RFC822 to address some of limitations in SMTP that includes:
Cannot transfer binary files by
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 s
Translation problem between ASCII and EBCDIC
Problems with carriage return, linefeed, truncating/wrapping lines, dealing with tabs and space characters, etc.

34. Overview of MIME
Five new message headers are added to add new features for content formats, transfer encodings, etc.:
MIME Version
MIMIE-Version-1.0 in the header means it conforms RFCs 2045 and 2046)
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)
Content-Transfer Encoding
type of transformation used to represent the body
Content ID
identifies MIME entities in a unique way
Content Description
text description of the object in the body (when it is unreadable like audio data, etc.)

35. MIME Content Types (RFC 2046)
15 subtypes
(see text book for examples)

36. MIME Transfer Encoding
Nature of Data (No Encoding)
Two conventional Encodings (See book for details)
Vendor-specific or application-specific encoding method

37. MIME Message Structure (RFC 2045)

38. MIME Message Structure (cont.)
Non-ASCII

39. S/MIME Functions enveloped data signed data clear-signed 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)

40. 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)
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)

41. S/MIME Cryptographic Algorithms (cont.)

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

43. Preparing EnvelopedData Entity
4/16/2017
Preparing EnvelopedData Entity
Generate a pseudorandom session key for a particular symmetric encryption algorithm
RC2/40 or 3DES
For each recipient, encrypt the session key with the recipient’s public RSA key
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.
Encrypt the message content with the session key
See pp. 467 book for an example.

44. Preparing SignedData Entity
4/16/2017
Preparing SignedData Entity
Select the message digest algorithm
SHA or MD5
Compute the message digest, or hash function, of the content to be signed
Encrypt the message digest with the signer’s private key
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.
See pp. 467 book for an example.

45. 4/16/2017
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.
See pp. 468 book for an example.

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

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

48. Certificate Authorities (cont.)
Optional parts of Digital IDs contain other user-supplied information including
Address
address
Basic registration information (country, zip code, age, gender, etc.)
with increasing levels of checks & hence trust
Class Identity Checks Usage
1 name/ check web browsing/
2+ enroll/addr check , subs, s/w validate
3+ ID documents e-banking/service access

49. VeriSign Public-Key Certificate Classes
Confirmation by postal address

50. Summary
have considered:
secure
PGP
S/MIME