secure distributed auction infrastructure

IADIS International Conference WWW/Internet 2007

SECURE DISTRIBUTED AUCTION INFRASTRUCTURE Júlio da Silva Dias, Carlos Roberto De Rolt e Thiago Souza Araujo Universidade do Estado de Santa Catarina – UDESC Av. Madre Benvenuta, 2037 – 88035-001 – Florianópolis – SC – Brasil

ABSTRACT The use of electronic online auctions has increased and this kind of mechanism has been widely used by organizations and individuals around the world. Many models have been proposed to make this kind of business model trustworthy. It is proposed in this paper a flexible, fraud resistant, infrastructure to allow the set up of distributed online auctions. The concept developed here has strong process directions, in contrast to traditional cryptographic or hardware approaches. The proposed system is composed of functional modules that provide evidences of the activities carried out by bidders and auctioneers making the detection of misuse possible. The infrastructure that collects evidences about the user behavior can also be used in the future to profile bidders in order to detect frauds. KEYWORDS Security, E-Business, E-Commerce

1. INTRODUCTION An auction is used to buy and sell products by offering them for bid, receiving bids and then selling the product to the winner, following business rules. Auction is an important economic mechanism that allows value determination where it has an undetermined or variable price. Online auctions, using the Internet, lead to business models where sellers and bidders are spread around the world. It is important to note that there are different rules for each of the auction models inhibiting the standardization of the online infrastructure. For this reason there is still no online infrastructure that can be applied to all models. Given the vast array of these rules there is a need to collect detailed information on how each auction model is performed in order to abstract the implementation requirements and this kind of business will be viable only if a minimum set of such requirements are fulfilled. In this regard the focus of this paper will be on security and functional requirements. The most important security requirements are anonymity, availability, non-repudiation, auditability, bid nondisclosure, confidentiality, privacy, traceability, fairness and robustness. Availability, non-repudiation, auditability, traceability, fairness and robustness must be fulfilled by all kind of auctions. Anonymity, bid nondisclosure, privacy and confidentiality are useful in certain types of auction models [Brandt 2006]. The security requirements are necessary to avoid collusion, where rival entities cooperate or collaborate in order to defraud the auction or misuse of computer systems that implements online auctions. This task is particularly difficult in the case of distributed online auction system. The security in the online auction is not related only to the transaction itself, but also to the logic operation. The bidding process on an action is guided by the interaction between economical agents, where which one wants to maximize earns. But like in any other marketplace it is equally subject to the participant opportunists attitudes. One of the situations where the process is not fare is when some participant obtains privileged information regarding the auction in progress. The privileged information on the auction gives to the economical agent an advantage in relation to the other participants and that asymmetry of information is usually not beneficial for the process. When promoting the auction in the distributed methodology, with several auctioneers, the tendency of some agreement between the auctioneers and one of the buyers, or a group of them, decreases strongly. It happens because in this case the auctioneer loses the possibility to lead the auction entirely, all by himself,

125

ISBN: 978-972-8924-44-7 © 2007 IADIS

