Blockchain privacy-preservation in IntelligentTransportation Systems

Liviu-Adrian Hırtan∗, Ciprian Dobre∗

∗Faculty of Automatic Control and ComputersUniversity Politehnica of Bucharest, Bucharest, RomaniaE-mails: liviuhirtan@yahoo.com and ciprian.dobre@cs.ro

Abstract—Blockchain technology, on which digital currenciesare based, is poised to be the most important disruption businessinnovation since the Internet. Today researchers and renownedcompanies have proposed the use of this technology in otherareas such as voting, identity management, smart city, andothers. Regarding smart city, car navigation systems is oneof the main research directions that aims to streamline trafficand calculate travel routes. Existing applications such as GoogleTraffic or Waze are often used, but for users worried about theirpersonal data, these systems are something of a black box. Usingblockchain technology, in this paper we describe the architectureof a car navigation system in which personal data protection isa major concern.

Index Terms—Blockchain; smart city; car navigation.

I. INTRODUCTION

Privacy-preserving represents a major concern those daysconsidering that the amount of data in our world is rapidlyincreasing. According to recent reports, total Internet traffichas experienced dramatic growth in the past two decades, asglobal Internet reached in 2016 more than 20,000 GBps [1].In the Big Data era, all this data is constantly being collectedand analyzed, leading to innovation and economic growth.Companies and organizations use the data they collect topersonalize services, optimize the corporate decision-makingprocess, predict future trends and more. No wonder that today,data is a valuable asset in our economy [2].

For smart cities, ICT-infused infrastructures enable the ex-tensive monitoring and steering of city maintenance, mobility,air and water quality, energy usage, visitor movements, neigh-borhood sentiment, and so on [3]. Evidently, such processesuse and produce massive amounts of data. However, this alsoraises issues about who has legitimate access to the data, orwhat is the appropriate privacy framework for the linkage ofdifferent data? While some claim that ‘big data’ will help citiesbecome cleaner and more efficient, Kitchin [4] argues thatthere is little attention for ‘politics of city data’, as the ubiq-uitous collection of data about all city processes may produce’panoptic’ cities, inwhich “systems that seek to enable moreeffective modes of governance [may] also threaten to stiflerights to privacy, confidentiality, and freedom of expression”.Smart cities may be more prepared to respond to challengesthan one with a simple “transactional” relationship with itscitizens. Yet, the term itself remains unclear to its specificsand therefore, opens to many interpretations [5], [6], [7].

Most current car navigation applications existing today aredeveloped as closed-source solutions (probably we all useWaze or Google Traffic, but know little of what is happeningbehind the “closed doors”). Among main concerns relatedto such applications, are the interconnectivity between thesystems and the ways they implement (or even care forthat matter) about privacy-preservation [8]. Users of suchapplications have no guarantees about what happens to theirdata, they have no control over the sharing process. Sharingpersonal data (e.g., location and speed, coupled with the user’sidentity, or maybe the MAC address of his mobile smartphone,communication cellular links he crosses, etc.) could potentiallylead to disclosing sensitive information about driving routesor driving preferences. The process of sharing information,sometimes sensitive, may raise questions regarding users’privacy needs and requirements: Who owns the data? Whatare conditions under which other entities (e.g., can Google“sell” your data to third parties?) can access the data, or whobenefits from the data collection [9].

In recent years, a new class of accountable systems emerged.The first such system was Bitcoin, which allows users totransfer currency (bitcoins) securely without a centralized reg-ulator, using a publicly verifiable open ledger (or blockchain).Since then, other projects demonstrated how these blockchainscould serve other functions requiring trusted computing andauditability [10].

Here, we propose a new model of privacy-preservation incase of Intelligent Transportation Systems, particularly tailoredfor in-car navigation applications. The model is based onan offline blockchain-based storage, where all sensitive datacoming from the users is stored in a safe manner, encryptedwith a shared key corresponding to a cluster of cars. Userscan apply different security policies, from the simplest, likeenable/disable speed sharing, enable/disable location sharing,etc, to complex policies, like excluding some areas where thedata is shared with the central server.

The remainder of this paper is structured as follows. Wefirst start, in Section II from a presentation of backgroundon which we fundament our proposal. This is followed bythe actual presentation of our solution, theoretically discussedin Section III, and with practical implications in Section IV.Finally, Sect. V presents our conclusions.

