PGP and S/MIME are two standards for securing email communications. PGP uses asymmetric encryption with RSA and symmetric encryption with algorithms like IDEA. It provides authentication, confidentiality, compression and is free but not controlled by standards bodies. S/MIME is the IETF standard that uses X.509 certificates and PKCS #7 to provide the same security features as PGP through signing, encrypting and signing/encrypting emails. It supports algorithms like SHA-1, RSA, Triple DES and is used more for professional email security. Both standards segment long messages and include mechanisms for trust and revoking public keys.

1. Electronic mail security

2. Outline
• Pretty Good Privacy (PGP)
• S/MIME
• Recommended web sites
2
2

3. Security facilities in the TCP/IP protocol stack
3
3

4. Pretty Good Privacy
• Philip R. Zimmerman is the creator of PGP (1992).
• PGP provides
 confidentiality
 and authentication
service that can be used for electronic mail and file storage
applications.
4
4

5. Why Is PGP Popular?
• It is available free on a variety of platforms.
• Wide range of applicability
• Based on well known algorithms. (Why ?, Is it Secure ?)
• Not developed or controlled by governmental or standards
organizations (Is-it trust worthy)
5
5

6. Operational Description
•Notations Z = Compression using ZIP
Ks = Session key used in Algorithm
symmetric encryption scheme R64 = Conversion to Radix 64
PRa = Private key of user A, ASCII format
used in public-key encryption EP = Public key encryption
scheme DP = Public key decryption
PUa = Public key of user A, EC = Symmetric Encryption
used in public-key encryption DC = Symmetric Decryption
scheme H = Hash Function (SHA-1
Used, 160 bit hash)
• Consist of five services:
| | : Concatenation
 Authentication
 Confidentiality
 Compression
 E-mail compatibility
 Segmentation
6
6

7. Authentication
• The sender creates a message
• SHA-1 is used to generate a 160-bit hash code of the message
• The hash code is encrypted with RSA using the sender’s private
key, and the result is prepended to the message
• The reciever uses RSA with sender’s public key to decrypt and
recover the hash code
• The reciever generates a new hash code for the mesage and
compares it with the decryupted hash code.
7

8. Confidentiality
• The sender generates a message and a random 128-bit number
to be used as a session key for this message only
• The message is encrypted using CAST -128 / IDEA / #DES with
the session key.
• The session key is encrypted with RSA using recipients public key
and is prepended to the message
• The reciever uses RSA with its private key to decrypt and recover
the session key.
• The session key is used to decrypt the message
8

9. PGP Cryptographic Function
E[PUb, Ks]
9
9

10. PGP Cryptographic Function
10
10

11. Compression
• PGP compresses the message after applying the signature but
before encryption
• The placement of the compression algorithm is critical.
• The compression algorithm used is ZIP (described in appendix G or
search internet)
• Message encryption is applied after compression to strengthen
cryptographic security.
11
11

12. E-mail Compatibility
• The scheme used is radix-64 conversion (see appendix or online).
• The use of radix-64 expands the message by 33%.
12
12

13. Segmentation and Reassembly
• Often restricted to a maximum message length of 50,000 octets.
• Longer messages must be broken up into segments.
• PGP automatically subdivides a message that is to large.
• The receiver strip of all e-mail headers and reassemble the block.
13
13

14. Transmission and Reception of PGP Messages assembly
14
14

15. Format of PGP Message
15
15

16. General Structure of Private and Public Key Rings
• Keys need to be stored and organized in a systematic way for
efficient and effective use by all parties
• Scheme used in PGP providesa pair of data structure at each node
 To store public / private key pairs owned by that node (Private Key
Ring)
 To store public keys of other users known at this node (Public Key Ring)
16

17. General Structure of Private and Public Key
Rings
Least significant 64 bits
17

18. PGP Message Generation
18

19. PGP Message Reception
19

20. The Use of Trust
• No specification for establishing certifying authorities or for
establishing trust
• Provides means of
 Using trust
 Associating trust with public keys
 Exploiting trust information.