and he starts to take the risk that other auctioneers gets a better bid, and consequently win the largest commission. Another subject about safety in this process is the agreement formation among the buyers to bid an item for a price below the value that each one would be willing to pay, what consists in a violation on the logic of the system. The logic of the auction is to allocating the item to be auctioned for the buyer that more values that item, adapting the demand to the supply. With the distributed auction the participation of more auctioneers simultaneously hinders the agreement formation and the participants control in relation to the process, and at this way the risk that a new bidder non participant of that agreement wins the auction will rise. So the possibility of agreement formation, or collusion, is deeply reduced. The aim of this paper is to propose a secure distributed auction infrastructure applicable to all auction models. The core of this infrastructure is a secure workflow engine composed of a workflow engine and a secure code execution module to enhance its security. The secure code execution module follows a model carrying code philosophy proposed by Sekar [Sekar 2003]. The workflow engine allows a flexible process management that is not found in other approaches. The system could use an approach based on a Trusted Platform Module - TPM [TCPA 2002] or a Hardware Security Module – HSM that could protect the software running the auction. However, both approaches are expensive and require the hardware to be trustworthy. Also, in the case of the TPM approach the system will be dependent on specific hardware that does not have wide acceptance and using an HSM would lead to a FIPS certified hardware. The infrastructure was developed in order to perform faultlessly even in the presence of malicious entities, using any hardware architecture. The TPM or HSM solution can be used but this is not a fundamental requirement. The system that runs the auctions must be simple to operate allowing administrators and auctioneers to deploy any auction model as fast as possible. The sellers and bidders must have an interface with ease access to information on the auction in progress. Providing a simple and transparent system is as important as ensuring a secure one, allowing more participants to join the auction and trust the system. It is important to understand some basic concepts of electronic auctions and these are presented in section 2. The proposed secure distributed auction infrastructure is then presented in section 3 and evidences are provided to demonstrate its applicability to all auction models. A discussion then follows on the results obtained from the implementation of the infrastructure proposed.

2. ELECTRONIC ONLINE AUCTIONS An auction can be classified in different ways [Klemperer 1999]. There are open auctions as well as sealedbid auctions. There are auctions where the price ascends and auctions where the price drops at regular intervals. Generally, there are four major one-sided auction formats: English, Dutch, First-Price sealed-bid, and Vickrey (uniform second-price). One difficulty is the lack of commonality in naming conventions. What some people call a uniform second-price auction is known in financial communities as a Dutch auction, and no end of confusion results. In an English auction, participants bid openly against one another, with each bid being higher than the previous bid. The auction ends when no participant is willing to bid further, or when a pre-determined price is reached, at which point the highest bidder pays the price. In a Dutch auction the auctioneer begins with a high asking price which is lowered until some participant is willing to accept the auctioneer's price, or a predetermined minimum price is reached. That winning participant pays the last announced price. The Dutch auction is named for its best known example, the Dutch tulip auctions. In a first-price auction (one unit up for sale) each bidder submits one bid in ignorance of all other bids. The highest bidder wins and pays the amount he bid. Speaking generally, a sealed-bid format has two distinct parts--a bidding period in which participants submit their bids, and a resolution phase in which the bids are opened and the winner determined (sometimes the winner is not announced). Second-price auction, in which participants submit sealed bids and the highest bidder wins, but pays only as much as the second-highest bid.

126


A general auction timeline is presented in Figure 1. Once an auction is started it is able to receive bids until the announced end. After the end the bids are processed following the business rules, and the winner can be proclaimed. If necessary the evidences collected during the process can be revealed and the auction validated.

Figure 1. Auction Process.

There are two general types of auctions. In the first, the bids are sealed and only released during the processing, after the auction end. In the other type the bids are open and all participants can access the information. All auctions have some points of failure: the participants can collude; the system can be defrauded by the administrators or the participants and administrators can collude together. Firstly, the auctioneer can collect restricted data about the bids and defraud the auction sending information to other bidders. For example, in cases where the highest price is only disclosed at certain point in the process. The collusion can also be carried out by the bidders to disvantage of the seller or auctioneer. This problem can be avoided through the use of a trusted system that controls the auction and does not allow release of sensitive and restricted data to the participants or even the auctioneer. The second point is the system used to deploy the auction that must be fraud resistant. The electronic online auctions used today do not provide information about their systems and the participants must trust it without knowing the applied rules behind the system and whom has accessed the information stored in its database. It is clear that these two situations do not solve problems such as malicious sellers who do not have the product at all or the announced product is different from the real one. The other aspect is the malicious bidder who will not pay or wants to disturb the auction process for personal reasons. The online auction systems provide some mechanisms to detect this kind of fraud. Reputation scores are discussed and proposed as reputation schemes in online auctions as a mechanism to avoid and predict fraud by sellers and buyers [Dellarocas 2003],[Woods 2002]. Some authors such as Perrig and Nurmi [Perrig 2001], [Nurmi 2005] propose the use of specific hardware and the use of cryptographic protocols to avoid fraud in auctions. In both approaches the bidders and seller must trust in third parties and do not have any information about how the process was completed. It is known that reputation schemas are not the ideal mechanism as they can be easily defrauded and specific hardware that can not be easily audited is not trusted and accepted by bidders and sellers. All previous publications have focused on a particular scheme to avoid misuse and frauds in online auctions. This paper proposes a general infrastructure composed of modules that together can help to avoid or limit fraud in the auction process. It is also possible, and desirable, to use the infrastructure in a distributed auction with composite trading rules if the auctioneers are able to describe the process using a language common to all system users, including sellers and bidders.