II. BACKGROUND

In 2008, an individual or a group published under thepseudonym Satoshi Nakamoto an article titled “Bitcoin: APeer-To-Peer Electronic Cash System” [11]. The paper intro-duced an online peer-to-peer payment system that operateswithout a central financial institution. Electronic payments canbe made in a secure, immutable and verifiable way. Soon after,Bitcoin was released as an open source program, with the Gen-esis block of 50 coins [12]. Today more than ever, Bitcoin’spopularity is increasing, and companies and researchers areproposing new technologies based on Blockchain [13], [14],[15], [16].

Blockchain, the technology behind Bitcoin, is a publicledger that stores all ever-executed transactions [17]. Thepublic ledger grows concomitant as new records are added. Ablock contains the current records at the time of its creation,and once filled, it will be stored in this permanent database.The number of blocks in the blockchain is not limited. Blocksare linked to each other, like a chain, in a linear, chronologicalorder (hence, the name). Each block contains a hash of theprevious block.

Blockchain is considered the main technological innovationas it is proof of network transactions. Each node has acopy of the blockchain that is downloaded automatically whenit joins the network. The blockchain has all the addressand balance information from the genesis block to the lastgenerated block. Compared to the classic banking system,blockchain represents the history of all banking transactions.Bitcoin records are chronologically stored. Blockchain is keptup-to-date with the aid of cryptographic techniques and animpressive computing power guaranteed by a worldwide net-work of computers. Blockchain is public, so each participantcan check whether a transaction is initiated by a legitimateuser.

Bitcoin, as virtual money, is considered to be a chain ofdigital signatures. Each owner transfers a virtual currency bydigitally signing a hash of the previous transaction and thepublic key of the next owner and adding this information toits end. The receiver can verify its authenticity by checkingthe chain of ownership. The only way to verify a transaction isto be aware of all transactions. In order to achieve this withouta trusted party, transactions must be publicly announced andthe entire network of participants must certify this with thehelp of the historical transactions.

Bitcoin’s blockchain consists of blocks that store transac-tions. Those are verified every 10 minutes through the miningprocess. When a user creates a transaction, it is broadcastedover the entire network to determine if it is legitimate. Thistype of protocol prevents the double spending problem, whena user tries to spend the same Bitcoin multiple times. Eachblock contains a hash of the previous block, which leadsto creation of a chain from the genesis block to the lastgenerated block. Blocks are entered into chronological order,confirmed by the fact that each of them has a hash of theprevious block. Considering the computational power, it is

practically impossible to modify a block because all theblocks generated after its appearance must be regenerated.Honest nodes generate new blocks based on the last blockof the longest valid chain. Length is considered the combineddifficulty of the chain, not the number of the blocks. Thisprevents certain types of attacks. A chain is valid if only allblocks and transactions are valid and if begins with the genesisblock. When blocks are created just few seconds apart, forksmay appear. When this happens, nodes build new blocks afterthe first blockchain received. Blocks in the short chains arenot used, and the transactions inside them will once again beincluded in the mining process. Generating blocks in shortchains is not rewarded. Two forked chains will never merge,because each block contains a single hash of a previous block.A new block is generated every 10 minutes, which will causeproblems regarding storage and synchronization.

Proof-of-work involves searching for a value whose hashstarts with a certain number of zero bits. The required pro-cessing power is exponential with the number of bits of zerorequired and can be easily verified applying a hash operation.Searching for this value implies computational effort and,implicitly, power consumption. After finding this value, theblock can no longer be modified unless all the work is restored.The longest chain, which has the greatest proof-of-work, hasthe majority decision. If the majority of processing power ishandled by honest nodes, the honest chain will grow rapidlyand outperform other competing chains. To modify an oldblock, an attacker would need to perform all the proof-of-work of the current block and those after it. The difficulty ofproof-of-work is constantly changed so that a new block isgenerated around 10 minutes.

New blocks generation implies validating transactions andspending computational effort for proof-of-work scheme. Thebenefit of investing in expensive hardware equipment andelectricity is the chance to be rewarded. When a node, knownas miner, finds the proof-of-work solution, it will broadcast thenew block to all other nodes. Nodes accept the new block if alltransactions are valid. Accepting it implies that the miners willstart working on a new forward block which will contain thehash of the newly generated one (a process known as mining).

