Tassos Dimitriou
email: tassos.dimitriou@ieee.org

Ioannis Krontiris
email: ioannis.krontiris@huawei.com

Privacy-respecting Auctions as Incentive Mechanisms in Mobile Crowd Sensing

Keywords: Mobile Crowd Sensing, Multi-attribute auctions, Incentive Mechanisms, Security and Privacy

In many mobile crowdsensing scenarios it is desirable to give micro-payments to contributors as an incentive for their participation. However, to further encourage participants to use the system, one important requirement is protection of user privacy. In this work we present a reverse auction mechanism as an efficient way to offer incentives to users by allowing them to determine their own price for the data they provide, but also as a way to motivate them to submit better quality data. At the same time our auction protocol guarantees bidders' anonymity and suggests a new rewarding mechanism that enables winners to claim their reward without being linked to the data they contributed. Our protocol is scalable, can be applied to a large class of auctions and remains both computation-and communication-efficient so that it can be run to the mobile devices of users.

Introduction

The availability of sensors in today's smartphones, carried by millions of people, has led to a new sensing paradigm, where people provide sensing capabilities to applications in order to map the environment and offer a better understanding of people's activities and their surroundings. This trend is often referred to as Mobile Crowdsensing (MCS) [START_REF] Guo | From participatory sensing to mobile crowd sensing[END_REF] or, using the more general term, as Mobile Crowdsourcing [START_REF] Chatzimilioudis | Crowdsourcing with smartphones[END_REF].

In this paradigm there is a platform provider who publicizes multiple sensing tasks from which people can choose and execute those that match their location and sensing capabilities. However, there are two factors that hinder the largescale deployment of such applications. First, lack of proper incentives does not motivate users to participate, and second, in many cases data coming from users' smartphones can have a large impact on user privacy.

These two issues have been studied separately in existing research. For example, a number of MCS systems started incorporating different incentive features, including various forms of rewards based on monetary [START_REF] Yang | Crowdsourcing to smartphones: Incentive mechanism design for mobile phone sensing[END_REF], social or gamingrelated mechanisms [START_REF] Di | Incentive mechanism for collaborative smartphone sensing using overlapping coalition formation games[END_REF]. The work from Zaman et al. present an overview of many available incentive mechanisms in MCS till today [START_REF] Zaman | Incentive model design for participatory sensing: Technologies and challenges[END_REF]. In particular, micropayments have been shown to be effective in encouraging participation [START_REF] Reddy | Examining micro-payments for participatory sensing data collections[END_REF] and recently Rula et al. [START_REF] Rula | No "one-size fits all": Towards a principled approach for incentives in mobile crowdsourcing[END_REF] presented additional experimental evidence that such a mechanism can increase the productivity of the participants.

One of the challenges in offering micro-payments to contributors is to determine the right amount they expect to receive as a payment for their effort in reporting sensing data. This amount may depend on personal preferences and the perceived cost of their participation, but also on the context and situation users are currently involved which can be different among individuals. One attractive solution to this problem is the use of reverse auctions, where the auction takes place among data providers (sellers) and data requester (buyers) of sensing data [START_REF] Krontiris | Monetary incentives in participatory sensing using multiattributive auctions[END_REF][START_REF] Yang | Crowdsourcing to smartphones: Incentive mechanism design for mobile phone sensing[END_REF][START_REF] Lee | Sell your experiences: a market mechanism based incentive for participatory sensing[END_REF]. This mechanism is more attractive as it eliminates the need for the requester to set or guess the price which users consider reasonable for their data; instead it is the data provider who sets the price for the data it is willing to provide to the requester.

However, as mentioned above, privacy is an important factor that hinders user participation. Indeed, collecting data from users' devices has many privacy implications since user-sensitive information such as daily patterns, location and social relationships can easily be deduced from provided data [START_REF] Christin | A survey on privacy in mobile participatory sensing applications[END_REF][START_REF] Wang | Respecting user privacy in mobile crowdsourcing[END_REF]. It is thus imperative to address privacy in mobile crowdsensing systems. While several efforts already exist that suggest anonymizing users' contributions to protect user privacy (see for example [START_REF] Shin | AnonySense: A system for anonymous opportunistic sensing[END_REF]), it still remains an open problem on how to provide privacy protection when incentive mechanisms are also incorporated in the system.

Our Contribution: In this work, we suggest a privacy-respecting protocol that allows anonymous users to participate in reverse auctions employed by an MCS system. Our protocol consists of two main parts. The first part provides bidders' anonymity for the auction while it offers guarantees in terms of correctness and fairness of the auction process. The second part explores different options of rewarding users and suggests a new mechanism that enables winners of the auction to claim their rewards without being linked to their contributed data. Thus participants can have the highest privacy assurance, while the MCS platform operator can maintain the flexibility of offering incentives to users and encouraging participation. More specifically, our protocol (i) offers strong privacy protection by guaranteeing user anonymity and unlinkability of transactions, (ii) it is scalable and applicable to typical MCS applications, (iii) it offers resilience to compromised or colluding MCS entities, and (iv) it can support any type of reverse auction.

Organization: The rest of the paper is organised as follows. In Section 2, we overview work related to privacy and incentives for MCS systems, while in Section 3, we describe the system and adversarial models for our protocol. In this section we also present a generic auction mechanism that does not take privacy into account. Then, in Section 4, we add privacy by describing a scheme that provides for bidder anonymity in MCS auctions as well as different mechanisms that can be used to reward participating users. In this section we also specify the security properties expected by both the auction and rewarding schemes. The protocols' security guarantees and performance are analyzed in Section 5, while Section 6 concludes the paper.

Related Work

One of the earliest works that addresses the use of incentives for participatory sensing using auctions is [START_REF] Lee | Sell your experiences: a market mechanism based incentive for participatory sensing[END_REF]. Since then several other incentive models based on reverse auctions have been proposed [START_REF] Yang | Crowdsourcing to smartphones: Incentive mechanism design for mobile phone sensing[END_REF][START_REF] Zhang | Free market of crowdsourcing: Incentive mechanism design for mobile sensing[END_REF][START_REF] Koutsopoulos | Optimal incentive-driven design of participatory sensing systems[END_REF]. At the same time, auction theory for electronic commerce continues to advance and multi-attributive auctions have gradually become a research hot spot, incorporating qualitative attributes to decide the winner [START_REF] Pham | Multi-attribute online reverse auctions: Recent research trends[END_REF]. This was shown to have many advantages for the MCS case, too [START_REF] Krontiris | Monetary incentives in participatory sensing using multiattributive auctions[END_REF].

Privacy is an important requirement in auctions which are used to facilitate the trade of goods. For example, Shi [START_REF] Shi | A sealed-bid multi-attribute auction protocol with strong bid privacy and bidder privacy[END_REF] proposes a sealed bid multi-attribute contract auction protocol that pays special attention on bid privacy and bidder anonymity. However, this and previous work [START_REF] Peng | Optimization of electronic first-bid sealed-bid auction based on homomorphic secret sharing[END_REF][START_REF] Brandt | How to obtain full privacy in auctions[END_REF][START_REF] Zheng | First price sealed bid auction without auctioneers[END_REF][START_REF] Nojoumian | Efficient sealed-bid auction protocols using verifiable secret sharing[END_REF] on conducting secure auctions has emphasized on attaining full privacy in which case bids remain secure even after the auction is over. This is typically achieved by distributing trust among bidders or by using multiple auctioneers. As a result, these works rely on heavier cryptographic operations and primitives (e.g. secret sharing techniques, multi-party computations, etc.) and as such they are not considered suitable for the MCS model described here. To this end, we have chosen to protect bids only during the bidding phase. Once this phase is over, all bids are revealed as they don't affect the correctness and fairness of the process or the privacy of users. Some generic privacy-respective architectures for MCS exist that could be of interest in our discussion. For example, Gisdakis et al. [START_REF] Gisdakis | SPPEAR: security & privacypreserving architecture for participatory-sensing applications[END_REF] recently proposed the SPPEAR architecture, which supports anonymous users to contribute to sensing tasks and receive credits, as long as they submit at least n reports. In that sense it supports incentive mechanisms, but it concentrates mainly on the rewarding process.