3. SECURE AUCTION INFRASTRUCTURE The approach proposed in this section is focused on the deployment of a flexible distributed secure online auction infrastructure. This infrastructure must be able to support any auction model and also support many auctioneers, sellers and bidders. As explained before there are different rules for each of the auction models and this approach can also be seen as a tool to design and carry out trading activities with multiple parties and different protocols. The technical and functional solution will be presented but it is clear that there are legal and fiscal implications that will not be discussed here. There are 3 steps that must be performed before the auction can be run as can be seen in Figure 2. The first step is performed by auctioneers that describe the auction rules. The second step is performed by the analysis and validation module that produces the rules that can be loaded into the workflow engine that will

127

ISBN: 978-972-8924-44-7 © 2007 IADIS

run the auction. The workflow engine was modified in order to enhance its security and it can also use a set of modules in order to increase the auction trustworthiness. The third step is performed by the administrator that loads the auction model and code on the workflow engine.

Figure 2. Auction Preparation

In the first step the auctioneers must select the rules that will guide the auction process creating a behavioral model that can be validated later. The language used to perform this description must be clear enough to allow the correct interpretation of the process. In this approach the use of Business Process Modeling Notation – BPMN [BPMN 2006] is proposed. BPMN is a language that can be used to explain the internal business procedures in a graphical notation and will allow the auctioneer to communicate these procedures in a standardized manner. The BPMN description can be translated into a Business Process Execution Language – BPEL [BPEL 2003] that presents an XML style syntax. The BPMN model must also be translated into a Petri Net model that is used to validate the process. It is also possible to translate the BPEL specification to a Petri Net specification so it can be cross-checked with the model produced in the BPMN to Petri Net translation. All the security requirements must be described in the model to allow the correct process validation. A Petri Net was used to model the process because a language that supports distributed systems is needed to allow its use in a distributed marketplace. Petri Net models also provide a graphical and mathematical formalism that can be used to validate the process. Figure 3 presents the relation between the languages used to describe, validate and execute the auction.

Figure 3. Relations Between Description an Execution Languages

Once the auctioneer has finished describing the auction, on the second step this description is validated against the business rules. The business rules are presented to the system by its administrator in accordance with the legal and economic rules which the auctioneer must follow. The second step also allows the translation from a descriptive language into an execution language. This process produces the code to be loaded into the electronic auctioneer that is a secure workflow engine and basic modules such as the web interface, time stamp authority, encipherment and temporal key release and secure log storage. The third step is performed by the administrator that loads the auction model produced by the auctioneer and the code generated and validated in the second step. In our prototype the execution language was that provided by the workflow engine. In the distributed infrastructure each auctioneer has his own secure workflow engine that can contact the others to exchange information on auctions in progress. The Figure 4 presents the basic modules used to enhance the trustworthiness of the process. The system is flexible enough to allow other modules to be added in order to support different auction models.

128


Figure 4. Secure Auction Infrastructure

