KR19990087911A - a mechanism for secure tendering in an open electronic network - Google Patents

Abstract

According to the present invention a mechanism is provided for securing bids up to the closing of a bid for an electronic bidding system on an open network. In order for the bid to be fulfilled electronically in response to the announcement of the bid, potential vendors encrypt their bids using session keys obtained from a third party source. Encrypted bids are submitted by bidders who do not have access to session keys while the bidding period is open. Encrypted bids are stored in a secure repository until the close of the bid. In one embodiment, the bidder itself holds the encrypted bid and obtains session keys for accessing their contents from a third party at the end of the bid submission period. In another embodiment, the bidder may double-encrypt each encrypted bid when it receives it using a key held by him personally and send the double-encrypted bids to a third party to secure the repository until the end of the bid. Keep at. Next, the third party returns the double-encrypted bids together with the session keys to the bidder, allowing the bidder to access their contents. In another case, the party storing the bids by the end of the bid does not have access to the key required to decrypt the bid.

Description

Mechanism for secure tendering in an open electronic network

FIELD OF THE INVENTION The present invention generally relates to the field of computer networks, and more particularly, to a mechanism for providing secure public bidding in an electronic business environment.

Broadly speaking, an electronic business can be thought of as a kind of commerce, or part of a transaction, done through a computer network, a configuration of a data processing device, and software connected for information exchange.

Computer networks can be classified according to their degree of safety. In open networks such as the Internet, there is no intentional disruption to the free flow of information (limitations in network traffic and hardware can slow or even stop transmissions, but this is random and unintentional).

Extremely closed networks provide communication for a defined set of users on dedicated hardware without any external connection. Most networks used today by commercial entities such as businesses and governments have external communication links to the Internet, but special filtering software, commonly called "firewalls," allows internal files and databases to be exported from external users. Protect. The firewall software provided is strong enough to withstand "hacking" from external users so that users on an Internet network can securely access the Internet.

Businesses or governments extend their closed network connections to their trading partners (eg suppliers), allowing these parties limited access to their Internet network resources such as inventory databases, Inventory levels can be maintained.

Advances in computer hardware and software are increasingly making the Internet and other "open" networks an attractive place to run e-commerce. Unlike a closure system, no dedicated communication links are required and a potential larger "crowd" (customer, supplier, etc.) can be reached.

One area of significant development over the past few years is the area of protection against transmission or interference by so-called "hackers" or other third parties not intended as recipients. This is an absolute requirement for communications with commercial nature because they include the transfer of sensitive financial information from the customer's credit card number to the desired customer's pricing, or information requiring accuracy, such as ordering items and bids. to be.

In order to perform secure communication, authentication and encryption techniques are required. Authentication is proving to the network that the network entity (eg, network user or network client) is the real person required. Encryption prevents network entities from accessing confidential information that is not authorized to access.

