Part 4 – Electronic Mail

This is the fourth part in a list of cheatsheets based on the book Network Security: Private Communications in a Public World (2nd Edition).

This post is about standards. The first part, Cryptography Introduction Cheatsheet – part 1, was about cryptography, the second part, Cryptography Introduction Cheatsheet – part 2, about authentication and the third part Cryptography Introduction Cheatsheet – part 3, about standards.

Electronic Mail Security

There are two types of mail distribution lists

• The remote exploder method is where a remote site sends the message to its recipients;
• In the local exploder method the sender gets the list of recipients from the remote site.

Mail infrastructure consists of different Message Transfer Agents – MTA that store and forward a message. The path for mail from source to destination might be intermittent.

A list of security services that can be provided for electronic mail are

• privacy Alice wants to send a message to B, she chooses a random secret key S, encrypts the message with S, encrypts S with Bob’s key and then send both the encrypted message and the encrypted S to Bob;
• sourceauthentication can be done with public key technology (signing the message) or secret keys (doing cryptographic computation on the message which results in a MIC or message integrity code or MAC – message authentication code);
• message integrity is -in most cases- already provided by source authentication;
• non-repudiation is provided with public key by signing the message (source authentication). With secret keys we can use a seal provided by a notary-N (Alice sends the message to N and does source authentication with N, then N knows the message came from Alice. N does some computation on the message and Alice’s name which generates the seal on the message);
• a proof of submission can be done by generating a message digest on the message with any other useful information;
• The proof of delivery can be done with a message receipt. Note that this is not a “if and only if”. If the recipient signs before the delivery it can get lost, if the recipient has to sign after delivery he might not furnish a signature at all;
• message flow confidentiality can be established by sending encrypted messages to intermediaries and including the final message as part of the encrypted message;
• anonymity;
• containment;
• audit;
• accounting;
• self destruct;
• message sequence integrity;

There’s on single standard for text representation so sometimes systems have to do transformations (encode) on the message text.

PEM and S/MIME

PEM was developed as a means of adding encryption, source authentication and integrity protection to email. The design of PEM lets you base user keys on secret key or public key technology.

A mail message can contain pieces that have been processed in different ways by PEM. PEM marks a piece that it has processed with a string before and after. PEM can combine these pieces into a message (note that these pieces can also be nested inside one another)

• ordinary, unsecured data;
• integrity-protected unmodified data (called MIC-CLEAR);
• integrity-protected encoded data (called MIC-ONLY);
• encoded encrypted integrity-protected data (called ENCRYPTED).

The long-term key used by PEM is the interchange key (either the public key or the shared secret key). The interchange key is used to encrypt the per-message key.

For the PEM certificate hierarchy, RFC1422 recommends an organization of CAs. The single root CA, IRAP – Internet Policy Registration Authority certifies other CAs called PCA – Policy Certification Authorities. The different policies are

• HA – High assurance, meant as ‘super-secure’;
• DA – Discretionary assurance, doesn’t impose any rules on the orgs to which it grants certificates (other than being the ‘owner’);
• NA – No assurance, no constraints except that it is not allowed to issue two certificates with the same name.

PEM users can issue a CRL-RETRIEVAL-REQUEST to the CRL service to get a list of revoked certificates.

Encryption of a message is done with a randomly chosen per-message key and a initialization vector (IV). Integrity protection is done by calculating a MIC (MD2 or MD5). Users can (usefully) forward a message if public key technology is used.

S/MIME says that its encrypted blobs are binary data so MIME takes care of encoding them. S/MIME supports different public key infrastructures

• S/MIME with Public Certifier (like for example issued by companies as Verisign);
• S/MIME with Organizational Certifier (easy to configure in an internal network, more difficult to have someone external have trust the issuer);
• S/MIME with Certificates from Any Old CA, you first send me your certificate, I store it in my address book and trust it.

PGP – Pretty Good Privacy

PGP is not only for mail, it can do encryption and integrity protection on files. It uses public key cryptography for personal keys. PEM assumes a rigid hierarchy of CAs, PGP assumes anarchy. PGP allows you to specify if the handled file is text or binary. If it’s set to binary then PGP will not canonicalize it. PGP indicates whether what is being signed is a message or a certificate. It includes a file name with every message (specifies the name of the file that was read to produce the PGP object). PGP allows you to choose any name you want (no uniqueness enforced).

A PGP message contains different primitive objects. Every PGP object has a human-readable header and footer. The list of message formats are

• Encrypted message;
• Signed message;
• Encrypted signed message;
• Signed Human-Readable Message;

The key ring stored public keys and information about each key. Each key consists of the name of the human associated with the key (userid), set of certificate signatures you’ve received and the trust information about each of the pieces of information. [publickey|trust|userid|trust|signature|trust|…|signature|trust].