SwiftSend Versus PDF Email Attachments

Overview

Secure Socket Layer (SSL) is the security standard for financial industry web sites. There are good reasons for this: all techniques for sending discrete files (e.g., emailing attachments) are inherently less secure than SSL. SwiftSend complements SSL with a well-designed, robust architecture designed from the ground up for security. SwiftSend is readily available, supports virtually any document creation process, is cost-effective and is much easier to use than email-based systems. Using email with PDF attachments for document delivery simply does not meet the due-diligence requirements placed upon financial and other institutions by Federal law and regulation.

Among the security weaknesses of email-PDF systems:

• Email is far more available than SSL streams, making it much more vulnerable to security exploits. Email is passed from server to server at various locations on the Internet, at ISPs, and inside companies. Copies are retained on some servers and backed up on yet other systems or media. And recipients can easily forward emails to anyone or, by leaving their system unattended, make them easily accessible to others.
• Email's inherent lack of security places the burden on PDF/Acrobat security, which can be easily circumvented. Acrobat can create "protected" files but PDF security can be ignored by readily-available non-Acrobat PDF viewers.
• Acrobat encryption is vulnerable at several levels. Automated systems can be used to reliably encrypt PDF files but not all of the file is encrypted. Acrobat also lets users generate passwords, reducing users' productivity and making the entire process vulnerable to weak "human nature" practices.
• Acrobat's newest and best security is too hard to use. PKI certificates that make Acrobat/PDF genuinely secure exact a huge price in productivity and are simply not practical for typical users and applications.

SwiftSend uses industry standard SSL secure web access

SwiftSend uses an uninterrupted Secure Socket Layer (SSL) circuit from its server to the user's workstation. This is the technique used by all major financial institutions for their customer transactions and for many secure business-to-business financial systems as well.

SSL streams are not cached by the Internet or by proxy servers. The SSL stream can be obtained only by intercepting it at the time it is sent - and the key used to encrypt it is never used again. The keys used are negotiated between our server and the recipient's browser. As a result, it is difficult to intercept this data. Even if intercepted, the SSL encryption is extremely difficult to decode: 128 bit keys are used with modern browsers and those keys are changed with each transaction with our server (i.e. every time the user clicks to get a new document or a new screen). There is currently no practical way of breaking these keys and most industries consider this to be acceptable protection.

SwiftSend security controls how recipients access and view documents

When document senders select secure delivery, all recipients must log in to obtain their documents. The workgroup administrator for the company sending the documents can control this policy, ensuring that all recipients must log in. The workgroup administrator can also control both the length of time a recipient can stay logged in to SwiftSend and the length of inactivity before the system automatically logs the user out. The result is that unauthorized access to documents can be made very difficult, even when the user has left his system both accessible and unattended.

Email attachments are very easy to access

Email on the Internet works much differently than SSL. Email is a "store and forward" process: emails are saved temporarily on each of several interim email servers. Many company's email is processed through the servers of their ISP and is retained for some period of time on those servers. Those servers are not always managed securely and ISP employees have access to them.

Even when a company directly receives their own email, individual emails reside for some time on relatively insecure corporate email servers. When those servers are backed up, additional copies of all emails and their attachments are transferred to other systems and media.

Very few users make any effort to protect email on their desktop from prying eyes. Unlike SwiftSend, most companies have no central control of login policy for email access. Users often leave their desktops unattended with nothing but a click enabling someone else to access their email.

In practice, email attachments are much more readily available than an SSL stream can ever be. Files accessibility makes it possible to apply numerous security exploits to attachments, even when they are encrypted. These security exploits are continuously being improved and made available on the Internet.

PDF/Acrobat must provide all security because email is not secure

Since email provides no security and, even worse, makes access to the document attachments relatively easy, all document security must be provided by the PDF file and the Acrobat reader.

Basic Acrobat security is easy to circumvent

Adobe enables the Acrobat user to set "security options". However, all options except user password provide no security at all: Anyone with access to the file can view it using Ghostscript, Apple Max OS X Preview or XPDF, all of which ignore security options set in the file. It is also very easy to print the file with a PDF compatible printer or PDF-to-Postscript converter.

Password-encrypted PDF files are vulnerable, easy to "crack"

