Secure File Exchange Over the Internet

Sending files over the Internet is common, and sending those files securely is vital to many businesses. There are a number of ways you can transfer files, just as there are a number of ways you can secure those files during transmission. Your choice of transfer and encryption methods depends on your overall needs: Do you simply want to ensure that your files are secure while in transit? Or is it more important to you to encrypt files so that they remain secure after they arrive at their destination? Let's take a close look at your secure file-transmission options.

In Transit and Beyond
If you want only to protect files as they're transferred across the Internet, you need a secure transport technology. One option is to transfer files using a Web site that accepts uploads and provides a method for secure downloads. For secure uploads, you can build a Web page that uses an ActiveX control or Javascript, along with Secure Sockets Layer (SSL) to provide a secure transport. For example, you could use Persitis Software's AspUpload control, which claims to be "the most advanced upload control on the market." Or you could use the Free ASP Upload script, which doesn't require the use of a binary component. To gain further security, you might even password-protect the Web page and the associated upload directory. For downloads, you need only ensure that the Web server provides an SSL-enabled connection for at least the particular URL used to download the files.

An alternative would be to use an FTP server that supports FTP Secure. FTPS is essentially FTP running over an SSL connection. Many popular FTP client applications support FTPS, but unfortunately Microsoft's FTP Service doesn't support FTPS. Therefore, you'll need to use an FTP server application (e.g., the popular WFTPD) that does support FTPS. Don't confuse FTPS with SSH File Transfer Protocol. SFTP is a file-transfer protocol that runs over Secure Shell (SSH), and you can also use it to transfer files. Keep in mind, however, that SFTP isn't compatible with the traditional FTP protocol, so you'll need a special SFTP client (e.g., the client that the PuTTY Telnet/Secure Shell package provides, or the GUI-based WinSCP), along with a secure shell server (e.g., the one available from SSH Communications Security).

You can also use a VPN to securely transfer files. Windows Server platforms offer support for VPN technology through RRAS. However, this support might not be compatible with that of your partners' VPN solution. If it isn't, you could use a common solution such as the open-source Open-VPN tool, which is free and runs on a variety of platforms, including Windows, Linux, BSD, and Macintosh OS X. For information about how to integrate OpenVPN, see "Putting Open-VPN to Work," InstantDoc ID 45844. With an encrypted VPN connection in place, you can map directories and transfer files back and forth. With any VPN, your traffic is already encrypted, so you wouldn't necessarily need to encrypt the files, unless you want to ensure that the files remain secure on the system to which they're transferred. This principle applies to all the transfer methods I've discussed so far.

If you aren't worried about the transfer process and are mainly concerned that any unauthorized users not have access to file content, simply encrypting the files before you transfer them is a good approach. In this case, email is probably an efficient way to send the files. Email is the most commonly used application on desktops, so if you use email, you wouldn't need any additional technology besides a data-encryption method. Sending files over email is efficient because messages and associated file attachments typically go directly to the recipient's mailbox, even though the email might traverse several servers along the way.

If you do want additional security during the email-transfer process, consider using the SMTP Secure (SMTPS) and POP3 Secure (POP3S) protocols. SMTPS and POP3S are essentially the ordinary SMTP and POP3 protocols running over an encrypted SSL-based connection. Microsoft Exchange Server supports SMTPS and POP3S, as do most email clients, including Microsoft Outlook. Remember, even if you use SMTPS between your mail client and mail server, your mail server might deliver the email to its final destination over a regular, unencrypted SMTP connection.

Because email is so common, the rest of this article will focus on using email to securely transfer files. The inherent assumption is that you want to encrypt the message data to protect it during transit and after the data's arrival. Now, let's look at the more popular encryption technologies available for email today. After doing so, you should have a good idea about which encryption technology is right for your needs.

File-Compression Applications
Many types of file-compression applications are available for compressing files into a single archive file, and many of these solutions provide some form of encryption with which to protect the archive's content. Typically, you set a password during file compression, and anyone who wants to open the archive must have that password.

One of the most popular archival compression schemes is zip compression, which most archival applications support. One of the most popular zip-compression applications available today is WinZip. WinZip can work as a standalone application, integrate into Windows Explorer for easy access, and integrate with Outlook, thanks to the WinZip Companion for Outlook.

WinZip—and many other zip-enabled archive applications—offers support for Zip 2.0 Encryption. However, Zip 2.0 Encryption is a weak file-protection method. Strong encryption is new to WinZip 9.0. As Figure 1 shows, WinZip now supports the Advanced Encryption Standard (AES), using either 128-bit or 256-bit encryption keys. AES is a relatively new technology, but it's already considered an industry standard.