Another recent work that places emphasis on rewards is given by Li and Cao [START_REF] Li | Providing efficient privacy-aware incentives for mobile sensing[END_REF], who propose two privacy-aware schemes for mobile sensing, where each data provider gets some credit for each contribution they make. The use of these credits/tokens may incentivize users to participate, however no auction mechanism is presented to help improve the quality of data provided.

Finally, Krontiris and Dimitriou [START_REF] Krontiris | A platform for privacy protection of data requesters and data providers in mobile sensing[END_REF] have proposed a solution to protect the privacy not only of data providers but also of data requesters. However, to the best of our knowledge, this is the first work that shows how to integrate more advanced incentive mechanisms, like auctions, in mobile sensing frameworks, while offering strong privacy protection guarantees.

Preliminaries

System Model

We consider a generic Mobile Crowdsensing (MCS) system that consists of the following three actors.

Service Providers: These are the requesters of sensing data. We assume that a requester has a specific budget and wants to collect real-time sensing data from a specific area of interest. To ensure data is real-time, the requester defines short time periods T i , within which data are to be collected from a given area.

Users: They participate in the sensing process using various types of mobile devices such as smartphones or wearable devices. These devices come equipped with different types of sensors such as cameras, microphones, GPS, etc.

Auction Infrastructure: For the sake of modularity we separate this into three different servers, even though they can belong to the same entity: The Task Server, which is responsible of publishing the sensing tasks, the Auction Server, which is responsible for running the auction process, and the Report Server, which collects the reports from the auction winners and forwards them to the Service Provider.

Participating users first contact the task server to see if there are any tasks that match their preferences and context. Then, they decide which ones to download and execute. The advantage of this approach is that users do not reveal private information, like context or location, to the task server in order to execute the sensing task. At the network level, we assume the existence of an anonymizing network which can be used to protect the network identities of the communicating devices as in [START_REF] Shin | AnonySense: A system for anonymous opportunistic sensing[END_REF].

Threat Model

We assume that both internal and external adversaries could try to compromise the system. External adversaries can monitor communications, in order to extract information about user activities. They can also manipulate the collection of information by submitting unauthorized data or replaying data of benign users. Typically, these attacks can be mitigated using traditional cryptographic mechanisms to provide confidentiality and integrity guarantees. External attackers can also target system availability by launching jamming and DoS attacks, but here we assume that these are handled by the network operators and so they fall outside the scope of this work.

Internal adversaries, on the other hand, can be malicious users or MCS system entities that target the auction and/or rewarding processes. For example, adversarial users could try to obtain rewards without offering contributions or could try to double-spend already redeemed quotas. Internal adversaries can also target the privacy of participating users, by trying to profile them and reveal their identities by colluding with other entities in the system. Thus, with respect to user privacy, our goal would be to ensure that bids, reports and rewards cannot be linked to a particular user even if that user has submitted multiple bids and has accepted multiple rewards for the data it has provided. Attacks where malicious users submit false sensing data are outside the scope of this work, as these can be addressed by different methods, such as anonymous reputation schemes [START_REF] Christin | Incognisense: An anonymity-preserving reputation framework for participatory sensing applications[END_REF].

A Generic Auction Mechanism

The goal of this section is to give a description of a generic MCS system, integrating an auction mechanism, without, however, taking privacy concerns into consideration. Then, in the next section, we will pose our security and privacy requirements and add all the mechanisms required.

As we mentioned in Section 2, many auction mechanisms proposed for MCS systems are mainly based on reverse auctions [START_REF] Lee | Sell your experiences: a market mechanism based incentive for participatory sensing[END_REF][START_REF] Yang | Crowdsourcing to smartphones: Incentive mechanism design for mobile phone sensing[END_REF][START_REF] Zhang | Free market of crowdsourcing: Incentive mechanism design for mobile sensing[END_REF][START_REF] Koutsopoulos | Optimal incentive-driven design of participatory sensing systems[END_REF]. However, reverse auctions constitute a sub-optimal solution because they incorporate only the expected price into the user's auction bid and they do not allow participants to negotiate on data quality as well. In MCS applications, sensing data may be of different qualities and this has to be considered in the auction mechanism in order for better data to reach the service providers.

A more general form of auction is the multi-attributive auction, which enables service providers also pose quality criteria on the sensed data they are looking to buy, in addition to the price. This, however, does not affect our privacy solution, which is generic and can work with any reverse auction variant. In Figure 1, we highlight the three main phases of the auction process. The specific steps involved are described below, however for a more detailed discussion the reader is referred to [START_REF] Krontiris | Monetary incentives in participatory sensing using multiattributive auctions[END_REF].

Step 1 : The Task Server (TS) publishes the tasks received by the Service Providers. Once a task is published, the bidding phase for this task begins and lasts for a fixed amount of time T i . This deadline is announced in the description of the task, which also contains other details like the acceptance conditions C i which define the required sensors, termination conditions, etc., and a utility function S(x) for this task, setting the ground for which mobile devices qualify for executing it. The role of the utility function is to allow the service provider to announce its budget and quality requirements in order to be addressed by the mobile user (seller) when bidding for this task.

In summary, each task contains the following information: (i) Geographic area of interest, (ii) Acceptance Conditions C i , (iii) Utility Function S(x), and (iv) Bid duration T i .

Step 2 : The mobile devices periodically check with the Task Server to see if there are any tasks available for them, filtered based on their acceptance criteria which may also include other local, user-defined conditions like remaining battery level of the mobile device, and so on.

Step 3 : If the user/mobile device decides to execute a task, then it bids for it by calculating and sending the value of the utility function S(x) to the Auction Server (AS), during the bidding phase of this task. The value of S(x) is calculated locally at the mobile device, as all necessary information is already available to the device.

One important attribute that affects the calculation of S(x) is the price that the user expects for this task. However, besides the price, additional attributes can be integrated into the bid using multi-attribute auctions. More precisely, a bid can be expressed as a n-dimensional tuple of attributes x i , represented as x = (x 1 , . . . , x n ), which can be weighted together to compute the overall utility of a bid in terms of a utility score.

Typical examples of attributes x i that can be incorporated in the utility function include the distance from the desired location, the location accuracy, the sampling frequency, etc.

Step 4 : Before submitting their bids, the users can see their utility score, and if not satisfied, they can choose to improve it by adjusting the various attributes. For example, a user could set a lower price, move closer to the sensing area in order to provide more accurate data (see Figure 1(a)), and so on. When the utility score can no longer be improved, the bidder submits her bid to the AS (Figure 1(b)). We stress again that the user's bid is not comprised of the actual sensed data but is equal to the computed utility score.

Step 5 : Once the bidding phase for a task is over, the opening phase begins where the winning bidders will be determined. More specifically, the Auction Server determines the winners to be those with the n highest utility scores (n does not have to be equal to 1). These winners are publicly announced by the Auction Server.

Step 6 : The actual sensing data of the winning bidders are submitted to the Report Server (Figure 1(c)). Once the RS verifies the provided data match the utility scores promised in the bid, the winners collect their rewards for this task, typically the price that they have asked for in their bids.

Privacy-respecting Auction and Rewarding Protocols

So far we have not considered security and privacy in the auction protocol. Here we pose such requirements and we demonstrate how they can be satisfied in an efficient way.

The participants of the protocol include the m bidders (potential sellers of sensing data) and the Auction Server (buyer) who will get the data from the bidder(s) with the maximum utility scores. The auction consists of two main phases: the bidding and the opening phase. During the bidding phase, each bidder commits to a bid that is kept secret from the other participants. When the bidding phase is over, the Auction Server (AS) opens the bids and determines the winners with the highest utility scores. These bidders are the winners of the auction and they will be rewarded for their participation once they upload their sensing data.

Security and Privacy Requirements

The following properties are expected from our protocol.

