Email Security

Pretty Good Privacy (PGP)S/MIME

Introduction

• Email is one of the most heavily used network-based application.

• There are two widely used schemes for providing authentication and confidentiality for email security, PGP and S/MIME.

SMTP

• Internet email is originally based on SMPT-protocol (Simple Mail Transfer Protocol)

• SMPT transfers a message consisting of header lines and a body (all ASCII) using a packet relay network.

• SMPT does not have any security services. The messages can easily be read or modified. Also the senders address of routing information is easy to change.

MIME

• ”Multipurpose Internet Mail Extensions” is an extension to solve many limitations of using text-based messages and SMPT.

• MIME does not have security sercvices either.

PGP

• PGP provides a confidentiality and authentication service that can be used for file storage and electronic mail applications.

• PGP was developed be Phil Zimmermann in 1991 and since then it has grown in popularity. There have been several updates to PGP.

• A free versions of PGP is available over the Internet, but only for non-commercial use. The latest (Jan. 2000) current version is 6.5.

• Commercial versions of PGP are available from the PGP Division of Network Associates

• For three years, Philip Zimmermann, was threatened with federal prosecution in the United States for his actions. Charges were finally dropped in January 1996.

• At the close of 1999, Network Associates, Inc. announced that it has been granted a full license by the U.S. Government to export PGP world-wide, ending a decades-old ban.

• PGP enables you to make your own public and secret key pairs. • PGP public keys are distributed and certified via an informal network called

"the web of trust".

PGP

• Most experts consider PGP very secure if used correctly. PGP is based on RSA, DSS, Diffie-Hellman in the public encryption side, and CAST.128, IDEA, 3DES for conventional encryption. Hash coding is done with SHA-1.

• PGP has a wide range of applicability from corprorations that wish to enforce a standardized scheme for encryptin files and messages to individuals who wish to communicate securely with each others over the interent.

PGP – Operational description

• The actual operation of PGP consists of five services: authentication, confidentiality, compression, e-mail compatibility and segmentation (Table 12.1.)

Authenticaiton• The digital signature service is illustrated in Fig 12.1a.

– EC is used for conventional encryption, DC for decryption, and EP and ED correspondingly for public key encryption and decryption.

• The algorithms used are SHA-1 and RSA. Alternatively digital signatures can be generated using DSS/SHA-1.

• Normally digital signatures are attached to the files they sign, but there are exceptions– a detached signature can be used to detect a virus infection of an

executable program.– sometimes more than one party must sign the document.– a separate signature log of all messages is maintained

PGP – Operational description

Confidentiality• Confidentiality service is illustrated in Fig 12.1b. • Confidentiality can be use for storing files locally or transmitting them over

insecure channel.• The algorithms used are CAST-128 or alternatively IDEA or 3DES. The

ciphers run in CFB mode.• Each conventional key is used only once.

– A new key is generated as a random 128-bit number for each message.– The key is encrypted with the receivers public key (RSA) and attached to the

message. – An alternative to using RSA for key encryption, ELGamal, a variant of Diffie-

Hellman providing also encryption/decryption, can be used.

• The use of conventional encryption is fast compared to encryption the whole message with RSA.

• The use of public key algorithm solves the use session key distribution problem. In email application any kind of handshaking would not be practical.

PGP – Operational description

Confidentiality and authentication• Confidentiality with authentication is illustrated in Fig 12.1c. • Firs a signature is generated for the message and prepended to the message.

Then conventional enctryption is applied to message and signature. Finally the session key is encrypted using RSA.

• The order of operations is important: the signature must be computed fromm the plaintext message. Otherwise a trird party would need the session key to verify the signature.

Compression• As a default PGP compresses the message after the signature but before

encryption (Fig 12.1. compression and decompression are noted as Z and Z-1)• The signature is generated before compression for two reasons

– it now suffices to store only the plaintext version plus signature for later verification.– PGP’s compression algorithm is not deterministic; various implementations of the

algorithm achieve different tradeoff in running speed and compression rate. Thus recompression for the verification would not work if the signature was generated from the compressed message.

PGP – Operational description

Compression• Message encryption is applied after compression to strenghten cryptographic

security. – compressed message has less redundancy making cryptanalysis more difficult.

E-mail compatibility• Encrypted parts of the message form a stream of 8-bit octets. PGP uses aradix-

64 conversion to convert this stream into printable ASCII characters. • The length of the converted part of the message increases by 33%.• Fig. 12.2. illustrates the the transmission and reception of PGP messages. As

an option, radix-64 conversion can be applien only to the signature if the message is in plaintext. This enables a non-PGP recipient to read the message.

Segmentation and reassembly• PGP automatically subdivides messages into segments that are small enough

to be sent via email. In the receiving end, the reassembly is also automatic.

PGP – Cryptographic keys and key rings