The workflow engine proposed here has attached a secure code execution module that during the running step performs event validation allowing or not its execution. Any data flow inside the workflow engine must be validated against the model generated and loaded. This new secure workflow engine is the core of this proposal. The other modules are used to allow the system to run specific auction models but the workflow engine is used in all them. In this study a secure code execution module has been developed allowing the workflow engine to run the auction eliminating the possibility for any malicious behavior from the auctioneer. This secure code execution module runs the code validated previously. While the auction is open and receiving bids the workflow machine can only act following business rules described by the model presented to the workflow engine. This workflow engine and the attached secure code execution module can be packed in a hardware security module. The secure code execution is a software approach but it can also be used inside the HSM in complementary way enhancing its security. A hardware solution may be less susceptible to system failures and corruptions, such as viruses but it lacks a necessary transparency required in this kind of application. The secure code execution module, using a concept similar to model carrying code presented by Sekar [Sekar 2003], provides a way to control and validate the code execution. In this approach the focus is on a knowledge of whether the data has been accessed at some point of the auction or not, and if so the purpose must be explained by that entity. The reasons for any data access can only be later assessed subjectively, using the evidences collected during the process. The secure code execution and the time stamp module together can answer the questions of whether the data has been accessed and when. The authentication of system users is performed using digital certificates providing evidence of who has used the system. Every action performed by the system and any attempt to defraud the system is logged and the information is distributed to all participants. In this way the information is public and available not allowing the process to be defrauded. This module is important to fulfill auditability, traceability, fairness and robustness security requirements. The secure code execution applied in conjunction with the workflow engine provides flexibility, allowing any auction model to be carried out. The auctioneer does not need to know technical details about the system and only have access to a graphical interface where the process is modeled. All the translation from graphic description to the xml file that describes the process is performed during the validation process. The auxiliary modules are used only when necessary. The time stamp authority [Pasqual 2002] is used to date all the data generated in the auction process, this is very important for non-repudiation, auditability and traceability requirements. The digital time stamp does not allow posterior bid insertion by the auctioneer or the system manager and also is important for system auditing where date information is essential. The sequential nature of time stamping is preserved by the Time Stamp Authority and allows the auction process to be traced from begin to the end. The order of events can be followed and the participants can not alter the data once time stamped by the Time Stamp Authority. For data presenting a specific time stamp, the secure log storage can be simplified. In this implementation a simple machine attached to the auction server through its serial interface was used. The secure log storage has no network connection and when necessary the workflow machine can have access only to append or read data, never will it be allowed to erase its data.

129

ISBN: 978-972-8924-44-7 © 2007 IADIS

The encipherment module is important to manage the cryptographic keys used to seal the bids when necessary. In this approach the auctioneer has to use this module and does not need to generate or store the keys. When deploying the auction, the auctioneer indicates the time when the keys must be released in order to have access to bids. This module gives confidentiality and privacy to the auction and is discussed in detail elsewhere. The authentication is delegated to the web interface that can use digital certificates to identify the users accessing the system. In the prototype it was used an Apache web server that has been configurated to only accept clients with a X.509 certificate.

4. CONCLUSION Online auctions can be used to sell anything and their use has increased making it important to provide tools to enhance the trustworthiness of this business model. This paper presents a different approach to deploying online auctions, where the process management and transparency are used to enhance trust. The process described and validated graphically and mathematically using BPMN and Petri Net make it possible for all the parties involved to understand the rules and how the process will be executed. The information necessary to audit the process is generated by the system and will be available to the participants when required. The system provided can fulfill the security requirements necessary for this kind of business using both cryptographic and non-cryptographic methods. The use of a secure workflow engine makes the system flexible enough to be used in any auction model. The workflow machine in conjunction with the secure code execution module provides the tools that fulfill important security requirements. The authors agree that an online auction system only will be widely used if it offers a simple interface and full access to relevant data by the participants. The technological apparatus is only a part of the system and the transparency is fundamental to robustness and trustworthiness of the auction process. A fundamental stage in this system is the authentication through digital certificates avoiding anonymous bidders who can defraud the system. The first prototype developed used a workflow engine allowing at this point its use in the distributed marketplace with some scale limitations. However, the authors agree that it is possible to implement a trustworthy distributed auction system allowing more sellers and bidders to communicate and earn better revenues using this infrastructure. The system will allow the administrator to develop a consistent database on all the participants. The use of data mining techniques will allow extraction of user profiles and so any malicious participants will be detected and discarded.