I'm not sure how many compression applications support strong encryption through AES, but one other such application is BAxBEx Software's bxAutoZip, which can interface with BAxBEx's CryptoMite encryption product and can also integrate with Outlook. Whereas WinZip supports only Zip 2.0 and AES encryption, CryptoMite supports several different encryption schemes, including AES, the popular Twofish and Blowfish algorithms, Cast 256, Gost, Mars, and SCOP.

Although most computer systems probably already have the ability to decompress zip files, not all zip applications support various encryption algorithms. Therefore, before you send encrypted files, you need to ensure that the algorithm you choose is supported by the recipient's zip application.

When you use a zip application to encrypt files, you'll need to supply an encryption password. To decrypt the archive file, the recipient of the file will also need that password. Be careful when you choose a password-delivery method. The safest ways to deliver the password are probably by phone, by fax, or by courier. Whatever method you choose, don't email the password in plain text, because that method will greatly increase the likelihood that an unauthorized user will gain access to the encrypted file.

Keep in mind that encryption-enabled archival applications aren't limited to sending files over email. You can also use them effectively to transfer files through the other aforementioned methods.

Pretty Good Privacy
Another tremendously popular encryption scheme is Pretty Good Privacy. PGP made a huge splash when Phil Zimmerman first published it freely on the Internet in 1991. PGP became a commercial product in 1996 and was subsequently purchased by Network Associates (NAI) in 1997. In 2002, the startup company PGP Corporation acquired the technology from NAI.

Since that time, PGP Corporation has sold a commercial version of PGP that runs on Windows and Mac OS X. The current version, PGP 9.0, offers individual file encryption, entire disk encryption, and integration with AOL Instant Messenger (AIM). PGP 9.0 also integrates with popular email software-such as Outlook, Microsoft Entourage, Lotus Notes, Qualcomm Eudora, Mozilla Thunderbird, and Apple Mail.

PGP uses a public key system, a method that generates a pair of encryption keys: a public key and a private key. The two keys are mathematically related, so data encrypted using the public key can be decrypted only by using the private key.

A PGP user generates a public and private key pair, then publishes the public key in a publicly accessible key directory or Web site. The private key, of course, is kept private and secret, and only its owner uses it. Although a password is required when using the private key to decrypt data, a password isn't required to use the public key to encrypt data because public keys are meant for public use.

For ease of use, PGP offers the ability to automatically query public key directories for a user's public key by using that person's email address as the query string. PGP can automatically retrieve public keys, which you can store locally on your system in a file-based keyring for easy access. By querying the public key directory, PGP can ensure that the keys in your keyring are current. If a user changes his or her public key, you have access to the latest key when you need to use it.

For added assurance of public key authenticity, public keys can also be digitally signed by another user's key. Having a key signed by another user gives you some assurance that a key actually belongs to its alleged owner. PGP can add a digital signature to a key by performing a mathematical operation, then adding the unique resulting output to the key. The signature can then be validated by checking the signature against the signing key that was used to create the signature. Think of this process as one person vouching for another person's identity.

Many people trust PGP because of its longstanding reputation in the industry as a technology for keeping information secure. Even so, if you decide to use PGP or another form of public key encryption, the recipients of your files must also use a compatible encryption system. A benefit of using PGP for email is that it supports its own proprietary encryption as well as X.509 and S/MIME, which I discuss next.

Also, whether you decide to use PGP, WinZip, or another encryption system, if you want to encrypt the contents of the message itself in addition to the files you're attaching, you'll need to write your message in a separate file and encrypt it, too. You could place that message file in the archive along with your other files, or you could make it a separate file attachment, depending on your particular needs.

PKI
Although Public Key Infrastructure (PKI) is unique, it works somewhat similarly to PGP. PKI uses a public and private key pair: People use your public key to encrypt data they want to send to you, and you use your private key to decrypt that data after you receive it.

One major difference is that, in PKI, the public key is typically stored in a data format known as a certificate. Certificates can contain much more information than just the key. For example, certificates also contain an expiration date, which lets you know when the certificate and associated key are no longer valid. In addition, a certificate might contain the key owner's name, address, phone number, or other data. Figure 2 shows certificate contents as seen from within Microsoft Internet Explorer (IE) or Outlook. To some extent, certificate content depends on what the owner wants to put inside.