• PGP makes use of four types of keys: one-time session conventional keys, public keys, private keys and passphrase-based conventional keys.

• One-time session keys are generated with a ”random number generator” using time intervals of the users keystrokes as the seed. CAST-128 is used as a generator to produce 128-bit sesion keys.

• There are several reasons for one user to have multiple public/private key pairs– change the key from time to time for security– use different keys for communication with different correspondant groups

• There is not a one-to-one correspondence between users and their public keys. This problem is solved by using key ID’s.

• The overall scheme for key storage is that each PGP entityu maintains two files, one for his own private keys, and the other for the public keys of the correspondents.

PGP – Cryptographic keys and key rings

Key Identifiers • The combination of user and key ID identifies the key uniquely.• A key ID is consists of 64 least significant bits of the key being identified

(public or private).– this identifies the key with a very high propability– other solutions would have either space wasting or key management overhead.

• The sender simply adds the key ID of the public key used into the message. This allowes the receiver to determine which private key to use for encryption.

• A key ID is also required for the PGP digital signature. The recipient must know which of the many private keys was used in the signature. This ID is also a 64 least significant bits of the corresponding public key.

• The general format of the PGP message is presented in Fig. 12.3.• The message has three components: message component, signature

component and session key component.• Normally the entire block is encoded with radix-64, but the conversion can be

applied also only to selected components.

PGP – Cryptographic keys and key rings

Key Rings • The keys and key ID’s need to be stored and organized in a systematic way in

order to be used efficiently by all parties. • The scheme in PGP is to use a pair of tables in each node, the public key ring

stores the public keys of other users known to this node, and the private key ring to store this nodes own public/private key pairs.

• The private key ring stores the timestamp, key ID, public key, private key in an encrypted form and the user ID.

– private key is stored encrypted with conventional algorithm for security reasons. The key used in the encryption is a hash-code from a user selected passphrase. When the user needs to retrieve the private key he must provide for the passphrase.

• The public key ring stores the timestamp, key ID, public key, owner trust, user ID, key legitimacy, signature(s) and signature trust(s).

– owner trust, key legitimacy, signature(s) and signature trust(s) are used to build a ”web of trust” for public key management (explained later)

• Now we can show the message transmission and reception in total (omitting the radix-64 conversion). See Fig. 12.5 and 12.6.

PGP – Public key management

”This 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.”

- Phil Zimmermann –

• PGP provides a structure for solving the problem. Unlike the solution used in S/MIME, PGP has no rigid public key management scheme is used in PGP.

• A number of approaches are possible for minimizing the risk that a user’s public key ring contains false public keys. Suppose A wishes to obtain a reliable public key from B.

– A can get the key physically. This is very secure but unpractical.– The key could be verified in telephone. Also very secure but unpractical.– A could obtain the key from a mutual trusted individual D. This is a variation of the

public-key certificate scheme discussed before. – A could obtain the key from a trusted certifying authority, i.e. use the public-key

certificate scheme discussed before.

PGP – Public key management

• The solution used by PGP is to build a ”web of trust” using public key certificates of several variably trusted individuals. With this web, trust information can be explited and associated with public keys.

• In the public-key ring there were several fields for each stored public key for this purpose. Each entry in the ring is a public key certificate.

• Key legitimacy field indicates the extent to which PGP will trust that this is a valid public key for this user. This field is computed by PGP.

• Assiciated with each entry there are zero or more signatures that the ring owner has collected that sign this public key certificate.

• Each signature has a signature trust fiela that indecates the degree to which this PGP user trusts the signer to certify public keys. The key legitimacy is derived from the collection of signature trust fields in the entry.

• Each entry defines a public key associated with a particular owner. Owner trust field is included to indicate the degree to which this public key is trusted to sing other public key certificates. This level of trust is assigned by the user.

• A Trust Flag Byte contains the three metioned filelds (table below)• The trust processing operates as follows:

– A inserts a new public key on the key ring. If the key is A’s own, then ultimate trust is assigned. Otherwise A has to enter his assessment of trust to be assigned to the owner of this key.

– When the new public key is entered. one or more signatures can be associated with it. When a signature is enrered, PGP searches the key ring to see if the author of the signature is among the known public key owners.

PGP – Public key management

• Trust processing continues....– If the author was found, the OWNERTRUST value of this owner is

assiged to the SIGTRUST field for this signature. If not, an unknown user value is assigned.

– The value of the KEYLEGIT field is calculated on the basis of the signature trust fields present in this entry. If at least one signature has a SIGTRUST value ultimate then the key legitimacy is set to be complete. Otherwise a weighted sum of trust values is computed. This derivation of trust can be controlled by used-defined parameters.

• PGP processes the public.key ring periodically to achieve consistency going from OWNERTRUST to SIGTRUST fields and finally computing the KEYLEGIT values.

