Share: Smart Contract for Secure Car Sharing

Akash Madhusudan

, Iraklis Symeonidis

1,2

, Mustafa A. Mustafa

1,3

, Ren Zhang

1,4

and Bart Preneel

imec-COSIC, KU Leuven, Belgium

SnT-APSIA, University of Luxembourg, Luxembourg

School of Computer Science, University of Manchester, U.K.

Nervos, Beijing, China

mustafa.mustafa@manchester.ac.uk

Keywords:

Smart Contracts, Ethereum, Car Booking and Payments, Security, Privacy, Car Sharing.

Abstract:

This paper presents an efﬁcient solution for the booking and payments functionality of a car sharing system

that allows individuals to share their personal, underused cars in a completely decentralized manner, annulling

the need of an intermediary. Our solution, named SC

Share, leverages smart contracts and uses them to carry

out secure and private car booking and payments. Our experiments on SC

Share on the Ethereum testnet

guarantee high security and privacy to its users and conﬁrm that our system is cost-efﬁcient and ready for

practical use.

1 INTRODUCTION

Recent years have witnessed an exponential growth

of the sharing economy (Cusumano, 2017). It enables

individuals to share their personal assets for ﬁnancial

gain, helping others who temporarily need these as-

sets. As of 2018, all practical solutions supporting

the sharing economy rely on centralized platforms for

exchanging information and settling payments. Un-

fortunately, a series of incidents indicates that these

platforms are not as trustworthy as they promise to

be. First, their centralized membership system and

pricing scheme allow them to undermine fairness. Ai-

rbnb, an online marketplace for sharing accommoda-

tion, has been in the news for targeting a subgroup of

the population to exclude them from using its servi-

ces (Collins, 2018). This highlights the fact that there

is no mechanism to prevent them from misusing this

power, for instance, to target a minority. Furthermore,

the peer-to-peer car sharing platform Uber charges

its customers based on an algorithmic prediction on

how much they are willing to pay, rather than the

services they receive (Newcomer, 2017). Second, by

keeping all data in one database, these platforms be-

come attractive targets for attackers, resulting in se-

veral data breaches that violate the privacy of milli-

ons of users (Carsten, 2016; Lee, 2017). Along with

the fairness and privacy constraints, using these plat-

forms entails an added cost to both, the user and the

service provider. (Thellmann, 2018).

Fully decentralized solutions based on block-

chain (Sharma, 2018) are seen as a solution to the

fairness issues of these centralized platforms. A

blockchain is a trustless platform that allows any

user to transfer funds and execute smart contracts–

decentralized applications. Although the open na-

ture of the blockchain provides better fairness gua-

rantees, it is unclear how these solutions protect the

users’ privacy. Of the two blockchain-based asset-

sharing schemes the authors are aware of, La‘Zooz

stores the private information in a centralized da-

tabase (La‘Zooz, 2015), while the relevant code of

Slock.it is closed-source, possibly under develop-

ment (Jentzsch, 2016). Moreover, these systems pro-

vide a limited set of functionalities in comparison

with their centralized competitors. La‘Zooz only sup-

ports Consumer-to-Consumer (C2C) car-pooling in

their advertisement, therefore it is unclear whether

they can support C2C personal car sharing. As it ap-

pears, users of Slock.it cannot cancel a request once it

is registered, therefore any misoperation might lead to

ﬁnancial loss for the user. Moreover, Slock.it has not

yet been extended to car sharing. Robust car access

provision protocols, such as SePCAR (Symeonidis

et al., 2017), are also limited in terms of functiona-

lity, as they do not provide a solution to booking and

payments.

This work proposes a novel peer-to-peer car

Madhusudan, A., Symeonidis, I., Mustafa, M., Zhang, R. and Preneel, B.

SC2Share: Smart Contract for Secure Car Sharing.

DOI: 10.5220/0007703601630171

In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 163-171

ISBN: 978-989-758-359-9

163

booking and payments system, named SC

Share.

Share works along the existing car access pro-

vision protocols such as SePCAR and uses a smart

contract to register car sharing offers, match requests

and settle payments. Compared with existing sche-

mes, our system has the following advantages:

• Fair. Our system provides better fairness guaran-

tees as it does not suffer from centralized price

manipulation and membership exclusion.

• Resistance against Data Breach. There is no

central point of failure in our design. Most inte-