-Correctness and Fairness: The result of the auction is determined according to the rules described in the previous section. In our case the first n < m bidders (e.g. n = 2) that made the highest utility bid win the auction and get rewarded. Additionally, no bidder can obtain an unfair advantage over the rest of the bidders by determining or changing its own bid based on information revealed about other bids. -Bidders' privacy: Bidders remain anonymous throughout the whole process of the auction. This means that the identity of the bidder cannot be linked in any way to the bids they submit. Moreover two different bids from the same user cannot be linked with each other, thus nobody can build a profile and reduce users' anonymity. Finally, the claim of a reward by a winning bidder cannot be linked with either a bid or a user ID. -Confidentiality of bids: All bids remain secret until the opening phase. If the Auction Server (AS) or any other party can recover some of the bids before the opening, he can inform a colluding bidder in order to cheat and win the auction. Contrary to prior work [START_REF] Shi | A sealed-bid multi-attribute auction protocol with strong bid privacy and bidder privacy[END_REF]- [START_REF] Nojoumian | Efficient sealed-bid auction protocols using verifiable secret sharing[END_REF] that requires distribution of shares among participants or the use of heavy zero-knowledge schemes which are not easy to apply in the participatory sensing paradigm, we will develop a lightweight, yet secure protocol, that guarantees bid secrecy up until the opening phase. -Public verifiability: The correctness of the auction process should be easy to verify by any interested party. This includes assurance about the validity of the bids, as well as winner selection. -Non-repudiation: No bidder should be able to change its mind (e.g. deny or modify its bid) once the bid is submitted. Our protocol will ensure this property by requiring the bidders to commit to their bids prior to the opening phase.

Auction Protocol

In what follows we assume that bidders are aware of the public key K AS of the auction server. They can use this to send confidential information to AS and authenticate messages signed by the AS. We denote by H() a secure cryptographic hash function with at least 256 bits of output. In this context 'secure' means that H() is one-way and collision resistant. Thus inverting the hash function or finding x and y satisfying H(x) = H(y) is computationally infeasible. We also assume the existence of a "bulletin board" that is used to communicate messages between the bidders and the Auction Server (AS). Once a message is posted to the bulletin board, anybody (even third-parties) can read it. However, erasing from the bulletin board is not possible. Thus, the bulletin board is nothing more than a public channel where broadcasted messages are received by anybody and can be verified by any third party [START_REF] Cohen | A robust and verifiable cryptographically secure election scheme[END_REF].

The two main phases of the auction are bidding and opening, however, there is also an implicit, registration phase in which the AS sets up the bulletin board, publishes its public key and announces various parameters of the auction like the auction ID, starting/ending time, duration of each phase, and so on. Upon registration, each bidder i sends to the AS a pseudonymous ID (BidderID) to represent its identity during the auction along with a one-time public key K i . AS publishes this information to the bulletin board and every bidder can verify it has been properly registered for the auction.

Bidding: During the bidding phase, each bidder i computes its utility score S i , masks it with a random number r i and sends a commitment C i of the form

C i = Sig i (AuctionID||BidderID||h i ), (1)
where h i = H(S i ||r i ). Thus the auction server receives a bid, however it cannot read this bid before the opening phase. Additionally, these values are published in the bulletin board so that anybody can verify that its bid has been correctly accounted for.

Opening: When the auction server marks the end of the bidding phase, each bidder reveals both S i and r i that have been used in the computation of the commitment C i . The server goes through the values C i and recovers the n highest utility scores as the winners of the auction. Then it sends a signed message

Sig AS (AuctionID, BidderID i1 , K i1 , S i1 , r i1 , BidderID i2 , K i2 , S i2 , r i2 , . . .) (2)
which contains the pseudonymous IDs of the winners along with their public keys and the committed values that have been opened in the beginning of the phase. Thus, any participant can verify correctness by computing H(S i ||r i ) and comparing with the signature C i received during the bidding phase. In the next section we discuss how the winning bidders can be rewarded for the data they provide.

Rewarding mechanisms

Once the winning bidders are selected, they contact the Report Server (RS) in order to transmit their sensed data (recall Figure 1(c)). Each winning bidder i provides RS with the winning notification shown in (2) (alternatively the auction server can forward this directly to the RS) and submits its sensed data as follows:

Bidder i → RS : BidderID, AuctionID, D, σ , (3)
where σ = Sig i (BidderID, AuctionID, H(D)) and D is the sensed data for the relevant task. The Report Server goes on to verify if the signature comes from a winning bidder whose public key is listed in the winning notification shown in [START_REF] Chatzimilioudis | Crowdsourcing with smartphones[END_REF] and evaluates the utility function on the received data D. If the utility score matches the one shown in the winning notification, it proceeds to reward the bidder for the data provided 4 . In the following, we demonstrate how this can be achieved using (i) an existing payment service (e.g. a Bank) along with an e-cash scheme, and (ii) a decentralized token-based scheme.

While the e-cash scheme may be easier conceptually, it suffers from a potential loss of privacy if the report server and the Bank collude together to reveal the bidder's identity. To mitigate this possible loss of trust, we have developed a decentralized variant where the RS is the sole issuer of rewards that can be redeemed by the bidder.

Using e-cash: An e-cash scheme in its general form is a set of cryptographic operations that allows a party S (in our case the report server) to withdraw electronic money from a bank in order to purchase something from a second party B (the bidder), and B to deposit the money in its bank account. E-cash schemes are distinguished between "on-line" and "off-line" ones depending on whether the bank has to be actively involved in the purchase protocol. The auction protocol that we present here works with both schemes, however an offline scheme is more preferable as the bidder does not have to query the bank for the validity of the payment it will receive from the report server. We therefore abstract away the actual implementation details of the digital cash protocol used and describe a coin as tuple c, σ Bank (c) , where c basically denotes the value of the coin and σ Bank (c) is the signature of the bank. Other information such as expiration day, or details that might help in extracting the ID of the owner in case of double-spending are omitted here [START_REF] Chaum | Untraceable electronic cash[END_REF].

Once the Report Server receives the data sent by the winning bidder in message (3), it sends back to the bidder a coin c, σ Bank (c) encrypted with 4 An issue may arise if the provider refuses to reward the bidder after obtaining the sensed data. Although there are cryptographic protocols to mitigate this type of behavior [START_REF] Rial | Optimistic fair priced oblivious transfer[END_REF], we chose to keep the protocol as simple as possible since (i) the damage to the reputation of the provider will be much higher than any gains for data received but not paid, and (ii) the provider runs the risk of losing potential bidders which goes against the idea of introducing payments in the first place as a means to enhance user participation in crowdsensing applications.

the bidder's public key. The value of the coin matches the price agreed in the specification of the utility function. The RS does not need to know who the bidder is, only that it is one of the winners of the auction. The encryption of the coin is required so that only the bidder can recover (and use) the coin. Thus, anyone else who eavesdrops on the communication line cannot steal and spend the coin. The bidder now can either deposit the coin to the Bank or spend it if the coin is transferable. This depends on the underlying digital cash protocol used.

Another alternative, that avoids the use of digital cash but still uses a centralized payment service, is for the Report Server to authorize a payment directly with the bank. In this scheme, the winning bidder computes

µ = F (H(D), N ),
where F is a secure one-way function, D is the data submitted and N is a new unpredictable number. Then it includes µ in the message and the signature σ shown in [START_REF] Yang | Crowdsourcing to smartphones: Incentive mechanism design for mobile phone sensing[END_REF]. Once the Report Server receives and validates the signature, it produces a payment p RS = Sig RS ( H(D), µ, Amount ), where Amount corresponds the price for the data received, and forwards p RS to both the bidder and the payment service. To claim the money from the bank, the bidder has to reveal N used in the computation of µ. Once the bank verifies the signature of RS on p RS and validates µ, it credits the bidder with the specified amount.

Both schemes presented here protect the bidder's anonymity as long as the Report Server and the payment service/Bank do not collude to reveal the bidder's identity. If the payment service is not trusted, we can use a decentralized variant where the bidder itself constructs the coins to be redeemed by the RS. This is explained below.

Using a decentralized scheme: To eliminate the need for a centralized payment service, we can use the Report Server as an issuer of reward tokens that can be redeemed by the bidder. However, since it is the RS who issues these tokens we must be sure that tokens cannot be used to track bidders. A similar token service was developed in [START_REF] Dimitriou | PEPPeR: a querier's privacy enhancing protocol for participatory sensing[END_REF], however for use in a different setting. There, a querier Q wishing to access an MCS network for sensor data could use tokens issued by the application owner to pay for data received by some producer P .

In our setting there is no querier for data, however we can leverage this technology to allow a winning bidder to obtain rewards for the data provided once the auction is over. This approach can still be thought as a lightweight e-cash scheme, yet without the requirement of a trusted payment service. However, in this case, double-spending detection becomes an important property as bidders may be tempted to redeem these tokens more than once. In what follows, we explain how to adapt these ideas to build a rewarding mechanism for auctions. In particular, we will explain (i) how tokens can be constructed during submission of sensing data without compromising bidder privacy, and (ii) how tokens can be redeemed.