For each validated new block, the winning miner willreceive a reward in Bitcoins. As a convention, the first trans-action represents the new coin owned by the block’s creator.Once 210000 validated blocks, the reward is halved. Initially,the reward was 50 bitcoin, but now the prize value is 25bitcoins. This process will take place until the year of 2140,when the prize value will be the smallest unit of Bitcoin, 1satoshi or 10−8 Bitcoin [18]. The incentive for transactionvalidation will not be removed. The Bitcoin protocol allowstransaction fees to be applied for each validated transaction.Initially, the transaction fee was zero, but as Bitcoin gainedpopularity, it increased gradually. The chance that a minerearns the reward is proportional to his computing power.In competition, there exists massive computing power, so adishonest miner has very few chances to corrupt the validationprocess.

Fig. 1. Traffic information request workflow (proposal).

A. Summary

As we know, there are no proposed solutions for usingblockchain technology to privacy-preserve in car navigationsystems (althought there are are some interesting work in thedirection of decentralising blockchain for applications, as wedo, in [19], [20], [21], [22]).

In this paper, we propose a secure mechanism based onblockchain technology, which is able to preserve privacy inIntelligent Transportation Systems (ITS), more exactly in carnavigation applications. The system is able to gather sufficientinformation about traffic within a city so it can offer enoughsupport for the users.

Within car navigation systems, a wide range of smartdevices, such as mobile phones with embedded GPS sensor,video surveillance systems, pneumatic road tube counting,piezoelectric sensor, acoustic detector, etc. can be used toachieve better performance regarding traffic information. Themost convenient way to develop a car navigation applicationprototype is to use smart phones, devices that are very popularnowadays and are used by a vast majority of people. Tosimplify the scenario, in order to obtain traffic information,we considered the use of mobile phones equipped with a GPSsensor. We also included a server whose role is to store andprocess high capacity information.

All the entities, server and smartphones, must be full-proofagainst passive and active attacks. The solution is to collectinformation from mobile devices, which are forwarded toserver. The user communicates only with the server for gettingthe desired data. No other entity has access to this information.The summary of the proposal is described in Figure 1.

In the following Sections, we provide a theoretical modelaccomplishing these facts.

III. SYSTEM ARCHITECTURE

The design of the system consists of two applications: aclient application, which is installed on the user’s smartphone,and a main application, which is installed on a server.

A set of simple security policies are to be used, for examplespeed sharing, location sharing, etc. (from within the mobileapplication). More complex security policies (fine granularity)can be chosen by advanced users, like excluding locationsharing in some areas, disable data sharing if the data trafficspeed is greater than a certain threshold, etc.

We assume that both the server and the smartphone aresecurely-configured, so that the data cannot be stolen. Also, thecommunication channel should not be susceptible to attacks(e.g. all data is sent encrypted).

A. System design

The ITS system is comprised of mobile phone users and acentral server, as shown in Figure 2. The server processesall incoming and outgoing transactions and uses a sharedkey for communications with the enrolled devices. It runs allservices that require processing personal data for operationaland business-related reasons, and nodes, entities entrusted withmaintain the blockchain (the central entity in Figure 2).

Fig. 2. System design.

Comparing to Bitcoin technology, within the network thereare a special kind of nodes named fully validating nodes. Theirrole is to be permanently connected, to store the entire block

Fig. 3. Server database module.

chain and hear/forward every node/transaction. Currently, theBitcoin blockchain is about 170 GB. We assume that a carnavigation application used by many clients will generate asimilar amount of information, size that is quite big for today’ssmartphones.

Another aspect specific to Bitcoin technology is Proof ofWork (POW), the piece of data that requires high computationsto be produced. In order for a block to be accepted by thenetwork participants, miners must complete a Proof of Work,which covers all the data in the block. Mining implies speciallydesigned hardware, which costs even thousands of dollars.Therefore, POW implies high resource requirements, but alsohigh delays attributed to mechanisms, which prevent doublespending.