Like PGP, PKI lets you establish a chain of trust, in which certificates can become signed through the use of other users' certificates. Furthermore, Certificate Authorities (CAs) have been established as trustworthy third parties that don't only issue certificates but also sign certificates—and therefore can vouch for the authenticity of a certificate. As with PGP and its associated key servers, certificates can be published to a publicly or privately accessible certificate server or LDAP server, emailed, or even posted to a Web site or file server.

To automatically validate a certificate's authenticity, email clients and Web browsers are typically designed to interact with the servers of CAs. This process can also inform you when a certificate has been revoked for whatever reasons, which in turn lets you know that the certificate can no longer be trusted. Of course, using a CA to issue and vouch for a certificate sometimes comes at a price, and that price can vary depending on which CA you choose. Some CAs offer free personal email certificates, and others charge significant fees.

Because PKI is based on the X.509 specification (which is a derivative of the LDAP X.500 specification), certificates issued by one authority— including certificates you generate for yourself—are typically compatible across multiple platforms, as long as those platforms support the X.509 standard. You could generate certificates yourself by using any number of available tools, such as OpenSSL.

If your organization uses Microsoft Certificate Services, you can use that to request a certificate. The process should be similar for both Windows Server 2003 and Windows 2000 Server. Access your certificate server's Web page (typically http://servername/CertSrv), then select Request a Certificate. On the next page, select User certificate request and follow the Web-based wizard until you're done. If your certificate services are configured to require administrative approval before issuing the certificate, you'll see a message to that effect, and you'll need to wait for an administrator to handle your request. Otherwise, you'll eventually see a link that lets you install the certificate immediately.

Some third-party CAs, such as Thwate and Comodo Group's InstantSSL, offer free personal email certificates—an easy way to obtain certificates. And the certificates would already be signed by the issuer, which helps verify authenticity.

When it comes to using PKI for sending encrypted data through an email application, Secure MIME (S/MIME) is the specification that makes it happen. Outlook, Mozilla Thunderbird, and Apple Mail are only few of the email applications that support S/MIME. To send someone encrypted email (with or without file attachments), you need to have access to his or her public key.

To obtain someone's public key, you can look up key data in an LDAP server, as long as that person uses LDAP to publish the key. Alternatively, you can ask the person to send you a digital signed message; typically, S/MIME-enabled email clients will attach a copy of the public key when delivering the signed message to you. Or, you could simply ask the person to send you a message with the public key attached. You can then store the public key in your key-management interface, which should be available in your email client. (Outlook integrates with the Certificate Store built into Windows.) The public key will then be readily available when you need to use it.

Identity-based Encryption
Voltage Security has developed a new technology called identity-based encryption (IBE), which is similar to PKI but with an interesting twist. IBE uses a private key to decrypt content, but instead of using a typical public key to encrypt content, IBE uses a person's email address as the public key. This way, no one need be concerned about obtaining a person's public key before sending him or her encrypted data. All you need is the person's email address.

With IBE, a recipient's private key is stored on a key server. The recipient authenticates to the key server and obtains the private key, which he or she then uses to decrypt the message content. IBE technology works with Outlook, Outlook Express, Lotus Notes, PocketPC, and Research in Motion (RIM) BlackBerry. According to Voltage Security, IBE also works with any browser-based email system on nearly any OS. With all this flexibility, Voltage Security's solutions might be just what you're looking for.

As it turns out, FrontBridge Technologies uses IBE to facilitate secure encrypted email exchange. As you might already know, Microsoft acquired FrontBridge in July 2005 and intends to eventually integrate FrontBridge solutions with Exchange, possibly offering the combined technologies as a managed service in the relatively near future. So, if you and your partners' email systems are based on Exchange, keep an eye on potential developments.

Careful Consideration
There are many ways to transfer files securely over the Internet, and by far the easiest and most effective way to do so is by email. Of course, if your needs dictate that you must transfer a large number of files, adding up to a large amount of data, you might consider a different method.

Think about how many files you need to send, how large those files are, how often you need to send those files, who needs access to them, and how they will be stored at their destination. All these factors will help you determine the best way to transfer files.

If email turns out to be your best choice, keep in mind that many email servers and email clients can run scripts or perform certain actions based on rules when email arrives. By using these features, you can help automate the movement of your files both en route through mail servers and upon arrival into a mailbox.

Mark Joseph Edwards (mark@ntshop .net) is a senior contributing editor for Windows IT Pro and writes the weekly email newsletter Security UPDATE (http://www.windowsitpro.com/email). He is a network engineer and the author of Internet Security with Windows NT (29th Street Press).