eTender Bid Encryption: Assurance for the Paranoid Contractor

I thought it was important to write this post in order to clear up some common misconceptions which may exist relating to the ContractComplete bid encryption system.  When we were designing ContractComplete, we knew that security and privacy would be among our clients’ top priorities in selecting an eTendering system.  Contractors, concerned about nepotism and tampering, often submit their bid at the last possible moment.  This can obviously lead to costly mistakes and other frustrations.

We then came to the disheartening conclusion that eTendering itself does not actually solve this problem.  Technically, what’s to prevent a contractor from bribing a ContractComplete engineer to disclose information on a competitor’s bid?  The answer, aside from the unwavering moral compass possessed by all ContractComplete employees, was bid encryption: the perfect alternative for the paranoid contractor.

“In ContractComplete, non-encrypted does not mean insecure.”

Rather than directly explaining what bid encryption is, it may be clearer for me to first explain what it is not.  ContractComplete uses the SSL protocol for client-server communication, which, like any other website, is indicated to you by the use of https://  in the URL and the green “Secure” padlock icon in your browser’s navigation bar.  SSL automatically encrypts all traffic between your internet browser and our servers, regardless of whether or not you’ve selected “I want my bid encrypted”.  Not encrypted, therefore does not mean insecure!  It simply means that your bid is stored in plain text format in our database.  The ContractComplete database is only accessible by a limited number of ContractComplete engineers working at specific IP addresses who possess a specific access key which authorizes them.  For all of these reasons, we decided that bid encryption could safely be made optional instead of mandatory, because as I will discuss later, there are some negative consequences.

In designing ContractComplete’s encryption system, we had several goals in mind for encrypted bids:

1. 1. Our server should never have access to read values (line item pricing, documents, etc) at any point during the tendering process

1. 1. Encryption should be unbreakable, even by those who understand our specific implementation details

1. 1. Encrypted bids must be accessible to the contractor on multiple computers

1. Encrypted bids must be unlockable by consultants at the moment of tender closing

Implementation

Typically, encryption requires a “key”.  A key acts as a variant on a basic encryption algorithm.  Take for example a primitive ancestor to modern encryption algorithms known as a Caesar Cipher, in which the sender of a message replaces each letter in the text with the next letter alphabetically.  HELLO becomes IFMMP.  The recipient, knowing the cipher applies the reverse procedure to decrypt the message.  This algorithm is obviously weak and obsolete, but can be made slightly stronger by incrementing the letters not by one, but by a random number, which is sent to the recipient separately from the message itself.  That random number is analogous to a modern day encryption key because it increases the possibilities for the decrypted message from 1 to 26.  Still not great, but a modern encryption algorithm has trillions of possibilities through the use of encryption keys.

Back in ContractComplete’s offices, we were wondering how this key would work.  Clearly, if the key were generated on our servers, it would violate goal #1 (because our server would have the capability to read the bid) and possibly #2 (because again, the server has the key and malicious code could intercept the bid on its way to the database).  It eventually became obvious that the key should be selected by the contractor and given to the consultant by the contractor around the time of tender closing.  The key should be stored only by the contractor until the time of tender close.

How then, the astute reader may ask, is it true that both a) ContractComplete does not store my key on its servers, and b) I don’t have to type my key in each time I start a new browser session?  Well, astute reader, do you remember  cookies?  Those things your parents were terrified of in the 1990s?  No, they don’t actually give you viruses.  And they weren’t invented to allow the government to spy on you.  They’re just a way for websites to store simple pieces of text on your computer between visits.  These are often configurations or other pieces of information to improve your experience on the next visit.  ContractComplete uses one of the many modern local storage options to keep your key on your computer for use later. Similarly, contractors provide their bid keys to the tendering authority (or consultant) around the time of the deadline, allowing the consultants to decrypt the bids for tender review.

As with any design, there are trade-offs involved.  Some of which include, in the case of encrypted bids, the following:

• • Calculations (totaling, bid completion %, etc) are offloaded to your browser.  We can’t pre-calculate these values on our server because we don’t have access to your bid.  In theory this could cause a mild performance impact for particularly large contracts.

• • We cannot help you recover your bid key should you lose it.  This would violate our original goals.  The best we can do is delete your bid, allowing you to pick a new key and re-enter your pricing.  There are also limits to our ability to provide support if something goes wrong because we obviously can’t read much of what you’ve submitted.

• Internet explorer is not supported (for both encrypted and non-encrypted bids).  The ContractComplete browser experience, as are most other websites, is powered by a programming language called JavaScript which is interpreted in real-time by your internet browser during your time on our website.  It is absolutely essential for most modern websites and provides the basis for managing data, popups, and dynamic network requests.  Unfortunately, because JavaScript is interpreted by each specific browser, there are often slight differences in the way JavaScript functions in the various browsers.  These variances prevent us from supporting Internet Explorer and certain older browsers; the JavaScript engines of which may be missing certain features that ContractComplete requires.

Still unconvinced?  Good.

A great story about security such as this one may ease some minds, but a story alone means nothing if it isn’t verifiable.  The good news is there is an easy experiment you can do to see bid encryption in action.  All modern browsers have tools which allow web developers to see what exactly they’re sending to the server.  The way these tools are accessed may vary slightly from browser to browser, but at least for Google Chrome and Firefox on Windows, you can access them by simply pressing F12, then selecting the “Network” tab in the popup panel.  When you save your bid, or when your bid auto-saves, ContractComplete will send a network request to our servers, and you can actually see what’s being sent!

So it is indeed provable that in the case of encrypted bids, we are sending to the server something that appears to be encrypted.  How do you know this isn’t just another Caesar Cipher?  Well, you can certainly try breaking the encryption on your own.  But unfortunately, if you aren’t a cryptography expert you may just have to trust us on that.