ractions happen in a peer-to-peer fashion between

the car owner and the consumer, which involves

no intermediary. Sensitive information stored on

the blockchain is encrypted with the receiver’s pu-

blic key, which is different for each participant.

A compromised private key will not affect other

users of the system.

• Complete Functionalities. Our system offers

complete functionalities that cover all typical exe-

cution paths in an Uber car sharing instance, in-

cluding several conﬂict handling capabilities that

ensure ﬁnancial safety of each involved party

against an adversary, the other party, and miso-

peration by the user himself. To the best of our

knowledge, these combination of features is not

offered in any existing decentralized car sharing

platform.

• Cost-effective. As an additional advantage, our

system is more cost effective to use due to the ab-

sence of a commission. The only cost involved

is the deployment and transaction costs incurred

by the blockchain. The experiments with our de-

ployed contract in Ethereum testnet highlights the

operational costs and efﬁciency of SC

Share.

The remainder of this paper is organized as fol-

lows. Section 2 presents the necessary background.

Section 3 presents the system model, threat model and

design requirements used in our design. Section 4

describes SC

Share, followed by its evaluation in

Section 5. Finally, Section 6 concludes this paper and

it offers future research directions.

2 BACKGROUND

Since SC

Share handles only the booking and pay-

ments aspect of car sharing, we ﬁrst give a brief over-

view of SePCAR, a secure and privacy-enhancing car

access provision protocol to generate and revoke car

access tokens (Symeonidis et al., 2017). Then, we

brieﬂy introduce smart contracts in Ethereum - the

main building block of SC

Share.

2.1 SePCAR

SePCAR (Symeonidis et al., 2017) is a car sharing

scheme that offers strong security and privacy proper-

ties; it extends earlier work described in (Symeonidis

et al., 2016). The system consists of various functio-

nal components. We only list the ones that are rele-

vant to our system. An Owner is a user who is willing

to share his car, a consumer is the user who wants to

rent a car and authorities are the entities responsible

for ensuring that the entire system is legal as well as

for resolving any disputes between users.

The SePCAR protocol starts with the mutual

agreement of booking details by the owner and con-

sumer. Due to the presence of sensitive information

such as the identities of the owner, consumer and the

car along with its usage duration and location, the

system server encrypts these booking details and an

access token is generated. This access token is then

stored in a public ledger, where it is retrieved by the

consumer. Subsequently, a consumer uses this token

to access the car without revealing his private infor-

mation. SePCAR also guarantees the conﬁdentiality

of the car key and booking details.

2.2 Smart Contracts in Ethereum

Ethereum is a cryptocurrency with the third largest

market capitalization (CoinMarketCap, 2018). Ai-

ming at realizing a “world computer”, Ethereum al-

lows users to program smart contracts with a Turing-

complete language and guarantees the correct execu-

tion of these contracts and the integrity of the system

with its underlying blockchain (Buterin, 2014).

Smart contracts are special accounts on Ethereum

blockchain, that contain code and persistant storage

along with an address and balance like normal ac-

counts (Luu et al., 2017). They are computerized pro-

tocols, that, without relying on any intermediaries, sa-

tisfy contractual conditions and minimize attacks by

adversaries. As in any other computer program, the

code of smart contracts also manipulates variables,

and it can be invoked by sending a transaction to its

address along with the required payment for its exe-

cution and parameters.

Miners, entities who embed transactions into the

blockchain, are compensated by transaction fees in

ether, the native currency of Ethereum, from the tran-

saction initiators. The transaction fee is calculated as

the total amount of gas consumed by the transaction

execution, multiplied by the gasPrice, while the gas-

ether exchange rate is speciﬁed in the transaction. The

total gas is calculated by accumulating the gas con-

sumption of all instructions of the execution. Each

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

164

owner Consumer

Car

Smart Contract

Public Ledger

Figure 1: System model of SC

Share.

instruction has a predeﬁned gas consumption. To pre-

vent denial of service attacks, each transaction also

speciﬁes a startGas. A transaction execution that ex-

ceeds that startGas cannot be carried out, however, the

transaction fee still goes to the miner.

3 SYSTEM MODEL, THREAT

MODEL AND DESIGN

REQUIREMENTS

This section introduces the system model, the threat

model and assumptions as well as the functional, se-

curity and privacy requirements used in the design of

Share.

3.1 System Model