Our system design includes a lightweight blockchain-based architecture for car navigation applications, where theblockchain is managed centrally by a trusted entity and theinformation is updated by the smartphones with the clientapplication installed. We consider that this implementation de-creases processing overhead and decreases packet significantlycompared to the blockchain implementation used in Bitcoin.

The mobile device maintains a policy header defined bythe user to authorize the outgoing transactions. Those devicesgenerate transactions in order to share, request, or store data.

To decrease network delay and overhead, the clients aregrouped in clusters, according to their location (see Figure 2).Users cooperate and work together to have a common senseof traffic conditions.

B. Server application design

The server application has three main components, as shownin Figure 4:

1) A blockchain module – blocks containing information,like location, speed, traffic events, etc., are provided byusers and verified by the rest of the users in the samecluster. This means that each user node received datasuch as “please validate there is ice on road” (if he

Fig. 4. Server application design.

is on the premises, he can tell). This means that eachinformation that is entering the block chain needs to bevalidated by “voice of the crowd”.

2) A processing module – this module responds to queriesfrom all the participants in real time, while gathering andbasing the decision to data coming from all participants.The module interacts with all others modules in theserver application, and with the client applications. Allthe computations are made by this module: examplesinclude computing the average speed on a particularroad segment, computing the optimal route from thestart location to the end location, computing an estimatedarrival time, etc.

3) Database module – this module contains informationabout the users, about their (current) clusters and theircorrespondence. To better understand the relations, wepresent an example of such a schema in Figure 3.

Fig. 5. Client database module.

Fig. 6. Client application design.

C. Client application design

The client application design has three main components,as shown in Figure 6:

1) A sensor module – various sensors of the smartphone arecollected (i.e. GPS, accelerometer, gyroscope), togetherwith user feeds (e.g., user preferences collected throughthe touch screen or a keyboard), and transmitted to the

server (through the network module).2) A database module – that contains information about

permissions granted by the smartphone’s user, for exam-ple enable/disable speed sharing, enable/disable locationsharing, excluding some areas where the data is sharedwith the central server, etc. An example of such aschema can be seen in Figure 5.

3) A processing module – that interacts with all the othersmodules in the client application design, with the serverapplication (for serving the UI of the mobile app).

IV. COMMUNICATION WORKFLOW

The user communicates only with the server for gettingthe desired data, such as the optimal route from the startlocation to the end location or uploading information, suchas speed, traffic jams, etc. The system is not designed withthird parties who intermediates communication or stores data,although, implemented in practice, there could be an additionalserver ensuring the redundancy. The data transmitted betweenthe server and the clients are encrypted to ensure the confi-dentiality, integrity and authenticity. A diagram showing thecommunication flow is described in Figure 7.

The system itself is designed as follows. The blockchainaccepts two types of transactions: Tenrollment, used for userenrollment in the application, and Tdata, used for data storageand retrieval.

To illustrate, consider the following example: a user installsthe client application on his smartphone. As the user signs upfor the first time, a new shared identity is generated and sent tothe blockchain in a Tenrollment transaction. The user is able

Fig. 7. Update blockchain workflow.

to define different security policies, from the simplest, likeenable/disable speed sharing, enable/disable location sharing,etc., to complex policies, like specifying some areas wherethe data is not to be shared with the central server (“critical”areas). If he wants to share data, thus contributing to systemoptimization regarding traffic conditions, the information col-lected on the phone (e.g. sensor data) is encrypted using ashared encryption key, and then sent to the blockchain in aTdata transaction.

The benefit of blockchain is that an attacker has to com-promise 51% of the system to surpass the hashing powerof the target network. Thus, it is computationally impracticalto launch an attack against the blockchain network (meaningcome up with the computational equivalent of 51% of all carscontributing data an any given time).

The Tdata transaction is represented as a block includinginformation such as block number, previous block, and trans-action records, like location (latitude, longitude), speed, etc.The other entities verify the information within block, and ifmore than 50% of the entities approve the block, then thetransaction is confirmed and added to the chain. Here, theverification means that each block is sent to all other nodes,

and the nodes in the proximity verify the facts contained. Iffacts are not to be confirmed, they broadcast to all nodesnot to approve the block and send an approval if the factconcurs. In any case, each node receiving a block first has towait for confirmation or denial (within a time interval). Theattacker cannot use “bots” (emulated fake entities), becausethey would need to show computationally-viable “proof-of-work”. The other devices could form coallitions in support ofthe attacker, but in this case they get to influence (sometimespositively) the traffic anyway.

