Navigating E-Mail Security: Key Management, Privacy, and Integrity Issues

1. Lecture 18: E-Mail Security • issues specific to email security • key management • services • privacy • integrity/authentication • nonrepudiation/plausible deniability • proof of submission/deliver • others • text formatting issues

2. Complexities of E-Mail • non-real-time • text-based • with potential reformatting on the way • distribution lists • local explosion – list maintainer sends back the users’ addresses to the sender • remote explosion – list maintainer forwards the message to everyone on the list • store-and-forward • by multiple MTAs

3. Security Services for E-mail • privacy – only intended recipient reads the message • authentication – recipient confirms the identity of the sender • integrity – message has not been altered in route • non-repudiation (third-party authentication) – recipient can prove that the sender indeed sent the message • proof of submission – verification to sender that mail system accepted message for transmission (how’s that similar/different from US Postal service?) • proof of delivery – verification to sender that the recipient received the message • message flow confidentiality – third party cannot know that the exchange between sender and recipient occurred • anonymity – recipient does not know the identity of the sender • others: audit (network records), (security levels) containment, accounting, self-destruction, message sequence integrity

4. Key Management the security services can be provided using either public or private keys • a per-message symmetric key is used for message encryption, • which is conveyed in the mail, encrypted under a long-term key (typically a public key) • long-term keys can be established, • offline • online, with help from a trusted third party (PKI, KDC) • online, through a web, email, etc

5. Privacy end-to-end • Alice encrypts the message with her shared key with Bob or her public key • if public – better to a invent and encrypt a symmetric key and use the key to encrypt the message (why?) mailing lists • local explosion (what’s wrong with local explosion and privacy?) • message key will be encrypted under each recipients long term key in the message header. • Bob’s ID, KBob{S} • Carol’s ID, KCarol{S} • Ted’s ID, KTed{S} • S{m} • E.g.: To: Bob, Carol, Ted From: Alice Key-info: Bob-4276724736874376 Key-info: Carol-78657438676783457 Key-info: Ted-12873486743009 Msg-info: UHGuiy77t65fhj87oi..... • remote explosion – use public key for the list

6. Integrity/Authentication • why do we need integrity together with authentication? • public key, how? • secret key – use a MAC (what’s that?) • MAC can be • CBC residue computed with shared key. • message digest of the shared key appended to the message • message digest encrypted with shared key • which method is most efficient if there are multiple recipients?

7. Non-repudiation/Plausible Deniability • Public keys: nonrepudiation easy, PD hard (why?) • Secret keys: vice versa • PD with public keys, why does this scheme work? • Alice, to send message m to Bob, • chooses a random symmetric key S • computes [{S}Bob]Alice • computes MACS(m) • sends m, MACS(m), [{S}Bob]Alice • Secret key NR: with notary • Alice negotiates with notary to add “seal” to msg, f(SN, msg, “Alice”); SN is secret local to notary • Bob can’t tell if seal OK, but could ask • Or Notary can add second seal for Bob: Note: Bob’s seal better cover Alice’s. Why? • does the notary need to know the message to add a seal?

8. Proof of Submission/Delivery • submission • post office signs MD of message • proves it received it, not that it was delivered • delivery • signed by recipient, when should recipient sign the message • before delivery (what if lost after signature) • after delivery (what if does not want to sign?)

9. Confirming Time of Message Transmission, Others why is confirming desirable? two attacks • backdating – claiming something happened later than it did • prevention – notary dates and signs the message upon receipt • postdating – claiming something happened earlier than it did • prevention – include in message something that could not be known until later, or signed timestamp of a notary for that date other services • protecting message flow, anonymity – use intermediaries • not straightforward, why? • containment – deploy security level aware mail system

10. Text Format Issues • Mail gateways/forwarders may modify the format of the message (wrapping long lines, end-of-line character, high order bits, etc.), causing the integrity check to fail • Encode messages in a format supported by all mailers. 6-bit representation, no long lines, etc. (similar to uuencode) • Non-supportive clients should be able to read authenticated (but not encrypted) messages, • MAC without encoding (subject to corruption by mail routers) • Encode & MAC/encrypt (may not be readable at the other end)