Token construction: To create such a token, the collaboration of both the bidder and the Report Server is needed. The bidder has to introduce some private piece of information (a unique ID) to the token T so that upon redemption, the RS can tell if T is already spent. The token will also contain a public part, introduced by the RS, minimally containing the value of the coin but perhaps an expiration date, etc. To make these tokens untraceable, blind signatures will be used to blind the private information introduced to the token by the bidder before it is signed by the RS. When the blinding factor is later removed, the token will bear the signature of the RS but the only identifiable information on the coin will be its public part.

To introduce this unique ID to the token and make double-spending possible, we leverage the identification scheme of Schnorr [START_REF] Schnorr | Efficient signature generation by smart cards[END_REF]. The bidder first selects two primes p and q, where q|p -1. Then it chooses at random two numbers s, r ∈ Z p and computes u = g -s mod p and v = g r mod p, where g is a generator of order q in Z * p . The token ID now is comprised of the two values u and v, which has to be further blinded by the bidder and signed by the RS as mentioned above (details omitted due to space restrictions, however the interested reader is referred to [START_REF] Chaum | Blind signatures for untraceable payments[END_REF]). After the signature by the RS, the bidder will have in its possession a token T of the form

T = Sig RS ( u, v, V alue, Expiration ). (4)
Token spending: When, at some future time t, the bidder wants to spend T , it has to prove it knows s, r. This is possible using a non-interactive zero-knowledge proof. In particular, the bidder sends along with the token T , the pair y, t , where t is the date/time of the transaction, e = H(T, t) and y = r + es mod q.

The RS verifies the authenticity of the token by first checking its signature on T and then wether v = g y u e mod p. If both tests succeed, the token is considered valid. However, RS still needs to check that T has not been used before.

So, RS looks in its database of spent tokens for a token with the same ID u, v . If no such token exists, T is accepted and RS records the tuple T, y, t . If, however, a token T with the same ID already exists, there will be two tuples y, t and y , t of token T such that v = g y u e mod p, v = g y u e mod p, y = r + es and y = r + e s. From these two last values, RS can obtain the secret value s = (y -y )/(e-e ) and subsequently r. Thus, two submissions of the same token will result in evidence that the coin has already been spent. However, as these values are not tied to the bidder's identity, its privacy is maintained even in the case of double-spending.

In summary, the protocol ensures that i) tokens are not tied to bidder identities, and ii) the RS is protected by malicious bidders who try to double-spend tokens. A snapshot of both data submission and token construction phases is shown in Figure 2 ------------------------------→ Verify signature σ.

Is Bi a valid winner? Pick random numbers s, r ∈ Zp Set u = g -s mod p, v = g r mod p Create blinded token ID u * , v * Obtain blind signature 1b: ------------------------Remove blinding factor T okenT = SigRS( u, v, V al, Exp ) Fig. 2: Data Reporting and Token Generation.

u * , v * ------------→ Send signed, blinded token 2: SigRS( u * , v * , V al, Exp ) ← -

Evaluation

In this section we first emphasize on how our solution satisfies the security and privacy requirements posed in Section 4.1. Then, we also discuss performance issues.

-Confidentiality of bids. Since bids are opened only after the bidding phase, nobody can compute the bids before they are opened. This is because the bids at this time consist of only a commitment of the form h i = H(S i ||r i ). The one-wayness of the hash function H ensures that bid values remain hidden, eliminating the possibility of collusion since no bidder or the Auction server can leak any information about anybody else's bidding. It is only after the opening phase that bids are revealed to all. -Correctness & Verifiability. Since all values are published in the bulletin board anybody can verify the correctness of the auction. This is possible as all bidders reveal their utility scores S i and the random numbers r i used in the computation of the signed bid commitment h i . Hence no new values can be introduced at this point (all values must already exist in the bulletin board) or changed (due to the collision resistance of the hash function H). A value that is not available in the bulletin board at the end of the opening phase automatically excludes the bidder for the remaining of the auction. Additionally, anybody can compare and verify if the winning bidders published in message (2) by the AS are indeed the ones with the highest utility scores. Thus, correctness of the auction is assured. -Non-repudiation. Since each bid carries the bidder's signature, nobody can deny its bid. The collision resistance of the hash function also ensures that it is not possible to find a different set of (S i , r i ) such that H(S i ||r i ) = H(S i ||r i ). Hence nobody can deny its bidding price once the bids are opened. Furthermore, if a dispute arises over the winning bids, the bid commitment can be used to resolve the dispute: the values (S i , r i ) and the bidder's signature can be used to prove authenticity of a bid.

-Unlinkability between bids. This property is related to the privacy of the bidder. In particular, we would like to be sure that it is not possible to relate two bids submitted at different auctions by the same bidder. It should be clear that this property holds as bidders participate in auctions using different pseudonyms and public keys. Hence it is not possible to relate the bids. 5-Unforgeability/Unreusability of tokens. The zero knowledge proofs used during token spending ensure that only a bidder who knows the representation of u and v in the token ID can supply these proofs. Furthermore if the bidder supplies two different proofs for the same token, the secret values r, s used in the construction u and v can be extracted, thus providing a proof of doublespending. Thus, a token can be used only once, satisfying the unreusability property.

-Bidder privacy/Unlinkability of tokens. When a user tries to redeem a token and provides the server (directly or indirectly through a proxy) the zero knowledge proof, the server cannot tell which bidder created the token as the only visible part during the token construction is the public part V al, Exp of the token.

There are, however, other side channels that can be used to infer bidder information. Consider, for example, the case where the IP address of a bidder is visible when the user submits sensed data/retrieves a token to/from the server and then tries to spend this token. Obviously, in such a case additional mechanisms are required to ensure that a connection cannot be made with the reporting bidder. However this can be avoided by using an anonymizing network at the network layer, as we mentioned in our system model.

Another side channel is the structure of the token's public part V al, Exp . If the value of the token or its expiration date is an unusual quantity, both can be used to associate the data with the bidder upon redeeming the token. Hence these values must be drawn from a universe that does not allow for this kind of discrimination. For example, expiration dates can be set to the end of the current year and token values can be coarsely defined. This would exclude tokens with unusually precise values, e.g. $1.236743. A simpler alternative, however, is to use a trusted proxy or representative that can redeem these rewards on behalf of a user.

Performance

The bid submission protocol is very simple, requiring the submission of just a single message (recall the bidding message shown in ( 1)). The bidder has to compute a hash value H(S i ||r i ) on the utility score S i and random r i , along with a signature C i on this data. A typical signature using a 1024-bit signing key on a 450MHz processor takes approximately 30ms as shown in [START_REF] Lauter | The advantages of elliptic curve cryptography for wireless security[END_REF], which is well within the capabilities of modern-day phones incorporating much faster CPUs. Similarly, the opening phase requires one more message in which each bidder reveals the committed values S i and r i .

Perhaps it is more instructive to consider the token rewarding protocol we developed in Section 4.3, as this actively involves the bidder in the token generation process. Here we argue that the most expensive operation is the actual transmission of the sensed data submitted by the user (Step 1a in Figure 2). The creation of the token requires two modular exponentiations for u and v, and two modular multiplications for the blinding and unblinding of the u * and v * . However, these operations are well within the capabilities of modern phones as mentioned above. Token redemption requires the user to prove knowledge of the values u and v, however this requires only one extra addition and multiplication to compute T, y, t . The burden is on the side of the server who has to verify the corresponding signature, but this overhead is negligible given the capabilities of the RS.

Finally, from a storage point of view, the server has to maintain only the collection of tokens that have not expired yet. As the sensor data collected along with these tokens are perhaps orders of magnitude larger, the overhead for the Report Server is again minimal.

Conclusions

In this paper we have presented a protocol for privacy-protecting auctions in mobile crowdsensing systems. Users of mobile devices can participate anonymously in the auctions and define the price they expect for contributing sensing data. On the other side, the buyer of the data can select the winners based not only on the price, but also on the quality of the offered data. The winners of the auction can then collect their price without linking their real identity to the data they contributed. Our solution uses a lightweight and decentralized rewarding scheme eliminating the need for a single trusted payment system.