As illustrated in Figure 1, our system model consists

of the following entities:

• Owner - An individual with the intention to share

his underused personal car.

• Consumer - A person in temporary need of a car.

• Car - The car that is available to be shared. Access

provision to this car is handled by any robust

access provision protocols such as SePCAR (Sy-

meonidis et al., 2017).

• Public Ledger - A structure that irrefutably re-

cords transactions and is operated by a single

or several decentralized parties. All transactions

made in SC

Share are recorded in this public led-

ger.

• Smart Contract - This smart contract is responsi-

ble for receiving a booking request, making sure

that appropriate deposits have been made by both

the owner and the consumer, handling cancella-

tion requests, dealing with fraudulent activities,

and a smooth rental procedure in general.

3.2 Threat Model and Assumptions

In SC

Share the following threat model is used. The

owner and the consumer are not trusted to carry out

all transactions honestly. The integrity and correct

execution of the smart contract is guaranteed by the

underlying public ledger, in our case the Ethereum

blockchain. Due to the blockchain’s public nature,

any private information embedded in the blockchain

is considered leaked.

For our system to work, we also make the follo-

wing assumptions. The owner and the consumer mu-

tually agree upon the initial booking details and are

successful in keeping them conﬁdential against any

third party. We also assume that the owner and the

consumer have a public/private-key pair along with

their digital certiﬁcates. Lastly, the communication

channels are used by the owner and the consumer are

private and authentic.

3.3 Design Requirements

Our system should satisfy the following functional,

security and privacy requirements.

Functional Requirements

• Booking and Payments Process: SC

should handle bookings, car usage and payments

in an immutable way. It should be able to re-

ceive booking requests, safeguard deposits placed

by owners/consumers and handle payments.

• Fraud Prevention: SC

Share should be able to

deal with fraudulent actions taken by both ow-

ners and consumers. Example actions are not ma-

king the car availlable and not returning the car.

Share should penalize the initiators of such

fraudulent actions.

• Cancellation: SC

Share should handle cancella-

tions of the booking agreement and distribute the

deposit according to the booking agreement.

• Extra Time Surcharge: In case of extra time re-

quest by the consumer, SC

Share should be able

to deduct the required extra amount from the con-

sumer’s deposit and transfer it to the owner.

Security and Privacy Requirements

• Authenticity of Booking Details: the integrity,

origin and approval of the booking details should

be validated by the car.

• Non-repudiation of Access Token: SC

should be able to prove the authenticity of the

SC2Share: Smart Contract for Secure Car Sharing

165

Car

Smart Contract

Owner

Customer

Booking details

Retrieve balance (x - y eth)

Booking Request (x ether)

No. of days

Car info, price per day

Deployment (x ether)

encrypt and store details / allow car usage

Withdraw earnings (x + y eth)

Access Car

End Car Rental

Figure 2: Overview of the SC

Share system.

access token that is generated by the owner to the

car and the consumer.

• Forensic Evidence Provision: In an adverse sce-

nario of a fraudulent action, authorities should be

able to retrieve forensic evidence from the system

and gain access to speciﬁc booking details.

• Conﬁdentiality of Booking Details: Only the

owner and consumer should have access to the

information stored in booking details. Booking

details can hold personal identiﬁable and potenti-

ally sensitive information such as the license plate

number, the location, booking time and type of the

car.

• Conﬁdentiality of Access Token: Only the car

should have access to the information stored in the

access token.

• Anonymity of Consumer And Car: The identity

of the consumer and the car should be hidden to

anyone except the owner, the consumer and the

car.

4 SC

This section provides an overview of how SC

handles a car sharing scenario. Then, we explain in

detail the algorithms that implement the functionali-

ties described.

4.1 Overview of SC

As it is illustrated in Figure 2, we provide a high-level

overview of how our system works. It consists of se-

ven steps described below.

1. An owner deploys a smart contract on the block-

chain and deposits a value of x ether in it.

2. A consumer sends a request to rent the car by de-

positing x ether (the same amount as in step 1) in

the deployed smart contract.

3. The owner and the consumer agree on mutu-

ally accepted booking details such as the required

number of days to share the car, the pick-up and

drop-off location and the daily price.

4. Once the details are agreed, the owner signs the

booking details using his private key and encrypts

them using the consumer’s public key. Once en-

crypted, he sends these details to the storage of