Third party authentication is a method for securing communication between a client and a server on an open network. Well known as a trusted third party authentication protocol is the "Kerberos" model developed by MIT (eg, JGSteiner, BCNeuman, and JISchiller's "Kerberos: Authentication in Open Network Systems". Services, "USENIX Association Bulletin, 1998.2, pp191-202; and JTKohl," Development of Kerberos Certification Services, "European Association Bulletin, 1991.5, pp295-313). In this Kerberos model, for secure communication to a server, the client first authenticates itself and presents a nonce (non-recurring identity certificate) when the client requests proof for use with a particular server. By contact with the key distribution center (KDC). This KDC combines the response including the session key, nonce, and ticket. The ticket identifies the client, specifies the session key, fills in the start and expiration times for ticket use, and is encrypted by the KDC using a key shared with the server. The KDC returns the response back to the billing client, which decrypts the ticket, checks the nonce, and saves the ticket for later use. When a client wants to communicate with a server, it presents a ticket and a newly issued certificate to the server. Upon receipt, the server decrypts this ticket using a key shared with the KDC and uses the session key from the ticket to verify that the client's identity and timestamp are accepted.

Kerberos is a trusted third party protocol: R.M. Needham and M.D. Schroeder, "Use of Passwords for Authentication in Large Networks of Computers", ACM Communications, Vol. 21, Chapter 21, 1978.12, pp993-999; And R.M. Needham and M.D. Schroeder, "Leviated Certification", Operating System Review, Vol. 21, Chapter 1, 1987.1, based on the much earlier work of Needham-schroeder in pp7.

Communications are standard or nonstandard encryption algorithms, such as those defined in RC2 and RC4 developed by the Data Encryption Standard (DES), Triple DES, International Data Encryption Algorithm (IDEA), and RSA Data Security Company. It can be encrypted using either. These encryption algorithms are known as symmetric key encryption algorithms because both transmitting and receiving parties share the same encryption key. The encryption key must be communicated secretly between the sending and receiving parties, and this key must be kept secret. In relation to symmetric key encryption, there is key management that addresses issues such as how to create, distribute, store, and destroy keys. Key management can be particularly problematic when one client or server has millions of operators. The distribution and management of symmetric encryption keys may be a nightmare. The invention of the public key crypto-system has solved this problem. Public key crypto-systems are also known as asymmetric key systems because cryptographic keys are different from decryption keys. In a public key crypto-system, there is a pair of keys, one known as the public key and the other a private key. The public key is made public like its name, so anyone who wants to access it can access it. The private key is kept secret. If A wants to encrypt the data and send it to B, A first finds B's public key and uses it to encrypt the data, and then sends the encrypted data to B. B can decrypt the encrypted data using its private key. Since only B knows his private key, no one else can decrypt the encrypted data. Thus, the confidentiality of the data is well maintained. Current encryption and decryption of public keys are not as effective as symmetric key encryption, and the general approach is to create a symmetric key known as the session key to encrypt the data and to use the receiving party's public key to encrypt the session key. After receiving the encrypted session key and encrypted data, the receiving party first decrypts the encrypted session key using its private key. Next, the encrypted data is decrypted using the session key. In order to deploy a public key system, a public key infrastructure (PKI) is required, which allows communication parties to register themselves, contains a public key and is known as a certificate authority (CA). Enables you to obtain proof of those and others that have been verified by the public key issuer.

In order to conduct electronic transactions on an open network, secure payment is required. Secure payment deals with the potential millions of customers who purchase goods on the Internet. There are other secure payment protocols that have been developed over the years. For example, IBM has developed a secure payment protocol called the Internet Keyed Payment Protocol (iKP), which handles a set of payment mechanisms such as clearing electronic checks as well as credit and payment card transactions. Based on iKP, Visa and Mastercard are a way to protect payment card transactions on the Internet, with the help of IBM, GTE, Microsoft, Netscape, SAIC, Terisa, and Verisign. A secure payment protocol known as Secure Electronic Transaction (SET) has been developed. Microsoft and Visa International have also developed the so-called Secure Transaction Technology (STT) to process secure payments with bank cards on the Internet.

International application WO97 / 415 for Verifone, Inc., "Systems and Methods for Secure Network Electronic Payments and Credit Card Collection," without first establishing a public key cryptographic infrastructure for use by customers. , Permitting the immediate development of architectures such as security payment technology and SET architecture. The system set up in this WO97 / 415 includes three parties, a customer, a merchant, and a payment gateway, and relies heavily on Secure Sockets Layer (SSL) to conduct communications and negotiations between the parties. Once the PKI is established, it will appear that the system presented in WO97 / 415 is no longer required.

With improved safety, the Internet has become a more reliable and acceptable transmission medium for all types of commercial transactions.

In response to requests for bids, using an open network to submit bids is a natural extension of e-commerce, especially where safety measures such as encryption, third party authentication, and PKI are already available. . Electronic announcements of bids generally do not differ from traditional forms; A non-extensible submission deadline is set for receipt of a sealed bid and only bids received by the deadline are considered.

However, a problem that arises in e-bidding that does not exist in other areas of e-commerce is the requirement that the bidding process be justified, especially where public money is involved (i.e. in bids from governments or other public entities). Notice) Yes. Where traditional non-electronic bidding methods are used, bids received are not immediately disclosed, but are often stored in a secure place (locked box) with a trusted third party, such as an accounting firm, so that bid submission times are Open after closing.