As future work, we plan to extend our protocol to address some research questions that remain open. In particular, we plan to incorporate a mechanism for encouraging users who lose the auction, to return, so that the system maintains its base of participants. We also think it is important to include user credibility as one of the attributes that determine the winners of the auction. In order to do that, we plan to show how to integrate an anonymous reputation mechanism in our auction protocol so that winners can collect reputation points based on the quality of their submitted data.

Fig. 1 :

 1 Fig. 1: Acquisition of sensing data.

  (although Steps 1a and 1b are shown separate for presentation clarity, they can be merged into one.) Winning Bidder Bi Report Server RS Data submission and token generation D is the sensed data Set σ = Sigi(BidderID, AuctionID, H(D)) 1a: BidderID, AuctionID, D, σ -

This, however, necessitates the use of an anonymity service so that bid submissions cannot be linked to an internet identifier such as the IP address of the bidder. Hence the use of services like TOR mentioned in the system model.

Acknowledgments

The first author would like to acknowledge support of this work by Kuwait University, Research Grant No. QE 01/13.


Miguel Morales-Sandoval

Arturo Diaz-Perez

DET-ABE: a Java API for data confidentiality and fine-grained access control from Attribute Based Encryption

Keywords: pairings, cryptographic API, attribute based encryption Groups, Finite Fields, Elliptic Curves, Pairings: Theorems and Axioms Arithmetic operators: MUL, DIV, INV, ADD, SUB, SQR, EXP, PAIRING Pairing Based Cryptographic Schemes: encryption, digital signature PBC protocols: information security services End-user Applications Protocols providing information security services Encryption and digital signature, egovernment Layer 5

Many works in the literature have proposed information security mechanisms relying on Paring Based Cryptography (PBC), for example, Ciphertext Policy Attribute Based Encryption (CP-ABE). However, a public set of software modules that allow integrating that kind of encryption for data security of information systems in an easy and transparent way is still missing. Available APIs like PBC (C-based) or jPBC (Java-based) are focused on low level arithmetic operations and several non trivial issues must still be addressed to integrate a functional PBC/ABE scheme into end-user applications for implementing end-toend encryption. We present a novel and portable Java library (API) to ensure confidentiality and access control of sensitive data accessed only by authorized entities having as credentials a set of attributes. Novel encryption and decryption processes are defined, using the digital envelope technique (DET) under a client-server computing model. The new DET-ABE scheme supports standard security levels (AES encryption) and provides the user with an easy interface for transparent use of next generation cryptography, hiding the complexity associated to PBC (field and group arithmetic, curve selection) and ABE (setup, key management, encryption/decryption details). Running times of main API's modules at server (ABE setup and key generation) and client (DET-ABE encryption/decryption) side are presented and discussed. From these results, it is concluded that the proposed API is easy to use and viable for providing confidentiality and access control mechanisms over data in end-user applications.

Introduction

Since ancient times, human beings have had the necessity to protect information in a way that only authorized entities have access to it. Nowadays, cryptographic schemes are vital to provide information security services to IT applications, such as confidentiality, integrity, authentication and non-repudiation [START_REF] Menezes | Handbook of Applied Cryptography[END_REF]. A relative novel field in cryptography is Pairing Based Cryptography (PBC) [START_REF] Boneh | Pairing-based cryptography: Past, present, and future[END_REF]. It is based on mathematical mappings defined on algebraic structures of abstract algebra. PBC provides elegant solutions to open problems of the past, such as Identity Based Encryption [START_REF] Boneh | Identity-based encryption from the weil pairing[END_REF], where cryptographic operations are performed in function of the public identity of participants. Thus, under this approach digital certificates and their costly PKI (Public Key Infrastructure) are not required [START_REF] Braun | Trust views for the web PKI[END_REF].

Research on PBC has increased recently. Currently, there are academic forums completely dedicated to it as the Pairings1 and ECC2 Conference series. A useful web resource for PBC is The Pairing-Based Crypto Lounge Barreto's website 3 . Attribute Based Encryption (ABE) [START_REF] Sahai | Fuzzy identity-based encryption[END_REF][START_REF] Goyal | Attribute-based encryption for finegrained access control of encrypted data[END_REF] is a kind of public key encryption constructed over the foundation of PBC. ABE is a relatively new research topic, ideal to provide a fine-grained and non-interactive access control mechanism of encrypted data. Although several contributions on ABE exist at theoretical level, there are very few on the practical side [START_REF] Pang | A Survey of Research Progress and Development Tendency of Attribute-Based Encryption[END_REF].

Secure end-user applications as e-mail, e-payment, e-government, etc., can be seen as several layers, where the upper ones rely on the security and efficiency of the lower ones. Using PBC, the layered view of a secure application can be seen as shown in Figure 1.

In the past, some software modules have been published and made available for the community to serve as building blocks in the construction of applications at upper layers. Two of the most known are PBC [START_REF] Lynn | On the implementation of pairing-based cryptosystems[END_REF] and jPBC [START_REF] De Caro | jPBC: Java pairing based cryptography[END_REF]. Others for example, have been proposed to target specifically computing constrained devices [START_REF] Ambrosin | On the feasibility of attribute-based encryption on smartphone devices[END_REF][START_REF] Liu | Android PBC: A Pairing Based Cryptography toolkit for android platform[END_REF][START_REF] Picazo-Sanchez | Secure publish-subscribe protocols for heterogeneous medical wireless body area networks[END_REF][START_REF] Xiong | TinyPairing: A Fast and Lightweight Pairing-Based Cryptographic Library for Wireless Sensor Networks[END_REF]. However, these APIs are mainly focused for layer 2 of Figure 1 and provide some specific implementations for layer 3, leading to a gap for an easy incorporation of PBC and ABE in IT information systems at layer 5. Unlike other public key cryptosystems, as RSA [START_REF] Rivest | A method for obtaining digital signatures and public-key cryptosystems[END_REF], the mathematical background of PBC (Cyclic Groups, Finite Fields, Elliptic Curves, modular arithmetic, pairing computation,...) could be a complex subject for IT engineers without a cryptography specialization that want to use and integrate PBC-based protocols to enable security services in their applications. Going from layer 3 to layer 5 implies several important issues related to security and efficiency when using pairings in cryptography [START_REF] Galbraith | Pairings for cryptographers[END_REF]. That decision taking could discourage IT engineers to use PBC.

This paper is mainly for IT engineers who are interested in using Pairing Based Cryptography and Attribute Based Encryption to provide security information services in IT systems. The aim of this work is to contribute to reduce the gap between the pairing based cryptographic foundation and the practical use of it. As main contribution, this work presents the design and implementation results of a set of classes written in Java that encapsulate the implementation details from layer 1 to layer 4 in Figure 1 (underlying algorithms, security parameters, type and size of the elliptic curve) and provide an easy interface to IT security implementers for using this type of next generation encryption at layer 5 in Figure 1.

The novel security modules proposed in this work are based on the Digital Envelope Technique (DET) [START_REF] Rosenberg | Handbook of Financial Cryptography and Security[END_REF]. In this work, an AES-key k used for bulk encryption [START_REF] Miller | Advanced Encryption Standard[END_REF] is protected by means of CP-ABE encryption [START_REF] Bethencourt | Ciphertext-policy attribute-based encryption[END_REF], which is a specific type of ABE. Once encrypted, the encrypted data (with AES) together with the encrypted AES-key (with CP-ABE) can be securely distributed over insecure networks or stored in a honest but curious untrusted third party (i.e Cloud storage provider). Thus, DET allows to achieve confidentiality and CP-ABE enable fine-grained control access mechanisms. Only those authorized entities with a valid set of attributes could decrypt and recover the AES-key k to launch the AES decryption process over the encrypted data. Under this solution approach, typical applications as securing digital medical records or storing and sharing of digital documents in the Cloud could be easily implemented. As an application example, in this paper we provide a performance evaluation of the proposed security modules for encryption and decryption of digital documents (.doc and .pdf files). Due to the layered and highly modular design of the publicly available set of software modules, they can be further optimized to meet specific timing requirements.

The rest of this paper is organized as follows. Section 2 presents main aspects related to the use of pairings in cryptography as well as the general concept of Attribute Based Encryption. Section 3 describes the proposed approach for new DET-ABE encryption and decryption using pairings. Section 4 describes with details the design of the proposed set of Java classes that implement DET-ABE with PBC. Also, this section shows a practical use of the proposed API for confidentiality and access control of digital documents. Section 5 presents and discusses the running time of the main software modules for setup, encryption, decryption and key generation. Finally, section 6 gives the concluding remarks of this work and points out future work.