smart contract and allows the consumer to access

the car. The encrypted details stored in the smart

contract can be accessed by the consumer and de-

crypted using his private key. However, as seen in

Figure 3, we do not encrypt all information stored

in booking details.

5. The consumer accesses the car and uses it for the

agreed amount of time.

6. After completing the trip, the consumer ends the

car rental process by dropping off the owner’s car

at the agreed location.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

166

Address of the owner

Address of the Consumer

Required number of days

Car plate number

Location of the car

Car type

Car access rights

Type of car

Price per day

Price per extra day

Address of the owner

Address of the Consumer

Required number of days

Price per day/extra day

Car plate number

Location of the car

Car type

Car access rights

Type of car

Details that we encrypt

Details that we do not encrypt

Figure 3: List of Booking Details.

7. Once the process is over, both the owner and the

consumer can separately withdraw their earnings

and balances, respectively.

4.2 SC

Share in Detail

This section describes SC

Share in detail. We ﬁrst

present the main protocol followed by the description

of the cancellation, car access and extra time functio-

nalities.

Algorithm 1 depicts a pseudo-code of how our sy-

stem works. As explained in the overview, the system

is initiated by the owner, which is followed by the

consumer sending a request for booking. Once the

consumer is set as the current driver of the car, the

booking details are mutually agreed before being en-

crypted and stored on the blockchain. We use exter-

nal libraries such as eth-crypto and eth-ecies to carry

out the encryption off-chain, and to generate the iden-

tities of the owner and the consumer (libertylocked,

2018; pubkey, 2018). The Javascript code that exe-

cutes with the smart contract, and the smart contract

itself are available online.

While storing the details in the smart contract, the

owner has to set allow car usage value to ‘true’ in the

smart contract to inform SC

Share that the car can be

used by the consumer. Once the consumer has access

to the car, he can use it for the decided time. If they

exceed the agreed time limit, the extra time surcharge

is handled by Algorithm 4. In order to calculate extra

time, the smart contract keeps deducting the mutually

agreed ‘price per extra hour’ from the consumer’s de-

posit. SC

Share also has a fail-safe option, that is acti-

vated if the consumer fails to return the car. It awards

the owner the total deposit stored in the smart con-

tract, although it does not yet deal with the post-theft

scenario. A possible solution to the post-theft sce-

nario is provided by insurance businesses for sharing

economy industry, such as SafeShare.

In cases where either the owner or the consumer

wants to cancel the booking, Algorithm 2 comes into

play. The pseudo-code explains how SC

Share hand-

Algorithm 1: SC

Share main.

1: procedure SC

2: Owner Deploys Contract

3: if Deployment successful then

4: Customer Requests for Car Booking

5: if Request successful then

6: currentDriverAddress ← cAddress

7: cDeposit ← x Ether

8: oDeposit ← x Ether

9: Mutually agree on booking details(BD)

10: Encrypt BD and store

11: if Owner allows car usage then

12: if Owner wants to cancel then

13: goto Algorithm 2;

14: if Customer access’s car then

15: if Customer cancels then

16: goto Algorithm 2;

17: Use Car;

18: End Usage;

19: Owner withdraws earnings;

20: Consumer withdraws deposit;

21: if Extra time then

22: goto Algorithm 3;

23: else

24: if Customer cancels then

25: goto Algorithm 2;

26: else

27: if Owner cancels then

28: goto Algorithm 2;

29: Customer withdraws total deposit;

30: Restart if deployment fails.

les the cancellation at different stages of the system.

If the owner cancels the booking before allowing car

usage, he is not penalized, but if they do it after al-

lowing the car usage, then SC

Share ensures that the

consumer gets an incentive. The customer also pays

the penalty based on whether they cancel the booking

before accessing the car, or after.

If the owner fails to give car access to the con-

sumer after they have made the deposit, Algorithm 3

depicts how the owner is penalized for committing a

fraudulent action as SC

Share awards the total depo-

sit stored in the smart contract to the consumer.

Once the consumer has successfully ended the

car rental (see Algorithm 1), SC

Share calculates the

amount that has to be deducted from their deposit and

adds it to the owner’s deposit, after which the owner

and consumer can separately withdraw their money.

SC2Share: Smart Contract for Secure Car Sharing

167

Algorithm 2: Cancellation functionality.

1: procedure CANCELLATION

2: currentDriverAddress ← cAddress

