Home / NexProcure Enterprise / Secure Bid Process

Secure Bid Process

Compliance
  • Fully compliant with EU Directives 2004/17/EC and 2004/18/EC* and other applicable UK and EU legislation
  • Complies with Electronic Procurement norms of multilateral development banks; has been assessed by the World Bank and Asian Development Bank in Assam, Madhya Pradesh and Chhattisgarh
  • Complies with the Indian Information Technology Act, 2000, the CVC guidelines and the GFR
  • The system has been tested by Standardisation Testing and Quality Certification Directorate (STQC) of Ministry of Information Technology, Government of India
Note These Directives specify certain security requirements that the NexTenders patented Secure Bid Process matches absolutely in respect of integrity, traceability, and tamper-evidence and is based upon a ubiquitous security standard (PKI) to guarantee compliance.

Ensuring Tender Security

Secure Bid Process™ or SBP is patented technology developed by NexTenders that meets all security criteria for tendering and uniquely makes the electronic tendering process tamper-evident. It is the most secure bid security solution available in the market today. The solution actually replicates the “sealed box” and “sealed envelope” system of a physical tendering system in an electronic environment, and extends the same system to all three stages of the bidding process—bid preparation, bid submission and opening of the tenders. SBP implements Public Key Infrastructure (PKI) at its very core, as opposed to other solutions that implement PKI like a wrapper, making SBP inherently compliant with all the requirements of the Indian Information Technology Act and future-proof. However, what enables SBP to guarantee tamper-evidence in a bidding process is the inventive use of a technology that enables users to apply established algorithmic standards to data to create “hash values” of bid documents and bid data. Through the use of PKI, the system also ensures security of data during other stages of the tender process—Tender preparation, Bid preparation or Bid evaluation. Data remains encrypted with the user’s public key so it can only be viewed or modified using that user’s private key. Simply put, any number of fetches and modifications of data between server and browser involve three steps—get encrypted data from server, decrypt it with own private key, view or modify, encrypt it with one’s public key and send it back to server. This process can be repeated any number of times.

Preparing and submitting the bid fingerprint

Once bidders have prepared their bid, they need to submit their bid hash— the fingerprint of their bid document— to the system before a specified cut-off date and time. This is done by the automated application of an international standard hash algorithm to the bid data. Any submission of bid hashes after the cut-off time is automatically treated as invalid. The bid hash is also digitally signed by all bidders using their respective public keys. Thus, the authenticity of the bid hash cannot be questioned. After receiving all hashes, the tendering authority generates a hash of hashes, or a superhash, signs it and sends it to all bidders whose bid hashes have been submitted. The superhash is also digitally signed so that its authenticity can be verified. The superhash can be made publically available on the tender system portal.

Bid security after submission of tender

Once the bid hash submission process is completed, and after the bidders have received the superhash from the tendering authority, the bidders decrypt their bid data stored on the system server using their private keys. They then need to encrypt the data using the tender authority’s public key and submit the actual bid data to complete the submission process.

Matching bid fingerprints while opening the tender

The tender authority can now open the bids. As each bid is decrypted and opened using the tender authority’s private key, its bid hash called the “comparative hash” is also generated. Once all bids are opened and their comparative hashes generated, the “comparative superhash” is generated, which is automatically compared with the original superhash to ensure that no tampering has taken place. In case of a mismatch with the superhash, the system sends an alert to all the participants (the tender authority and the bidders). The system also allows the tender authority to determine the cause of tampering, including comparing individual bid hashes to isolate the tampered data. The process of superhash matching can be publicly shown to bidders or anyone else to prove the authenticity of one or all bids.
secure-bid-step1-icon
Bid Preparation & Hash Submission
Supplier encrypts and saves bid data with Public Key encrypt-key-icon
Supplier submit’s the bid hash signed with Private Key private-key-icon
secure-bid-step2-icon
Tender Locking
Buyer personnel generates the super-hash and signs with Private Key private-key-icon
secure-bid-step3-icon
Bid Re-encryption
Supplier re-encrypts bid data with buyer’s Public Key & submits it encrypt-key-icon
secure-bid-step4-icon
Bid Opening
Buyer personnel decrypts bid data with own Private Key private-key-icon
Time