• Basic Structure
 Key legitimacy field : indicates the extent to which PGP will trust
See Table 7.2
public key for user
(W. Stallings)
 Signature trust field : Indicates the degree to PGP user trusts the
signer to certify public keys
 Owner trust field : Indicates degree to which public key is trusted to
sign other public-key certificates; assigned by user
20
20

21. PGP Trust Model (Example)
21
(Reading Assignment)

22. Revoking Public Keys
• The owner issue a key revocation certificate.
• Normal signature certificate with a revoke indicator.
• Corresponding private key is used to sign the certificate.
22
22

23. S/MIME
• Secure/Multipurpose Internet Mail Extension (RFC5751)
• S/MIME on the IETF standard track
 Will be the commercial standard for secure e-mails
• Uses X.509 certificates (Public-Key Cryptography Standards (PKCS) #7) to
sign/encrypt messages
 PKCS # 7: An updated Cryptographic Message Syntax (CMS)
– CMS is the IETF's standard for cryptographically protected messages which is
used to digitally sign, digest, authenticate or encrypt digital data.
• Provides same features as PGP
 authentication, message integrity and non-repudiation of origin
– provided by use of digital signatures
 privacy, data security
– provided by use of encryption
• PGP for personal e-mail security, S/MIME for professional e-mail security 23
23

24. S/MIME Fucntion
• Enveloped Data
 Consists of encrypted content of any type and encrypteed-content
encryption key
• Signed Data
 Digital signature is formed by taking the message digest and then
encrypted with public key
 Contents + Signature are encoded using base64 encoding
 Can only viewed by recipeint with S/MIME capabilities.
• Clear-Signed Data
 Digital signature are formed and encoded using base64
 All can see message but can not verify signature.
• Singed and Enveloped Data
 Encrypted data may be signed
 Signed data or clear-signed data may be encrypted
24

25. Plain Mail (just MIME)
Content-Type: multipart/mixed; boundary=bar
--bar
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
=A1Hola Michael!
How do you like the new S/MIME specification?
It's generally a good idea to encode lines that begin with
From=20because some mail transport agents will insert a greater-
than (>) sign, thus invalidating the signature.
Also, in some cases it might be desirable to encode any =20
trailing whitespace that occurs on lines in order to ensure =20
that the message signature is not invalidated when passing =20
a gateway that modifies such whitespace (like BITNET). =20
--bar
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
--bar-- 25
25

26. S/MIME filenames
Media Type File
Extension
application/pkcs7-mime (SignedData, .p7m
EnvelopedData)
application/pkcs7-mime (degenerate SignedData .p7c
certificate management message)
application/pkcs7-mime (CompressedData) .p7z
application/pkcs7-signature (SignedData) .p7s
26
26

27. S/MIME singed message
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
--boundary42
Content-Type: text/plain
This is a clear-signed message.
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42--
27
27

28. Algorithms Used in S/MIME
• Message Digesting
 MUST : Absolute Requirement
– SHA-1
 SHOULD : May be required in particular cases
– MD5 (Receiver)
• Digital Signatures
 MUST : DSS (Sender / Receiver)
 SHOULD : RSA (Key size of 512 – 1024 bits) (Sender / Receiver)
• Encryption with one time session key
 MUST
– Triple-DES (Sender / Receiver)
 SHOULD
– AES, RC2/40 (Sender)
28
28

29. Algorithms Used in S/MIME
• Asymmetric encryption of the session key
 MUST
– RSA with key sizes of 512 to 1024 bits (Sender / Receiver)
 SHOULD
– Diffie-Hellman (for session keys). (Sender / Receiver)
• Creation of MAC
 MUST : HMAC with SHA-1 (Receiver)
 SHOULD : HMAC with SHA-1 (Sender)
29

30. Recommended Web Sites
• PGP home page: www.pgp.com
• MIT distribution site for PGP
• GOOGLE -> PGP
• S/MIME Central: RSA Inc.’s Web Site
30
30