The need for electronic procurement is to provide a secure environment similar to a "locked box" for the receipt of electronic bids, which, if desired, can be trusted by third parties. The locked information cannot be accessed by the third party or the party requesting the bid, at least until the bid expiration time has expired.

Accordingly, one object of the present invention is to provide a secure public bidding in the electronic procurement area.

It is also an object of the present invention to provide a secure open bidding protocol that does not require a third party holding a bid to be a trusted third party.

Another object of the present invention,

1. The party requesting the bid (eg government air exhibition) may not see the contents of the bid until the bid is closed;

2. The third party holding the submitted bid shall not see the bids in all cases other than the trusted third party;

3. To provide an electronic bidding system where no vendor can see the contents of any other vendor's bid.

1 is a schematic diagram illustrating a typical open bidding situation in an electronic environment;

2 is a flow chart illustrating a process for third party authentication in a secure public bidding system in accordance with a preferred embodiment of the present invention;

FIG. 3A is a flow diagram subsequent to FIG. 2 showing one processor for securely storing a bid received in a bid process until expiration of the bid submission expiration time, in accordance with an aspect of the present invention; FIG.

FIG. 3B is a flow chart similar to FIG. 3A illustrating another process for securely storing bids received until expiration of the bid submission expiration time, in accordance with another aspect of the present invention.

In accordance with the above and other objects, the present invention provides a lock box mechanism for securely storing electronic bids submitted by vendors during open bid on a network. The mechanism is: (i) shared only between the vendor and the third party certifier during open auction, which is used by the vendor to transform the bid into an inaccessible form before submitting the bid to the bidder. A first cryptographic key, (ii) means subsequently held by the bidder to make the bid inaccessible to third party authenticators following submission by the vendor, and (iii) public bidding. It consists of an electronic repository for storing bids submitted until expiration. According to one aspect, while the third party authenticator does not have access to the electronic repository, the bidder accesses the electronic repository directly, and preferably, the bidder notifies the third party authenticator of receipt of the bids. According to another aspect, the third party authenticator accesses the electronic repository and the bidder does not. Next, the bidder preferably double encrypts the bids he receives using his privately held encryption key and sends the double-encrypted bids to a third party authenticator for storage.

The present invention also provides a method for providing secure electronic bidding in an open network. In terms of bidders, the method includes the steps of: publishing an announcement for bidding an electronic bid (which includes requiring encryption of bids prior to submission, using cryptographic keys generated from a particular authentication source), Accepting encrypted bids and making their contents inaccessible to a specific authentication source; and when the bid is closed, obtaining a cryptographic key from the specific authentication source to access the bids. In terms of a third party authenticator, the method involves generating a cryptographic key to the vendor to encrypt a bid submitted by the vendor to the bidder in response to the request, the seller cryptographic key until the expiration of the public auction is notified. Managing the; and upon expiration of the public auction, transmitting an encryption key to the bidder.

Next, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

As shown in FIG. 1, the three parties involved in a secure public bidding process in accordance with a preferred embodiment of the present invention, a vendor 100 wishing to be a supplier, a bidder 102 such as a government company, and a third party There is an authenticator 104.

The present invention is directed to a system for which a party element supporting network / internet access and message digests, ciphers, and digital signature techniques are provided to ensure preservation, privacy, authentication, and non-denial of communication between the parties. It is not limited to any particular kind of hardware and software support.