For the communication, as seen in Figure 7, both the serviceand the user can query the data. The blockchain server verifiesthat the digital signature belongs to either the user or theservice. The user can change the permissions any time, usingthe client application.

Let’s consider this examples: An attacker wants to sendinformation such as fake speed on a road segment (to influencethe algorithm giving traffic routes to cars, such that to havecars travelling to that road and freeing in return a route maybethe attacker wants to use for personal benefit). In this case,the attacker sends the data that has to be validated by carson that road segment. If cars invalidate the information, than

Fig. 8. Enrollment workflow.

the navigation algorithm is not influenced. Let’s suppose theattacker manages (somehow) to co-operate with cars able tovalidate the information (by promising an exchange of “gooddeads” maybe). In this case, in the beginning the wronginformation is validated. But as the first “good” cars getto navigate into the area, they would start to invalidate theinformation (because the “positive” majority of validators getto increase), so the attacker cannot benefit much of his attack.

In the proposed system design, we illustrate the followingworkflow:

A. Enrollment workflowThis workflow is specific to the enrollment step. The client

application installed on the user’s smartphone sends to theserver the enrollment information, like user ID and the sharedkey; the server processes the received information, updates theinternal user database and sends to the client an ACK message.This workflow is illustrated in Figure 8.

For sharing the data, we believe our solution could be nicelyintegrated with the idea proposed in [23] (at least for the initialstep, until the block chain becomes the trusted mediator ofprivacy). There, authors describe an architecture designed tohandle the management of identities and cryptographic keys,together with the security of communications. Of course, theiridea of using pseudonyms for handling the privacy aspectscannot work (as demonstrated in [24]).

The baseline architecture is based on well-established andunderstood cryptographic primitives which can be imple-mented on today’s hardware and which deserve sufficient trustbecause of their existing deployment. At the same time, the ar-chitecture allows deployed systems to be tuned or augmented,in order to meet more stringent future requirements.

V. CONCLUSION

In this paper we approached current concepts such asBig Data, Blockchain technology, Smart City and Intelligent

Transportation Systems. All those concepts have to accomplishprivacy-preserving requirements, which are a must in nowa-days applications.

Because blockchain holds promise for privacy and securityin financial transactions, we had chosen to adopt it in Intelli-gent Transportation Systems. However, applying Blockchaintechnology in ITS implies a higher resource consumption,scalability, and processing time than the classical system.Considering this, our proposed solution groups all clients intoclusters, according to the location, in order to decrease thecomputation resources, network delay and overhead. Userscooperate and work securely together in a distributed environ-ment to have a common sense of traffic conditions. Privacypolicies are defined by the users and enforced automaticallyby the client application. The system is able to offer optimalresults based on the facilities offered by the Blockchaintechnology, such as transport routes.

Future work includes more extensive evaluation of the im-pact of design choices on security and overhead in the overlay,and a comprehensive analysis on consensus and security of theframework.

ACKNOWLEDGMENT

The research presented in this paper is supported byprojects: NETIO Tel-MonAer (cod SMIS2014+ 105976),SPERO (PN-III-P2-2.1-SOL-2016- 03-0046, 3Sol/2017) andROBIN (PN-III-P1-1.2-PCCDI-2017-0734).

We would like to thank the reviewers for their time andexpertise, constructive comments and valuable insight.

REFERENCES

[1] C. V. Networking, “The zettabyte era–trends and analysis,” Cisco whitepaper, 2017.

[2] K. Schwab, A. Marcus, J. Oyola, W. Hoffman, and M. Luzi, “Personaldata: The emergence of a new asset class,” in An Initiative of the WorldEconomic Forum, 2011.

[3] Y. WANG, K. FANG, and Y.-C. GAO, “The development status andfocus issues of smart city,” DEStech Transactions on Computer Scienceand Engineering, no. cimns, 2017.

[4] R. Kitchin, “The real-time city? big data and smart urbanism,” GeoJour-nal, vol. 79, no. 1, pp. 1–14, 2014.

