1 / 10

Lecture 18: E-Mail Security

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. Complexities of E-Mail. non-real-time text-based

ivi
Download Presentation

Lecture 18: E-Mail Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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)

More Related