1 Lecture 18: Security issues specific to security key management services –privacy –integrity/authentication –nonrepudiation/plausible deniability –proof of submission/deliver –others text formatting issues

2 Complexities of 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 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, , 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, K Bob {S} Carol’s ID, K Carol {S} Ted’s ID, K Ted {S} S{m} –E.g.: To: Bob, Carol, Ted From: Alice Key-info: Bob Key-info: Carol Key-info: Ted 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 MAC S (m) –sends m, MAC S (m), [{S} Bob ] Alice Secret key NR: with notary –Alice negotiates with notary to add “seal” to msg, f(S N, msg, “Alice”); S N 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)