3: cBalance ← consumer balance

4: oBalance ← owner balance

5: cDeposit ← consumer deposit

6: oDeposit ← owner deposit

7: Owner Allows Car Usage:

8: if consumer access’s car & cancels booking

then

9: x ← clientDeposit − penalty

10: ownerBalance ← balance + x

11: return true

12: if owner cancels booking then

13: x ← oDeposit − penalty

14: cBalance ← cBalance + x

15: return true

16: if consumer cancels & does not access then

17: return true

18: Owner Does Not Allow Usage:

19: if owner cancels booking then

20: oBalance ← oBalance + oDeposit

21: cBalance ← cBalance + cDeposit

22: return true

Algorithm 3: Car access functionality.

1: procedure CAR ACCESS

2: currentDriverAddress ← cAddress

3: cBalance ← consumer balance

4: if owner allows usage then

5: carStatus ← ready

6: consumer ← access

7: return true

8: if owner does not allow usage then

9: carStatus ← notready

10: consumer ← noAccess

11: consumer can retrieve total deposit

12: x ← totalDeposit

13: cBalance ← cBalance + x

14: return true

5 EVALUATION

In this section, we analyze our design and provide a

description of how SC

Share fulﬁlls the functional,

security and privacy requirements. We also provide

the real-world deployment cost of SC

Share on the

Ethereum blockchain along with all the transaction

costs it incurs while being used. Evaluation on the ba-

sis of total time taken is tricky as the execution time

for each transaction in SC

Share can only be aggre-

gated since there is no concrete way of knowing how

Algorithm 4: Extra time functionality.

1: procedure EXTRA TIME

2: currentDriverAddress ← cAddress

3: cBalance ← consumer balance

4: oBalance ← owner balance

5: cDeposit ← consumer deposit

6: oDeposit ← owner deposit

7: consumer Ends Car Rental:

8: if end time =< decided time then

9: currentDriverAddress ← null

10: carStatus ← idle

11: x ← cDeposit − rentCharge

12: oBalance ← oDeposit + x

13: cBalance ← cDeposit

14: return true

15: if end time > decided time then

16: currentDriverAddress ← null

17: carStatus ← idle

18: x ← cDeposit − rentCharge

19: y ← cDeposit − chargePerExtraHour

20: z ← x + y

21: oBalance ← oDeposit + z

22: cBalance ← cDeposit

23: return true

24: Consumer Runs Away With Car:

25: x ← totalDeposit

26: oBalance ← oBalance + x

27: return inform insurance

long a transaction would take before its included in

Ethereum. As of January 2019, the median wait time

between each block is ≈ 32 seconds.

5.1 Functionality Analysis

Share uses the Ethereum blockchain to imple-

ment the booking and payment functionalities for car

sharing applications. All transactions related to car

rental, are immutable when published on the block-

chain. Once a transaction is made using SC

Share,

the owner or the consumer cannot refute the owners-

hip of it. Moreover, no outsider knows the identities

of the owner and consumer, and all the sensitive infor-

mation in booking details is encrypted before being

stored on-chain.

The Algorithm 3 and 4 demonstrates how to mi-

tigate a malicious owner or consumer and hence pre-

vent fraudelent actions. Possible fraud behaviour is

countered with a penalty of losing the deposit made

in the smart contract. The Algorithm 4 also enables

the functionality of extra time surcharge.

Moreover, in SC

Share we consider all possible

cancellation scenarios, and a fair settlement for both

the owner and consumer in Algorithm 2. Hence we

guarantee the functionality of cancellation.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

168

Table 1: Deployment Costs of SC

Share.

Total Size (bytes) Deployment Cost in gas Deployment Cost in USD

8520 1,352,283 gas $0.21623

Table 2: Costs of Executing each Transaction in SC

Share.

Transaction Cost in gas Cost in USD

set required days (customer) 42,131 gas $0.00674

store encrypted details in contract (owner) 63,022 gas $0.02739

rent car (customer) 112,220 gas $0.01795

allow use of the car (owner) 28,655 gas $0.00459

access the car (customer) 29,038 gas $0.00464

cancellation of booking (owner/customer) 76,342 gas $0.0122

ending the rental procedure (owner/customer) 82,590 gas $0.01321

triggering the distribution of earnings (owner) 32,992 gas $0.00528