For example, a commercial bidding system for a large organization, filed with the Canadian Patent Office on January 30, 1998, filed under application number 2,228,331, entitled "Token-based Deadline Information System for Electronic Document Submission," No. CA998-003). In this system, the primary customer server running under the Microsoft Windows NT ^R operating system collects purchase requests from within the organization requesting bidding and behind a gateway with a firewall that protects the network within the organization from external networks. The requests are stored on a document information gateway operating under the IBM RS / 6000 ^R operating system. Communication with suppliers and third party authenticators is automatically received from the network to establish a secure structure before sending the message to the provider on the network, and to transmit plain messages to other components on the internal network in progress. This is handled by safety software that unpacks the safety structure. The primary purchase server publishes announcements of bids on the bid board, including software that can notify external parties (ie, potential suppliers / vendors) of the request for bidding. Vendors submit bids for the system using submission software that runs on PC operating systems with network / internet access, such as IBM OS / 2 ^R Warp and Microsoft Windows ^R 95. Third-party authenticators have similar support.

Referring back to FIG. 1, the bid requester issues a notification about a bid that presents a request for bidding (step 1). One requirement for publication is the time frame in which the bidding process remains open and a bid can be submitted. In addition, in a preferred embodiment, the announcement of bidding includes the conditions under which potential vendors / bidders obtain an application confirmation (discussed below) before submitting a planned bid. This application acknowledgment carries a secret cryptographic key that the vendor uses to encrypt the bid before submission.

Thus, in response to the bid requester 102 issuing a bid notice (step 1), the vendor 100 responds by indicating its intention to submit a bid and request certification to do so (step 2). The bidder 102 sends each certification request to the third party certifier 104 (step 3), and the authenticator then re-provides each vendor's certificate directly to the vendor 100 (step 4). ), Or indirectly through the bid requestor (not shown). Vendors 100 may then use their certification to submit their bids to bidder 102 (step 5). These bids are maintained in the bid cache 106 and may be located either on the bidder 102 or on the third party 104 until the close of the bid. However, neither the bidder 102 nor the third party 104 will have enough information to view the contents of the stored bids, and no vendor has access to the contents of any other vendor's bid submission. After the bid submission deadline has passed and all bids have been received in the cache 106, the third party 104 sends the information on the bid to the bidder 102, which, if the third party is the owner of the cache, encrypts it. A bid may be configured (step 7), the bid requester 102 making all bids open, and a successful bid selected (step 8).

The secure public bidding protocol of the preferred embodiment of the present invention is based on a public key infrastructure (PKI), where each party involved in the public bid is placed in a public key repository such as an X.500 directory or a public key database. It has a stored public encryption key and a digital signature key. These keys are authenticated by Certificate Authority (CA).

This safety public bidding environment can be implemented by the following process shown in FIGS. 2 and 3A, 3B.

Referring first to FIG. 2, a bidder (eg, a government agency) publishes a notice of bidding by any conventional means (block 200). This may include advertising through non-electronic media such as newspapers, advertising through electronic media such as websites, and notifying known providers directly via electronic or non-electronic means.

Vendors wishing to respond to the announcement for bidding first request the bidder to request a bid certificate (bid ID) by electronically sending a REQUEST_ID message to the bidder (block 202). This message includes the date and the vendor's digital signature.

Upon receipt of the vendor's REQUEST_ID message, the bidder attempts to verify the vendor's digital signature and date information (block 204). Failure to do so returns an error message to the vendor (block 206). Once the signature and date are verified, the bidder registers the vendor by generating a bid certificate (block 208), which is sent to a third party authenticator requesting the session key used to encrypt the vendor's bid (block 210). The vendor's session key is a secret shared between the vendor and a third party until the bid submission deadline has passed and the bid is closed.

Upon receiving the message of the bid requesting the vendor's session key, the third party first verifies the bidder's digital signature and date information (block 212, otherwise go to block 214 and an error message is returned to the bidder). After this verification, the third party generates the requested vendor's session key (block 216) and encrypts it using the vendor's public encryption key (block 218). The third party returns the encrypted session key to the vendor with a REGISTERED_ID message, which also includes the third party's date information and digital signature. If the third party accesses the vendor directly, the REGISTERED_ID message is sent directly to the vendor (blocks 220, 226). If the third party does not access the vendor directly, the REGISTERED_ID message must return to the bid requestor (blocks 220, 222), and then send this message to the vendor (block 224).

