Transcription

CS 465Computer SecuritySecure EmailLast Updated: Nov 30, 2017

Email Has been used for 50 years! Seamless interoperability among all email users,regardless of client device or software compare to instant messaging, which is often a walled gardenAs of 2017, 6.3 billion email accounts, owned by 3.7billion users (almost half of the earth!)

Email Protocols

Steps1. Sending client submits email to server — HTTPS orSMTP2. Originating server transfers to destination server —SMTP, may take multiple hops3. Receiving client receives email from server — HTTPS orIMAP or POP

SMTP

Why is Email Insecure No authentication in SMTP Can list any MAIL FROM address in the SMTP envelope Can list any FROM address in the message header Mail servers were originally open relays — would forwardmessages from anyone to anyone No confidentiality or integrity No anonymity, deniability, freedom from tracing, or ephemerality

Problems Spam In the 2010s, a typical campaign involved using a botnet of 3,000compromised machines to send 25 billion emails to 10 million emailaddresses. Pipeline of compromised machines, email list, software tools owned andsold by specialists, campaign run to generate pay-per-click revenue Storefronts for unregulated pharmaceuticals are over a third of spam er 6957289

Problems Malware trick users into downloading (e.g. a spreadsheet) or clicking (e.g. malwarewebsite) an-attack-carbanakPhishing and spear-phishing 100 million bank transfer fraud from 2013 — 2015 DNC and Podesta hacks in 2016 Presidential election C-2018.pdf

Protection by email providers

Link Encryption Can upgrade SMTP to use TLS using the STARTTLScommand works only between pairs of mail servers trivial for an adversary to conduct a downgrade attack by stripping thiscommandStrict Transport Security (STS) — DNS records thatadvertise STARTTLS requirement

Domain Keys Identified Mail (DKIM) sending mail server signs outgoing email (message body,not the envelope) receiving mail server authenticates signature using publickey of domain find the public key via DNSwhat to do if DKIM fails is up to the receiving mail server— can mark or drop

Sender Policy Framework (SPF) organization publishes DNS record indicating which IPaddresses can be used to send email for their domain receiving mail server validates that IP address of sendingmail server is on the list for the sending domain (as listedin the SMTP envelope) what to do if SPF fails is up to the receiving mail server —can mark or drop

Domain Message Authentication, Reporting,and Conformance (DMARC) organization publishes a DNS record indicating which authenticationservices (DKIM, SPF) it supports, plus a policy indicating action to betaken if authentication fails requires identifier alignment DKIM: domain used for signing must match domain in the header From addressseen by the user SPF: domain in the SMTP envelope must match domain in the header From addressseen by the userallows receiving mail server to send reports of failure back to sendingmail server, to identify misconfiguration or abuse

Authenticated Receive Chain (ARC) extends authentication to handle cases when messages areforwarded (e.g. to a mailing list) forwarding mail server adds headers indicating status ofauthentication checks from originator or any forwarder (e.g.DKIM, SPF, DMARC) forwarding mail server signs the message header and bodyas it was received, plus signs additional ARC headers it adds with multiple forwarders, can authenticate entire chain

End-to-end encryption

End-to-end Encryption encryption from the sending client to the receiving client provides both confidentiality and integrity end-to-end encryption seamless global interoperability disaster

S/MIME developed in early 1990s end users obtain certificates from a CA and email clients look upcertificates in a certificate directory encrypt with recipient’s public key verify signature with sender’s public keytypically used by a company or government department with a locallytrusted root, a local certificate directory, and private key escrow provide email scanning (spam/malware), comply with regulations that require accessto plaintext, provide recovery if client loses key

Pretty Good Privacy (PGP) developed in the early 1990s by Phil Zimmerman avoids certificate hierarchy in favor of web of trust — each usersindependently decides which public keys to associate with a givenemail address user associates name and email address with a key other users can add signatures attesting to this binding — was typically done at keysigning parties can receive signed keys from other users you trust — forming a web of trust can publish keys on key servers, e.g. https://pgp.mit.edu/

Pretty Good Privacy (PGP) distributed as freeware on the Internet in 1991, leading toan investigation of Zimmermann by the United StatesCustoms Office for allegedly violating U.S. export laws he published the PGP source code in book form in 1995, and the casewas subsequently dropped in 1996in the 1990’s, one way to skirt federal export controls was to publishthe source code in book form (1st Amendment), ship the books toEurope, have people retype or scan the source code using OCRhttps://heinonline.org/HOL/Page?collection journals&handle hein.journals/syrlr48&id 1331&men tab srchresults