withdrawal of money (owner/consumer) 22,099 gas $0.00353

5.2 Security and Privacy Analysis

Before publishing the booking details in the block-

chain, the owner has to encrypt and sign them.

Share veriﬁes the owner’s signature on the book-

ing details before giving access to the consumer to

verify if the owner also agrees with the conditions set

for the car rental, thus providing authenticity of book-

ing details.

Car access provision protocols such as SeP-

CAR (Symeonidis et al., 2017) use the encryp-

ted booking details to generate the access token.

Share veriﬁes the origin of encrypted details in

order to make sure that no one but the owner has sig-

ned them. This is achieved by comparing the address

of the signer to the address of the owner. This is how

we ensure non-repudiation of access token.

Smart contracts are auditable by nature, and in

case of an incident where the owner or the consu-

mer is involved, the SC

Share can be audited to re-

veal private information about the owner or the con-

sumer guaranteeing the requirement of forensic evi-

dence provision.

Share ensures the conﬁdentiality of booking

details by enabling only the owner and the consumer

to have access to the sensitive information stored in

booking details. These details are discussed ofﬂine

using a secure channel (see assumptions in Section 3)

and only stored in the smart contract when encrypted.

Share treats the encrypted booking details

as the access token and stores them in its internal

storage. No one except the consumer and the owner

can decipher an access token thus guaranteeing conﬁ-

dentiality of the access token.

Anonymity of consumer and car is provided by de-

Share. On the blockchain, the consumer

can choose to be anonymous by using his 20-byte ad-

dress to interact with the contract and not publicizing

any personal details, while the identity of the car is

encrypted along with the other private information by

the owner before storing it on-chain.

5.3 Deployment and Usage Cost

The deployment of a smart contract and the inte-

raction with it has a cost for the caller of the tran-

saction, and this cost is calculated in gas. This section

discusses the deployment and interaction costs asso-

ciated with SC

Share. It is important to mention that

the price of ether per gas unit is volatile, and these

results are obtained by using the price of ether per

gas unit for average conﬁrmation time as of January

2019. To evaluate the total cost of SC

Share, we look

at two different costs, the deployment and the tran-

saction cost.

Deployment Cost

The main costs for deploying a smart contract can

be calculated by combining the following parame-

ters (Wood, 2014):

• The costs associated with storing the contract

code (200 gas per byte);

• Additional data storage cost on the contract

(20,000 gas per 256-bit word);

• Each transaction has a base cost of 21,000 gas,

and 32,000 gas have to be paid for a CREATE

transaction (deployment of a new contract);

Ganache was used as a provider for web3.js to per-

form tests on SC

Share and calculate the estimated

gas for deployment, as well as the execution of each

transaction. The absolute deployment cost is inﬂuen-

ced by the size of the contract and the total bytes in

SC2Share: Smart Contract for Secure Car Sharing

169

its storage. Table 1 illustrates the deployment cost of

Share in USD. It can be calculated by multiplying

the total gas with the cost per gas unit in USD.

Transaction Cost

The cost for executing each transaction can be calcu-

lated as follows (Wood, 2014):

• The base cost of each transaction (21,000 gas);

• The cost for storing a 256-bit word on the smart

contract (20,000 gas);

• The cost for editing data stored in the smart con-

tract (5,000 gas);

• The cost of making a transaction call having a mo-

netary value (9,000 gas);

Table 2 illustrates the cost of executing each tran-

saction in SC

Share. Adding up the cost of all indivi-

dual transactions, the total cost of all transactions in

Share is USD 0.095. Hence, it can be deduced

that our smart contract implementation is not expen-

sive to deploy and operate.

6 CONCLUSIONS AND FUTURE

WORK

This paper presented a fully decentralized car book-

ing and payments system known as SC

Share. This

system can be incorporated with car access provi-

sion protocols to provide a secure and private car

sharing environment without the need of any interme-

diary. We have shown that SC

Share provides all ma-

jor functionalities that are required for a car sharing

platform, and provides security and privacy by design.

The total cost of deploying and using our system on

the Ethereum network sums up to USD 0.312, which

in comparison to the commission fee paid to large or-

ganizations is relatively cheap. Hence, we conclude

that along with being functionally sound, secure and

private, SC

Share is also cost effective for its users.

As future work we would like to advance our sy-

stem design and implementation to work with fully

encrypted booking details, including the price per

