| Once Upon a Time ... ... or, more specifically, 4 years ago, 15seconds.com published my article on sending secure e-mail from ASP applications using the certificate-based S/MIME standard (http://www.15seconds.com/issue/991217.htm). This is a sequel to that article, which I initially wanted to dub "Secure Mail Reloaded", but fearing vigilant copyright lawyers from Hollywood, eventually just added the dull "Part II" ending to the original title. The new article will describe an alternative approach to mail encryption based on Adobe PDF format. Speaking of Hollywood, if the movie industry is any guide, sequels can never be as good as the original creations. The S/MIME standard covered in my first article was the best one then and is still the best one now. However, it does have its limitations, which PDF-based secure mail successfully overcomes. So don't touch that Back button, keep on reading, and if you are truly a security freak like myself, you will be rewarded. Original Article's Summary Here is the contents of the original article in a nutshell. Scenario: you are an ASP developer hired to build an e-commerce application for a client. The client does not want real-time credit card processing. Instead, he wants to receive order information, including the credit card number collected from an SSL-protected HTML form, via email for manual processing. The catch: e-mail must be encrypted. A solution based on S/MIME was proposed. S/MIME is a de-facto standard invented by RSA Security which uses public-key infrastructure (PKI) and X.509 digital certificates. The idea behind it is to encrypt an e-mail message with the recipient's public key stored in a certificate. The corresponding private key is installed on the recipient's machine and used to decrypt the message. Even if the message is intercepted, no one else can decrypt it since only the recipient has the valid private key. The beauty of this approach is that all major e-mail packages such as Outlook, Outlook Express and Netscape Messenger have been S/MIME-enabled for many years now and are capable of decrypting such messages automatically, with no need to install additional software or plug-ins. 
Fig. 1. Outlook Express recognizes S/MIME messages and decrypts them automatically, provided the appropriate private key is installed on the user's machine. Back in 1999 when the original article was written, one had to use third-party ASP components to send e-mail in the S/MIME format. Nowadays, ASP.NET has much of the functionality to perform this task. Advantages and Disadvantages of S/MIME et's summarize S/MIME's strong points: - All major e-mail clients support it
- Decryption process is transparent to the user
- Requires no additional software or plug-ins
- Thanks to PKI, the sender and recipient do not need to agree upon a secret key or password. The user certificate does need to be placed on the server, but that's public information.
While an undisputed leader among secure mail standards, S/MIME does have its weaknesses and limitations: - To receive secure email, the recipient needs a certificate. Personal certificates are inexpensive but still not free, and require annual renewal.
- The recipient's choice of email software is limited to S/MIME-enabled packages. Browser-based email interfaces cannot be used.
- Email is transmitted securely, but once on the user's computer, it is accessible to anyone else who also has access to this computer.
- Once a secure message is decrypted and read, it can be copied or printed without limits.
Why PDF? Adobe Portable Document Format (PDF) has long been the de-facto standard for exchanging platform-independent, printable documents. This format is truly ubiquitous - virtually every document downloadable from the Web is a PDF. A copy of Acrobat Reader on your computer is as much a necessity nowadays as a browser or Microsoft Word. So here comes our novel idea: the e-commerce application that we described earlier will generate secure email in the PDF format instead of S/MIME. Such email will be based on passwords, as opposed to certificates, and free of all the shortcomings of S/MIME mentioned above. What makes PDF a great media for transporting secure mail? - PDF is printable - your document will come out the same no matter what printer or platform you print it on.
- PDF is platform-independent. Your email will never again look like gibberish due to encoding incompatibilities - all the fonts necessary to display the message are embedded in the document.
- PDF is free. Acrobat Reader, the most popular PDF viewer app out there is available from Adobe at no cost.
- PDF supports file attachments. A PDF document can contain binary embeddings of arbitrary size and contents (called File Attachment annotations) that can be extracted and saved to disk at a click of a button.
- And last, but not least, PDF is secure. That's really what makes this whole idea work. We will take a close look at PDF's security features next.
PDF Security Overview Security is built into PDF format in the form of password-based encryption, permission flags, and digital signatures. All of that is beneficial for secure mail, especially password protection. When a secure PDF is created, the document author supplies two secret strings: the Owner and User passwords. Applying these two passwords to the document using an algorithm described in Adobe PDF specifications produces a secure document. The author may optionally embed a set of permission flags in the document that would prevent a user from performing certain operations with the document, such as printing, copying/pasting, modifying and form filling. 
Fig. 2. Acrobat Reader grays out the Print button for this secure document (note the yellow key icon in the status bar). A secure PDF's content is encrypted with the RC4 algorithm, a stream cipher invented by Ron Rivest of RSA Security. Either a 40-bit or 128-bit key can be used. An encryption key is derived from the user password alone. The owner password is used to encrypt the user password and also to protect the immutability of the document's permission flags. An encrypted copy of the user password is embedded in a secure PDF for validation purposes. To open an encrypted document, the viewer must specify either the user or owner password. Specifying the valid user password enables a user to view the document, but also makes him subject to the permission flags associated with the document. For example, a user may not be able to modify or print the document. Specifying the valid owner password gives the user full control over the document: not only can he view it, but he can also change or remove its security settings. In addition to encryption and permission flags, PDF also allows a document to be digitally signed. A digital signature protects a document's integrity and provides proof of the signer's identity. PDF uses the same digital signature format, known as PKCS#7, as S/MIME, and it is also based on certificates. Digital signing of PDF documents is outside the scope of this article. Implementing PDF-Based Secure Mail Let's go back to our e-commerce ASP application. We can now put our hypothetical security-hungry client at ease and let him know that he does not need to obtain a personal certificate from Verisign after all. Isn't that a relief? Imagine having to explain to our middle-aged basket weaver-turned-entrepreneur what "digital certificates", "PKI" and "Verisign" are. The concept of a password, on the other hand, is understood by everyone. Since the new reincarnation of our secure email implementation is password-based, the sender and recipient do need to agree on a password. The best way to do it is probably by setting up a secure form on the Web where the client can specify and change his password online. The client's password is to be stored on the server (in a database, file, system registry, or otherwise) and used to encrypt PDF documents intended for the client. Whenever a secure message needs to be sent (per our scenario, this happens every time an online order is placed), our ASP application generates a secure PDF document containing order information including buyer's name, address, phone, and credit card number. The document is encrypted using the client's password and sent to the client as an attachment via email. Any mailing component can be used for that, such as CDONTS or AspEmail. Upon receipt of the message, the client opens the file attachment. Acrobat Reader comes up and prompts for a password. Once the password is entered, the PDF-packaged secure message can be read and the credit card charged. Note that the client is free to use any email software at all, and on any platform, including free Web-based email systems like hotmail.com -- a luxury the S/MIME approach could not afford him. As an additional amenity, the messages can be encrypted with two different passwords. One password allows the client to view the PDF document on screen only, the other gives him full control over the document, including printing and copying/pasting privileges. If only we knew how to generate PDF documents programmatically from ASP ... • Automatic Generation of PDF Documents >> |