Foundations of PBC and ABE

A cyclic group G is a set of elements S together with a binary operation ⋄ where exists an element g ∈ S such that for all h ∈ S, h can be obtained by applying the operation ⋄ over g d -1 times [START_REF] Escofier | Galois Theory[END_REF][START_REF] Herstain | Abstract Algebra[END_REF] (d is a positive integer number). This is denoted as h = g d using a multiplicative notation or h = d × g using an additive notation. The element g is named generator of G and written as G =< g >. The most common cyclic group is Z r = {0, 1, ..., r -1}, where r is a prime and ⋄ is the addition modulo r operation, being r the order of Z r .

Let G 0 =< g 0 >, G 1 =< g 1 >, and G T be cyclic groups of prime order r. A bilinear pairing or bilinear mapping is an efficient computable function e : G 0 × G 1 → G T , such that:

1. ∀a, b ∈ Z r , e(g a 1 , g b 2 ) = e(g 1 , g 2 ) ab 2. e(g 0 , g 1 ) = 1
The tuple (r, g 0 , g 1 , G 0 , G 1 , G T ) defines an asymmetric bilinear pairing. If G 0 = G 1 = G, and G =< g >, the tuple (r, g, G, G T ) defines a symmetric bilinear pairing [START_REF] Galbraith | Pairings on Elliptic Curves over Finite Commutative Rings[END_REF].

In practice, many cryptographic protocols based on pairings have used a subset of points in an elliptic curve [START_REF] Galbraith | Pairings for cryptographers[END_REF] as the cyclic group G . An elliptic curve E(F q ) is a set of pairs (x, y), with x, y elements of a finite field F q satisfying an elliptic curve equation E(x, y). The properties of such equation categorize the elliptic curve and determines its secure properties for practical use in cryptographic applications. So, in practice, pairings G 0 and G 1 are subgroups of the elliptic curve E(F q ) and G T is a subgroup of F * q k (an extension field of F q ). The number k is named the embedded degree. The security parameters to take into account when defining a paring over elliptic curves are: the size q of the finite field F q , the embedding degree k, and the order l of G 0 , G 1 , and G T . These security parameters must be chosen carefully to ensure that the discrete logarithm problem is hard to compute in the three groups.

In our proposed set of security modules, the selection of this security parameters and the corresponding pairing is transparent to the programmers. The parameters selection is in function of the security level chosen by the programmer, which is one of those recommended by international standards, as the National Institute for Standards and Technology (NIST): 80-bit (low-term security, not recommended anymore), 128-bit (minimum security level), 192-bit (mid-term security), and 256-bit (long-term security) [START_REF] Barker | Recommendation for Key Management Part 1: General(Revision 3)[END_REF]. In our proposed DET-ABE scheme, programmers only need to specify the security level to use, the pairing security parameters will be selected internally.

Attribute based encryption

Firstly introduced by Sahai and Waters [START_REF] Sahai | Fuzzy identity-based encryption[END_REF], Attribute-based Encryption (ABE) is a mean for complex access control on encrypted data. In this kind of cryptography, ciphertexts are not necessarily encrypted to one particular user as it occurs in traditional public key cryptography. Contrarily, ciphertexts and their corresponding private keys that decrypt them are associated with a set of attributes or a policy over attributes. This way, if there is a match ciphertext-private key, the ciphertext will be decrypted by that private key. In [START_REF] Bethencourt | Ciphertext-policy attribute-based encryption[END_REF], Betancourt et al., present Ciphertext-Policy Attribute-Based Encryption (CP-ABE), a method conceptually closer to traditional access control techniques such as Role-Based Access Control (RBAC). In CP-ABE attributes are used to describe users credentials, and an entity encrypting data determines a policy for who can decrypt. When an entity encrypts data, it specifies an associated access structure over attributes. This case, any other entity will only be able to decrypt a ciphertext if that entity's attributes pass through the ciphertexts access structure. What Betancourt et al proposed as access structure is a tree structure where its nodes represent threshold gates (AND, OR) and the leaves describe attributes. An AND gates is constructed as n-of-n threshold gate and an OR gate is a 1-of-n threshold gate. Generalizing, threshold gates are of the form m-of-n. Complex access controls including numeric ranges are also addressed by converting them to small access trees.

Basic modules in CP-ABE are constituted by four fundamental algorithms [START_REF] Bethencourt | Ciphertext-policy attribute-based encryption[END_REF]:

1. ABE-Setup: Select an elliptic curve and the associated security parameters to define a pairing. As it was stated previously, it is the tuple (r,g 0 ,g 1 ,G 0 ,G 1 , G T ). With the pairing and associated cyclic groups, this module produces a public key PK and a secret master key MK.

ABE-Encrypt:

The encryption algorithm uses P K to encrypt a message M under an access structure A over the universe of attributes U . As a result, the ciphertext is CT, which will be only decrypted by an entity possessing a set of attributes S that satisfies the access structure A. It is assumed that CT implicitly contains A.

ABE-KeyGen:

The key generation algorithm uses MK to produce a private key SK, related to a specific set of attributes S. 4. ABE-Decrypt: The decryption algorithm uses PK and SK associated to a set of attributes S to decrypt a ciphertext CT, which contains an access structure A. If S satisfies A, this module will decrypt CT and return the original message M .

The main components of CP-ABE are described in Table 1, considering both symmetric [START_REF] Bethencourt | Ciphertext-policy attribute-based encryption[END_REF] and asymmetric pairings [START_REF] Jahid | Easier: Encryption-based access control in social networks with efficient revocation[END_REF].

The construction of the CP-ABE modules involve many computations over groups and finite field (some of them are shown in Table 1). In the proposed set of security modules, all these computations are encapsulated and hidden from user. As part of CP-ABE encryption and decryption, main operations include tree traversal, boolean function (policy) evaluation, hashing and creation of private keys by computing several pairings, polynomials generation and evaluation, and computation of Lagrange's coefficients. All those operations as well as the internal representation and the storing and recovery processes of main components in CP-ABE (PK, SK, CT, MK) are not required to be understood by CP-ABE users. In our proposal, these modules are treated as blackboxes.

D = g (α+r)/β , ∀j ∈ S: D = g (α+r)/β 1 , ∀j ∈ S: dj = g r × H(j) r j dj = g r 1 × H(j) r j d ′ j = g r j d ′ j = g r j 0 r, rj ∈ Zr (random) r, rj ∈ Zr (random) H : {0, 1} * → G H : {0, 1} * → G1 CipherText CT {A, C ′ , C}, where {A, C ′ , C}, where C ′ = M × e(g, g) αs , C ′ = M × e(g0, g1) αs C = h s C = h s ∀ leaf node y ∈ A,
∀ leaf node y ∈ A, having j ∈ S, compute: having j ∈ S, compute: Cy, C ′ y , where Cy, C ′ y , where Cy = g qy (0) Cy = g qy (0) 0 3 Security services from the digital envelope concept with PBC and ABE

C ′ y = H(j) qy (0) C ′ y = H(j) qy (0) H : {0, 1} * → G H : {0, 1} * → G1 Access Structure A
The digital envelope technique (DET) [START_REF] Rosenberg | Handbook of Financial Cryptography and Security[END_REF] is a method for key exchange, not used by all key exchange protocols [START_REF] Diffie | Authentication and authenticated key exchanges[END_REF]. DET is used generally for secure transporting of a session key, that is, a secret key to be used by a symmetric encryption algorithm for protecting all traffic exchanged by a sender and receiver in a communication session. In DET, the secret key is usually encrypted with public-key cryptography (PKC). One advantage of DET is that end-users may switch secret keys as frequently as they would like. Switching keys often is beneficial because it is more difficult for an adversary to find a key that is only used for a short period of time. Another advantage of DET is the increase in performance which is obtained by using symmetric ciphers to encrypt the large and variably sized amount of message data, reserving PKC for encryption of short-length keys. In general, symmetric ciphers are much faster than public key cryptosystems [START_REF] Menezes | Handbook of Applied Cryptography[END_REF].