day, price per extra day and required number of days

which are used for calculation of payments, as well as

to provide formal security and privacy proofs of the

advanced system.

Another potential direction could be to adapt

Share so that it supports the use of advanced cryp-

tographic primitives such as zero-knowledge proofs.

Ethereum Whisper could also be used to possibly re-

move the waiting time of customer to get car access.

ACKNOWLEDGEMENTS

This work was supported in part by the Research

Council KU Leuven: C16/15/058 and by the Fle-

mish Government through FWO SBO project SNIP-

PET S007619N. We would also like to thank the ano-

nymous reviewers for their constructive feedback.

REFERENCES

Buterin, V. (2014). A next-generation smart contract

and decentralized application platform. URL:

http://blockchainlab.com/pdf/Ethereum white paper-

a next generation smart contract and decentralized

application platform-vitalik-buterin.pdf, last checked

on 2018-12-20.

Carsten, P. (2016). Hackers attack 20 mln ac-

counts on alibaba’s taobao shopping site. URL:

https://www.reuters.com/article/alibaba-cyber-

idUSL3N15J1P2, last checked on 2018-12-10.

CoinMarketCap (2018). Top 100 cryptocurrencies by mar-

ket capitalization. URL: https://coinmarketcap.com/,

last checked on 2018-12-20.

Collins, K. (2018). A running list of websites and apps

that have banned, blocked, deleted, and otherwise

dropped white supremacists. URL: https://qz.com/

1055141/what-websites-and-apps-have-banned-neo-

nazis-and-white-supremacists/, last checked on

2018-12-07.

Cusumano, M. A. (2017). The sharing economy meets rea-

lity. Commun. ACM, 61(1):26–28.

Jentzsch, C. (2016). Decentralized autonomous organiza-

tion to automate governance. URL: https://download.

slock.it/public/DAO/WhitePaper.pdf, last checked on

2018-12-10.

La‘Zooz (2015). La‘zooz white paper. URL: https://

www.weusecoins.com/assets/pdf/library/LaZooz

%20Blockchain%20Taxi%20Whitepaper.pdf, last

checked on 2018-12-10.

Lee, D. (2017). Uber concealed huge data breach. URL:

https://www.bbc.com/news/technology-42075306,

last checked on 2018-12-10.

libertylocked (2018). eth-ecies. URL: https://github.com/

libertylocked/eth-ecies, last checked on 2018-12-20.

Luu, L., Velner, Y., Teutsch, J., and Saxena, P. (2017). Smart

pool: Practical decentralized pooled mining. In USE-

NIX Security Symposium.

Newcomer, E. (2017). Uber starts charging what

it thinks youre willing to pay. URL: https://

www.bloomberg.com/news/articles/2017-05-19/uber-

s-future-may-rely-on-predicting-how-much-you-re-

willing-to-pay, last checked on 2018-12-07.

pubkey (2018). eth-crypto. URL: https://github.com/

pubkey/eth-crypto, last checked on 2018-12-20.

Sharma, T. K. (2018). What does blockchain me-

ans for a sharing economy? URL: https://

www.blockchain-council.org/blockchain/what-does-

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

170

blockchain-mean-for-a-sharing-economy/, last

checked on 2018-12-10.

Symeonidis, I., Aly, A., Mustafa, M. A., Mennink, B.,

Dhooghe, S., and Preneel, B. (2017). Sepcar: A secure

and privacy-enhancing protocol for car access provi-

sion. in the 22nd European Symposium on Research

in Computer Security (ESORICS17), ser. LNCS, vol.

10493. Springer, 2017, pages 475–493.

Symeonidis, I., Mustafa, M. A., and Preneel, B. (2016).

Keyless car sharing system: A security and privacy

analysis. In IEEE International Smart Cities Confe-

rence (ISC2 2016), pages 1–8.

Thellmann, P. (2018). Blockchain is the infrastruc-

ture for a new decentralized sharing economy.

URL: https://hackernoon.com/blockchain-is-the-

infrastructure-for-a-new-decentralized-sharing-

economy-f715da32bece, last checked on 2018-12-5.

Wood, G. (2014). Ethereum: A secure decentralised ge-

neralised transaction ledger byzantium version. URL:

https://ethereum.github.io/yellowpaper/paper.pdf, last

checked on 2018-08-5.

SC2Share: Smart Contract for Secure Car Sharing

171