The vendor receives the REGISTERED_ID message generated to obtain the bid confirmation certificate and verifies the digital signature and date information. If the message is from a third party directly (block 230), this verification is only for the third party's signature and date information (block 232, otherwise go to block 234 and return the error message to the third party). On the other hand, if sent by the requester (block 224), both the third party and the requestor's signatures and date information will be verified (block 226, otherwise go to block 238 and return an error message to the bidder). If the signature (s) and date information are verified, the vendor decrypts the encrypted session key originally provided by the third party by using its public key (block 236). The vendor generates a bid or bid that is inserted into the bid confirmation (block 238) and encrypts the bid using the session key (block 240). The encrypted bid message is dated and digitally signed by the vendor, returned to the bidder, and upon receipt, first verify this date and signature information (block 242, otherwise go to block 244, error message). Back to the vendor). Since the bidder does not have a session key, the vendor's bid cannot be read at this time.

3A and 3B illustrate another method for protecting bids in an electronic “lock box” until the bid submission deadline expires when all bids are published together.

First, referring to FIG. 3A, after verifying the date included in the bid message and the digital signature of the vendor, the bidder generates a separate session key called the claimant session key and encrypts the bid again. The requestor's session key is not shared with others and will be kept secret by the bidder himself. Messages containing double-encrypted bids are dated and digitally signed by the bidder, verifying the date and the digital signature of the bidder (block 302, otherwise go to block 304 and return an error message to the bidder. Transmit to a third party (block 300). In a preferred embodiment, after verifying the date and digital signature included in the double encrypted bid message, the third party sends proof of the bid acceptance to the vendor. It should be noted that other systems may be employed to send a direct receipt from the bidder to the vendor, and to notify the vendor of receipt of the appropriate bid. The token-based system of obtaining a time-sensitive token to attach a bid before a vendor submits a bid is the subject of an IBM application regarding the above-mentioned "Token-based Deadline Inflation System for Electronic Document Submission". to be.

Once the bidder's signature and date information is verified (block 302), the third party stores the bid in a secure repository or cache until the bid deadline date (block 308).

If the deadline for submitting bids expires, the bidder generates an ACCESS_REQUEST message (block 310), which is sent to a third party to request that bids be delivered. The third party encrypts the vendor's session key using the bidder's public encryption key (block 312) and attaches the encrypted session key to the double-encrypted bid (block 314). The ACCESS_GRANTED message with the encrypted session key attached to the double-encrypted bid is dated and digitally signed by a third party and returned to the bidder (block 316).

After verifying the date and the third party signature (block 318, otherwise go to block 320, returning the error message to the third party), the bidder can use the private key of his or her own, and only by the vendor and the third party. Decrypt the session key of the vendor that was shared and was encrypted by the third party using the bidder's public key (as discussed in connection with block 312) (block 322). The bidder then decodes the vendor's bid using the decrypted vendor's session key along with its secret session key (block 324).

The system can be used whether or not the third party holding the bid until the expiration of the submission deadline is a trusted third party.

Another protocol can be derived from the secure public bidding protocol described above, where only one cipher is used in addition to the double cipher. The third party may still be trusted or not trusted.

This alternative method is illustrated in FIG. 3B.

After verifying the date and the digital signature included in the bid message developed following the method of FIG. (Block 350). The bidder digitally signs the PROPOSAL_RECEIVED message, sends it to a third party (block 354), and stores the encrypted bid in its cache (block 352). It should be noted that the bidder does not actually send a copy of the encrypted bid, to a third party that holds the vendor's session key to decrypt the bid. Thus, the third party does not have access to the encrypted bid despite sharing the cryptographic key with the vendor.

After verifying the date and digital signature included in the PROPOSAL_RECEIVED message (block 356, otherwise go to block 358 and send an error message to the bidder), the third party sends evidence of the bid acceptance to the vendor (block 360), For non-repudiation, the PROPOSAL_RECEIVED message is kept in a secure repository (block 362).