REFERENCES [BPEL 2003] BPEL, 2003, Business Process Execution Language for Web Services version 1.1, http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf. [BPMN 2006] BPMN, 2006, Business Process Modeling Language version 1.0, http://www.bpmn.org/. [Dellarocas 2003] Dellarocas, C., “Efficiency and Robustness of eBaylike Online Feedback Mechanisms in Environments with Moral Hazard,” Working paper, Sloan School of Management, MIT, Cambridge, MA, January 2003, available at ccs.mit.edu/dell/SITE%202002.pdf. [Brandt 2006] Brandt, F., 2006, How to obtain full privacy in auctions., In Springer Verlag International Journal on Information Security., Vol. 5, No. 6. [Klemperer 1999] Klemperer, P., 1999, Auction Theory: A Guide to the Literature., In Journal of Economic, Vol. 13 No. 3. [Nurmi 2005] Nurmi, H. and Salomma, A., 2005, Cryptographic Protocols for Vickrey Auctions., In Springer Verlag Group Decision and Negotiation, Vol. 2, No. 4.

130


[Perrig 2001] Perrig, A. et al, 2001, SAM: A Flexible and Secure Auction Architecture Using Trusted Hardware, ., Proceedings of the 2001 First International Workshop on Internet Computing and E-Commerce (ICEC'01). [Sekar 2003] Sekar, R. et al, 2003, Model-Carrying Code: A Practical Approach for Safe Execution of Untrusted Applications, Proceedings of the 2003 ACM Sypmosium on Operating Systems Principles (SOSP'03). [Wood 2002] Wood, C. A. Fan, M. and Tan, Y. “An Examination of the Reputation Systems for Online Auctions,” Presented at the Workshop for Information Systems and Economics (WISE 2002), Barcelona, Spain, December 2002, most recent version available at http://www.nd.edu/~cwood1/research/wft_comments .pdf. [Balacheff 2001] Balacheff, B. et al, 2001, A trusted process to digitally sign a document., Proceedings of the 2001 Workshop on New Security Paradigms, ACM Press, pages 79--86 [Balfanz 1999] Balfanz, D. et al, 1999, Hand-held computers can be better smart cards., pages 15--24. [Berbecaru 2000] Berbecaru, D., et al, 2000, Towards concrete application of electronic signatures., pages 543--561. AICA 2000 Symposium. [ITU-T 1997] ITU-T, 1997, The directory: Authentication framework. Recomendation X.509. [Josang 2002] Josang, A., et al, 2002. What you see is not always what you sign.,Proceedings of the AUUG2002. [Marcacini 2000] Marcacini, A. T., 2000. Documento eletrônico como meio de prova. http://augustomarcacini.cjb.net/textos/docelet2.html. [Menezes 1997] Menezes, A. et al, 1997, HandBook of Applied Criptography. CRC Press, Boca Raton, FL - USA, 1 edition. [Microsoft 2003] Microsoft Inc., 2003. Microsoft next-generation secure computing base - technical FAQ. [Pasqual 2002] Pasqual, E.S., 2002. Idde - uma infra-estrutura para a datação de documentos eletrônicos., Master's thesis, Curso de Pós-Graduação em Ciência da Computação da Universidade Federal de Santa Catarina. [Safford 2002] Safford, D., 2002. The need for TCPA. Technical report, IBM. [Scheibelhofer 2001] Scheibelhofer, K., 2001. Signing XML documents and the concept of "what you see is what you sign". Master's thesis, Graz University of Technology. [Stinson 2002] Stinson, D.,2002. Cryptography - Theory and Practice. Chapman & Hall, 2 edition. [Stallings 1998] Stallings, W., 1998. Cryptography and Network Security. Prentice Hall, 2 edition. [TCPA 2002] TCPA, 2002, Trusted Computing Platform Alliance: Main specification version 1.1b, http://www.trustedcomputing.org/tcpaasp4/specs.asp.

131