So, in this work, data (text, image, sound, video,...) is encrypted using as symmetric cipher the Advanced Encryption Standard (AES) [START_REF] Miller | Advanced Encryption Standard[END_REF] in a way that the AES session key is protected and securely embedded in the ciphertext by using CP-ABE encryption. In this work, we re-define each main module in the original CP-ABE scheme by Betancourt et al. in [START_REF] Bethencourt | Ciphertext-policy attribute-based encryption[END_REF], leading to new building blocks for data encryption using the digital envelope technique with CP-ABE, we name it DET-ABE.

DET-ABE Setup

Setup involves the selections and settings for PBC and ABE. This includes the selection of the elliptic curve and the associated security parameters to define a pairing. The setup is performed in a trusted third party, that is responsible of generating and managing the public key PK and a secret master key MK.

In DET-ABE setup, the single parameter specified by the user is the security level to use in the encryption process. That security level is one recommended by the current standard for symmetric encryption, AES. According to NIST, security can be either minimum (128 bits), medium (192) or high (256). The elliptic curve and associated security parameters are internally selected to be consistent with the security level required. Table 2 shows the association of a given AES security level with a set of elliptic curves recommended for use in PBC and ABE. As it has been demonstrated and well documented in the literature [START_REF] Lynn | On the implementation of pairing-based cryptosystems[END_REF], the best attacks over the groups with prime order r defining the pairing require √ r operations, so at least the order of G 1 , G 2 , G T is twice the security level to achieve. Pairing-based cryptographic settings given in Table 2 ensure that the discrete logarithm problem will be intractable in each group G 0 , G 1 , G T . In our construction, we have selected type A curves with embedding degree k = 2 for the security level of 128. This curve defines a symmetric pairings (G 0 = G 1 = G). Also, the type F curves also known as Barreto-Naering (BN) curves [START_REF] Barreto | Pairing-friendly elliptic curves of prime order[END_REF] having embedding degree of 12 are used for the security levels 192 and 256 bits.

AES

In this work, the generation of PK and MK are based on the definition given in [START_REF] Bethencourt | Ciphertext-policy attribute-based encryption[END_REF] when using type A elliptic curves. For the case of type F curves defining an asymmetric pairing, PK and MK are derived as previously defined in [START_REF] Jahid | Easier: Encryption-based access control in social networks with efficient revocation[END_REF].

As in CP-ABE, the DET-ABE setup module is executed in the trusted third party (server). As part of the DET-ABE setup process, a set of attributes U containing N distinct strings must be defined and administrated in the trusted entity.

DET-ABE encryption

DET-ABE encryption is a client module of the trusted entity that encrypts a sequence of bytes (data) specified in a binary file. Main tasks in this module include:

1. Internally, an AES-key (k) is generated from a security level s given by the user. 2. With k, AES is used to encrypt data producing the ciphertext CT AES . 3. Then, CP-ABE is used to encrypt k, given a policy P over a set of valid attributes S. Being P a boolean expression over S, it is evaluated to be logically well formed and the corresponding access structure A is generated.

With A, k is encrypted using CP-ABE and the resulting ciphertext CT is stored together with CT AES and the policy A in a binary file. 4. For CP-ABE encryption, the client connects to the trusted third party (server) to retrieve the public key PK created during the DET-ABE setup module and associated to the security level s. 5. The policy P is specified by the client, and the attributes are retrieved and validated from the server. 6. The result is the tuple T E = {CT AES , CT, A, s}.

The client executing the DET-ABE encryption module requires three elements: the data to encrypt, the security level s (see Table 2), and the policy P as a boolean expression of valid attributes S. The tuple T E resulting from the DET-ABE encryption process can be either stored locally in the client side or uploaded to a public repository.

DET-ABE decryption

The DET-ABE decryption module is used to decrypt previously encrypted data represented by the tuple T E = {CT AES , CT, A, s}. The following tasks are performed during the execution of DET-ABE decryption:

1. The decryption client process requires T E and the list L of user's attributes. 2. The decryption client starts a connection with the trusted third party (server), asking a private key from L. The client sends L to the server and the security level s ∈ T E . 3. The server (trust party) validates the user's attributes L. The pairing parameters (curve type) associated to s are selected in the server side and the corresponding private key SK is computed by the server using those settings. SK is send back to the client together with the public key PK associated to s.

Proposed API for DET-ABE

Our proposal is to integrate the concept of DET and CP-ABE in a set of software modules as a kind of middleware that allows programmers to build secure applications by mean of data encryption over a policy and a set of attributes.

Figure 2 shows the layered view of modules needed to construct and execute secure applications based on the DET-ABE scheme proposed in this paper. The proposed set of security modules are written in Java and built on top of the jPBC library [START_REF] De Caro | jPBC: Java pairing based cryptography[END_REF] that performs low level finite field, group and pairing computations. The use of Java allows a broader range of applications as the security scheme is able to be used over different platforms (server, desktop, mobile).

Attributes management

Attributes management and how policies are constructed are dependent on the end-user application. Although attributes can be administrated in the trusted authority responsible for DET-ABE setup and key management, another trusted entity could be used specifically for attributes management. This entity (AA authority) should be responsible for registering and authenticating users in DET-ABE, either those that encrypt data (producers) or those that access encrypted data (consumers). When a user registers itself with the AA entity, a set of attributes are assigned to it, depending on the application specifications. For an authenticated producer U p , it is the AA entity that authorizes the encryption operation by providing it the attributes required to construct the policy needed by DET-ABE encryption. In the case of an authenticated consumer U c , the AA entity authorizes the decryption process by giving U c its corresponding attributes, assigned according to the user application restrictions. Communication between the AA entity and the user must be secured for example using TLS/SSL.

The server side

The server modules run in a trusted central authority as specified in the CP-ABE scheme. Communication between the server and clients is secured by means of the SSL/TLS protocol. The server is able to manage the three security levels in Table 2, having a specific set of curve parameters for each of those. That selection is based on recommended elliptic curves in [START_REF] De Caro | jPBC: Java pairing based cryptography[END_REF] and [START_REF] Lynn | On the implementation of pairing-based cryptosystems[END_REF]. The server executes the DET-ABE setup module and generates CP-ABE private keys for clients executing DET-ABE decryption. The server keeps a pair {PK, MK} for each security level supported. When clients connect to the server, they inform the security level to use and the server uses the correct curve parameters and keys. If keys are not already created for the demanded security level, the DET-ABE setup for that specific security level is launched.

The client side

A client properly authenticated in the AA entity can execute the DET-ABE encryption or decryption modules. In any case, a secure connection is established with the server at a specific port. During an encryption operation over a tuple T E , the client asks the server for the public key PK associated to the security level s ∈ T E . Also, the client constructs and validates the policy P . As PK is public, it is cached in the client side for future encryption operations using the same security level s. All the encryption operations (AES and CP-ABE) are executed in the client side. During a decryption operation, the client sends to the server the security level and its set of attributes, previously retrieved in a secure manner from the AA entity. The server constructs the private key from the client's attributes and returns that key to the client. All the main decryption operations are performed in the client side. Exceptions could be thrown during a DET-ABE encryption or decryption process due to connectivity problems. On success, during an encryption operation a file with extension .detabe is created containing the serialized version of tuple T E . In a decryption operation, the .detabe extension is removed from the input file, which contains the decrypted data of CT AES ∈ T E .

Keys management

The PK and MK keys are generated in the server side according to the arithmetic operations shown in Table 1. All the resulting values that characterize these keys are stored in server (trusted authority) only. The random numbers α and β used for their creation are local variables that are destroyed after the keys are created. While PK can be read by the server and sent to clients performing an encryption operation, MK is used exclusively in the server side. The private keys for clients used in CP-ABE are created only in the server side and securely sent to clients.

Using the proposed API

In this section we show how the proposed API for DET-ABE can be used. We target the application of encryption and decryption of digital documents (.doc, .pdf). After encrypting these files they can be either locally saved in the client or stored at a cloud storage provider. The DET-ABE encryption of a digital document is shown in Listing 1.1. The encrypt() method of objetc cipher at line five in listing 1.1 implements all the logic specified in section 3.2. What is only specified by the programmer is the file to be encrypted (contract.pdf), the security level (128 bits) and the policy ((directive AND level = 7) OR (accountant AND level >= 3), with four attributes). An exception can be thrown at line five in the following cases: i) the given security level is not supported, ii) the policy is a bad boolean equation, and iii) the attributes are not previously registered in the server. The result of encrypt() method is the encrypted file contract.pdf.detabe.