Adobe lets senders encrypt the PDF file and set a user password for decryption. Old versions (prior to Acrobat 5) use very weak encryptions (i.e., passwords are easy to crack). To obtain the proper 128-bit encryption all generation and viewing must use the most recent versions of Acrobat (5.0 and higher). Many, many users do not have the newest Acrobat Reader, and may be unwilling to download the 10+ MB file in the middle of a busy day.

Even current PDF files with 128-bit encryption are not fully encrypted. Strings and streams are encrypted, but none of the document structure is encoded. Also, using "font subsetting" exposes a great deal of information about the encrypted text. As a result, PDF files provide considerable information making it easier for the password to be decrypted.

Finally, unless a special security system is developed around the PDF creation process, the document creator sets the password and communicates it to the recipient. It is onerous for users to create unique, strong passwords for every user and every document, and secure the transmission of the password. As a result, users often fall prey to human nature, substantially compromising security. Here are some examples:

1. Users select very poor passwords, both too short and often using recognizable "words." Five totally random lower case characters can be brute-force cracked on a desktop PC in 1.5 hours, six characters in 1.5 days, seven characters in 38 days. If dictionary words are used in the password, these times can be dramatically reduced. These are actual numbers for the ElcomSoft PDF cracker (see references).
2. Users often email the password. Once selected, the password must be communicated to the recipient. The typical user will email the password, sometimes in the same email as the PDF attachment! Using email, even a separate email, to communicate passwords destroys security.
3. Users often re-use passwords. Users often use the same password with the same person over and over, or assign a password for a particular document and send it to many (or all) people. They may even randomly send "old" passwords to new users. All of these pose substantial risk for unauthorized document access.

Systems can be created which address these password selection issues. However, they rely upon sharing "secret information" between the sender and the recipient. For example, a recipient-dependent password could be automatically created from the social security number (SSN) and telephone number of the recipient. But SSN and similar facts are exactly the type of information that these systems are trying to protect!

SwiftSend's use of passwords is much more secure because they are applied to accounts, not to individual files, because each user selects their own password and because using email addresses for account names makes those accounts difficult to share. As a result, there is no recurring password selection problem and password sharing is difficult. Most importantly, it is hugely more time consuming to crack a website password than it is to crack the password encrypting a PDF file resident on the computer doing the cracking.

Public key infrastructure (PKI): secure, but unworkable in practice

Adobe calls the security features discussed above "Adobe Standard Security." Public key infrastructure (PKI) encryption is also available, called "Acrobat Self-Sign Security." PKI provides excellent security, but it entails setups and procedures that are both beyond the capabilities of most real users and which harm productivity by requiring substantial effort to maintain.

First, all document creators and recipients must install the Adobe Acrobat Reader 5 or later. Recipients then generate their own unique certificate, export it to a file and email it to each person sending them documents. It should be noted that normal PKI security authenticates the user by issuing a certificate from a formal Certificate Authority (CA). By circumventing this step, Acrobat pushes authentication entirely onto the users. The current certificate for each recipient must be added to each document creator's licensed Acrobat and selected whenever sending a document to that person. This means that a complete and current list of recipient certificates must be maintained on every PC sending encrypted documents. Each encrypted document must then be sent as an email attachment. This process is clearly both difficult and impractical for normal users. Real business processes, such as electronic transmission of mortgage closing packages, have many document creators and many document recipients at many locations. Document recipients constantly change as the employees at various title companies change. Document creators change as interest rates change. It is simply impractical to keep current certificates for all recipients on each document creator's desktop.

More importantly, the level of security provided by PKI remains a function of the fundamental security of the systems on which it runs. Security is particularly susceptible to how users' systems are managed. Given the opportunity, users will always choose options to "remember password", thereby making any email received on that system again viewable with a single click, even with PKI installed.

PKI is simply too difficult and time consuming in practice for normal users and normal business processes. This has prevented it from becoming the security standard for typical users in the financial or any other similar industry.

Conclusion

Federal law and regulation requires financial institutions to take the maximum practical and reasonable steps available to protect the private information of their customers. SwiftSend is much more secure than any practical system using emailed PDF files. SwiftSend is also readily available, quickly applied to virtually any document creation process, cost-effective and more easily used than email based systems. Emailing PDF attachments clearly does not meet the intent of Federal regulations. SwiftSend clearly does.

References:

http://www.pdfzone.com/news/101150.html
http://www.planetpdf.com/planetpdf/pdfs/pdf2k/02E/tmerz_pdfsecurity0602.pdf
http://www.adobe.com/epaper/tips/acr5secure/main.html