[5] M. Angelidou, “Smart cities: A conjuncture of four forces,” Cities,vol. 47, pp. 95–106, 2015.

[6] N. Komninos, “What makes cities intelligent?” in Smart Cities. Rout-ledge, 2013, pp. 89–107.

[7] M. Cavada, D. Hunt, and C. Rogers, “Smart cities: Contradictingdefinitions and unclear measures,” in World Sustainability Forum, 2014,pp. 1–12.

[8] C. Dobre, G. Suciu, C. Chilipirea, and C. Gosman, “Mobility beyond in-dividualism: an integrated platform for intelligent transportation systemsof tomorrow,” in ITS Romania Congress, 2014, pp. 31–35.

[9] C. Gosman, T. Cornea, C. Dobre, F. Pop, and A. Castiglione, “Control-ling and filtering users data in intelligent transportation system,” FutureGeneration Computer Systems, vol. 78, pp. 807–816, 2018.

[10] G. Zyskind, O. Nathan et al., “Decentralizing privacy: Using blockchainto protect personal data,” in Security and Privacy Workshops (SPW),2015 IEEE. IEEE, 2015, pp. 180–184.

[11] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.[12] D. Yermack, “Is bitcoin a real currency? an economic appraisal,” in

Handbook of digital currency. Elsevier, 2015, pp. 31–43.[13] A. Dorri, S. S. Kanhere, and R. Jurdak, “Towards an optimized

blockchain for iot,” in Proceedings of the Second International Confer-ence on Internet-of-Things Design and Implementation. ACM, 2017,pp. 173–178.

[14] D. Malkhi, N. Nisan, B. Pinkas, Y. Sella et al., “Fairplay-secure two-party computation system.” in USENIX Security Symposium, vol. 4. SanDiego, CA, USA, 2004, p. 9.

[15] E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, andM. Virza, “Zerocash: Decentralized anonymous payments from bitcoin,”in 2014 IEEE Symposium on Security and Privacy (SP). IEEE, 2014,pp. 459–474.

[16] I. Miers, C. Garman, M. Green, and A. D. Rubin, “Zerocoin: Anonymousdistributed e-cash from bitcoin,” in Security and Privacy (SP), 2013IEEE Symposium on. IEEE, 2013, pp. 397–411.

[17] M. Andrychowicz, S. Dziembowski, D. Malinowski, and L. Mazurek,“Secure multiparty computations on bitcoin,” in Security and Privacy(SP), 2014 IEEE Symposium on. IEEE, 2014, pp. 443–458.

[18] J. A. Kroll, I. C. Davey, and E. W. Felten, “The economics of bitcoinmining, or bitcoin in the presence of adversaries,” in Proceedings ofWEIS, vol. 2013, 2013, p. 11.

[19] G. Kaptchuk, I. Miers, and M. Green, “Managing secrets with consensusnetworks: Fairness, ransomware and access control.” IACR CryptologyePrint Archive, vol. 2017, p. 201, 2017.

[20] A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz, “Permacoin: Repur-posing bitcoin work for data preservation,” in 2014 IEEE Symposiumon Security and Privacy (SP). IEEE, 2014, pp. 475–490.

[21] P. Danzi, M. Angjelichinoski, C. Stefanovic, and P. Popovski, “Dis-tributed proportional-fairness control in microgrids via blockchain smartcontracts,” in 2017 IEEE International Conference on Smart GridCommunications (SmartGridComm). IEEE, 2017, pp. 45–51.

[22] I. Eyal, A. E. Gencer, E. G. Sirer, and R. Van Renesse, “Bitcoin-ng: Ascalable blockchain protocol.” in NSDI, 2016, pp. 45–59.

[23] P. Papadimitratos, L. Buttyan, J.-P. Hubaux, F. Kargl, A. Kung, andM. Raya, “Architecture for secure and private vehicular communica-tions,” in Telecommunications, 2007. ITST’07. 7th International Con-ference on ITS. IEEE, 2007, pp. 1–6.

[24] M. Gerlach and F. Guttler, “Privacy in vanets using changingpseudonyms-ideal and real,” in Vehicular Technology Conference, 2007.VTC2007-Spring. IEEE 65th. IEEE, 2007, pp. 2521–2525.