The DET-ABE decryption of the file privateLetter.doc.detabe is shown in Listing 1.2. For decryption, the client only provides to the server its set of attributes. The server validates them and generates the corresponding private key for the client. The input encrypted file privateLetter.doc.detabe contains the ABE ciphertext, the the access structure, and pairing parameters. With all these elements together with the received private key from the server, the client recovers the original file privateLetter.doc performing all the steps described for DET-ABE decryption in section 3.3.

Before running the client programs the server must be launched, for example, by executing java com.detabe.server.ABETrustedAuthority. Also, in the client side the configuration file configuration.cfgt must have the correct IP or host name where the server (trusted authority ) is running.

Implementation and performance results

In this section we present the running times of the main modules in the proposed API. The experimentation was carried out on a desktop machine 32-bit Intel Core2 Quad 2.40GHz, 4GB RAM with Windows7 as operative system. The main objective to present the execution time of DET-ABE scheme is to show the feasibility of using the proposed API in IT end-user applications. Further optimizations could be done over specific modules in order to get the API running faster. The implementation of classes described in Figure 3 were built on top of jPBC, a Java API [START_REF] De Caro | jPBC: Java pairing based cryptography[END_REF] that provides specialized modules for pairing computations and is defined over PBC [START_REF] Lynn | On the implementation of pairing-based cryptosystems[END_REF].

All classes shown in Figure 3 except AES were implemented and validated. For AES, we use the implementation provided by Java in the packages javax.crypto and javax.crypto.spec. To support security levels above 128-bit, we use the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. All modules were integrated and the execution paths of DET-ABE main modules were validated performing unit and functional tests, ensuring that the result of each cryptographic function was correct.

In all tests, the client and server run on the same machine. Table 3 shows timing result of the DET-ABE setup module, that comprises of pairing parameters, the master and the public keys. That module is executed once, and the previously generated keys are chosen and used by each client connection for DET-ABE encryption or decryption. Figure 4 shows the running time for DET-ABE encryption, DET-ABE decryption and CP-ABE key generation. For all experimentations, we used a PDF document of size 182Kbytes and considered the three standard security levels of 128-bit (symmetric pairing with type A elliptic curve), 192-bit, and 256-bit (asymmetric pairing with type F elliptic curve). The size of data being encrypted does not impact significantly the overall timing of DET-ABE as the number of attributes and security level do. Data size only affects the running time of the block cipher AES, which is proved to have a complexity O(1) [START_REF] Daemen | The Design of Rijndael[END_REF].

Figure 4 a) shows the running time for DET-ABE encryption. Note that more considerable time is spent in case of using a symmetric pairing (128-bit security). While a linear time with respect to the number of attributes is demanded for 128-bit encryption, that is not true for 192-bit and 256-bit. The same behaviour is exhibited in Figure 4 b), that shows the time required for CP-ABE private key generation. Figure 4 c) shows the decryption time. For 128-bit and 256-bit security levels the time is very similar whereas a security level of 192-bit achieves the better timing. Finally, Figure 4 d) contrasts the timing for each DET-ABE operation considering the three security levels. For this last experiment, a PDF file of 182Kbytes size and 6 attributes were used.

As it is observed, 128-bit encryption and private key generation using type A elliptic curves are by far the most time consuming operations. In case of 192-bit and 256-bit security levels, significant reduced time is obtained except for DET-ABE decryption, which remains with high timing costs. As it was previously stated, the proposed modules can be optimized to reduce the timing, for example, the optimized versions of jPBC can be used to speed up the low level operation (abstract algebra arithmetic).

Conclusion

We presented a set of Java classes aiming to reduce the existing gap for using Pairing Based Cryptography (PBC) and Attribute Based Encryption (ABE) in end-user IT applications. We presented the DET-ABE scheme for data encryption over a set of attributes, thus providing confidentiality and fine grained access control under an end-to-end encryption approach. DET-ABE is the result of using the Digital Envelope Technique (DET) together with CP-ABE and AES. The proposed DET-ABE software modules are built on top of libraries for low level computations in finite fields and groups. The complexity associated to the operations and settings for a secure implementation of cryptographic algorithms (adequate pairing parameters as the elliptic curve type and properties) are encapsulated in the proposed API, facilitating the use of those modules in end-user applications. The efficacy of proposed software modules was verified in a simple application for securing digital documents. Further optimizations specially at low level modules can be done to outperform the achieved running times, which have shown to be viable in practical applications. Future work is planned to explore implementation alternatives of the proposed API, for example with multi-threading programming using GPUs and multi-cores as underlying computing platforms to speed up the execution time of DET-ABE modules. As the running time also depended on the pairing parameters and elliptic curves used, further research will be conducted to explore other elliptic curve types to achieve faster computations, for example, to use alternative elliptic curves for the 128-bit security level.

Fig. 1 :

 1 Fig. 1: Layered view of secure end-user applications based on Pairing Based Cryptography (PBC).

  Tree structure where each internal node represents a k-of-n gate, and leaves represent attributes.

4 .Fig. 2 :

 42 Fig.2: a) Layered view of components for building secure applications using the digital envelope technique (DET) with AES and CP-ABE. b) Main components in the proposed API, executing the main tasks for DET-ABE data encryption/decryption under a client-server architecture.

Fig. 3 :

 3 Fig. 3: Proposed set of Java classes for DET-ABE.

1 5

 5 import com . d e t a b e . c l i e n t . e n c r y p t i o n . * ; 3 p u b l i c s t a t i c v o i d main ( S t r i n g a r g s [ ] ) { S t r i n g p o l i c y = " ( d i r e c t i v e AND l e v e l = 7 ) OR ( a c c o u n t a n t AND l e v e l >= 3 ) " ; DETABECipher c i p h e r = new DETABECipher ( ) ; 7 c i p h e r . e n c r y p t ( " c o n t r a c t . pdf " , 1 2 8 , p o l i c y ) ; } Listing 1.1: Encrypting a digital document using DET-ABE

1 9

 9 import com . d e t a b e . c l n t . c i p h e . * ;3 p u b l i c s t a t i c v o i d main ( S t r i n g a r g s [ ] ) { L i s t <S t r i n g > a t t r i b u t e s = new L i n k e d L i s t <S t r i n g >() ;5 a t t r i b u t e s . add ( " d i r e c t i v e " ) ; a t t r i b u t e s . add ( " l e v e l = 5 " ) ; 7 a t t r i b u t e s . add ( " a c c o u n a n t " ) ; a t t r i b u t e s . add ( " l e v e l = 4 " ) ; DETABECipher c i p h e r = new DETABECipher ( ) ; 11 c i p h e r . d e c r y p t ( " p r i v a t e L e t t e r . doc . d e t a b e " , a t t r i b u t e s ) ; } Listing 1.2: Decrypting a ciphertext with DET-ABE

Fig. 4 :

 4 Fig. 4: Running times of DET-ABE main modules considering different number of attributes, a 182Kbyte digital document, and the three standard security levels. a) DET-ABE encryption. b) CP-ABE private key generation to open the digital envelope. c) DET-ABE decryption. d) Contrasting the three main DET-ABE modules using 6 attributes and the three standard security levels.

Table 1 :

 1 Main components in Ciphertext Policy Attribute Based Encryption (CP-ABE)

	Component	Definition on a	Definition on an
		symmetric pairing	asymmetric pairing
	Public key PK	g, h = g β , e(g, g) α	g0, g1, h = g β 0 , e(g0, g1) α
	Master key MK {β, g α }	{β, g α 1 }
	Private key SK	D, dj, d ′ j , where	D, dj, d ′ j , where

Table 2 :

 2 Security settings

		Curve	log 2 r Embedding
	Security(bits)	type		degree
	128 (minimum) A (symmetric pairing) 256	2
	192 (medium) F (asymmetric pairing) 384	12
	256 (high) F (asymmetric pairing) 512	12

Table 3 :

 3 Running times for DET-ABE setup.

		Timing (secs)
	Module	128-bit 192-bit 256-bit
	Curve param. generation 30.78 8.47 24.03
	PK and MK generation	2.26	2.32	4.45

http://www.ieccr.net/2013/pairing2013/

http://www.eccworkshop.org

http://www.larc.usp.br/ pbarreto/pblounge.html