• Figure 12.7. is an example of the way in which signature trust and key legitimacy are related. (the node ”You” refers to the entry in the public-key ring corresponding to this user).

PGP – Public key management

• A user may wish to revoke his or her public key for a variety of reasons. In this case the owner issues a revocation certificate signed by the owner. This certificate is then dissiminated as widely as possible to enable the correspondents to update their public key rings.

Introduction

• S/MIME is the de-facto industry standard for secure mail over the Internet. Secure MIME (S/MIME) was developed by an industry consortium, and is now appearing in a number of major products.

• MIME is an extencion to the RFC 822 addressing many limitations of the use of SMPT.

• MIME specification includes– new message headers

– a number of content formats supproting multimedia electronic mail

– transfer encodings

• The MIME content types are listed in table 12.3.

S/MIME Functionality (messages)

• The general functionality of S/MIME is very similar to PGP buth offering the ability to sign and/or encrypt messages.

S/MIME Functions

The S/MIME functions are implemented as new MIME content types.These are listed in table 12.7.

• Enveloped data– This content type consists of encrypted content of any type and encrypted

content encryption keyys for one or more receipients.

– An enveloped data entity is prepared as follows: 1) Generate the pseudo random session key. 2) Encrypt the session key with each recipients public RSA key. 3) For each recipient prepare a RecipientInfo block containing senders public key certifcate, an identifier of the encryption algorithm and the encrypted session key. 4) Encrypt the message content with the session key.

S/MIME Functionality

• Signed data– A digital signature is formed by taking the message digest of the content

to be signed and encrypting that with the private key of the signer. – 1) Compute the message digest with SHA or MD5. – 2) Encrypt the message digest with senders private key– 3) prepare SignerInfo block containing singer’s public key certificate, an

identifier of the message digest algorithm, and identifier of the encryption algorithm and the encrypted message digest.

– A signed data message can only be read by a recipient having S/MIME capabilities

• Clear signed data– Same as previous but now the message contents are readable without

S/MIME, which is needed if the recipient wishes to verify the identity if the sender.

• Signed and enveloped data– Signed-only and encrypted-only messages can be nested in both

orderings.

S/MIME Functionality

• Registration request– An application or a user typically applies to a CA for a public-key

certificate. This content format is used to transfer such request.

• Certificates-only message– this is a message containing only certificates or a certificate revocation

list. It is sent as a response to registration request.

S/MIME – cryptographic algorithms

• The used algorithms are summarized in table 12.6.

• There are two requirement levels:– MUST means an absolute requirement in order to be in conformance with

the specification.

– SHOULD allows an implementation to ignore this feature for valid reasons. it is however recommended that all implementations include these features.

• S/MIME incorporates three public-key algorithms– DSS is recommended.

– ElGamal (a varition of D-H that allows also encryption) or RSA as alternatives

• The recommended hash-function is SHA-1. The alternative MD5.

• For message encryption, three-key triple DES is recommended. All compliant implementations must support RC2 using a key of only 40 bits, which is a weak encryption algorithm.

S/MIME – Certificate Processing

• S/MIME uses public key certificates that conform to X.509v3 directory services.

• The public key management scheme is a hybrid between the strict X.509 certification hierarchy and PGP’s ”web of trust”.

• As with PGP, S/MIME administrators/users must configure each client with a list of trusted trusted keys and certificate revocation lists. – the responsibility for maintaining certificates needed to verify incoming

messages and encrypt outgoin ones is local.– however, the cerificates are signed by certification authorities.

User’s role• An S/MIME user has several key-management functions to perform• Key generation: the user MUST be able to generate DSS and D-H key

pairs and SHOULD be able to generate RSA key pairs.• Registration: a user’s public key must be registered with a CA in order

to receive an X.509 certificate.• Certificate storage and retrieval: a list of certificates can be

maintained by the user or some local administrative entity.

S/MIME – Certification Authorities

• "Certificate Authority" (CA), or "Trust Center", is the name used for an organisation that acts as the agent of trust in a PKI (Public Key Infrastructure) and also for the piece of software. PKI needed for secure use of public key based protocols

• A CA performs 5 main functions:– Verifies users' identities - this may be done by the CA itself, or on its

behalf by a Local Registration Authority (LRA) – Issues users with keys (though sometimes users may generate their own

key pair) – Certifies users' public keys – Publishes users’certificates– Issues certificate revocation lists (CRLs)

• There are several companies that provide CA services.• CA services exist in the full range from individual users wishing to

secure personal mail to full scale enterprise CA solutions.• An examlple of the types and uses of public key certificates is shown

in table 12.8.

OpenPGP

• Email is one of the most heavily used network-based application.

• There are two widely used schemes for providing authentication and confidentiality for email security, PGP and S/MIME.