After the expiration of the bid submission date, the bid requester sends a KEY_REQUEST message to the third party and requests the vendor's session key to access the vendor's encrypted application (block 364). The third party encrypts the session key shared between itself and the vendor by using the bidder's public encryption key (block 366). A KEY_GRANTED message containing an encrypted session key and a third party's digital signature is sent to the bidder (block 368).

After verifying the date and third-party signature in the KEY_GRANTED message (block 370, otherwise go to block 372 and return the error message to the third party), the bidder transfers only by the vendor and the third party using his private key. Decrypt the session key of the encrypted vendor that was shared at (as discussed in block 366). The bidder then decodes the vendor's bid using the decrypted vendor's session key (block 376).

Embodiments of the invention which are apparent to those skilled in the art are considered to be within the scope of the appended claims.

The configuration of the present invention can provide a mechanism for secure bidding that cannot be accessed by a third party or a party requesting a bid until the expiration time of the electronic bid in the open network expires.

Claims (10)

In a lock box mechanism for securely storing electronic bids submitted by vendors during open bid on a network, A first cryptographic key shared only between the vendor and a third party certifier during the open auction and used by the vendor to transform the bid to an inaccessible form before submitting the bid to the bid requester; Means privately held by the bidder for the bidder to be inaccessible by a third party following submission by the vendor; And An electronic repository for storing the submitted bids until expiration of the open auction. Lock box mechanism. The method of claim 1, Means held personally by the bidder for the purpose of ensuring that the bid is inaccessible by a third party certifier following submission by the vendor, Direct access to an electronic repository for storage and retrieval of bids; And Means for informing a third party certifier of receipt and storage of the bid; The third party authenticator is not authorized to access the electronic repository. Lock box mechanism. The method of claim 2, Upon expiration of the open tender, further comprising means held by the bid requester to retrieve a bid from the electronic repository and to obtain a first cryptographic key from a third party authenticator. Lock box mechanism. The method of claim 1, Means held personally by the bidder for the purpose of ensuring that the bid is inaccessible by a third party certifier following submission by the vendor, A second cryptographic key privately held by the bidder for encrypting the modified bid submitted by the vendor; And Means for sending the double encrypted bid to a third party certifier for storage until expiration of the open bid; The third party certifier has access to the electronic repository for the storage and retrieval of bids. Lock box mechanism. The method of claim 4, wherein Retrieve the double encrypted bid from the electronic repository, attach the first cryptographic key to the double encrypted bid, form a message, and upon expiration of the public auction, send the message to a bid requester Further comprising means held by a third party certifier Lock box mechanism. In a method executed by a bidding party to provide secure electronic bidding in an open network, Publishing an announcement for bidding electronic bids, the announcement including a requirement to encrypt bids prior to submission using cryptographic keys generated from a particular authentication source; Accepting encrypted bids and making their contents inaccessible to the specific authentication sources; And At the close of bidding, obtaining cryptographic keys from the particular authentication source to access bids Way. The method of claim 6, The step of making the contents of the bids inaccessible to a specific authentication source, Storing the encrypted bids; And Notifying the received bids to a specific authentication source. Way. The method of claim 6, The step of making the contents of the bids inaccessible to a specific authentication source, Double encrypting the bids received using a private cryptographic key unknown to the particular authentication source; And Sending the double encrypted bids to the particular authenticator for archiving; Obtaining a cryptographic key from the particular authentication source to access the bids at the closing includes obtaining dually encrypted bids with the cryptographic keys from the particular authentication source. Way. In the method performed by the authenticator to provide stability in the open bidding method disclosed by the bidder, In response to the request, generating an encryption key to the vendor to encrypt the bid submitted by the vendor to the bidder; Maintaining a cryptographic key secret of the vendor until notification of a public bid expiration; And Upon expiration of the public auction, transmitting the cryptographic key to a bidder. Way. The method of claim 9, Storing a bid received from the bid requestor, wherein the bid is encrypted twice with a key generated by the vendor and the bidder's personal encryption key; And Upon expiration of the open auction, returning a bid attached to the vendor cryptographic key to a bid requester. Way.