DataEncryption20060108.doc.doc

519 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
519
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DataEncryption20060108.doc.doc

  1. 1. Encryption Fall 2005 – Encryption for Email and File Transfer 1) Introduction 2) Encryption for Email a) Email Passwords i) Need for email password encryption ii) Methods of email password encryption iii) Client/Server support for email password encryption at Penn b) Email data encryption i) Limitations of SSL encryption for email data ii) Methods of end to end email data encryption (1) PGP/GPG (2) S/MIME iii) Using PGP/GPG and S/MIME with email clients iv) Other uses of PGP/GPG 3) Encryption for File Transfer a) Protocols for secure file transfer b) Secure protocols in file transfer clients supported at Penn 4) Supporting references and tables a) References and supplemental information b) Table A: Email Clients and Support for Use of Encrypted Passwords with Common Penn Mail Servers c) Table B: File Transfer Clients and Support for Password/Data Encryption with Common Penn Web Servers
  2. 2. 1) Introduction 2) Encryption for Email a) Email Passwords i) Need for email password encryption By default, email clients using the POP/IMAP/SMTP (the latter when used with SMTP-AUTH ) protocols send the authentication data (username and password) and send or receive the email message data itself in non-encrypted, “cleartext” form. To protect the password from being “sniffed” as it travels over the network, it is important to avoid such cleartext transmission. ii) Methods of email password encryption While a number of methods for encrypting passwords (e.g. APOP, CRAM-MD5) have been developed and implemented in some email clients and servers over the years, there are currently two methods with wide support at Penn – SSL and Kerberos . The Secure Sockets Layer (SSL) method uses the same technology that is the basis for so-called “secure” websites using the HTTPS protocol to encrypt data sent between a web browser and a web server. When using the SSL method, the entire communication stream between the email client and server is encrypted, not just the password. The Kerberos protocol ensures that the password is never sent over the network at all, not even in encrypted form. This yields a very high level of security for the authentication that takes place between the client and server. iii) Client/Server support for email password encryption at Penn Current versions of all supported email clients at Penn support the SSL protocol and some support both SSL and Kerberos for the POP, IMAP, and SMTP protocols. See Table A for details regarding which clients support which of these protocols when used with a variety of mail servers at Penn. Some servers now require use of either SSL or Kerberos for authentication and disallow any cleartext authentication for the POP, IMAP, or SMTP protocols. b) Email data encryption i) Limitations of SSL encryption for email data As noted above, when SSL is used the data stream between the email client and server (either incoming for POP/IMAP or outgoing for SMTP) is encrypted, not just the password. The contents of the email message are thus not subject to sniffing as the data is sent to or received from the server. It should be noted however, that this provides very little protection for the email message itself.
  3. 3. This method only encrypts the data as it is sent to or received from the server by the client. The data is not encrypted as it is stored on the server nor is it generally encrypted as it is passed to other servers en route to the intended recipient. It also does nothing to ensure the identity of the sender or that only the intended recipient(s) can read it. Nonetheless, until or unless other methods of email encryption become widely used, encrypting the traffic with SSL as it travels across the network does have some benefits and given the wide client support for this protocol, and thus how easily it can be used to encrypt the authentication traffic, there is a very low cost to using it. ii) Methods of end to end email data encryption In order for email to be routed correctly, it may pass through any number of systems, known or unknown and secure or compromised, before it reaches its destination. The contents, much like a postcard, are readily viewed by individuals such as unscrupulous operators or curious hackers. There is no assurance of privacy for email sent in the clear over the public Internet. However, it is possible to take measures to protect a message via encryption so that it cannot be viewed in transit and can only be read by its intended recipient. Two approaches using PGP/GPG and S/MIME will be discussed here from the stance that confidential emails should always be encrypted. (1) PGP/GPG PGP, or Pretty Good Privacy, is a protocol for encrypting files and email. It depends on public key cryptography for its effectiveness. Public key cryptography is a procedure in which users exchange "keys" to send secure documents to each other. Using one of several available commercial or free software applications, a person can generate two digital IDs or keys, one public and one private. The public key is shared with anyone who needs to send encrypted data to the owner of the key. The private key is guarded by the owner and, in conjunction with a strong passphrase, is used to decode encrypted messages. This system depends on senders and recipients performing a one-time corroboration of the authenticity of their identities, their trustworthiness, and their keys' "fingerprints." GNU Privacy Guard (GnuPG or GPG) is a free software replacement for PGP and is functionally identical in terms of the core encryption functions. (2) S/MIME S/MIME, or Secure/Multipurpose Internet Mail Extensions, operates in a different manner. Instead of generating digital IDs himself, a person makes a one-time purchase of digital certificates from a certifying authority, or CA, such as Thawte or Verisign. These certificates can be used to both sign and encrypt email. To send encrypted mail, a person must first send a digitally signed copy of their encryption certificate to the recipient. Senders and recipients trust the CA, which has the responsibility of verifying the identity of the certificate owner.
  4. 4. iii) Using PGP/GPG and S/MIME with email clients In general, use of PGP/GPG to encrypt email communications will require the use of a 3rd party “plug-in” to make the process of signing and/or encrypting and decrypting messages. Such plug-ins are available for most popular email clients. When used, they generally provide toolbar buttons that allows for these functions to be performed easily. Even without such plug-ins, text can be encrypted using the PGP/GPG tool and then pasted in to the body of the message or included as an attachment. Most major email clients do have built-in support for S/MIME , to one degree or another .Clients vary in how they handle certificates and the processes associated with signing and/or encrypting and decrypting messages. Some guides to use of various clients with S/MIME include the following: S/MIME Secure Email - A Beginners Guide and Mac OS X 10.3: Mail - How to Use a Secure Email Signing Certificate (Digital ID). Certificate providers such as Verisign and Thawte also often have guides on how to obtain and use a digital certificate for signing and encrypting mail. John Lupton from ISC’s Information Security group has presented on the use of PGP for email encryption this fall and has made his slides available here: http://www.upenn.edu/computing/security/pgp/present_pp/PGP_0511.html iv) Other uses of PGP/GPG Using PGP Encryption to Protect Files Stored on Disk S/MIME was designed to provide authentication and encryption of email data only, specifically while it is in transit across the wire. PGP/GPG have more utility in that they can be used not only to encrypt email but also to encrypt static data files on a disk drive. These uses of PGP/GPG are covered in the other document produced by the Data Encryption team. 3) Encryption for File Transfer a) Protocols for secure file transfer Just as with email password and data transmission, electronic file transfers using FTP have been cleartext transmissions. To protect the password from cleartext transmission, it is necessary to use a more secure protocol. As with email client, a variety of options exist with file transfer clients, using Kerberos, SSL, or other secure protocols such as SCP, SFTP, both based on SSH. b) Secure protocols in file transfer clients supported at Penn Table B lists a variety of file transfer clients and Penn web servers (since file are often transferred for the sake of publication to the web) and indicates which protocols
  5. 5. can be used. As with email, the protocols that result in encryption for the data stream provide protection against sniffing only as the data moves between the client and server. This may not be necessary if files are being moved for publication to the web, but when data protection is required, something like PGP would have to be used to provide secure end to end transmission. References IETF OpenPGP Working Group / OpenPGP Alliance http://www.openpgp.org/ IETF S/MIME Working Group http://www.imc.org/ietf-smime/index.html FREE Digital Certificates from Thawte http://www.thawte.com/secure-email/personal-email-certificates/index.html FREE Digital Certificates from InstantSSL http://www.instantssl.com/ssl-certificate-products/free-email-certificate.html Email Encryption Primer from the Electronic Frontier Foundation http://www.eff.org/Privacy/Crypto/emailencryption/ PGP Desktop v. 9.0.3 information provided by Jerry Cheng Unlike prior versions, it does not integrate with Outlook 2003. PGP does offer the ability to encrypt and decrypt the contents of the window from within PGP Desktop application. The PGP Desktop application would be a helper application located in the system tray on Windows PCs. Unlike a Zip self-extracting executable with password, PGP can create passphrase zipped files; however, the recipient will need to have PGP installed. PGP Encrypt Window PGP can be used to encrypt the contents of the email message without leaving the application. One draw back to PGP encrypting the contents of the current window is the loss of formatting. If formatting or graphical data is being encrypted, encrypting the document (as an attachment) is recommended. PGP Virtual Disk – covered in file/disk encryption document
  6. 6. Table A: Email Clients and Support for Use of Encrypted Passwords with Common Penn Mail Servers Platform/ SSL Kerberos Mail.SAS** Pobox*** SEAS Notes Client Support* Support* Compatible Compatible Compatible Windows Eudora 6.2x Yes Yes SSL and SSL and SSL and Kerberos Kerberos Kerberos Outlook Yes None SSL SSL SSL MS Kerberos may be used with Exchange servers, XP/2003 but MIT Kerberos can not be used with POP/IMAP/ SMTP servers Thunderbird 1.x Yes No SSL SSL SSL Kerberos support as of 1.5, now in beta Mac Eudora 6.2x Yes Yes SSL and SSL and SSL and Kerberos Kerberos Kerberos Apple Mail 1.x Yes Yes SSL and SSL and SSL and Kerberos Kerberos Kerberos Thunderbird 1.x Yes No SSL SSL SSL Kerberos support as of 1.5, now in beta Above table does not cover all mail servers on campus, but only ones about which team members had sufficient information. More information can be added when/if it becomes available. Note that Exchange servers on campus, when used with Outlook as a client, may use different forms of authentication. In general, when used in Exchange mode, the password, but not the traffic, could be encrypted using the NTLM or NTLMv2 protocol. MS Kerberos authentication may also be supported, but MIT Kerberos would not be. SSL could be used for the POP/IMAP/SMTP protocols, at least for the latest versions of Exchange and Outlook. * Unless otherwise noted, client supports use of this protocol for IMAP, POP, and SMTP. ** Mail.SAS supports numerous domains apart from sas.upenn.edu itself, e.g. chemistry.upenn.edu, econ.upenn.edu, physics.upenn.edu *** Pobox hosts numerous domains apart from pobox.upenn.edu itself, e.g. dolphin.upenn.edu, isc.upenn.edu, mail.med.upenn.edu
  7. 7. Table B: File Transfer Clients and Support for Password/Data Encryption with Common Penn Web Servers Platform / Client Password Data WWW.SAS WWW.UPENN.EDU SEAS Notes Encryption Encryption Compatible Compatible Compatible Standalone Clients Windows Filezilla 2.2.14 Kerberos / SFTP SFTP SFTP only Kerberos only SFTP and No kerberized ftp on mail.sas Kerberos WinSCP SCP SCP Yes Yes Not officially recommended Mac Fetch Kerberos No Yes Yes No kerberized ftp on mail.sas Command line scp/sftp SCP/SFTP SCP/SFTP SCP and No SCP and SFTP SFTP Integrated Clients Dreamweaver MX 2004 SFTP SFTP Yes Not for SFTP* Yes *Could use kerberos FTP proxy Contribute 3 SFTP SFTP Yes Not for SFTP* Yes *Could use kerberos FTP proxy Above table does not cover all web servers on campus, but only ones about which team members had information. More information can be added when/if it becomes available.

×