Security is always one of the top priorities considered in any business application, especially in the financial sector. Our recent project for a financial services client requires the ability to store and share business documents among end users in a web application. It is far from the simple access control with user authorization and authentication as used commonly in any content management systems (CMS). The ultimate solution needs to prove that the encrypted document can’t be viewed when downloaded by a genius hacker or a curious IT person who has Superuser access.
Still, it should be an easy-to-use approach for authorized users, who are normal business people with common experience of office applications. Obviously, the solution needs to consider at least three key features: Securely transmit the documents over the network, protecting against man-in-the-middle attacks. Encrypt the documents on the server with a strong cipher, which stops an unauthorized person getting to the sensitive information even if the encrypted documents should somehow be leaked. Share the cipher among end users safely, permitting authorized user access conveniently without need for special skills. Keeping the above requirements in mind, the architectural plan seeks to meet the challenges by using a couple of standards; compared to an ad-hoc solution, they are widely accepted, maturely implemented, and confidently proven as well as much more cost-effective for the client.
For the secure transmission, HTTPS, as a widely deployed secure communication protocol over the internet, provides a guarantee that the user can communicate with the server. It also ensures that the contents of communications between the user and site cannot be read or forged by any third party. It is a common feature in almost any browser and server with nearly no cost to use immediately. For the document encryption, we chose the Advanced Encryption Standard (AES), as used by the U.S. government (effected as a federal government standard on May 26, 2002) to protect classified information. It has many open implemented software libraries throughout the world to encrypt sensitive data. There are three common cipher key sizes, 128, 192 or 256 bits. Though 128 bits is quite sufficient, 256 bits is used to provide extremely strong protection considering the performance is still acceptable, with the business document’s size usually less than 10MB. Using a not so strict analogy, it takes 500 years to break a 128 bits key cipher text and 1,000,000,000 years to break a 256 bit one. The trickiest part is sharing.
A common scenario is user A (let’s call her Annie) uploads a document for user B (let’s call him Bob) to view. When Annie uploads a document, the server will encrypt it with a 256 bit cipher key. Bob needs the same cipher key to decrypt the document and view the sensitive information. However, he can’t simply store his cipher key in the database, because there is risk of access by an unauthorized person. Fortunately, we don’t need to reinvent the wheel here as well. Public-key cryptography addresses this in a standard way. Both Annie and Bob will have their own pair of digital keys: public and private. The public key could be disseminated widely; and the private key is protected by a password only known to the owner. Since anything encrypting with the public key could only be decrypted by the paired private key and vice versa, the keys pair achieves two functions: Something encrypted with Annie’s private key could only be decrypted by Annie’s public key, which means it authenticates that the encrypted stuff originated from Annie as the holder of the paired private key; Something encrypted with Bob’s public key ensures that only Bob, as the holder of the paired private key, can decrypt it.
So, Annie could encrypt the cipher key firstly with her own private key (requiring her password), then with Bob’s public key (known publicly). Next, the encrypted outcome could be shared with Bob in any open channel (in our case, stored in the database) with no worries of any unauthorized person accessing it. Only when Bob gets the encrypted outcome, could he start to decrypt it firstly with his own private key (need his password), then with Annie’s public key (known publicly) to get the original cipher key for viewing the business document from Annie properly. With the standards discussed above, we closed the circle of a confident solution to store and share business documents securely as well as providing easy-of-use experience. The end users only need to keep their passwords in mind as usual, with no extra burden. All the complexities are handled in the background and are hidden to them.
