16. Email Security

Email Security Requirements

SMTP (Single Message Transfer Protocol, RFC 5321) used to transmit email.

Message user agent (MUA) connects client to a mail system, using POP/IMAP to retrieve mail from message store (MS) and SMTP to send mail to a message submission agent (MSA).

The message handling system (MHS) transfers messages from the MSA to the MS via one or more message transfer agents (MTAs).

 Message Transfer    ...     Message Transfer
   Agent (MTA) 1   -------->   Agent (MTA) n
        ^                            |
        |                            | (Local SMTP)
        |                            v
Message Submission             Mail Delivery
    Agent (MSA)                 Agent (MDA)
        ^                            |
        |      Message Handling      |
        |        System (MHS)        |
- - - - - - - - - - - - - - - - - - - - - - - - - - -
        |                            | (Local SMTP)
        |                            v
        |                         Message
        |                       Store (MS)
        |                            |
        |                            | (IMAP/POP)
        |                            v
   Message User                Message User
    Agent (MUA)                 Agent (MUA)

Email content should be confidential and/or authenticated. The email service should also have a high level of availability.

Spam:

• Unsolicited bulk email (UBE)
• Common vector for phishing
• Email filtering to counter
• Proposal for proof of work: email sender must solve some problem before MHS accepts the email

Link Security

DomainKeys Identified Mail (DKIM)

Domain-to-domain security.

Standard which provides email authentication. RFC 6376.

Sending mail domain signs outgoing emails with its RSA signatures, verified by receiving domain.

Public key of sending domain stored in a DNS record.

Widely used to prevent email spoofing, spam, phishing.

The email contains:

• Version
• Algorithm
• Domain claiming origin
• List of signed header fields
  • Hash for those fields
• Hash for the body
• Selector subdividing namespace
  • Name of DNS record which contains public key the email was signed with
  • e.g. if you want to retire old keys, use different keys for each server

STARTTLS

Extension of SMTP/POP (RFC 2595) and IMAP (RFC 3207) to run over TLS.

Link-by-link security; not end-to-end. However, use of TLS means forwards secrecy may availlable, although this doesn’t help if an attacker controls on of the links.

Link-to-link security allows metadata information (e.g. email destination) to be protected since most nodes provide transmit email for many users (ala VPN), making it hard to determine where a specific email is going from observing network traffic.

Opportunistic use of TLS; use if possible, continue if not available. This makes it vulnerable to STRIPTLS attacks where an attacker interrupts TLS negotiations, making it fail and fall back to plaintext.

End-to-End Security

Client-to-client security.

Pretty Good Privacy (PGP)

Email authentication and encryption for message contents.

• OpenPGP: RFC 4880
• GnuPG: open implementation

Hybrid encryption:

• New random ‘session key’ generated for each new message
• Message content encrypted with symmetric encryption
  • Compress plaintext contents with zip
  • OpenPGP requires 3DES with 3 keys (168 bits total), recommends AES-128, CAST5 and a few other algorithms to be supported
• Session key encrypted using asymmetric encryption using receiver’s long-term public key
  • OpenPGP requires Elgamal support, recommends RSA support

Optional authentication:

• Optionally sign hash of plaintext (SHA1/SHA2) with sender’s private key
  • OpenPGP requires RSA signature support, recommends DSA signatures support
• RSA-signed messages hashed with SHA1 (or SHA2)

Then packaging: content encoded with radix-64 so that binary strings can be sent.

Web of Trust:

• Public keys available on distributed key servers
  • Users generate their own public/private key pairs:
• Any PGP user can sign another user’s public key, indicating a level of trust
• Users can revoke their own keys by signing a revocation certificate with the revoked key
  • Or set an expiry date when generating their keys

Usability:

• Average user can’t understand it
• Difficult to make an interface that allows users to operate PGP correctly and safely
• Vulnerable to EFail
  • Client tricked into placing decrypted message within JS or HTML tag, allowing it to be sent to an attacker’s server

Criticisms:

• Old algorithms used
• No support for new ones
• No support for authenticated encryption
• Lots of metadata not protected: file length, recipient key identity

Secure/Multipurpose Internet Mail Extension (S/MIME)

Has similar features to PGP, providing authentication, integrity, non-repudiation and confidentiality of the message body, but it cannot interoperate with PGP.

It includes the sender’s public key in each message, keys being X.509 certificates issued by CAs. It is supported by most popular mail clients.

Authentication:

• Sender:
  • Creates message $m$
  • Generates message digest $h(m)$: SHA-256 hash of $m$
    • SHA guarantee: no one else can find a message $m$ that creates the hash $h(m)$
  • Signs $h(m)$ with private RSA key to create signature $s$
    • RSA guarantee: only the owner of the private key can generate $s$
  • Sends $s$ and $m$
• Receiver:
  • Uses the sender’s public key to verify $s$
  • Calculate the digest themselves and check it corresponds to the received digest

Confidentiality:

• Sender:
  • Creates message $m$, random 128 bit content-encryption key $k$ for this message
  • Encrypts $m$ using $k$ using AES-128 with CBC mode
  • Encrypts $k$ using the receiver’s public RSA key
  • Send $m$ and $k$
• Receiver:
  • Decrypts $k$ using their private RSA key
  • Decrypts the encrypted message using $k$

The use of symmetric cryptography makes the process more efficient. By using a new ‘session key’ each time (one-time-mechanism), the encryption approach can be strengthened.