----------------------------------------------- Backdrop: my ISP (sbcglobal) does the following ----------------------------------------------- (a) requires I provide username/password to send via sbcglobal SMTP servers - but given those correct credentials, lets me connect from anywhere to those servers and send (i.e. no IP address validation required) (b) for message retrieval (via POP3), requests username/password, which are sent in the clear... as are the contents of the email ----------------------------------------------- Backdrop: CS stanford does... ----------------------------------------------- (a) for sending via Stanford servers: uses TLS for connection (b) for message retrieval (via POP3), entire connection is over SSL ---------------------------------------------- Backdrop: What we want secure email to provide ---------------------------------------------- (1) privacy: the contents of the email (even that the sender is sending an email to a certain recipient) are private (2) integrity: the contents of the email have not been tampered with (3) the sender is assured that only the recipient can read the email - recipient authenticated to sender (4) the recipient is assured that the purported sender is indeed the sender - sender authenticated to recipient (5) the recipient does not receive email from unintended sources - prevention against spam - prevention against receipt of phishing emails (6) low overhead, easy to set up, easy to send to non-enrolled, easy to enroll... - sender doesn't have to obtain recipient's cert prior to sending email - few-to-no changes to MTA required... (7) non repudiation: sender cannot later claim to have not sent this email (8) off-line viewability: - recipient can read email without having to be on-line (9) Optional: - policies applied automatically so that sender doesn't have to decide whether or not to encrypt/sign... - provision of anti-spam, anti-phishing, anti-malware services on email -- if we encrypt before the network elements that perform anti-spam, anti-malware checking operate, then they may be hosed -- unless those elements can either (a) decrypt the email then scan it or (b) scan through the encryption - and if they can scan through the encryption, what does this say about the ability of intervening passive network elements to perform this same scanning to look for keywords... glean info about the email contents +++++++ Threats +++++++ (1) eavesdropping - read email - copy email - steal authentication credentials sent over SMTP/POP3 session + protect via encryption (2) invasion of privacy - IP of sender - email client used by sender + protect via scrubbing email of headers that reveal sender's IP and/or sender's email client... replace with a remailer's info (3) msg modification + protect via integrity check on (encrypted) email, e.g. via MAC (4) false (spoofed) messages + protect via sender signing MAC for example with his private key (5) message replay + protect via use of nonces (6) unprotected backups - msgs stored on e.g. SMTP server in the clear (7) repudiation - sender claims later to have not sent message + protect via sender signing MAC for example with his private key (8) spam emails: unsolicited email + protect via ensuring can only receive from identified acceptable senders (9) phishing emails: unsolicited email used in identity theft etc. + protect via ensuring only can receive from identified acceptable senders + and protect via ensuring that if email is purportedly from some acceptable sender (e.g. bankofamerica.com) that the email is signed using a valid key for that domain... ================================================= Backdrop: where might email encryption be applied ================================================= (1) On the end-user system (client-based) - via a plug-in to user's email client (2) On a gateway - organization has a gateway - all email sent via this gateway - gateway encoded with policies specifying which emails should be encrypted and how - especially appropriate if encryption being applied for compliance reasons; relieves end user of burden of determining when to apply encryption and what encryption to use etc. - possible question: does email from client to gateway travel in plaintext? +++++++++++++++++++++++++++++++++ Push solutions vs. Pull solutions +++++++++++++++++++++++++++++++++ (1) Push delivery: deliver encrypted email directly to user's inbox -- mail is encrypted at sender's site (either on desktop or via gateway server), then shipped to recipient -- once recipient receives email, opens and decrypts it - has to authenticate to Key Server in order to obtain decryption key -- once have obtained decryption key, recipient can subsequently view the email offline -- outside users can only receive (or at best securely reply to) secure emails; outside users cannot initiate a secure email conversation -- possibly also provide web interface that enables outside users to initiate a secure email conversation (2) Pull delivery: messages stored centrally; viewed by recipients using secure website -- webmail; browser-based email infrastructures -- sender controls storage, access control, expiration date for email -- minimum setup... -- but: users like to receive their email in their email clients -- also users have to be online to read their emails -- sender must backup messages... -- legal liabilities associated with sender company having access to receiver's email? ========================= Email encryption: OPTIONS ========================= (0) S/MIME (Secure/MIME): provides authentication, integrity, non-repudiation - client must install (root?) cert from CA - client must obtain recipient's cert (signed by that CA?) - client validates recipient's cert - client encrypts email using recipient's pubkey - client provides his own cert to recipient too + Not clear whether sender is authenticated to recipient only that recipient is authenticated to sender - encrypting with RSA pub key takes long time - must obtain certs for self and all with whom want to communicate securely + Can be Gateway-to-Gateway: encrypt messages using a site key to another domain that will decrypt the messages then deliver them in the clear to the end user (1) PGP and OpenPGP (2) PostX - send encrypted payload plus decryption code to recipient -- payload encrypted with unique secure random session key - that session key stored on PostX key server (is not sent with message itself) - recipient must have on-line access to key server, to authenticate self and then to obtain the decryption key -- this takes place over SSL session to key server - recipient can open email without a plugin and within their existing email clients -- i.e. they don't have to be restricted to only viewing the email on a webmail interface (browser, online) -- in reality, no plugin, but email comes with decrytion code (is this really better?) -- in reality, recipient *does* have to connect to a server in order to view the email: in particular the recipient must authenticate himself to this server in order to obtain the decryption key from that server... so there is an on-line requirement - moreover, if each msg encrypted with unique session key, then recipient will have to connect to key server every time he receives a new message. - claims massive interoperability: server-side and recipient-side technologies designed to work in "all major distributed IT enviros" -- claim: email-client-agnostic -- claim: platform-agnostic - authenticating the recipient: (a) if sender already has info on recipient that can be used to authenticate the recipient (the recipient's member ID, e.g.), then use that as authentication credentials when email accessed by recipient (b) else, sender needs to "enroll" the recipient to setup authentication credentials - so PostX comes with an authentication DB to store recipient credentials - however, PostX can also access existing customer directories using LDAP lookups (interoperates with existing authentication infrastructure - rather than requiring parallel architecture) - for envelope delivery method, server may look up user in "enrolled users" DB and if cannot find recipient, then will queue the message and send an enrollment-request message to that recipient -- then PostX server polls for successful enrollment and sends the secure email when that has been completed - NB: enrollment process sends clear-text enrollment request message to the recipient - so passive observer could see this message then beat recipient to the punch by providing fallacious authentication credentials/data - assuming recipient specifies credentials given sender doesn't have any a priori credentials for the recipient This couldn't possibly be the case, right? Too brain dead. - (3) IBE: - enrolled client can send to non-enrolled recipient easily - client generates message to recipient then encrypts that message using a key K where: P and s * P are public key params ID_bob : the identity of the intended recipient, bob; e.g. "bob@b.com" r <--- new random number generated by client/sender K = Pair( r * ID_bob, s * P ) obtains r * P (recall r generated by sender and P public) Then sender/client sends to recipient: E_K[msg] || r * P - recipient downloads plug in in order to perform decrytion which entails recipient generates that same key via: recipient has his own public key: s * ID_bob (obtained from key server) calculates: K = Pair( s * ID_bob, r * P ) then uses K to decrypt E_k[msg] ADVANTAGES: - sender can send to non-enrolled recipient without having to obtain any info a/b him (e.g. a cert or similar); can just use his identity -- conceptually, anyway; in practice, the recipient's identity may be a combination of his email address and a valid-duration period - recipient only has to contact an on-line entity once - to obtain his private key, which he can then use for all subsequent messages and also to read his messages off-line - also offer Zero Download option whereby non-enrolled recipient can view his email on a Zero Download server (similar to webmail); means that the recipient doesn't have off-line access to his email - no CRLs (4) Client-to-Server and Server-to-Client encryption (not end-to-end) (a) SMTP w/TLS: mail client to SMTP server (running MTA) on port 465 or 587 - how user sends mail (b) POP3 with SSL: POP3 mail server (port 995) to email client - how use retrieves mail - easy to use, low overhead, no plug in required - not end-to-end ================================================ Notes about SSL regarding use w/mail sessions... ================================================ (1) If use RSA as pubkey algo instead of DH, then don't have perfect forward secrecy... that is, with RSA, if server's private key exposed, then one can review the logs of this SSL exchange and determine the master secret... thus being able to decrypt all communications Using Diffie Hellman, OTOH, means that even if server's private key exposed, observer still has to compute discrete logs modulo X ... in order to learn the master secret. I.e. computationally hard. (2) Entire SMTP session encrypted; that is, the MAIL From: RCPT To: etc. are ALL encrypted... vs. protocols that would only encrypt the body of the message (i.e. that sent via the DATA cmd). (3) But security is not end-to-end: that is, if I create a TLS session with my mail server, then the mail I send over that connection (and all details about it) are kept secret. However, if my mail server connects to the target domain's mail server and *does not use TLS for this connection*, then the contents of my mail may be learned by a passive observer. Similarly if that mail server doesn't perform TLS for the POP connection the recipient makes to that mail server, also exposed. Me +++ TLS conn +++ my SMTP Server X X X (SMTP conn) X X relay MTA for destination domain X X X (SMTP conn) X X local MTA for destination domain X X X (POP conn probably) X X target recipient Where the +++ denote protected connections and the XXX denote connections that I have no control over... if that relay MTA (for the destination domain) doesn't support TLS, the contents sent over that connection may be sent in the clear. Likewise for the connection between the recipient and his local MTA etc. +++++++++++++++++++++++++++ Review: Encrypting with RSA: take message; preprocess it; raise that to e; transmit +++++++++++++++++++++++++++ Ways of doing preprocessing: ---------------------------- (1) PKCS1 v1.5 - top 16 bits: 0x0002 - random pad - next 16 bits: 0xffff - message (2) PKCS1 v2.0 : OAEP (Optimal Asymmetric Encryption Padding) - msg - PAD: H'( ( M || 0x0001 || 0x000...00 ) XOR H( rand ) ) XOR rand ... etc other options ====================================== Why pad at all? Textbook RSA insecure. ====================================== C = M^e mod N M = C^d mod N For starters, is deterministic and semantically insecure. Also, for SSL premaster secret, imagine session key k is in { 0, 2^64 - 1 } - eavesdropper sees: RSA( k ) and e,N Suppose k = k_1 * k_2 where k_1, k_2 < 2^34 So build table, for i = 0, 1, 2, ..., 2^34 k_i' = i^e mod N entry = C/k_i' For k_2' = 0, 1, 2, ..., 2^34 check whether: ( k_2' )^e is in table --------------------------------------------------------------- Recall: N = p * q PHI(N) = ( p - 1 ) * ( q - 1 ) choose e such that: gcd( e, PHI(N) ) = 1 then solve for d via: d * e == 1 mod ( PHI(N) ) --------------------------------------------------------------- E.g. N = 499 * 577 = 287923 (19 bits) e = 3 k requires 7 bits; k = k_1 * k_2; k_1, k_2 < 2^3 k_1 = 7 k_2 = 5 k = 35 Attacker knows N = 287923; e = 3; sees C = k^e mod N = 42875 for i = 0, 1, 2, ..., 2^3 - 1 0^3 = 0 mod 287923 C/0^e = undefined 1^3 = 1 mod 287923 C/1^e = C = 42875 2^3 = 8 mod 287923 C/8 = decimal value 3^3 = 27 mod N C/27 = decimal value 4^3 = 64 mod N C/64 = decimal value 5^3 = 125 mod N C/125 = 42875/125 = 343 6^3 = 216 mod N C/216 = decimal value 7^3 = 343 mod N C/343 = 42875/343 = 125 Then for k_2' = 0, 1, ..., 2^3 - 1 is ( k_2' )^e mod N == ( k_2' )^3 mod 287923 in the table? So, what's required here? Well I don't see that this attack would work if e were large or k were much larger... i.e. the attack relies on being able to divide C by some integer value (candidate k_1) and obtain some other integer value (candidate k_2) for some k_1, k_2. Now if C^e > N then we won't be able to divide C^e by candidate k_1^e and get an integral value, even for the correct k_1^e So the attack directly states requirement that k_1, k_2 < sqrt( k ) but doesn't specify any requirements vis a vis the size of k relative to N or the size of C^e relative to N... ========== References ========== (1) Dan Boneh lecture notes - RSA padding etc. http://crypto.stanford.edu/~dabo/courses/cs255_winter00/RSA.pdf (2) Why Textbook RSA and El Gamal are Insecure (Boneh, Joux, Nguyen) http://crypto.stanford.edu/~dabo/abstracts/ElGamalattack.html