PGP Cryptographic Functions

PGP Encryption and Decryption

Difficulties with PGP difficult to scale beyond small groups due to web of trust an manual key management difficult to revoke compromised keys difficult for non-technical users — and plagued by poor implementations Why Johnny Can’t Encrypt (1999): https://people.eecs.berkeley.edu/ tygar/papers/Why Johnny Cant Encrypt/USENIX.pdf Why Johnny Still Still Can’t Encrypt (2016): https://arxiv.org/pdf/1510.08555.pdfPeople are giving up on PGP Filippo Valsorda, long-time user, dislikes the long-term key model and lack of forward secrecy: / Moxie Marlinspike considers it to be too complex and outdated: https://moxie.org/blog/gpg-and-me/

Next generation PGP trusted public key servers (e.g. gmail.com would run one for its users) audited key servers — use a public ledger that allows monitors toexamine a history of advertised public keys and detect rogue certificatesand misbehaving servers trust-on-first-use key exchange forward secrecy see the autocrypt standard (TOFU) and mailipile for examples of wherethe PGP community is working on now -roadmap

Secure Webmail provides secure email (usually based on PGP) for users of the sameservice email server stores public keys and (password-protected) private keys for all users sending: JavaScript automatically looks up public key on the server and encrypts email forthe user you send to, JavaScript also retrieves your private key and signs outgoing emails receiving: JavaScript downloads email, retrieves your private key, and decrypts it if sending to a user of another system, can choose a password for encrypting the email,and the recipient gets a link to the password-protected email on the email server’s websiteexamples: ProtonMail, Tutanota

Secure Webmail security issues must trust the JavaScript (long term,maybe it is signed and verified free ofbugs) third-party JavaScript can access theDOM and thus get the plaintext (longterm, maybe browsers will implementprivilege separation betweenJavaScript) alternatively, use a non-browser clientor a browser extension

State of Secure Email Enterprises / governments : S/MIME with a local certificate directory and CA, plus private key escrow Individuals: Secure webmail (e.g. ProtonMail) Journalists: Small PGP deployments When the Weakest Link is Strong: Secure Collaboration in the Case of the Panama Papers: /technical-sessions/presentation/mcgregor No one-size-fits-all solution and little interoperability between similar solutions or between differentsolutions End-to-end encryption without escrow means your provider can’t scan emails for spam, phishing, andmalware, and can’t provide search over your archives Phishing is a huge problem Most users store extensive, unencrypted email archives with their providers — based on the 1986Electronic Privacy Communications Act, any email stored over 180 days in the US may be read byfederal government without a warrant — see https://epic.org/privacy/ecpa/

Why is Secure Email Not More Widely Used? lack of perceived risk info being sent is not valuable they are not a valuable target poor awareness of effective security practices routine encryption of email considered paranoid requires cooperation from people you send email to (must use acompatible system), so it can’t be unilaterally adopted no system today provides universal compatibility

Encryption in the US Longstanding debate between privacy advocates and federal law enforcement regarding endto-end encryption federal government would like some way to get access to encrypted data (sometimes called an “encryptionbackdoor”) privacy advocates say this is both not desirable and not technically feasibleOriginally started in the 1990s — NSA developed the “Clipper chip” designed to performencryption with a backdoor each chip programmed with a key and key also put into escrow (with NIST and Treasury) government can get the decryption key with a warrant plagued by technical flaws, stiff opposition from privacy groups, resistance from industryRekindled recently with widespread adoption of smartphone encryption and secure messagingapps (e.g. Signal)

Encryption in the US Based on the fear that if there is strong end-to-end encryption, then criminals and terrorists will be able to use it tocommunicate securely and federal government will lose its ability to wiretap Privacy advocates point to a history of wiretapping abuses, suggest there will be plenty of unencrypted data andmetadata available for authorities Security community worries about reversing progress in deploying forward secrecy, substantial increases incomplexity that makes it harder to build secure systems, concentration of value for targeted attacks (e.g. on anescrow system) Jurisdictional issues on a global Internet are a significant complication Whenever service providers have access to keys that can decrypt customer email, this allows plaintext to berevealed due to incompetent or untrustworthy service providers, by disillusioned employees, by governmentsubpoena, or by regulatory coercion The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption (1997): 8GM8F2W Keys under doormats: Mandating insecurity by requiring government access to all data and communications(2015): https://dspace.mit.edu/handle/1721.1/97690

1. Sending client submits email to server — HTTPS or SMTP 2. Originating server transfers to destination server — SMTP, may take multiple hops 3. Receiving client receives