Abstract
With the rapid development of the Internet, electronic commerce has become more and more popular. As an important element of e-commerce, many Internet companies such as Yahoo! and eBay have launched electronic auction systems. However, like most electronic commerce products, safety is an important issue that should be addressed. Many researchers have proposed secure electronic auction mechanisms, but we found that some of them do not exhibit the property of unlinkability, which leads to the leakage of users’ privacy. Considering the importance of privacy preservation, we have designed a new auction mechanism. Through symmetrical key establishment in the registration phase, all messages transmitted over the Internet would be protected and, meanwhile, achieve the property of unlinkability. The security analysis and performance analysis show that our protocol fulfills more security properties and is more efficient for implementation compared with recent works.
1. Introduction
With the development of network technology, more and more people are searching for information on the Internet. In 2013, the number of Internet users of the whole world reached 2.92 billion [1]. Now, people not only read the news and search for information on the Internet but also do business with others. Not surprisingly, e-commerce has grown rapidly in recent decades. As the founder and CEO of China’s most famous e-commerce company Alibaba, Jack Ma was ranked as the second richest man in China in 2014. Many famous Internet companies launched electronic auction products several years ago such as Yahoo! and eBay. On these websites, users can play the role of not only auctioneer but also bidder after they register their accounts successfully. They can participate in the auction anytime and anywhere when their devices have access to the Internet.
Auctions can be classified into many types [2]. According to numbers of sellers and buyers, auctions can be classified as forward auctions and reverse auctions; according to the determinant of the winner, auctions can be classified as single attribute auctions and multiattribute auctions; and according to whether the bidding price is made open, we can classify auctions as sealed-bid auctions and open auctions. The sealed-bid auctions can be subdivided into sealed-bid first-price auctions and sealed-bid second-price auctions. In the first mode, all bidders submit their sealed bids to the auctioneer of an auction at the same time, and the auctioneer or arbiter of the auction secretly calculates the highest price. After that, the auctioneer or arbiter announces the winner as the owner with the highest price bid. In a sealed-bid second-price auction (also called Vickrey auction), the highest price bidder wins the auction but only needs to pay the second highest price. The designer of the sealed-bid second price auction thinks that everyone will submit their bidding price rationally in this mode; however, this method confronts a lot of problems in practice, such as bidder collusion. Open auctions can be further classified into English auctions and Dutch auctions. In an English auction, the auctioneer changes the current price dynamically, with the bidding price increasing. This means that, if one bidder’s bid price is higher than the current price, then the auctioneer uses this price as the new current price and waits for someone to offer a higher price than the current price. If someone submits a higher price, the current price is changed simultaneously; if no one offers a higher price when the auction is closed, the owner of the current price bid wins the auction. A Dutch auction is bidding process contrary to the English auction. In a Dutch auction, the auctioneer decreases the current price until one bidder can afford it and is the winner of the auction.
A lot of problems arise when we introduce the auction process in reality on the Internet. An important issue is the information security of the system. As an Internet product is connected with money and goods, users are concerned with the safety of the online auction. Many researchers have proposed their protocols to solve security problems in auction systems. In 1999, based on millionaires’ problem, Cachin [3] proposed a private bidding and auction scheme with an oblivious third party. In 2000, Nguyen and Traoré [4] used a group signature to protect bidders’ anonymity. However, the huge computational cost and the special authority of group managers still cannot be resolved. In 2001, Omote and Miyaji [5] applied a bulletin board to overcome these problems, but their scheme does not publish the winner’s information at the end. In 2003, C.-C. Chang and Y.-F. Chang [6] proposed an anonymous English auction protocol to ensure that bidders can bid arbitrarily. In 2005, Jiang et al. [7] considered that the scheme in [6] cannot protect against man-in-the-middle attacks. In 2006, Y.-F. Chang and C.-C. Chang [8] proposed another anonymous auction scheme to resolve the problem in [6]. In 2005, Suzuki and Yokoo proposed safety problem in the multiattribute auction systems [9]. In 2007, Shih et al. proposed a privacy preserving multi-item auction mechanism with a shared key chain [10]. In 2008, Parkes et al. used a homomorphic cryptograph to achieve bid privacy in multi-item auction [11]. In 2009, Xiong et al. [12] proposed an anonymous auction scheme based on the ring signature. However, like the group signature-based protocol in [4], huge computational cost is an essential problem that should be resolved. In 2012, Xiong et al. [13] proposed another protocol based on revocable ring signature to solve the problem of high computational cost in [12] and added a dispute section.
In 2013, Chang et al. [14] pointed out that [13] is vulnerable to denial of service attacks and designed an ECC-based protocol which provides a secure on-shelf phase. Unfortunately, we found that Chang et al.’s proposal [14] does not provide unlinkability. In [14], users’ privacy can be leaked by monitoring the communication of system and linking the captured information. Although some important data such as public key and certificate are encrypted before transmission, unencrypted messages such as on-shelf information can link different packets together. For example, in the on-shelf phase, although attackers cannot calculate the true public key of the auctioneer using an encrypted message transmitted from the auctioneer and the published anonymous public key on website, attackers still can link transmitted packets and website information together through on-shelf information. This is because the on-shelf information is transmitted in plaintext. On the other hand, bidders’ privacy is in more serious danger during the bidding phase. At the end of the bidding phase, the agent center (AC) publishes the information with the bidder’s true public key on its website. Attackers can link this public key with a certain IP address and know what the user bids on. Then, attackers can trace this public key owner’s transaction history.
Until now, many researchers have stressed the importance of privacy preservation in online auctions [15–17]. Hence, in order to overcome the privacy problem in [14], in this paper, we provide a new English auction system with privacy preservation. The overview of the auction system architecture is shown in Figure 1. Using the same system mode with Chang et al.’s proposal [14], our system has 5 phases: the registration phase, on-shelf phase, bidding phase, product-claim phase, and dispute phase. We utilize a trusted third party as the AC of our system, a well-meaning role that will not initiate attacks. However, the safety of the AC’s database cannot be completely guaranteed. We do not consider the case of hackers controlling the AC, but hackers may get access to read data in the AC. The only data we consider to be completely safe is the private key of AC. Besides this, any leaked data cannot do serious harm to the safety of the whole system. In addition, we built our protocol on Elliptic Curve Cryptosystem. According to the analysis in Section 8, our proposal has an efficiency advantage over the original proposal. In our scheme, messages transmitted between any two entities are encrypted with a symmetrical encryption algorithm such as AES. By utilizing this method, monitors cannot link different messages together. Security analysis shows that our proposal provides more security properties than the original one.
The rest of this paper is organized as follows. In Section 2, we introduce the Elliptic Curve Cryptosystem and ECDLP (elliptic curve discrete logarithm problem). Subsequently, we briefly review Chang et al.’s auction protocol [14] in Section 3. In Section 4, we talk about network model, adversary model, and properties that an auction mechanism needed. We describe our proposal in detail and use BAN logic to analyze authentication accuracy of on-shelf phase and bidding phase in Sections 5 and 6, respectively. In Sections 7 and 8, we compare the security and efficiency of our protocol with related schemes.
2. Preliminaries
In this part, we introduce some basic ideas of Elliptic Curve Cryptosystem including the definition of elliptic curve, basic operations on the Elliptic Curve, and ECDLP on ECC that can be used to construct cryptographic algorithms.
2.1. Elliptic Curve Cryptosystem
Elliptic Curve Cryptosystem (ECC) is an asymmetrical cryptosystem. It was independently proposed by Miller [19] and Koblitz [20] in 1985 and 1987. Compared to RSA, ECC can achieve the same security requirement with a shorter key-length [21]. Hence, it has been widely used in many cryptographic schemes recently.
An elliptic curve [22, 23] is defined over a finite field by equation , where is a large prime and . The points on this elliptic curve form a cyclic group. Addition in this group is defined as if points on one line, and then ( is infinite point). Given an integer and a point , the multiplication operation over is defined as in times. If is symmetrical with on the -axis, then . Furthermore, point is a base point with an order if and only if .
2.2. ECDLP
Every cryptosystem has its own difficult problem, such as the integer factorization used in RSA. The most important difficult problem in ECC is the elliptic curve discrete logarithm problem (ECDLP) [24]. Based on ECDLP, we can develop many other difficult problems, such as the computational Diffie-Hellman problem (CDLP) and the elliptic curve factorization problem (ECFP). In our scheme, we will use ECDLP.
Definition 1 (elliptic curve discrete logarithm problem (ECDLP)). Given two points and over , it is very hard to find an integer such that .
3. Related Work
In this part, we describe Chang et al.’s proposal [14] briefly and analyze the security and privacy preserving in it.
Chang et al.’s protocol includes five phases: registration phase, on-shelf phase, bidding phase, product claiming phase, and dispute phase. A new user should register to an agent center (AC) and AC will issue a certificate for him/her such that he/she can play the role of both auctioneer and bidder. If a registered user wants to initiate an auction, he/she should send some basic information about auction (i.e., product identity, basic price of the auction, and deadline) to AC via the on-shelf phase. Upon checking the legality of user’s identity and the information of the new auction, AC publishes an advertisement on its website (BBAC) such that anyone can read it after the auction has started. If someone wants to bid for the product of this auction via the bidding phase, he/she can send bidding information to AC. After AC checked the legality of bidder’s identity and the bidding price is higher than current price, AC should change the value of current price to the bidding price and publish the bidder’s public key and bidding price on BBAC; else, AC ignores this bid and waits for new bid. After the auction deadline, AC selects the bidder with highest price as the winner, sends a receipt to the winner, and publishes final result on BBAC such that anyone can read and verify it. After getting the receipt, the winner can claim the product from the auctioneer by showing the receipt via the product claiming phase. Then, the auctioneer can verify the correctness of this receipt and send the product to the user. With regard to the dispute phase, if a user takes action illegally, the user trading with him/her can submit dispute information to AC and wait for the arbitration of AC. If illegal action existed, AC can trace the identity of malicious user and punish him/her.
The notations used in Chang et al.’s protocol are as follows and the details of their protocol are described in the following except of the dispute phase: : a trusted agent center. : a Bidder . : an auctioneer . : the identity of . : ’s private key. : ’s public key. : ’s password. : the certificate of signed by AC. : the Bulletin board of AC. : the base point of ECC group over a finite field with order , where is a large prime. : an operation using -coordinate in ECC. : an operation using -coordinate in ECC. /:AES-based encryption/decryption with key . : a secure one-way hash function.
3.1. Registration Phase
If a user wants to play the role of an auctioneer or a bidder in the auction, he/she should register an account at AC by the following steps.(1)User chooses , and a random number , and computes his/her public key . Then, the user calculates , , and and sends () to AC.(2)AC retrieves user’s identity and public key . Subsequently, AC chooses a random number calculates and , and sends them to the user. User checks the correctness of equation to verify the validation of this certificate. If valid, then user stores it with .
3.2. On-Shelf Phase
If a registered user wants to host an auction, then he/she becomes an auctioneer and performs the following.(1) chooses a random number and a nonce and calculates , , , and . generates auction information , that is, the identity of a product, basic price of this auction, and the deadline of this auction. Finally, computes and sends to AC.(2)AC retrieves ’s public key . Then, AC computes the symmetrical key shared with . AC can decrypt O2 with to extract ’s certificate. AC should check the correctness of the certificate by verifying if equation holds and the integrity of by verifying if equation holds where . If both are valid, AC generates a unique gid for ’s product. AC then computes a verifier and sends to .(3)After received message from AC, he/she computes and checks if . If the equation holds, responds Approval message to AC. Upon receiving Approval from , AC publishes on and anyone can verify this message by checking equation .
3.3. Bidding Phase
If someone is interested in this auction, he/she could play the role of a bidder and send bidding message to AC by the following.(1) chooses a random number and computes , , , and . generates bidding message and signs it as . sends to AC.(2)Upon receiving these messages, AC retrieves ’s public key and computes . Then, AC decrypts using to extract ’s certificate. AC can verify the correctness of by checking equation . If it is valid, AC checks the correctness of BM by checking equation . If it is valid too, AC further checks Deadline and BasicPrice of the auction by using gid to search the corresponding information on its website. If the auction has closed or the price is not larger than BasicPrice, AC rejects this bid; otherwise, AC generates a unique transaction identity tid for Bi and chooses a random number . AC then computes , , , and . Finally, AC updates BasicPrice = price, publishes () on , stores ( in database, and sends to bidder.(3)After received the message from AC, can extract the transaction information from . Then, checks the validation of receipt by verifying . If the equation holds, stores and .(4)After deadline, AC sets the winner as the bidder with the highest price. AC then publishes the winner’s information on BBAC including several items such that anyone can verify its validity by checking .
3.4. Product Claiming Phase
After the auction deadline, the winner can claim the product from the auctioneer by showing his/her receipt and performing the following steps. After the auctioneer checked the correctness of receipt, the auctioneer should send the product to the winner.(1) selects a random number and a nonce from , computes , , and , and sends () to .(2)Once receiving ’s claiming request, retrieves and . Then, verifies . If the verification holds, is convinced that is the actual winner and sends the product to .
3.5. Security Defect of Chang et al.’s Protocol
According to our analysis, we found that Chang et al.’s protocol meets most of the security requirements of an auction protocol except for unlinkability. In Chang et al.’s protocol, although some important data such as users’ public keys and certificates are encrypted before being transferred, unencrypted messages such as the on-shelf information still can be linked together with different packets. Figures 2 and 3 show the linkage between transferred messages and published messages on AC’s website. The solid border represents the message transferred on the Internet, and the dotted border represents the message published on AC’s website.
From Figures 2 and 3, we can see that these messages can be linked together through certain parameters. For example, in the on-shelf phase (Figure 2), although attackers cannot calculate the public key or certificate of an auctioneer from the encrypted message (solid border) based on the definition of ECDLP and the security assumption of underlying AES algorithms, attackers can still find the relevance of transferred messages (solid message) and published messages (dotted message) to analyze the specific user’s privacy. As shown in Figure 2, we find that , , , , and are linkable. Obviously, an adversary can link the captured message on the Internet with the published message if they have the same parameters , , , , and. Furthermore, the adversary can decide that if these messages come from the specific IP address. If so, the adversary obtained this IP address owner’s identity .
On the other hand, as mentioned previously, bidders’ privacy is in more serious danger in the bidding phase. At the end of the bidding phase, the AC publishes the information with the winner’s true public key on AC’s website. As shown in Figure 3, similar to Figure 2, attackers have the ability to determine the IP addresses of captured messages on the Internet and to link the specific transferred encrypted bidding information with the published message (the winner’s information). Consequently, attackers would find the relevance of the winner’s public key and the specific IP address. If this user continues to anticipate other auctions, his/her transaction history will be traced. For example, an adversary used Sniffer (a network tool to capture the packets transferred in local network) to capture packets transferred in the local network of his/her office environment and found that some packets are transferred to the auction server (AC). After analyzing the important parts of these packets and comparing them with the messages published on AC’s website, the adversary can know what the specific IP address owner had bidden for or sold out. Obviously, the adversary can easily know who uses the IP address in this office if he/she wishes.
According to the aforementioned analyses, we can see that the main problem that results in privacy disclosure is that some published data is transferred in plaintext before such that an adversary can easily link them together. Hence, in our proposal, we establish a shared symmetrical key between each user and the AC to encrypt the message transferred on the Internet to avoid linkability. By using symmetrical encryptions and fewer ECC operations, our proposal can not only improve the security but also reduce the system cost. In the registration phase, we connect a user’s identity and the corresponding symmetrical key so that the AC can compute the shared symmetrical key easily with the user’s identity. Besides, each user’s identity is encrypted with the AC’s public key so it cannot be revealed without the knowledge of AC’s private key. In our proposal, we fulfill the verifiability of all messages published on the AC’s website; however, Chang et al.’s proposal only partially achieved this feature.
4. System and Adversary Model
In this section, we describe the definitions of our network model, adversary model, and requirements as follows before introducing our proposed scheme.
4.1. Network Model
We consider a network composed of an agent center (AC) and users. The AC is a trusted third party that undertakes most tasks of system running, such as user registration, generation of users’ certificates, and product on-shelf. With regard to the application of the trusted third party, it is widespread in e-commerce systems [25–28]. The AC is also an arbiter of an auction and has the right to determine who the winner is or punish the illegal user’s identity. Hence, we think that the AC has large capability of computation and storage. The AC should maintain a database on its machine to store users’ data. Herein, we do not consider this database to be completely secure. Hackers may have methods to access it, but such actions will not destroy the security of the whole system. Furthermore, the AC’s private key should be kept in a trusted place such as a bank security box.
On the other hand, users use their devices such as computers or mobile devices to communicate with the AC through the Internet. When a user wants to connect with the AC, he/she should type in a password or insert a smart card with a password into the machine. The client in the user’s machine erases the password after the user goes offline.
4.2. Adversary Model
In this paper, we assume that an adversary can launch a passive attack to monitor the communication channel of the system. The adversary has knowledge of the format of a packet, so he/she can analyze what content is included in the packet. We also think that the adversary has the ability to access the database stored in the AC and can read the AC’s website as the other users. In addition, some registered users may attack the system jointly.
4.3. Security Requirements
In order to provide a secure auction scheme, the following security properties are critical [29].
Anonymity. User’s identification should be kept secret as the system is running. No one can obtain the user’s identification from messages transmitted or published.
Easy Revocation. A user’s right should be easily and correctly revoked in the auction system by the AC.
Fairness. All bidders should have the ability to verify whether their bids have indeed been included in the auction.
Nonrepudiation. Users including bidders and auctioneers cannot deny the actions that have been taken before. For example, if an auctioneer puts a product on-shelf, he/she cannot deny that he/she did it and off-shelf this product arbitrarily.
Onetime Registration. Any registered user can host or participate in any auction without reregistration at the AC.
Traceability. If some illegal actions are taken such as a nonpaying bid (NPB), the AC should have the ability to identify and publish the dishonest user’s true identity anytime.
Unforgeability. No one can forge a valid message or impersonate any legal users to do illegal things.
Unlinkability. No one can link different messages together to trace a specific user’s transaction history even if he/she does not know the true identification of the user.
Verifiability. All winning bids and product information published on a bulletin board should be publicly verifiable without revealing the bidders’ identities.
5. Proposed Scheme
In this section, we propose a secure English auction system with privacy preservation. Our proposal consists of six phases: the system setup phase, registration phase, on-shelf phase, bidding phase, product claiming phase, and dispute phase. There are two kinds of participants in this system: the AC and the users. In the system setup phase, the AC inputs a security parameter and generates a set of system parameters. The AC then requests a certificate from an acknowledged certificate authority and publishes these data on its website. Anyone can get these data from the AC’s website. If a new user wants to register an account, he/she can connect with the AC during the registration phase. After registration, the user can either host or participate in an auction. If he/she wants to host an auction, he/she can on-shelf his/her products in the on-shelf phase; if he/she wants to bid for some on-shelved products, he/she can send the bidding information to the AC during the bidding phase. The AC should publish every bidder’s bidding information except for the bidder’s identity on its website such that anyone can read it. If a bidder wins the auction, he/she will receive a receipt and a session key shared with the auctioneer from the AC. Then, the winning bidder can obtain his/her product from the auctioneer during the product claiming phase. In our proposal, the AC has the capability of tracing the whole transaction and identifying the participants in an auction if necessary. If a dispute has occurred, anyone participating in an auction can submit the dispute request to the AC in the dispute phase. The notations used in our proposal are as follows and the details of our proposal are described in the following subsections: : a bidder . : an auctioneer . AC: a trusted agent center. : the system security parameter chosen by AC. : finite filed of order . : an elliptic curve based on order finite field. : a cyclic group of the elliptic curve. : the base point of ECC group. : an operation using -coordinate in ECC. : AC’s private key. : AC’s public key. : the certificate of signed by the certificate authority. : the identity of a user . : ’s password. : a nonce. : ’s partial key used for computing symmetrical key shared with AC. : the symmetrical key of AC and a user. : the symmetrical key of AC and a bidder. : the symmetrical key of AC and an auctioneer. : an AES-based encryption with key . : an AES-based decryption with key . : a secure one-way hash function. : the bulletin board of AC.
5.1. System Setup Phase
Before the system is running, the AC chooses as the private key. The AC then inputs a security parameter and generates a set of system parameters through the steps below:(1)Choose a -bit prime .(2)Determine the tuple ; is a finite filed modular , is an elliptic curve defined over , is a cyclic group defined over , and is the generator of .(3)Compute the AC’s public key .(4)Choose a cryptographic hash function .(5)Request a certificate of from the certificate authority.
Then, the publishes on its online and keeps secret.
5.2. Registration Phase
If a user wants to host or participate in an auction, he/she must perform the following steps to register an account at the .(1)The user obtains system parameters on and checks the validation of the AC’s public key by . If is invalid, he/she terminates the subsequent operations; otherwise, he/she chooses his/her password and identity and generates a random number and a nonce . Afterwards, he/she computes , , , and and sends () to , where .(2)Upon the receipt of the message sent from the user, the AC can extract and by computing and . The AC then checks the freshness of . If is valid, the chooses a nonce and computes . The AC then sends RESPONSE to the user and stores () in its database, where .(3)After receiving RESPONSE, the user retrieves and checks if success is contained in it. If so, the user checks the freshness of . If both are valid, the user ascertains that he/she has registered successfully and then can either host or participate in an auction.
Note that each registered user has a partial key and can share a key with the AC. For convenience, in the following, we use to imply the key shared between the AC and a user who plays as an auctioneer , and ’s partial key is . In contrast, the keys of a user who plays as a bidder are and .
5.3. On-Shelf Phase
If a registered user wants to host an auction to sell some products, he/she becomes an auctioneer and performs the following steps.(1) generates on-shelf information firstly, where refers to the identity of a product, indicates the basic price of this auction (every bidder’s bidding price should not be less than this value), and Deadline represents the deadline of this auction. Then, computes . After that, randomly chooses a nonce and calculates , , , and . Then, sends () to the .(2)The retrieves from by computing . Then, the searches its database to extract the corresponding () of and calculates . The AC extracts by decrypting operation . The AC checks whether the identity in is equal to that retrieved from . If they are not equal, the AC may confront a replay attack, and the AC should terminate sequent operations immediately; otherwise, the AC checks the freshness of . If both are valid, the AC generates a unique on-shelf identity for and sends to , where is a nonce.(3)After receiving the message from the , retrieves by decryption with key . checks the integrity of the message by checking if a correct is in it and checks the freshness of this message by checking . If both are valid, the auctioneer then sends APPROVAL to AC.(4)Upon receiving APPROVAL from , the AC chooses a random number and computes and , where . Waiting minutes (), the AC publishes () on . Once the AC publishes the on-shelf information, the auction has been held, and anyone can verify the validation of the auction information by checking the correctness of equation .
5.4. Bidding Phase
If a bidder wants to bid for an on-shelved product, he/she should send the bidding information to the AC, including the corresponding identity of the product and a bidding price . We denote as here.(1) computes firstly. Then, computes , , and , where is a nonce. Then, sends () to the AC.(2)After receiving the bid sent from , the AC can retrieve from by computing . Then, the AC searches the in the database. If the does not exist, the AC terminates the sequent operation; otherwise, the AC retrieves the corresponding by computing and computes the symmetrical key shared with as . The AC decrypts with to extract . The AC can check the integrity of this bid by seeing if is equal to the one retrieved from . If they are not equal, the AC may confront a replay attack, and the AC should terminate the sequent operations; otherwise, the AC checks the freshness of . If both are valid, the AC uses in to search the corresponding auction information in .(3)After finding the corresponding auction, the AC compares in with of the auction. If is not larger than , the AC ignores this bid and returns to the waiting state; otherwise, the AC updates and generates a unique identity for this transaction. Then, the AC generates a nonce and computes and . Let () be ; the AC then generates and computes and . Waiting minutes, , the AC publishes on such that anyone can verify it by checking if equation holds.(4)The AC then finds out the corresponding of the auctioneer’s of this auction in the database. The AC computes the symmetrical key shared with . Then, the AC generates a session key shared between and as . The AC generates a receipt for as and sends to , where is a nonce.(5)Upon receiving the message from the AC, decrypts it with and checks the and in it. If is correct and the nonce is fresh, stores ().(6)After the DeadLine arrives, the AC closes the auction and determines the bidder with the highest price as the winner. The AC determines from the corresponding winning bid information on whose price of the bid is equal to Basic_price. Let ; the AC chooses and computes and . Then, the AC publishes the winning information () on . Anyone can verify the winner’s information by checking .
5.5. Product Claiming Phase
After the AC publishes the auction result, every bidder can check whether he/she is a winner by checking whether his/her transaction identity is equal to the winner’s . If a bidder wins the auction, then he/she can claim the product from the auctioneer using the following.
computes and sends it to , where is a nonce. Upon receiving the claiming request, computes firstly. Then, he/she browses the and computes the session key shared with the winner and extracts by decrypting the ciphertext sent from using . Then, checks the freshness of . If is fresh, verifies the validity of RECEIPT by checking . Note that and can be found in the winner’s information on . If the equation holds, is convinced that is the winner and sends the product to him/her.
5.6. Dispute Phase
In our proposal, the AC has the capability of tracing the whole transaction and identifying the participants in an auction if necessary. If a dispute has occurred, anyone who participates in an auction can submit a dispute request to the AC in this phase. In the following, we consider two situations to explain the dispute phase.
Situation 1 (auctioneer appeals to AC). If a nonpaying auction happened, which means that the winner did not contact the auctioneer after he/she won the auction, can appeal to the AC and the AC will trace the transaction to deal with this dispute.
browses and finds the winner’s firstly. Then, selects a nonce and computes , , , , and . Subsequently, sends () to AC. Once receiving the dispute request from , the AC retrieves and checks the validation of in the database. If it is valid, then the AC computes and decrypts to extract , , and . The AC checks the freshness of . If the nonce is fresh, the AC checks if in equals in . If they are not equal, the AC terminates operation immediately; otherwise, the AC searches the on and traces the transaction history to determine whether the problem really exists. If the AC ascertains that the problem claimed by is true, the AC then finds out the corresponding dis and among the winner’s information from . Afterwards, the AC computes ) and extracts () from dis. Finally, the AC can retrieve the dishonest winner’s identity as and publish it.
Situation 2 (bidder appeals to AC). If the auctioneer of an auction refuses to send the product to the winner , also can appeal to the AC.
Firstly, computes , , , , and , where is a nonce. then sends () to the AC. Upon receiving the dispute request from , the AC retrieves and checks if exists in the database. If it exists, the AC then computes and decrypts to extract , , , and . The AC checks the freshness of . If the nonce is fresh, the AC checks if in equals in . If they are not equal, the AC terminates the operation immediately; otherwise, the AC then finds the corresponding and of on and the corresponding of in the database. Then, the AC calculates and . The AC checks the validation of RECEIPT by verifying . Note that and can be found in the winner’s information on . If RECEIPT is valid, the AC traces the transaction history to determine whether the problem really exists. If the AC ascertains that the problem claimed by is true, the AC publishes the identity of the dishonest auctioneer .
6. BAN Logic Analysis
In this part, we will use BAN logic to analyze the authentication accuracy. Burrows-Abadi-Needham logic (also known as the BAN logic) is a set of rules for defining and analyzing information exchange protocols. Specifically, BAN logic helps its users to determine whether exchanged information is trustworthy, secured against eavesdropping, or both [30]. The notations of BAN logic are as follows: : believes . : sees . : once said . : has as a public key. : the formula is fresh. : has jurisdiction over . : and have a shared key for communication. : the formula encrypted under key .
We mainly focus on the proof of on-shelf phase and bidding phase.
6.1. On-Shelf Phase
We idealized the on-shelf phase as below:(I1).(I2)
In this phase, we want to ensure that AC believes in the on-shelf information and believes in the transferred from AC, so we can conclude the two goals below:(G1).(G2)
We need to assume that AC believes the nonce is fresh and believes the nonce is fresh; AC believes that does not send fake and , so if believes and are true then AC will believe them too; KAA is computed by AC self, so believes that is shared between him/her and AC; and believes that AC does not send fake , so if AC believes is true then will believe them too. All 6 assumptions are listed as below:(A1).(A2).(A3).(A4).(A5).(A6).
Proof. For goal (G1), our deduction is shown as the following formulas:(F1).(F2) (message decryption rule).(F3)(our hypothesis, we will prove that it is true later).(F4) ((F3), the computing property of believing in operator).(F5).(F6) ((F4), (F5), message meaning rule).(F7) ((A1), freshness propagation rule).(F8) ((F6), (F7), nonce verification rule).(F9) ((F8), believing rule).(F10) ((F9), (A3), jurisdiction rule, our hypothesis in (F3) is proved).(F11) ((F8), believing rule).(F12) ((F11), (A3), jurisdiction rule).According to formula (F12), the proof of (G1) is completed.
For goal (G2), our deduction is shown as following formulas:(F13).(F14) ((F13), (A4), message meaning rule).(F15) ((A5), freshness propagation rule).(F16) ((F14), (F15), nonce verification rule).(F17) ((F16), believing rule).(F18) ((F16), (A6), jurisdiction rule).According to formula (F18), the proof of (G2) is completed.
6.2. Bidding Phase
Our bidding phase can be idealized as below:(I3).(I4).
In bidding phase, we want to ensure that AC can be convinced that bidding information transferred from is true; additionally, should be convinced that RECEIPT and transferred from AC are true. So the three goals below can be concluded:(G3).(G4).(G5).
We need to assume that AC believes is fresh and believes is fresh; if believes and are true, AC believes in them too because they are generated by ; similarly, if AC believes in RECEIPT and then believes in them too; because is generated by , believes that he/she shared with AC. All assumptions are listed as below:(A7).(A8).(A9).(A10).(A11).(A12).(A13).
Proof. For goal (G3), our deduction is shown as the following formulas:(F19).(F20) (message decryption rule).(F21) (our hypothesis, we will prove that it is true later).(F22) ((F21), operator believes in property).(F23).(F24) ((F22), (F23), message meaning rule).(F25) ((A7), freshness propagation rule).(F26) ((F24), (F25), nonce verification rule).(F27) ((F26), believing rule).(F28) ((F27), (A9), jurisdiction rule, our hypothesis in (F21) is proved).(F29) ((F26), believing rule).(F30) ((F29), (A8), jurisdiction rule).According to formula (F30), the proof of (G3) is completed.
For goal (G4), our deduction is shown as the following formulas.(F31).(F32) ((F31), (A10), message meaning rule).(F33) ((A11), freshness propagation rule).(F34) ((F32), (F33), nonce verification rule).(F35) ((F34), believing rule).(F36) ((F34), (A12), jurisdiction rule).According to formula (F36), the proof of (G4) is completed. Finally, the goal of (G5) is deduced by the following formulas:(F37) ((F34), believing rule).(F38) ((F37), (A13), jurisdiction rule).The proof of (G5) is completed.
According to our proofs, we can see that our protocol completes the mutual authentication between users and AC. In on-shelf phase, AC can be sure that on-shelf information is sent from legal user and auctioneer can be sure that is transmitted from AC; in bidding phase, AC can be sure that bidding information is sent from legal user and bidder can be sure that receipt and session key are generated and sent by AC. As the results, our protocol achieves authentication accuracy.
7. Security Analysis
In this part, we analyze the security of our proposal. We assume that an adversary can eavesdrop on public communications on the Internet and read the information on ; however, he/she cannot read ciphertexts without getting the encrypting keys. Of course, the adversary cannot calculate the keys from ciphertexts. All roles in the system except for the AC can conspire to do something illegally for their benefit. In the following, we provide different scenarios to explain our security defense.
(1) Impersonation Attack. It is impossible for an adversary to impersonate a user. When a user wants to communicate with the AC, he/she should send his/her identity ciphertext () to the AC. The AC retrieves and checks the user’s identity from this message. We can see that the adversary cannot generate a legal () to pass this verification without the knowledge of the AC’s private key and the key shared between the AC and the user. Even if the adversary eavesdrops on the other users’ communications and stores their (), he/she still cannot use these to do anything because the AC will check if the identity included in equals that in . The only method for the adversary is to replay the whole (); however, this will not work because the AC can check the freshness of the nonce in .
(2) Collusion Attack. In some cases, bidders and auctioneers may conspire to break the secret of the AC. For example, a bidder may send RECEIPT instead of to an auctioneer. However, with this knowledge, they can only compute , where can be computed by the auctioneer and can be found in . Even obtaining , they cannot compute because is a one-way hash function.
(3) Forging Receipt. Firstly, we consider the case that a malicious bidder wants to forge a receipt to impersonate the winner of an auction by himself/herself. Because , the malicious bidder obviously cannot forge a valid receipt without knowing the AC’s private key and the key shared between the AC and the auctioneer. Secondly, it is also impossible for the winner and auctioneer to conspire and create the receipt of another auction. As mentioned in the Collusion Attack, they only can compute . However, for different bidders, ’s are different, so are different in different auctions. Obviously, they cannot create a useful receipt of the other auction with by collusion. Besides, it is meaningless for the winner and auctioneer of an auction to forge a receipt of the auction.
(4) Denial of Service Attack. If an adversary wants to mount a deny of service attack on a bidder () such that he/she cannot claim the product in the product claiming phase when he/she wins an auction, the adversary should generate a fake receipt and send it to the bidder during the bidding phase. However, the receipt transmitted to needs to be encrypted with ’s identity by the symmetrical key shared between and the AC as . After receiving the ciphertext, the bidder should decrypt it and check if his identity is correct. So it is impossible for an adversary to deceive a bidder to accept a fake receipt.
(5) Publishing Fake Information. In our proposal, all published information, including new auction information in the on-shelf phase and bidding information and winner information in the bidding phase are signed by the private key of AC, so anyone can verify the published information with AC’s public key. Let us consider a situation: if a bidder wants to win an auction, he/she may try to publish a fake bidding message with a very high bidding price on so that no one else wants to compete with him/her. However, he/she cannot be successful without knowing the private key of the AC, because every user can check the signature of the AC on this message.
(6) Privacy Preserving. In our scheme, an adversary cannot link any information together to analyze a user’s privacy. Only auctioneers’ identities need to be published in for enhancing users’ willingness to bid. All packets transmitted in the public channel are encrypted, so the adversary cannot know whether these packets can be linked to certain information published on even if they captured these packets. It is noteworthy that, in our schemes, we use a delay operation in bidding and on-shelf phases for increasing difficulty of linkage of different messages. For example, if the adversary detects that Alice sends an on-shelf message to the AC and the AC publishes an auction advertisement on the website including the auctioneer’s identity immediately, the adversary would ascertain that Alice is the auctioneer and obtain Alice’s identity. If we delay publishing the auction message several minutes later (i.e., the AC publishes it with other auction information together), then the adversary cannot distinguish a specific user from them. The larger the we use, the stronger the privacy preserving function is. However, we should balance the privacy preserving and user experience. Moreover, in the bidding phase, a bidder’s identity can be retrieved by , where and are involved in the information published on . However, these parameters are protected by AC’s private key as before being published on , where , such that no one can extract except for the AC. In the product claiming phase, an auctioneer cannot know the winner’s identity from but can only know the validity of the receipt. As indicated in the results, our scheme indeed achieves privacy preserving.
(7) Accessing to the Database of the AC. In the definition of a network model (Section 4), we have mentioned that we do not consider the database of the AC to be completely secure in our proposal. An adversary may access the messages stored in it by certain methods. However, accessing the database would not destroy the security of the whole system. Furthermore, the AC’s private key should be kept in a trusted place, such as a bank. There are mainly four data sets maintained in the AC: the first is generated in the registration phase, the second is generated in the on-shelf phase, and the final are and generated in the bidding phase. Only the first data set is unpublished, so we only consider the safety of the first data set here. If a hacker reads the content of the first data set, he/she only can obtain all users’ identities and their partial keys () which have been protected by AC’s private key as the form . With only protected partial keys, the hacker cannot compute the symmetrical key () shared between users and the AC, because the private key of the AC is kept secret. Furthermore, he/she cannot retrieve a user’s password from the partial key based on ECDLP. So we can see that accessing the database does not destroy the safety of the whole system.
(8) Password Guessing Attack. In our scheme, users’ passwords are needed to protect system security. However, because the user’s password is not very long and there is a certain routine mode, attackers may try to mount the password guessing attack to the password-based communication schemes. To prevent this attack, in our scheme, users’ passwords will not be transmitted or stored in plaintext. As mentioned in the registration phase (Section 5.2), the password related information is transformed to ciphertext before transferring and is stored as the format of in AC’s database. Obviously, even an attacker collects ciphertext or by eavesdropping the whole communication channel or intruding AC’s database; he/she can not obtain any user’s password by password guessing attack without the knowledge of AC’s secret key .
Table 1 (“” means fully achieved, “” means partially achieved, and “” means not achieved) shows the security comparison among our proposal and three other schemes: Chang et al.’s [14], Xiong et al.’s [13], and Chung et al.’s [18]. As shown in Table 1, our scheme fulfills the most secure properties of an electronic auction system. In the analysis of “privacy preserving,” our scheme can achieve the properties of anonymity and unlinkability; in the analysis of “Publishing Fake Information,” our scheme can achieve the properties of fairness and verifiability; and in the analyses of “Impersonation Attack, Forging Receipt, and Denial of Service Attack,” our scheme can achieve the property of unforgeability. Similar to [13, 14, 18], the bidding information should be published on an open website, so the bidder can check if his/her bid appeared on it to ensure fairness. Based on the digital signature, bidders cannot deny their bids so nonrepudiation is achieved in four proposals. By providing the dispute mechanism, our scheme achieves the properties of easy revocation, nonrepudiation, and traceability. Furthermore, our scheme overcomes the security problem (leakage of unlinkability) and meanwhile inherits the advantage of without a secure channel in Chang et al.’s scheme [14]. It is noteworthy that, compared to [14], our protocol needs to store a little of the verification table in the server side. However, as we analyzed before, leakage of these verification tables will not influence system security, so we say that our protocol achieves partial property of no verification table.
With regard to verifiability, in the bidding phase of Chang et al.’s proposal [14], only the winner’s bidding information will be signed by the AC and can be publicly verified, which may lead attackers to modify any new bidding information with a higher price such that no one else wants to bid for it further. So verifiability is not fully achieved in [14]. As [14] analyzed, the designed revocation function in [13, 18] only partially achieved easy revocation. Our protocol and [14] have a secure on-shelf phase compared to [13, 18]. Our protocol does not need a secure channel to achieve verification in any phase similar to [14]. However, in [13, 18], a secure channel is needed to assist in the completion of the whole protocol.
8. Performance Analysis
In this section, we compare the cost of our scheme with the other three schemes [13, 14, 18] with regard to computational cost, traffic, and communication rounds.
Table 2 shows the comparison of computational cost, where “PM” means a point multiplication operation of ECC, “BM” means a bilinear mapping which can be implemented on ECC such as Weil pairing, “E” means a symmetrical encryption, “D” means a symmetrical decryption, “H” means a hash function, and “” means the number of bidders in an auction.
As we know, a bilinear map is an expensive operation; the more it is used, the more computation cost is needed. Compared with point multiplication, the hash function only consumes negligible computation cost. Symmetrical cryptographic operation is also cheaper than point multiplication. From the comparison in Table 2, we can see that our proposal needs less computation cost compared with Chang et al.’s proposal [14] in each phase, except for the dispute phase. However, in reality, the first four phases are more frequently executed.
To make the traffic comparison, we determine the elliptic curve operation as NistP 192 [24], hash function as SHA-256 [31], and symmetrical encryption/decryption as AES-256 [32]. The length of the user’s identity is 4 bytes, product identity is 5 bytes, transaction identify is 5 bytes, GID in [14] is 5 bytes, price is 5 bytes, and Deadline is 4 bytes. Note that we ignore the length of nonce transmitted in communications. As shown in Table 3, we can see that our protocol has a traffic advantage compared with related works [13, 14, 18], except for dispute phase of Chang et al.’s scheme [14]. The main reason for this is that our scheme finished the key establishment in the registration phase for saving the traffic cost of public keys and certificates. Comparing with Chang et al.’s proposal, though our dispute phase needs more traffic, this phase is not often used compared with the other four phases. As a result, we believe that our proposal has traffic advantages still. Finally, we compare the communication rounds of our scheme and the related schemes in Table 4. As shown in this table, our protocol needs the same communication rounds as those in Chang et al.’s protocol [14].
9. Conclusions
In this paper, we pointed out that Chang et al.’s protocol does not fulfill the unlinkability such that users’ privacy will be leaked by linking different messages together. Considering the importance of privacy preservation, we proposed a novel electronic English auction system. By using symmetrical encryptions and fewer ECC operations, our protocol can not only improve the security but also reduce the system cost. In the registration phase, we connect a user’s identity and the corresponding symmetrical key so that the AC can compute the shared symmetrical key easily with the user’s identity. Furthermore, each user’s identity is encrypted with the AC’s public key so it cannot be revealed without the knowledge of the AC’s private key. In the bidding phase, we improve the efficiency of generating bidding receipts. In our proposal, we fulfill the verifiability of all messages published on the AC’s website; however, Chang et al.’s proposal only achieved this feature partially. We used BAN logic to prove that our protocol indeed realizes mutual authentication. The security analysis and performance analysis show that our protocol fulfills more security properties and is more efficient for implementation compared with recent works.
Competing Interests
The authors declare that they have no competing interests.