Utilizing Homomorphic Cryptography to Improve Privacy in ... · 2 Background...

EMSEC

Utilizing Homomorphic Cryptography to ImprovePrivacy in Driving Pattern-Based Insurance Plans

Bernhard Borsch

Master’s Thesis. March 30, 2014.Chair for Embedded Security – Prof. Dr.-Ing. Christof PaarFirst Advisor: Prof. Dr.-Ing. Christof Paar, Ruhr-Universität Bochum, GermanySecond Advisor: Prof. Dr. Susanne Wetzel, Stevens Institute of Technology, NJ, USA

Abstract

Today, people like to be ‘connected’ all the time. We have learned that having informa-tion readily available is at least a great convenience if not a great advantage and havebecome accustomed to it. Connected cars are a natural progression of this idea. Theseconnected cars are not only able to communicate with their drivers, but they are alsoable to communicate with other vehicles, the environment, and service providers. Thecommunication between the vehicles enables the sharing of information, such as hazardwarnings or critical vehicle data needed to prevent accidents. Every vehicle continuouslycollects data on changing conditions and then this data must be evaluated, e.g., for aninsurance plan by an insurance company. This evaluation can have a huge impact on theparticipants; in the cost of their insurance policy or their insurability at all. In currentsystems, the insurer has to install a blackbox in the vehicle of the insured to gatherthe necessary information, e.g., current speed, acceleration, route, etc. . This highlysensitive information is sent periodically to an external service provider, who preparesthis information for the insurer and the insured. This driver’s personal information isunprotected as well as the insurer’s specific parameters algorithm for determining anoverall evaluation of the driver.

This thesis deals with the idea of an individual driving pattern based insurance planwhich protects both parties privacy as an example of comparing continuously privateinputs with also private thresholds for increasing counters and storing of information. Amethod is described wherein the control over the gathered data will be moved away fromthe service provider to the data producer, the driver with his vehicle, so he may controlwhat really happens with his personal information. On the other hand, the insurer isable to keep his driving pattern evaluation parameters confidential, while still offering anindividualized insurance plan. This is possible with the techniques of Secure MultipartyComputation (SMC) with the utilizing of homomorphic cryptosystem.

SMC is a specialization of distributed computing where a number of distinct butconnected computing parties to carry out joint computation functionality. Each partybrings in his inputs and does a part of the calculation. The field of SMC deals withthe question of how to securely compute a functionality, but does not ask the questionof whether the functionality should be computed in the first place. This thesis showsa theoretical solution for a comparison of private inputs and performing operationsdepending on the comparison result. The developed protocol is privacy preserving in thesemi-honest model and it fulfills the desired functionality of implementing individualizedinsurance policies.

i

DeclarationI hereby declare that this submission is my own work and that, to the best of myknowledge and belief, it contains no material previously published or written by anotherperson nor material which to a substantial extent has been accepted for the award of anyother degree or diploma of the university or other institute of higher learning, exceptwhere due acknowledgment has been made in the text.

ErklärungHiermit versichere ich, dass ich die vorliegende Arbeit selbstständig verfasst und keineanderen als die angegebenen Quellen und Hilfsmittel benutzt habe, dass alle Stellen derArbeit, die wörtlich oder sinngemäß aus anderen Quellen übernommen wurden, als solchekenntlich gemacht sind und dass die Arbeit in gleicher oder ähnlicher Form noch keinerPrüfungsbehörde vorgelegt wurde.

Bernhard Borsch

Contents

1 Introduction 11.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Organization of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 52.1 Current Vehicular Communication Models . . . . . . . . . . . . . . . . . . 5

2.1.1 Location Based Service Applications . . . . . . . . . . . . . . . . . 52.1.2 Road Toll Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Automatically Emergency Calls: eCall . . . . . . . . . . . . . . . . 82.1.4 Theft Protection and Car Location Systems . . . . . . . . . . . . . 92.1.5 Car Insurance by Driving Style Analytics . . . . . . . . . . . . . . 9

2.2 Car Communication Systems . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.1 Car2X/Vehicle2X Communication . . . . . . . . . . . . . . . . . . 112.2.2 Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Security View of Background . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.1 Overview of Participants . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Intelligent Transporting System (ITS) Security Services . . . . . . 162.3.3 Vehicular Ad Hoc Network (VANET) Security Communications

Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 Secure Multiparty Computation . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.2 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.3 Security in Multiparty Computation . . . . . . . . . . . . . . . . . 202.4.4 Influence of a Corrupt Party . . . . . . . . . . . . . . . . . . . . . 22

2.5 Homomorphic Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.2 Cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.3 Homomorphic Cryptosystem . . . . . . . . . . . . . . . . . . . . . 232.5.4 Pallier Cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.5 Paillier Threshold Cryptosystem . . . . . . . . . . . . . . . . . . . 24

3 Example Model and Assumptions 273.1 Model for Car Insurance Policy based on State Data . . . . . . . . . . . . 27

3.1.1 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.2 Trust Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . 29

iv Contents

3.1.3 Regulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.4 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.1 Communication Channels . . . . . . . . . . . . . . . . . . . . . . . 393.2.2 Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.3 Key Exchange and Storage . . . . . . . . . . . . . . . . . . . . . . 403.2.4 Checking Parameters and Store Information . . . . . . . . . . . . . 40

3.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4 Summery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4 Protocol Description 494.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1.1 Summary of Assumptions . . . . . . . . . . . . . . . . . . . . . . . 504.2 Needed Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.1 Ticket Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3 Protocol to Compare Two Positive Integers with Paillier: F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 . . 52

4.3.1 Comparing Two Integers using the Kreschbaum Protocol . . . . . 524.3.2 Extension to Compare Two Positive Integers with Shared Output . 52

4.4 Handling Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.4.1 Homomorphic Multiplication with Encrypted, Private Integers:

F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.4.2 Operations for Involving Ticket 𝑡: F𝑡𝑖𝑐𝑘𝑒𝑡 . . . . . . . . . . . . . . . 564.4.3 Operations for Counter 𝑐𝑜𝑢𝑛𝑡𝑒𝑟: F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 . . . . . . . . . . . . . . 56

4.5 Protocol for one Building Block: F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 . . . . . . . . . . . . . . . 574.6 Transmission of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.7 Overall Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 Analysis 635.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2 Evaluation of F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.1 Correctness and Privacy . . . . . . . . . . . . . . . . . . . . . . . . 635.2.2 Amount of Operations . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3 Evaluation of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3.1 Correctness and Privacy . . . . . . . . . . . . . . . . . . . . . . . . 655.3.2 Amount of Operations . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4 Evaluation of F𝑡𝑖𝑐𝑘𝑒𝑡 and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 . . . . . . . . . . . . . . . . . . . . . . . 665.4.1 Correctness and Privacy . . . . . . . . . . . . . . . . . . . . . . . . 665.4.2 Amount of Operations . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.5 Evaluation of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 . . . . . . . . . . . . . . . . . . . . . . . . . . 675.5.1 Correctness and Privacy . . . . . . . . . . . . . . . . . . . . . . . . 675.5.2 Amount of Operations . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.6 Evaluation of OverallAlgorithm . . . . . . . . . . . . . . . . . . . . . 68

Contents v

6 Conclusion 716.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A Acronyms 73

B Appendix 75B.1 Intelligent Transporting System (ITS) Station Reference Architecture . . 75

B.1.1 Defintion of the Certificate Format . . . . . . . . . . . . . . . . . . 76B.1.2 Security Profiles in ITS . . . . . . . . . . . . . . . . . . . . . . . . 79

B.2 Computation Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80B.2.1 Computation of Distance . . . . . . . . . . . . . . . . . . . . . . . 80B.2.2 Computation of Speed . . . . . . . . . . . . . . . . . . . . . . . . . 81B.2.3 Computation of Average Speed . . . . . . . . . . . . . . . . . . . . 81B.2.4 Rule Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

B.3 Comparison of Actors of State-of-the-Art and new Model . . . . . . . . . 82B.4 Generic Building Block and Overall Picture . . . . . . . . . . . . . . . . . 83B.5 Class Diagram of Used Data Structures . . . . . . . . . . . . . . . . . . . 85B.6 Protocol to Compare Two Positive Integers Bitwise: F𝑐𝑜𝑚𝑝𝐵𝑖𝑡 . . . . . . . 87

B.6.1 Oblivious Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 87B.6.2 Construction of Order Preserving Function 𝐹 . . . . . . . . . . . . 88B.6.3 Protocol to Compare Two Integers . . . . . . . . . . . . . . . . . . 89B.6.4 Extension to Shared Output and Encrypted Input . . . . . . . . . 89B.6.5 Evaluation of F𝑐𝑜𝑚𝑝𝐵𝑖𝑡 . . . . . . . . . . . . . . . . . . . . . . . . . 90

B.7 Homomorphic Addition with XOR of Two Bits: F𝑋𝑂𝑅 . . . . . . . . . . . 92B.7.1 Correctness and Privacy . . . . . . . . . . . . . . . . . . . . . . . . 93B.7.2 Amount of Operations . . . . . . . . . . . . . . . . . . . . . . . . . 94

List of Figures 95

List of Tables 97

List of Algorithms 98

List of Listings 101

Bibliography 103

1 IntroductionThe idea of being connected at anytime does not stop in front of the road. People wantto be connected with their car and they also want the benefits of connecting cars toeach other. Volvo presented his invention of ‘Scandinavian pilot’ with the intention tocollect information of traffic conditions on a large number of vehicles. They propose touse this data to warn other vehicles of dangerous situations [Per14]. An idea, new toGermany [Gle13], already in use in other countries such as Great Britain [Mau14], is torank the driver of a vehicle by his/her driving pattern to offer individual car insuranceplans. As part of such an insurance plan or the identification of traffic conditions, theactual driving pattern is continuously compared to an expected pattern. Both ideasrequire observing properties such as current speed, position, acceleration, time, and more.The gathering, evaluating, and publishing of this measured data is a problem bothconcepts share. In each case, the problem involves individual vehicles with “voluntary”drivers and transmitting the gathered data to a provider. The provider has now toevaluate the raw personal information sent by the vehicle before even the driver has seenit. Only the aggregated result is offered back to original producer — the driver of thevehicle. At the cost of a significant amount of his data, such as his personal, individualdriving pattern, the driver receives only the small benefit of a personalized insuranceplan [Ngo14].In this work, the administration of the data is transferred away from the service providerto the producer, the driver. This work provides a protocol for the evaluation of the datathat is privacy preserving and done jointly by both parties. The service provider — inthis work, an insurer — is interested in keeping private the specifics of how the receiveddata is interpreted to generate an overall evaluation of the producer’s performance. Also,the data producer — in this work, an insured — keeps his driving pattern private.

1.1 Related WorkThis work connects two huge fields of research: connected vehicles and privacy-preservingprotocols. The field of applications for connected vehicles is investigated in several papers,but many of them just point out a single application. The works [HW06, GMBK09]describe both specific problems as well as provide a general view of the applications ofconnected cars. The most complete overview is in [ETS10a]. An generally introductioninto the topic of Car2X/Vehicle2X, as a subtopic of connected vehicles focusing on thevehicle aspect, is given in [HDS+10,Sch11]. Focusing on the infrastructure of IntelligentTransporting Systems (ITS), the work of the standardization organization ETSI andIEEE is important [ETS10c, IEE13]. The topic of Vehicle Ad Hoc Networks (VANET),the (wireless) connection between two vehicles or a vehicle and the infrastructure, is

2 1 Introduction

discussed in [SSBP09, Bou11]. One application of connected vehicles are the DrivingStyle Based Insurance plans. Driving Style Based Insurance are in general public news,but a critical point of view is presented in [Gle13]. In his work the privacy aspect is thecenter of discussion. Several example insurance plans, which are currently offered, arelisted in [Mau14].The field of Secure Multiparty Computation (SMC) is introduced in [Can00,NP01,LP09,May12] and other papers, but these four have the strongest relevance to this work.Secure Multiparty Computation is often realized by privacy-preserving protocols [May12].One special case of Secure Multiparty Computation is the Yao’s Millionaire Problem.This problem, addressing the problem of comparing two numbers while preservingprivacy, is discussed in [KT06]. Kerschbaum provides a solution by using homomorphiccryptography. An approach without cryptography is given in [KG13], where the inputsare compared bitwise.

1.2 ContributionThis thesis connects the field of connected vehicles with Secure Multiparty Computation(SMC) to develop a privacy-preserving protocol. So it is possible for an insurance companyto offer a driving pattern based insurance plan without leaking the thresholds, which arethe driving pattern are compared with. On the other side, the insured keeps his drivingpattern private.In the first step a model of an algorithm for a driving pattern based insurance plan willbe developed. The algorithm uses a cascade of comparisons to aggregate information.Each single comparison influences operation on other parameters. This operations onparameter can be the increasing of a counter or the storage of a ticket. The developedalgorithm will be transferred in the second step into a privacy-preserving protocol betweentwo parties; here: an agent-box and a vehicle. The correctness and the privacy-preservingability of the protocol will also be proven.

1.3 Organization of this ThesisThis thesis is organized as follows: The background chapter, Chapter 2, offers an overviewof the existing connected car ideas. This review is driven by the interest of the possibilitiesand also of the security aspects in the field of connected cars. Additionally, a shortintroduction of Secure Multiparty Computation (SMC) and the used cryptosystem takesplace in Chapter 2. With the idea of the connected cars and driving style based insurancethe model is developed in Chapter 3. This chapter focus on an abstract descriptionof insurer to insured relationship to develop and algorithm for continually comparingmeasured properties with defined thresholds. This insecure algorithm has a basic buildingblock, which will be transformed in Chapter 4 to a privacy preserving protocol. Theprivacy preserving properties of the used protocols is shown in Chapter 5. The last

1.3 Organization of this Thesis 3

Chapter 6 resumes the conclusions and discuss the open problem, which are made by theassumptions during the developing of the model.

2 Background

Before it is possible to develop the in the introduction announced model, it is necessaryto figure out which are the state of the art and planned in future environment. The firstthree sections preparing a background view of connected vehicles. And the final twosections prepares the knowledge for Secure Multiparty Computation and the homomorphiccryptography.

2.1 Current Vehicular Communication ModelsThis section provides a short overview of state of the art technologies connected vehiclesand reviews Car2X/Vehicle2X idea. First, an introduction to Location Based Services(LBS) to get an impression of possible uses and categories illustrates how the automaticallygenerated location information can impact communication channels. Than, take a lookat passive technologies like radar and video to detect the environment and dangeroussituations for assisting the driver maintain safely. In the fourth, fifth, and sixth subsection,the current technologies [GMBK09, Web97, SNE06] of emergency call (eCall), theftprotection [SZC08], and car location services are discussed.

2.1.1 Location Based Service ApplicationsAs shown in Figure 2.1 the 0.25% of the world population were injured and 0.074% ofthe whole world population were killed in 2011 [SD13]. The automotive industry beganprograms for an active accident prevention [Gav01] by using cameras and radar sensors.These should detect dangerous situations earlier and assist the driver in their handling.These techniques can only scan and evaluate the scanned data.

With the enabling of the access to the Internet from any place, a new dimension ofcontent delivery based on the current location [Kys12] of the user was created. The ideaof an LBS was formed and first defined in [VMG+01]:

Definition 2.1.1 (Location based Service LBS) LBS are information services ac-cessible with mobile devices via the mobile network that utilize data generated regardingof the location of the mobile device.

In their lecture notes [SNE06], Steiniger, Neun, and Edwardes create an interestingpicture of uses for LBS. Figure 2.2 shows some of the categories of LBS. On the left sideof the figure are more user oriented goals like Leisure Activities, Games, InformationServices and Navigation. The more commercial categories are shown on the right side.The Emergency category is difficult to categorize, but this one can be shown also on the

6 2 Background

1995 2000 2005 20102400

2600

2800

3000

3200

3400

3600

Year

Inju

red

perm

illio

nin

habi

tant

s

(a) Injured in road accidents

1995 2000 2005 2010

80

100

120

140

160

Year

Kill

edpe

rmill

ion

inha

bita

nts

(b) Killed in road traffic accidents

Figure 2.1: Death or injury rates per million inhabitants. As shown, the number ofaccidents with dead or injured people per million inhabitants worldwidecollected by UNECE has been decreasing over the years. Data based on [SD13]from years 1993 to 2011 over all available countries.

right, because it is an external propelled service. The case of an emergency call will bediscussed later in subsection 2.1.3.Also the automotive industry has realized the added value of LBS and the lifestylefactor of smart phones. They also know the dangers of the distraction by mobilecommunication [HW06]. So the automotive industry is trying to connect cars to theinternet to also provide LBS. In most cases, the onboard electronics of the vehicleprovide an interface with the connection to a cell phone. The controlling units of thevehicle integrates the communication systems.Currently all big automotive companies try to provide in general new services [PvVT+11],mostly by using proprietary technical solutions including, e.g. BMW ConnectedDrive1,Audi connect2, Mercedes Comand3, Ford Sync4, Volkswagen Connected5 World, GMC6

and Buick7 IntelliLink, and Chevrolet MyLink8. To realize this services, often only anIOS or Andriod app is provided.

1http://www.bmw.de/de/topics/faszination-bmw/connecteddrive-2013/ubersicht.html2http://www.audi.de/de/brand/de/neuwagen/layer/audi-connect.html3http://apps.mercedes-benz.com/apps/de_DE4http://www.ford.de/UeberFord/FordTechnologien/Ford_SYNC5http://www.volkswagenag.com/content/vwcorp/content/de/innovation/communication_and_net

working/connected_world.html6http://www.gmc.com/owners/intellilink-how-to-guides.html7http://www.buick.com/experience/intellilink-infotainment-system.html8http://www.chevrolet.com/mylink-vehicle-technology.html

http://www.bmw.de/de/topics/faszination-bmw/connecteddrive-2013/ubersicht.html

http://www.audi.de/de/brand/de/neuwagen/layer/audi-connect.html

http://apps.mercedes-benz.com/apps/de_DE

http://www.ford.de/UeberFord/FordTechnologien/Ford_SYNC

http://www.volkswagenag.com/content/vwcorp/content/de/innovation/communication_and_networking/connected_world.html

http://www.volkswagenag.com/content/vwcorp/content/de/innovation/communication_and_networking/connected_world.html

http://www.gmc.com/owners/intellilink-how-to-guides.html

http://www.buick.com/experience/intellilink-infotainment-system.html

http://www.chevrolet.com/mylink-vehicle-technology.html

2.1 Current Vehicular Communication Models 7

Leisure

instantmessaging

buddy finder

Gamesgeocaching

mobile game

Information

shoppingguides

mobileyellow pages

travel planer

travel andtourist guides

infotaimentservices

Navigation

trafficmanagament

car parkguidance

indoorerouting

direction

LBSApplications

Tracking

lock/unlockservices

producttracking

people/vehicaltracking

Management

security(police, am-bulance, . . .)

environmental

fleetscheduling

customerrelationship

infrastructure

facility

Billing locationsensitivebilling

road tolling

Advertisingalerts ad-

vertisement

banners

Emergencyautomotiveassistance

emergencycalls

Figure 2.2: Categories of Location Service Applications, based on [SNE06]On the left side, the more user-oriented categories are listed. The morecommercial categories are on the right. Mostly all uses are currently availableor in late testing states and enabled by connecting the car to cell phones.

8 2 Background

2.1.2 Road Toll SystemsThe road toll systems are divided into two categories. The first systems generates the feefor road use, calculated by reading vehicle responder data. Examples for this kind oftechnology in the USA are ez-Pass and FasTrack [ADMR97]. They are using Road SideStation (RSS) to communicate with an Onboard Unit (OBU) to identify the vehicle andcalculate the fee based on roads used. So the gathering of the information is done by theservice provider.The second category also uses OBU for identification and for gathering the informationof roads used. The OBU provides more information than the identification, like the typeof the vehicle and the current direction, and calculates the fee based on this information.The RSS are only to observe and randomly check the accuracy of this system. In Germanythe TollCollect system works like this.Also all systems provide a service for manual fee collection on toll plazas.Neither systems is designed to track single or all vehicles but often are used for broadertasks, such as traffic forecast if the system has no explicit prohibition this such asTollCollect [Kön05].

2.1.3 Automatically Emergency Calls: eCallThe European Union decided in 2011 [Com03] to install a Europe-wide system forautomatically sent eCall by the year 2015. The EU plans that it will be mandatory forevery new vehicle to have this system [Hec14,Fel14]. This message should assist emergencyresponse teams to minimize the response time. The technical requirements [GMBK09]are:

∙ automatically dial the emergency number 112 and initialize a voice connection, ifan accident is detected

∙ possibility of manual and easy initiation of dialing to Public-Safety AnsweringPoint (PSAP)

∙ send the minimum set of data required for location and identification of the crashedvehicle

All data is supposed to be sent through General Packet Radio Service (GPRS), UniversalMobile Telecommunications System (UMTS), fourth generation of mobile telecommuni-cations technology (4G), or Short Message Service (SMS). The voice communication willbe established over Global System for Mobile Communications (GSM) [Tra09]. The SIMcards have no permanent connection to the Cellular Radio Network and only in case ofsending data or dialing a voice connection, the SIM card will be activated [Deu13]. Thismechanism should protect the citizens against government surveillance. Counter to theinterests of third parties, mainly the car insurers and vehicle makers, the eCall systemhas the specific purpose of rescue and not for diagnostic scenarios.

2.1 Current Vehicular Communication Models 9

2.1.4 Theft Protection and Car Location SystemsDespite declining numbers of stolen cars, the Anti-theft car device is the oldest, but mostprofitable field of application for cryptography in vehicles [Paa04]. The mechanisms aredivided into four categories:

∙ door lock

∙ electronic immobilizers

∙ alerting systems

∙ remote control and location services by Global Positioning System (GPS)

The oldest category is door locks, which are forced by law in Great Britain to usesince 1932 [Web97]. Today the a physical key is still in use, but also many keys areusing additionally modern techniques for access controls, like cryptography. The secondcategory includes all mechanisms to protect the car from being moving away. Thesemechanisms are physical such as a steering column locks [Web97] but can also integratedinto the engine controller like electronic immobilizers [LSS05]. Category three includesall mechanisms for alerts. One function is to get the attention of surrounding passersby.Another function is to alert the owner by sending a text message [Vai95]. The methods ofalerting of the passersby can be honking the horn or flashing the lights. The first use ofthe last two categories was in the 1960’s in Germany [Web97]. The most recent categoryis the location service and the remote control such as a remote shutdown, location viaGPS, and remote control of vehicles [YBC+07].Modern vehicles utilize technology of all categories.

2.1.5 Car Insurance by Driving Style AnalyticsSeveral providers of car insurance calculate insurance plans based on data of the drivingpattern of the driver. To incorporate Driving Style Analytics a kind of black box isinstalled into the vehicle to measure values and assessments regarding [Mau14]. Somemeasured values are:

∙ Number of journeys made

∙ Distances travelled

∙ Types of road used

∙ Speed

∙ Time of travel

∙ Acceleration and braking levels

∙ Accidents history

10 2 Background

Also [Mau14] lists 4399 different car insurance policies in the United Kingdom alone usinga black box. In the USA, Progressive with Snapshot is the most common insurance planwith a black box. Based on the plan it is possible to save up to 30% for each rate [Ove12].In Germany, since 2014 the Sparkassen-Direktversicherung also offers a car insurance byusing a black box [Gle13].All these systems collect the information directly in the vehicle and send them, in generalby using wireless networks, to an external data center for evaluation. The insured onlyhas access to this data by using the online interfaces of the insurer or sometimes an appon this smartphone. Figure 2.3 shows a model10 to describe this.The communication in Figure 2.3 can be divided into three categories:

insurer (I) agent-box (A) vehicle (V) insured (O)

HMI

conventional communication

sign insurance plan

direct communication

requesting data

setup

direct access

Setup

Operation

Finish

Sto

red

data

1a

1b

3

3

2

Figure 2.3: Communication channels depending on the current phase of billing period forcurrent car insurance with a blackbox.

(1) The connection (1a) between the insurer and the black box is temporary andrequires physical access. This is only granted during maintenance. Once the blackbox is installed into the vehicle, it is possible for the insurer to request the collecteddata (1b) by establishing a data connection. In some cases, the black box is sentback to the insurer after the billing period to access them physically.

9Website was visited on 06.03.2014.10The model is based on observations of current systems. Because of the closed system it is not possible

to describe the model in every detail correctly.

2.2 Car Communication Systems 11

(2) Between the black box and the vehicle are permanent connections (2), e.g., viainterface, bus, etc. Over this connection the black box has access to all data insidethe vehicle. The data is not limited or monitored by the vehicle or the insured.

(3) The communication between insurer (I) and insured (O) is done by conventionalcommunication infrastructure. This can be phone calls, letters, emails, prefabricatedforms, and personal meetings, along with a website interface to present the gatheredinformation.

2.2 Car Communication SystemsThis section deals with the question of how vehicles could communicate with each other.Some applications are specified in [ETS10a] and shown in Figure 2.4.

2.2.1 Car2X/Vehicle2X CommunicationThe terms Car2X, C2X, V2X, and Vehicle2X are used interchangeable in the literature.Typically, in older European documents of the European Telecommunications StandardsInstitute (ETSI) only Car2X and C2X are used. In newer documents and also in NorthAmerican documents the authors using Vehicle2X(V2X).A vehicle is no longer in comparison to Section 2.1 an isolated ecosystem of informationflows. With the possibility of communication with other participants, the automotiveindustry would benefit in future from opening their systems towards creating openstandards [Sch11].

Definition 2.2.1 (Car2Infrastructure) Car2Infrastructure means all communicationbetween a moving object like a car and a (geographically) stationary object like base-stationsor satellites.

The infrastructure can be a private/public Wireless Access-points or RSS for billing orlocal information services. Also the communication with geostationary satellites in case ofGPS or Gallileo is an example for Car2Infrastructure communication. The data exchangebetween a car and the cell phone of the driver is Car2Infrastructure communication. Itdoes not matter if the connection is over the air or using cables.

Definition 2.2.2 (Car2Car) Car2Car is the communication between two moving ob-jects such as two cars.

Typically the communication between two cars is only over the air. Mostly the participantshave an active role as sender or repeater and are passive as receiver. The communica-tion protocol is Wireless Local Area Network (WLAN) IEEE 802.11p [HDS+10], whichwas finally accepted in June 2010 by the Institute of Electrical and Electronics Engi-neers (IEEE).Car2X is the generic term for Car2Infrastructure and Car2Car communication. TheCar2X communication is divided into two parts: Car2Infrastructure and Car2Car. Ineach case, the car can be active as sender or passive as receiver.

12 2 Background

The ETSI starts their standardization [ETS10a] to define the Car2X communication forEurope. Figure 2.4 shows an overview of basic set of applications for Car2X communica-tions.

2.2 Car Communication Systems 13

Glo

bali

nter

-ne

tse

rvic

es

ITS

stat

ion

life

cycl

em

anag

emen

t

Vehi

cle

and

RSU

data

calib

ratio

n

Vehi

cle

softw

are

/da

tapr

ovisi

on-

ing

and

upda

te

Com

mun

ities

serv

ices

Load

ing

zone

man

agem

ent

Flee

tm

anag

emen

t

Insu

ranc

ean

dfin

anci

alse

rvic

es

Coo

pera

tive

loca

lser

vice

sLo

catio

nba

sed

serv

ices

Med

iado

wnl

oadi

ng

ITS

loca

lele

c-tr

onic

com

mer

ce

Aut

omat

icac

cess

cont

rola

ndpa

rkin

gm

anag

emen

t

Poin

tof

Inte

r-es

tno

tifica

tion

Coo

pera

tive

traffi

ceffi

cien

cy

Co-

oper

ativ

ena

viga

tion

In-v

ehic

lesig

nage

Lim

ited

acce

ssw

arni

ngan

dde

tour

notifi

catio

n

Enh

ance

dro

ute

guid

ance

and

navi

gatio

n

Traffi

cin

form

a-tio

nan

dre

com

-m

ende

diti

nera

ry

Spee

dm

anag

emen

t

Traffi

clig

htop

timal

spee

dad

viso

ry

Reg

ulat

ory

/co

ntex

tual

spee

dlim

itsno

tifica

tion

Car

2XA

pplic

atio

nsA

ctiv

ero

adsa

fety

Driv

ing

assis

-ta

nce

-Roa

dH

azar

dW

arni

ng

Dec

entr

aliz

edflo

atin

gca

rda

ta

Win

d

Visi

bilit

y

Roa

dad

hesio

n

Pre

cipi

tatio

ns

Haz

ardo

uslo

catio

n

Col

lisio

nris

kw

arni

ng

Roa

dwor

kw

arni

ng

Sign

alvi

ola-

tion

war

ning

Traffi

cco

ndi-

tion

war

ning

Stat

iona

ryve

hicl

eve

hicl

epr

oble

m

acci

dent

Wro

ngw

aydr

ivin

gw

arni

ng

Em

erge

ncy

elec

-tr

onic

brak

elig

hts

Driv

ing

assis

tanc

e-C

o-op

erat

ive

awar

enes

s

Mot

orcy

cle

ap-

proa

chin

gin

dica

tion

Inte

rsec

tion

col-

lisio

nw

arni

ng

Slow

vehi

cle

indi

catio

n

Em

erge

ncy

ve-

hicl

ew

arni

ng

Figu

re2.

4:In

telli

gent

Tran

spor

ting

Syst

em:

Bas

icse

tof

appl

icat

ions

defin

ition

base

don

[ET

S10a

]T

heus

eca

ses

from

ETSI

for

Car

2Xco

mm

unic

atio

ns.

14 2 Background

2.2.2 Message TypesThe communication model of Car2X/Vehicle2X uses two basic message types.

∙ Cooperative Awareness Message (CAM)/Basic Safety Message (BSM): periodicallybroadcast information about the station to other nodes in the vicinity (beaconing),will not be routed in general

∙ Decentralized Environmental Notification Massage (DENM)/WAVE service ad-vertisement (WSA): generated upon detecting an event and contains informationabout this event. They are addressed via geo-positioning, since they are relevantfor a defined geographic area

The Europeans use the terms CAM and DENM in their work. In the IEEE [IEE13] workthe terms BSM and WSA or only Wireless Access in Vehicular Networks (WAVE) as ageneral term are used. Additional to these basic messages, there are Signal Phase andTiming Message (SPaT) for traffic control and Service Announcement Message (SAM)for other services. Sometimes also a MAP - Geometric Intersection Description (MAP)message for geometric information is used.How these message types are embedded in the general C2X message format is shown inTable 2.1. Independent of the application (see Section 2.2.1) every data packet carries for

C2X Network Header C2X Message Payload

Network Layer Data Facility Layer Data

Senders

∙ ID

∙ position

∙ speed

∙ direction

∙ time-stamp

Addressing detailsfrom distributionand forwarding al-gorithm

Generic Informa-tion

Concert MessageInformation

∙ CauseCode

∙ ActionID

∙ cancellationflag

∙ generationtime

∙ validity du-ration

∙ CAM

∙ DENM

∙ . . .

Table 2.1: General Car2x Message Format

the transportation a lot of information, such as the current position, speed, and direction.

2.3 Security View of Background 15

2.3 Security View of BackgroundWith the connected vehicle, it is possible to attack the communication channels. Thissection gives an overview of mechanisms standardized to protect the system.

2.3.1 Overview of ParticipantsAll participants can be divided into two parties: the moving participants, called vehiclesand the service providers. This model, also includes an administrator to run the infras-tructure. Whoever actually fits in the role, e.g., government organizations or privateinterest groups, is not relevant. The important point is to manage the communicationservices between the moving participants and the service provider.The vehicles are characterizd by their rate of speed and their duration of use. So if avehicle is parked, the owner has the desires to take the vehicle out of the system. The ser-vice provider service provider wants to provide their services only to the correct targetedpartitions. A road hazard warning for example need not be addressed to someone, whois not in proximity. This challenge is addressed by using existing IP-based technologies.In the model of ETSI and the IEEE, based on the Road Side Unit (RSU) in the vehicles,

SatelliteBroadcast GPS/Galileo

RSS

RSS

RSSRSS

Cellular PortableInternet

Cellular PortableInternet

Hot-Spot(Wireless Lan)

vehicle-to-vehicle(e.g. ITS-5G, IR,...)

portable-to-vehicle

RSS-to-RSS

ITS-5G

CEN DSRC

IR

TerrestrialBroadcast

Figure 2.5: Scenario Illustration by ETSI (based on [ETS10b])

and RSS with different levels of Central Road Side Station (CRSS) as actors. The

16 2 Background

communication between different RSU and RSS based on the WLAN 802.11p and mobiledata connections [HDS+10]. If the RSU cannot connect to an RSS, it can use thirdgeneration of mobile telecommunications technology (3G) and/or 4G communication asa fallback. It is a standard approach to use both technologies as backup. Figure 2.5 alsoshows the ITS service and the Information Management Services (IMS) infrastructure.

2.3.2 Intelligent Transporting System (ITS) Security ServicesThe following subsection based on the definitions of [IEE13] and [ETS10c]. Somecompartments are based on [ETS13].The connected vehicle scenario requires different security services. These are discussedin [ETS10c] and listed here:

∙ Enrollment Service with Obtain, Update, and Remove Enrollment

∙ Authorization Services with Add authorization credential to single message, ObtainAuthorization Ticket, and Validate authorization credential of received messageService

∙ Security Association management11 with Establish, Remove, and Update SecurityAssociation

∙ Confidentiality services with Encrypt/Decrypt single outgoing/incoming messageand also Send†/Receive† secured message using Security Association

∙ Integrity services with Insert, Validate, and Calculate check value

∙ Replay Protection services with Timestamp message, Validate timestamp, Insertsequence number†, Validate sequence number†, Insert challenge†, Use receivedchallenge †, and Validate use of challenge†

∙ Accountability services with Record incoming/outgoing message

∙ Plausibility validation with Validate data plausibility, dynamic parameters, times-tamp, and sequence number†

∙ Remote management with Activate†/Deactivate† ITS transmission

∙ Report Misbehaving ITS-Station with Report Misbehavior†

Most of them are directly compatible with the required services of [IEE13]. The func-tionality, marked with footnote † , cannot be directly served, because of the absence ofthe support of the management of session based security associations in IEEE 1609.2.The services are also partially possible only with the shown workarounds in [ETS13].As shown in Figure 2.6, with the example of acquisition of enrollment credentials the

process of updating, revoking, and verifying the credentials is symmetric. Every partition

11 IEEE 1609.2 [IEE13] doesn’t support session management for security associations.

2.3 Security View of Background 17

Invoke Enrollment Request Enrollment Enroll Station Auth. Station Process Auth.

EnrollEnrollment Request

Authentication RequestEnrollment Challenge

RequestRequest

Enrollment ChallengeAuthentication Request

Enrollment Request

Enroll

SuccessfulSuccessful (Confirm: Accepted)

Enrollment ChallengeAuthentication Request

Enrollment Request

Enroll

UnsuccessfulUnsuccessful (Confirm: Failed)

Figure 2.6: Acquisition of enrollment credentialsThe ITS-Station provides services for Invoke Enrollment, Enrollment Request,and Process Authentication. The ITS infrastructure provides the EnrollStation and Authenticate Station.

has its unique receiver and responder. This model is used in both standards.In this work only, Car2X is considered on the application layer. The media layers are nothighlighted in detail. For further information see [WWM07].

18 2 Background

2.3.3 Vehicular Ad Hoc Network (VANET) Security CommunicationsApproaches

Bouassida creates an interesting overview of the state of the art attempts to secureVANETs communication in Ad Hoc Networks [Bou11]. Summarizing this work, hefigured out five methods (see Table 2.2).In [RH07], Maxim Raya and Jean-Pierre Hubaux discuss the security of vehicules in

Secure Communica-tion Protocols

Functionality Disadvantage

[RH07] PKI + Mobile authenticationand anonymity + Data confi-dentiality

Large number of anonymouscertificates renewed by the CA

[NWHC09] Based on [RH07] + Symmet-ric encryption to secure groupcommunications for non-safetyapplications

Large number of anonymouscertificates renewed by the CA

[LLZ+08] RSU-aided Certification Revo-cation + Conditional PrivacyPreservation

Availability of TM and MMand two cryptographic encryp-tions for each message

[FRM+08,KPB+08] PKI + Secure Communication+ Privacy Protection

Storage and communicationoverhead due to pseudonymscertification + constrainingCRL broadcast process

[SSBP09] Mobile authentication + Pri-vacy (temporary anonymouscertified keys)

Storage and communicationoverhead to update anony-mous keys

Table 2.2: Short review of VANET security communication approaches based on [Bou11]

Ad Hoc Networks, by using a public-key infrastructure to enforce mobile authenticationand anonymity. Every vehicle has a tamper-proof device storing private and public keys.This is extended by other anonymous keys signed by a special Certificate Authority (CA)to prove privacy and authenticity. Emergency messages are self-signed by the creatorand based on the trust-chain from the CA, these messages are authenticated. TheCA service can be provided by governmental transportation authorities or the vehicle’smanufacturers. A real key revocation is not intended. Only the short certificate lifetimeand the fast random use of anonymous keys provides this mechanism. Having only veryshort time ranges in the certificates, the authors see no need to revoke a key. A lifetimeof a key should be around one minute, then a randomly chosen unused key should begenerated. By using short lifetimes and avoiding the key reuse, the count of keys couldbecome huge. Only if a practitioner runs out of keys, the CAs have to be available. Sothe vehicular network can run independently for short times.In [NWHC09], Lo Nai-Wei and Tsai Hsiao-Chien build on the idea of Raya [RH07] asecure scheme for VANETs. In this approach, groups of partitions are build to agree on

2.4 Secure Multiparty Computation 19

one symmetric key. For key generation, they use the Diffie-Hellman algorithm. In eachgroup, one group leader is responsible for key generation and maintenance. But they alsoneed a huge number of keys, signed by the CAs for authentication.Lin et al. discuss two security issues with VANETs [LLZ+08]: certification revocationand privacy preservation. If a CA detects a certificate to revoke, the revocation list willbe updated and sent to all RSS. The RSS broadcast then updates all vehicles, whichcan update their lists of revoked members (Certificate Revocation List (CRL)). Theprivacy issue is based on the GSIS protocol (see [LSHS07]), which defines the use of twomanagement parties in the network: the tracing manager and the membership manager.The membership manager organizes the public group keys and a private key for eachvehicle. Each message is signed by these two keys. The authentication of a receivedmessage using the public group key can ensure that the message was transmitted bya legal group member. In case of a dispute, the misbehaving vehicle is traced, and itsidentity is revealed by the tracing manager. So every message needs to be signed withthe private key and encrypted with the public key, that means every message needs twocryptographic operations.In [FRM+08,KPB+08] Papadimitratos et al. show the idea of a VANET secured by anpublic key infrastructure. They describe the identity and cryptographic key management,privacy and secure communications in the context of beacon exchanges, neighborhooddiscovery and geocast messages transmission. Every vehicle has a unique long-termidentity, a public and private key and a certificate, provided by a CA. The keys arestored in vehicles and RSUs within a tamper proof module for storage and cryptographicoperations. According to pseudonymous authentication concerning anonymity, eachHardware Security Module (HSM) generates a set of key pairs (public and private keys),and sends the public keys to a CA to get their anonymous certificates. A key revocationcan be done by a revocation certificate and the HSM removes the key. The method isprovided by a CRL, which is broadcasted by the RSU.The authentication method presented by Studer et al. in [SSBP09] is based on mul-tiplying the Temporary Anonymous Certified Key (TACK) to ensure vehicles privacyand maintaining revocation of misbehaving participants. A trusted group manager isresponsible for distributing unique long-term keys to each vehicle (called group user key).The trusted group manager maintains a history of all key/RSU pairs it has issued, so hecan be aware of misbehaving vehicles. The regional CAs are responsible for generatingshort-term keys for each vehicle in the regions one TACK. Each vehicle communicatessecurely with the current regional CA by signing the sent messages with its group userkey. By updating the TACKs often, this ensures short-term linkability and long termunlinkability and the traceability and revocability of malicious nodes.

2.4 Secure Multiparty ComputationThis section gives information for the scenario of secure multiparty computation. Itmentions the security goals, the classifications, and behavior of possible attackers. Theideas for this section are based on [LP09].

20 2 Background

2.4.1 MotivationTo computing a problem with multiple parties often a trusted third party is used. Soevery party sends his input values to this trusted third party and the trusted third partydoes the computation. With finishing the computation, the trusted third party returnsthe output for each parties. So every party gets the personal result.The idea for distributed computing is based on the scenario where a number of distinctbut connected computing parties try to carry out some joint computation. So everyparty brings in his input and spends some calculation time and not just sending theinputs to a trusted third party and receiving the results. The mutual aim is securely,distributed computation with multiple parties. Often the question in a distributedcomputing scenario is how to handle the lost of one party. But in the secure multipartycomputation scenario every party is expected to stay alive. Also the focus for protocoldesign is to handle with misbehaving behavior of parties.

2.4.2 ComplexityBased on the scope of an attacker, attackers can be categorized into two categories:polynomial-time and computationally unbounded. To define an polynomial-time attacker,a polynomial-time algorithm has to be defined. The computation model is a Turing-machine.

Definition 2.4.1 (polynomial-time algorithm (from [May13])) Let 𝐴 be an algo-rithm. 𝐴 is called polynomial-time (pt) algorithm if and only if 𝐴 stops for every inputwith length 𝑛 in time O(𝑛𝑘) for a constant 𝑘. If the algorithm uses some random bits, heis called probabilistic polynomial-time (ppt) algorithm.

The notation 𝑦 := 𝐴(𝑥) indicates that 𝐴 is a pt-algorithm. If 𝐴 is a ppt-algorithm it isnotated as 𝑦 ← 𝐴(𝑥). As an example of an ppt-algorithm is a random select of a value 𝜎from a set {0, 1}, with the notation: 𝜎 ∈𝑅 {0, 1}. With the definition of polynomial-timeand probabilistic polynomial-time algorithm it is simple to define an polynomial-timeattacker:

Definition 2.4.2 (polynomial-time attacker (from [May13])) A attacker, whouses only polynomial-time and probabilistic polynomial-time algorithms is calledpolynomial-time attacker.

Definition 2.4.3 (computationally unbounded attacker (from [May13])) A at-tacker, who uses not only polynomial-time and probabilistic polynomial-time algorithms iscalled computationally unbounded attacker. He has no computational limits.

2.4.3 Security in Multiparty ComputationAs mentioned in the previous section, parties may misbehave, making them corrupted.The secure protocol should resist any attack from a corrupt party. The security relevantgoals are [LP09]:

2.4 Secure Multiparty Computation 21

∙ Privacy

∙ Correctness

∙ Independence of Inputs

∙ Guaranteed Output Delivery

∙ Fairness

Privacy includes, as mentioned before, that no party can learn more than he discoveredfrom the output and the protocol run. Also mentioned before, the correctness guaranteesthat each party obtains the correct output. The requirement independence of inputsdefines the independent choices of inputs for each party. This includes independent inputof corrupt parties and no correlation of inputs from corrupt and non-corrupt parties.Guaranteed output delivery means that corrupt parties should not be able to preventnon-corrupt parties from receiving their output. This includes also the possibility ofdenial of service attacks. In a fairness corrupt parties should receive their outputs only ifthe non-corrupted parties receive their outputs.In general, it a real world and an ideal world scenario is discussed. The ideal worldscenario limits a possible attacker more than the real world scenario. Discussions aboutreal world scenarios and ideal world scenarios are necessary and investigated in severalpublications like [Can00] or [LP09]. This theses will discus only two-party protocols andlimit the attacker to a defined scenario, namely the semi-honest model (Definition 2.4.6).

Definition 2.4.4 (Protocol) A protocol can be understood as an algorithm that isexecuted in a distributed fashion by multiple parties. According to the protocol specification,each party may perform some local computation and communicate with the other partiesthrough the exchange of messages.

A protocol ℱ for two parties, Alice and Bob, has as first inputs parameter the privateinputs of Alice and as second input parameter the inputs of Bob. The optional thirdparameter are the public inputs. The first output parameter is the output of Alice andthe second is the output of Bob. The inputs and outputs are grouped by brackets, if aparty has more than one input parameter. For the empty output of one party the ⊥symbol is used. The parameter are delimited by ‘,’. For a protocol ℱ with one inputAlice 𝑖𝑛𝑝𝑢𝑡𝐴𝑙𝑖𝑐𝑒, multiple inputs of Bob (𝑖𝑛𝑝𝑢𝑡𝐵𝑜𝑏1 , . . . , 𝑖𝑛𝑝𝑢𝑡𝐵𝑜𝑏𝑛), only one result forAlice 𝑜𝑢𝑝𝑢𝑡𝐴𝑙𝑖𝑐𝑒 and Bob 𝑜𝑢𝑝𝑢𝑡𝐵𝑜𝑏, but no public input is written as:

(𝑜𝑢𝑝𝑢𝑡𝐴𝑙𝑖𝑐𝑒, 𝑜𝑢𝑡𝑝𝑢𝑡𝐵𝑜𝑏)← ℱ(𝑖𝑛𝑝𝑢𝑡𝐴𝑙𝑖𝑐𝑒, (𝑖𝑛𝑝𝑢𝑡𝐵𝑜𝑏1 , . . . , 𝑖𝑛𝑝𝑢𝑡𝐵𝑜𝑏𝑛))

Definition 2.4.5 (Simulation-Based Secure Multiparty Computation Security)The protocol ℱ𝑓 is called secure against adversary 𝐴 if there exists a probabilisticpolynomial-time simulator 𝑆𝐼𝑀 such that:

𝑆𝐼𝑀 ({(𝑖, 𝑥𝑖, 𝑦𝑖)}𝑖∈𝐴) ≡ {(𝑖, 𝑥𝑖, 𝑦𝑖, 𝑟𝑖, 𝑚𝑠𝑔𝑖)}𝑖∈𝐴

22 2 Background

If the simulator can generate such a transcript using only the knowledge of the idealexecution, this implies that the transcript cannot contain more information than the idealoutput.

2.4.4 Influence of a Corrupt PartyIt is necessary to discuss which influence a corrupt party can have on the designedprotocol. As mentioned before, the protocols in this thesis have only two parties, so anattacker can corrupt only one party. If he takes control of all/both parties, he has nomore motivation to fulfill each step and he can present directly an output for each party.Classically, two12 models of corrupt party are distinguished: semi-honest and maliciousadversaries.

Definition 2.4.6 (Semi-honest adversaries from [LP09]) In the semi-honest ad-versarial model, even corrupt parties correctly follow the protocol specification. However,the adversary obtains the internal state of all the corrupt parties (including the transcriptof all the messages received), and attempts to use this to learn information that shouldremain private. This is a rather weak adversarial model. However, there are some settingswhere it can realistically model the threats to the system. Semi-honest adversaries arealso called ’honest-but-curious’ and ’passive’.

Definition 2.4.7 (Malicious adversaries from [LP09]) In this adversarial model,the corrupt parties can arbitrarily deviate from the protocol specification, according tothe adversary’s instructions. In general, providing security in the presence of maliciousadversaries is preferred, as it ensures that no adversarial attack can succeed. Maliciousadversaries are also called ’active’.

Definition 2.4.8 ((informal) Secure Two-Party Computation from [LPS08])In the setting of secure two-party computation, two parties with respective private inputs,wish to jointly compute a functionality. The security requirements are that no partylearns anything from the protocol (privacy) and that the output is computed correctlyaccording the prescribed functionality (correctness).

2.5 Homomorphic CryptographyThis sections deals with the definition of the used homomorphic cryptosystem (Definition2.5.4,2.5.3) and extends it to a (2,2) threshold cryptosystem (Definition 2.5.5).

2.5.1 IntroductionDefinition 2.5.1 (𝑛𝑒𝑔𝑙(𝑛) (from [May13])) A function f: N→ R+ is called negligibleif and only if for each polynomial 𝑝(𝑛) there exists an integer 𝑁 with such as for all

12Also more kinds of corrupt parties exists, but the semi-honest and malicious adversaries are the mostcommon.

2.5 Homomorphic Cryptography 23

𝑛 > 𝑁 :𝑓(𝑛) <

1𝑝(𝑛)

The set of function are named as 𝑛𝑒𝑔𝑙(𝑛).

2.5.2 CryptosystemDefinition 2.5.2 (Cryptosystem by [May12]) A cryptosystem (encryption scheme)is a triple of ppt algorithms (𝐾𝑒𝑦𝐺𝑒𝑛, 𝑒𝑛𝑐, 𝑑𝑒𝑐) which operates as follows:

∙ Given the security parameter 1𝑛 the key generation algorithm 𝐾𝑒𝑦𝐺𝑒𝑛 outputs akey pair (𝑠𝑘, 𝑝𝑘) of bit strings.

∙ For every pair (𝑠𝑘, 𝑝𝑘) in the range of 𝐾𝑒𝑦𝐺𝑒𝑛(1𝑛), and for every plaintext𝑚 ∈ {0, 1}* the encryption 𝑒𝑛𝑐 and decryption 𝑑𝑒𝑐 algorithms satisfy:

𝑃𝑟[𝑑𝑒𝑐𝑠𝑘(𝑒𝑛𝑐𝑝𝑘(𝑚)) = 𝑚] ≥ 1− 𝑛𝑒𝑔𝑙(𝑛)

The key 𝑠𝑘 is called secret key and used for the decryption, the key 𝑝𝑘 is the public keyand used for the encryption. The notation 𝑒𝑛𝑐𝑝𝑘(𝑚) stands for the usage of algorithm𝑒𝑛𝑐 with the encryption key 𝑝𝑘 and the input 𝑚 from the plaintext space. The samenotation is used for the decryption algorithm 𝑑𝑒𝑐.

In general a value 𝑎 in the plaintext space is written with a small letter and a value𝐴 = 𝑒𝑛𝑐𝑝𝑘(𝑎) in the ciphertext space is written with a big letter.

2.5.3 Homomorphic CryptosystemDefinition 2.5.3 (Homomorphic Cryptosystem (from [May13])) A cryptosys-tem is said to be homomorphic if for given encryptions 𝑒𝑛𝑐𝑝𝑘(𝑚1), 𝑒𝑛𝑐𝑝𝑘(𝑚2) it holds forall encryption keys 𝑝𝑘 that 𝑒𝑛𝑐𝑝𝑘(𝑚1 �𝑚2) = 𝑒𝑛𝑐𝑝𝑘(𝑚1)� 𝑒𝑛𝑐𝑝𝑘(𝑚2) for some operators� in the plaintext space and � in the ciphertext space.

In this work, a Homomorphic Cryptosystem with addition as the plaintext space operation� operation used.

2.5.4 Pallier CryptosystemIn the case of decryption it is necessary to define a division in Z. This is written as𝑎 : 𝑏 = 𝑎

𝑏 ∈ Z such that 𝑏 divides 𝑎 to differentiate from 𝑎𝑏 = 𝑎 · 𝑏−1 mod 𝑁 .

Definition 2.5.4 (Paillier Cryptosystem (from [May13])) Let 𝐺𝑒𝑛𝑀𝑜𝑑𝑢𝑙𝑢𝑠(1𝑛)generate 𝑛-bit long primes p, q and 𝑁 = 𝑝 · 𝑞.

KeyGen: (𝑁, 𝑝, 𝑞)← 𝐺𝑒𝑛𝑀𝑜𝑑𝑢𝑙𝑢𝑠(1𝑛)Return public key 𝑝𝑘 = (𝑁) and secret key 𝑠𝑘 = 𝜑(𝑁)

24 2 Background

enc: For 𝑚 ∈ Z𝑁 , choose 𝑟 ∈𝑅 Z*𝑁 and calculate:

𝐶 := (1 + 𝑁)𝑚 · 𝑟𝑁 mod 𝑁2

dec: The function 𝐿(𝑥) = 𝑥−1𝑁 uses division in Z. For ciphertext 𝐶 ∈ Z*𝑁2 calculate :

𝑚′ := 𝐿(︁𝑐𝜑(𝑁) mod 𝑁2

)︁and 𝑚 := 𝑚′ · 𝜑(𝑁)−1 mod 𝑁

2.5.5 Paillier Threshold CryptosystemThe Paillier Threshold Cryptosystem can be generally defined for more than two parties.In this work, it is only the usage for two parties necessary, so a (2,2) Threshold Cryp-tosystem, where two out of two parties are needed for the decryption of a ciphertext.This subsection orientates in [May12] and [HMRT12]. Both works are introducing a moregeneral approach.

Definition 2.5.5 (Paillier Threshold Cryptosystem (from [May12])) Let𝐺𝑒𝑛𝑀𝑜𝑑𝑢𝑙𝑢𝑠(1𝑛) generate 𝑛-bit long primes p, q such that 𝑁 = 𝑝 · 𝑞 and𝑔𝑐𝑑(𝑁, 𝜑(𝑁)) = 1. Let be 𝑙 = 2 parties 𝑃1, 𝑃2 with 𝛿 := 𝑙! = 2.

KeyGen: Let 𝑝, 𝑞 be primes with 𝑝 := 2 ·𝑝′+1 and 𝑞 := 2 ·𝑞′+1 and set 𝑁 ′ := 𝑞′ ·𝑝′. Randomlyselect 𝛽, 𝑎, 𝑏 ∈𝑅 Z*𝑁 and compute 𝑔 = (1+𝑁)𝑎 ·𝑏𝑛 mod 𝑁2. The key for decryption𝑠𝑘𝑑𝑒𝑐 = 𝛽 ·𝑁 ′ is shared using (2, 2)-Shamir secret sharing to obtain 𝑙 shares 𝑠𝑖 with1 ≤ 𝑖 ≤ 𝑙. Each party 𝑃𝑖 gets his shares 𝑠𝑖. Define 𝜃 = 𝐿(𝑔𝑁 ′·𝛽) = 𝑎 ·𝑁 ′ ·𝛽 mod 𝑁to construct the public encryption key 𝑝𝑘 as 𝑝𝑘 = (𝑔, 𝑁, 𝜃). Returns 𝑠𝑘1 = (𝑠1) and𝑠𝑘2 = (𝑠2).

enc: For 𝑚 ∈ Z𝑁 , choose 𝑟 ∈𝑅 Z*𝑁 and calculate:

𝐶 := (1 + 𝑁)𝑚 · 𝑟𝑁 mod 𝑁2

dec: The decryption is divided into the two steps dec𝑝𝑎𝑟𝑡𝑖𝑎𝑙 and dec𝑟𝑒𝑐𝑜𝑣𝑒𝑟:dec𝑝𝑎𝑟𝑡𝑖𝑎𝑙: For ciphertext 𝐶 ∈ Z*𝑁2 the party 𝑃𝑖 calculates with secret key 𝑠𝑘𝑖 = (𝑠𝑖):

𝐶𝑖 := 𝑐2·𝛿·𝑠𝑖 mod 𝑁2

⇒ 𝐶𝑖 := 𝑑𝑒𝑐𝑝𝑎𝑟𝑡𝑖𝑎𝑙𝑠𝑘𝑖(𝐶)

dec𝑟𝑒𝑐𝑜𝑣𝑒𝑟: The function 𝐿(𝑥) = 𝑥−1𝑁 uses the division in Z. To reconstruct 𝑚, it is

2.5 Homomorphic Cryptography 25

necessary to have 𝐶1, 𝐶2. Now, 𝑚 can be computed as:

𝑚 = 𝐿

⎛⎝ ∏︁𝑗∈{1,2}

𝐶2𝜇𝑆

0,𝑗

𝑗 mod 𝑁2

⎞⎠ · 14 · 𝛿2 · 𝜃

mod 𝑁

with 2𝜇𝑆0,𝑗 = 𝛿 ·

⎛⎝ ∏︁𝑗′∈{1,2}∖{𝑗}

𝑗′

𝑗′ − 𝑗∈ Z

⎞⎠⇒ 2𝜇𝑆

0,1 = 𝛿 ·(︂ 2

2− 1 ∈ Z)︂

= 2 · 𝛿

⇒ 2𝜇𝑆0,2 = 𝛿 ·

(︂ 11− 2 ∈ Z

)︂= −𝛿

⇒ 𝑚 = 𝐿(︁𝐶4·𝛿

1 · 𝐶−2·𝛿2 mod 𝑁2

)︁· 1

4 · 𝛿2 · 𝜃mod 𝑁

⇔ 𝑚 = 𝑑𝑒𝑐𝑟𝑒𝑐𝑜𝑣𝑒𝑟(𝐶1, 𝐶2)

Often the step of dec𝑝𝑎𝑟𝑡𝑖𝑎𝑙 is written as 𝐶𝑖 = 𝑑𝑒𝑐𝑠𝑘𝑖(𝐶), which means that party 𝑖

uses his private key 𝑠𝑘𝑖 = (𝑠𝑖) to perform dec𝑝𝑎𝑟𝑡𝑖𝑎𝑙 on ciphertext 𝐶.

The (𝑡, 𝑙)-Shamir secret sharing is introduced in [Sha79].

3 Example Model and Assumptions forvehicle insurance

This chapter presents an example model for an insurance plan of a vehicle. The modelis designed to be transferred in the next chapter (Chapter 4) to a privacy-preservingprotocol. The basic idea of the insurance plan is the comparison of two integers andusage of the result. The comparison should respect the privacy of the inputs.The first section deals with the description of this example model, involving an actor,trust relationships, rules, and how this all should be concreted. The second section dealswith the realization of the model. This section discusses assumptions with regards to thesecurity model, how the key for the encryption scheme is exchanged and stored, and whata complete cycle of the whole model looks like. This overall picture uses all assumptionsand building blocks which were made in this chapter.The example of this model takes place the insurer insured relationship and is implementedin the connected vehicle environment (see Chapter 2).

3.1 Model for Car Insurance Policy based on State DataAs mentioned in the last section, this section develops an example model of how acar insurance policy could be realized by using information (such as position, speed,acceleration, etc.) of the behavior of the driver of the vehicle (V). The use of thisvery personal information with comparison to the private thresholds brings in differentproblems, so this personal information has to be protected, but on the other hand, itmust be possible to categorize and assess the driver. The categorization of the driver isin the interest of the insurance company.

3.1.1 ActorsIn this scenario, we have two actors: The insured owner (O) of a vehicle (V) and the carinsurer (I). Every vehicle (V) has only one owner and every owner has only one insurer.The insurer (I) provides the insurance policy.

Properties of the Insured (O)

Every insured (O) has exactly one vehicle (V) and one insurance company. Of course,a model with multiple vehicles with the same owner is possible, but behaves the sameas a one to one connection between insurer (I) and insured (O), just by modeling theinsured (O) multiple times. The insured’s (O) vehicle (V) is assumed to have the capability

28 3 Example Model and Assumptions

to automatically collect data from its sensors. This data is, e.g., speed, acceleration,position, direction, and time. Additionally, the vehicle (V) provides wireless connection,e.g., Cellular Radio Network such as 4G and/or WLAN 802.11p1.The vehicle (V) offers hardware for computation, secure storage and a user interface. Thetemper resistant storage saves data such as user credentials and keys for cryptographicsystem(s) or user credentials and denies unauthorized physical and digital access. Thisstorage is also used for storing the pattern of this driving style.

Interests of the Insured (O)

The insured (O) has several interests. His obvious interests includes

∙ keep driving pattern private (privacy)

∙ get the cheapest possible rate or to save money compared to the current rate

∙ avoid the paperwork or extra costs, e.g., additional devices

∙ protect against security breaches by nosy parties such as the police

But he could also be interested in manipulating the system to gain an advantage. Theinsured (O) can either misbehave in the executed protocol or by using the collected datato generate new information. Some malicious interests could be:

∙ manipulate the system to avoid higher rates

∙ turn the system off

∙ using the system track other people such as family members

Properties of the Insurer (I)

The insurer (I) provides the insured (O) with car insurance. For the provision of thisservice the insurer (I) can build up his own infrastructure. This infrastructure is dividedinto three parts:

1. customer service part for billing and customer relation for processing claims

2. communication channels between the insurer (I) and the insured (O) via theconnection interfaces of his vehicle (V)

3. an agent-box (A) controlling the function of the vehicle (V) by providing an interfacefor secure computation (see Defintion 2.4.8)

After establishing the insurance policies, this agent-box (A) will be installed into thevehicle (V) and will be removed when the insurance expires. During this time period,the insurer (I) can maintain agent-box (A) by using communication channels to the

1As discussed before in Chapter 2.2.1, a good resource for more information is [HDS+10]

3.1 Model for Car Insurance Policy based on State Data 29

vehicle (V) (see Section 3.2.1). The insured (O) has no access to the agent-box (O).For WLAN 802.11p the insurer (I) can install RSS along the streets. He also can rentparts of the communication channels to other service providers. The important case is,that the whole infrastructure is subliminally to the insured (O) and he does not need toconcern himself with what and how the insurer (I) will run his infrastructure.

Interests of the Insurer (I)

The insurer (I) is interested in fulfilling the insurance plan. His main interests includes

∙ optimize rates individually

∙ detect risky drivers

∙ accrue knowledge of the correlation between driver properties and his driving style

∙ lower the rate of disbursements

∙ get a competitive advantage by offering lower rates

The insurer (I) could have the intent such as the insured (O) in using the system againstthe agreed purpose. Some interests could be

∙ use collected data in other cases, e.g., marketing

∙ sell collected data

∙ manipulate data for increasing rate and get rid of unpopular insured

∙ track insured

3.1.2 Trust RelationshipsFor the insured (O) the infrastructure of the insurer (I) is not meaningful. He trusts thatthe assured functionality provided by the insurer (I). Also he wants to trust that theinfrastructure and agent-box (A) have no hidden functions, such as collecting unnecessarydata other than the designed and defined functionality, or malicious functionality such asmanipulating the transmitted data to the advantage of the insurer (I).The insurer (I) can trust the insured (O) such as the correctness of the measured values.Also, he has to trust him, that he does not manipulate the calculations.The insurer (I) and the insured (O) can trust each other in that there is no misbehaviorduring the execution of the protocol.An initialized connection is stable without losing information, until one party is discon-nected. This is assured by the underlying and supported layers of connections.

3.1.3 RegulationsThe parameter for the interaction between the insurer (I) and the insured (O) are definedby insurance contract. The regulations preparing the privacy preserving protocol but aredesigned for the algorithm of evaluating the insurance plan.


Insurance Plan

The insurance plan is assumed to be based on a punishment system. Every violationof a rule has an impact on the insurance policy based on the penalty of the rule. Therules are categorized in rule sets and each rule set describes the criteria of one property.The rule with the highest impact in the rule set counts also as the rule with the lowestimpact. For example, if the insurer (I) wants to observe if the vehicle (V) is movingfast, first the speed on the vehicle (V) is measured and the measurement value is testedwith each rule correlated to the property speed. The penalties of each violated rule isconsidered. The rule sets are independent of each other.

Types of Rules

Every rule has criteria and impact for the insurance plan. The criteria describes thresholds,e.g., a rule about speeding defines speeding as moving more than 130𝑘𝑚

ℎ for more than30 seconds. This violation will increase the rate by the penalty of some points2. Ruleswith the same kind of criteria, but different thresholds are grouped to rule set and buildup to a cascade of rules. One rule can only be associated with one rule set. The rulealways describes a ’greater than’ correlation between the input values.

Violation of a Rule

A violation of a rule exists if the rule criteria is not met. Every rule will continually bechecked by the vehicle (V) with the help of the agent box. It is assumed that the impactof a violated rule is defined by the insurer (I) and unknown to the insured (O).

Determination of Thresholds and Threshold Criteria

The determination of thresholds criteria are made by the insurer (I). He also defineswhich the measured values of properties are checked against the thresholds, such as’speed’.

Publishing of Thresholds Criteria

The insurer (I) has to publish the criteria for current thresholds3, such as speed limits,to the insured (O). The requirements for the publishing are:

∙ integrity - the data cannot be modified in an unauthorized and undetected manner,such as changing the speed limit by the insurer (I) or a third party

∙ availability - the communication channels must be functioning correctly and theinsured (O) must be able to prove later which limits were sent, e.g., if he wants tocheck if a violation rule was correct

2In our abstract model, we do not consider the real impact of one point. Only the fact, that the realrate depends on the collected points matters.

3The insurer does not publish the thresholds.


∙ authenticity - it is provable who (the insurer (I)) sent the data and which source(local traffic authorities) originally transmitted the data


thresholds 𝑡𝑖 for property 𝒫publish criteria of property 𝒫

criteria of property 𝒫

Figure 3.1: Publishing the criteria for the current thresholds, e.g., the threshold for theproperty speed, by insurer (I).The information of a speed limit comparison in this case is sent to theinsured (O) and it is automatically reported to the vehicle (V). Also, theagent box needs the threshold.

For example, the insurer (I) wants to observe the property ’speed’. He let know theinsured (O) by the insurance plan that the property ’speed’ is observe and checked againsta fixed number of thresholds. The amount of thresholds are which are compared withthe speed is also defined in the insurance plan. So they are published to the insured (O).The rules are also implemented by the insurer (I) in the agent-box (A).

Ticketlog

Every vehicle (V) has to maintain a logbook called ticketlog. This contains tickets with

∙ time

∙ speed

∙ current position

∙ possible more

and has a minimum resolution4. It also might provide more status parameter suchas the sum of driven distance a day. The ticketlog has to have methods to provideintegrity. Integrity in this case means, that it is impossible to delete or manipulate an oldentry without being detected. Also, it should not be possible to skip the current entry.Skipping because of a technical problem has to be noticed with all available information.The insured (O) of a vehicle (V) has to publish this ticketlog in case of disagreementbetween both parties. The insurer (I) has only access to the ticketlog entries in case of arule violation, and he can only view the saved data from the rule violations. If no ruleviolations occurred, he has to prove, that no rule violations were detected.

4In the car2X setting, a vehicle (V) reports this information with a frequency of 1Hz to 10Hz.


With the publishing of the ticketlog, all included tickets are open.The ticketlog has a functionality be initialized named ‘initialize()’. With calling of‘initialize()’ the ticketlog is prepared to store new tickets. All existing tickets are removedwith the functionality of ‘clear()’. The ticketlog is a set with a order. The adding of aticket 𝑡 at the end of the ticketlog is written as 𝑡𝑖𝑐𝑘𝑒𝑙𝑜𝑔𝑜𝑢𝑡 = 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛 ‖ 𝑡.

Computations

All calculations in a vehicle (V) should be done by the vehicle (V). The agent-box (A)can assist the vehicle (V) in the case of the necessity of private computation. Thiscomputation are, e.g., signing a data block, encrypting or decrypting data, or comparetwo values. The insurer (I) can only work with the data revised by the insured (O).


do operation 𝑓 with input 𝑥

return result 𝑦 with 𝑦:=𝑓(𝑥)

Figure 3.2: Performing a computation of 𝑓 with help of the agent-box (A) on value 𝑥

It is assumed that all computation are infinity fast, so the time for the computation isnegligible. Both parties are synchronized, so they know when to check which propertywith how many thresholds. The vehicle (V) keeps the overview of the controlling structureand maintenance the results.

Billing Process

The billing process can be started by the insurer (I) by requesting the relevant ticketlogentries or by the insured (O) by sending his ticketlog for the billing process. The pillingprocess also marks the end of one billing period.The insurer (I) has to transmit the bill to the insured (O), and the security goals for

the transaction are:

∙ integrity - the data cannot be modified in an unauthorized or undetected manner,such as changing an entry of the insurer (I), the insured (O), or a third party, andthe same data cannot be sent undetected multiple times by one party

∙ availability - the communication channels must be functioning correctly and boththe insurer (I) and the insured (O) must be able to prove later which data was sent,e.g. if one wants to check if a violation rule has correctly been counted

∙ authenticity - it is provable who (the insured (O)) sent the data and which periodrelevant



get entries

entriesentries

bill

by insured (O)by insured (O)

requestget entries

entriesentries

bill

by insurer (I)by insurer (I)

system reinitialization

Figure 3.3: Protocol for billing process

∙ confidentiality - no involved third party is able to disclose the transmitted informa-tion

If both actors confirm this bill and the bill is paid, all collected entries which theinsurer (I) has saved must be deleted. In the case of disagreement, the ticketlog can bereviewed jointly.

System Initialization

An uninitialized vehicle (V) has to be initialized by the insurer (I). This could, e.g., be thecase, if insurer (I) and the insured (O) establish an (new) insurance. After every billingperiod, the vehicle (V) will be reinitialized by the insurer (I) to provide the starting data.During the initialization all necessary keys are jointly generated and exchanged.If a system re-initialization fails, the last known working configuration, will be used.During a system (re-)initialization, the insurer (I) has to update all necessary parametersfor the next billing period.



System (re-)initializationSystem (re-)initialization

updates

okSystem initialized

System initialized

Figure 3.4: System (re-)initialization

Maintenance

The insurer (I) has to provide and control the maintenance of the system. He is notallowed to read the ticketlog or manipulate the ticketlog or other collected data by theinsured (O) during maintenance. The insurer (I), or a person appointed by him, hasphysical access to the vehicle (V) and the agent-box (A).


need maintenanceOK/ready

maintenancedone

maintenancedone

maintenance finished

Figure 3.5: Maintenance Protocol

Error Handling

The insurer (I) has to prove, that the source of an error is caused intentionally by theinsured (O). In this case, the violation of the role of the relative rule set with the highestimpact, will be used. In every other case, no role of the relative rule set can be used. If aparty detects an error, the party will be responsible to immediately report the error tothe other party and the system must be reinitialized.


If the vehicle (V) has not provided data or reported wrong information of the allowedspeed, no rule with a speed condition can be triggered. The insured (O) has to find thesource of the problem and fix it.The insurer (I) holds the right to cancel the insurance plan, if the insured (O) disablesthe system.

3.1.4 IllustrationBased on these abstract ideas, this section illustrates of the ideas.

Basic Rules Set

Table 3.1 lists some example rules. The insurer (I) has to publish the criteria of the rulesto the insured (O) (see Figure 3.6), so the insured (O) is able to provide the necessarydata. A insurance plan could look like:

Example: Insurance planInsurance plan between insurer (O) and insured (I).

The insurer has to install a agent-box (A) into the vehicle (V), whichdoes not have the ability to save any information after the installation. Theagent-box (A) has to assist the vehicle (V) and has all condition of thecomparison installed.

The insured is allowed to compared∙ every 30 seconds the speed with four thresholds∙ once a day the driven distance with two thresholds∙ . . .

∙ after each day and month the collected penalties are compared with athreshold∙ . . .

The billing period includes six month and the insured (O) sends the sum ofpenalties for the months to the insurer (I).

Some rules have a frequency in order to protect them from being excessively.


criteria rules of insurance plan

Figure 3.6: The insurer (I) publishes the criteria of the rules to the insured (O).


ID rule set rule name rule criteria timeout penalty1 speed 10 𝑚

𝑠 average speed is more than 10 𝑚𝑠

for more than 30 sec5 min 1

2 speed 15 𝑚𝑠 average speed is more than 15 𝑚

𝑠for more than 30 sec

5 min 2



5 min 3



5 min 5

5 distance 300km drive more than 300km in one day — 16 distance 700km drive more than 700km in one day — 5...

......

......

...100 month first month the total of penalties for days for

the first month is higher than 23— 13

101 month second month the total of penalties for days forthe second month is higher than22

— 12

Table 3.1: Example rules of insurance plan

Example: A vehicle (V) drives with a average speed of 𝑏 = 26𝑚𝑠 . During

rule-checking, rule 1 (𝑏 > 10𝑚𝑠 ), rule 2 (𝑏 > 15𝑚

𝑠 ), and rule 3 (𝑏 > 20𝑚𝑠 )

trigger but not rule 4 (𝑣𝑎 ≤ 30𝑚𝑠 ). Therefore, this violation has an impact of

6(= 1 + 2 + 3).

It is not necessary that the insured (O) knows every detail of a rule. In this example, theinsured (O) knows that the current speed is compared four times. Therefore, he has tooffer the one speed measurement for four comparisons against each threshold.

Units

The unit of speed 𝑣 are 0.01𝑚𝑠 and saved as an unsigned 14-bit integer.

The position is divided into latitude and longitude each as a signed 32-bit integer as0.1𝑚𝑖𝑐𝑟𝑜𝑑𝑒𝑔𝑟𝑒𝑒.The time is saved as an unsigned 15 bit integer and is representing the milliseconds since00:00:00.000 of 01 January 2004 UTC.The distance between two positions are presented in 1𝑚 and saved as an unsigned 28-bitinteger.

Measurements

The vehicle (V) measures the properties based on the insurance plan. The measurementvalue is provided for each comparison with each threshold and will not be changed


between two comparisons. After the comparisons the measurement value is not neededso it will be deleted.

Computation Proofs

The insurer (I) needs proof that all computations of the rule criteria checks (e.g., sum ofdriven distance or the relationship between allowed and actual speed) are done in thedescribed way. He can use the agent-box (A) in the vehicle (V). This agent-box (A) isnot allowed to save any measured or calculated data.Since, the insured (O) knows all the data, it can check his calculations of penalties withthe penalties billed by the insurer (I) by opening the ticketlog jointly with the insurer (I).If one proof fails, the party who makes the calculation, has to prove the correctness ofthis calculation.

Billing Period

The billing period depends on the time. The minimum billing period is one month. Afterevery billing period, a bill is written, and the insurer (I) transmits the bill securely theinsured (O). The duration of a billing period is based on the size of the saved data andthe insurance policy.

Error Reporting

If the insured (O) detects an error, he will have to imminently report this to the insurer (I).During the presence of an error, he is not allowed to stop other non-affected and functionalprocesses. Erroneous data is ignored. When the insurer (I) becomes aware of an error,he has to imminently inform the insured (O) and start a process of debugging in amaintenance session.



reporting errornotify error

insured (O) detects errorinsured (O) detects error

notify error

insurer (I) detects errorinsurer (I) detects error

start maintenancestart debuggingfinish debugging

Figure 3.7: Protocol for error reporting

3.2 Realization 39

3.2 RealizationThis section uses the abstract idea and definitions from the previous section, to definethe external parameters, which are necessary for the implementation in the next chapter.It defines the security model and how the necessary keys are exchanged and stored. Thelast subsection puts all the pieces together, and presents a building block and how thisbuilding block can be used to construct an overall picture.The state-of-the-art communication model (Figure 2.3) will be transferred to a model forthe communication of the privacy-preserving protocol (Figure 3.8).

3.2.1 Communication Channels


HMI


sign insurance plan

Privacy-Perserving Protocol

setupSetup

Operation

Finish

Sto

red

data

publishing selected data

2

4

1

3

4

4

Figure 3.8: Communication channels depending on the current phase of billing period

Before it is possible to start with realization of the requirements, it is necessary todiscuss which kind of communication channel between the parties exists. The requirementsfor the communication channels are discussed in the previous section. The channels canbe divided into four categories:

(1) The connection (1) between the insurer (I) and the agent-box (A) is temporallyand requires physical access. The permanent connections is only granted duringthe maintenance.


(2) Between the agent-box (A) and the vehicle (V) physical access (2) (by e.g a interface,bus, ...) exists. Over this connection has the agent-box (A) no access to any datainside the vehicle (V). The communication is reduced to the privacy-preservingprotocol communication.

(3) Every vehicle (V) is equipped with a Human Machine Interface (HMI) (3) by themanufacturer to present information to the insured (O) and revise instructionsfrom him.

(4) The communication (4) between insurer (I) and insured (O) is conventional com-munication infrastructure. The conventional communication includes phone calls,letters, emails, prefabricated forms, and personal meetings.

The agent-box (A) is limited to have no writable data storage. Also, it is forbiddento read, write, or request information from the vehicle (V) without a request of thevehicle (V).All generated and evaluated information are stored in the vehicle (V) and the insurer (I)has no direct or indirect access through the agent-box (A) to this data. The insured (O)can request this data through the HMI (3) and communicate it to the insurer (I). Thepublishing of counter related information can be handled through the conventional com-munication channel (4) or an additional path might be established.The conventional communication channel (4) can be extended to a digital data link for abetter user experience.In Figure B.2 both, the current state of the art and this approach, of the commu-nications are listed as one figure. Also the problem statement is illustrated, the thecontrol over the gathered data is moved from the insurer (I)/agent-box (A) side to theinsured (O)/vehicle (V).

3.2.2 Security ModelThe adversaries in this model follow the semi-honest model (see Definition 2.4.6). Eachparty follows the protocol as specified, but keeps a record of the messages and tries togain as much information as possible from them [KT06] and [LLZ+08].

3.2.3 Key Exchange and StorageBoth parties have the public key and their share of the private key of a (2,2) thresholdcryptosystem. The private key is stored temper-resistant. The key exchange, is a partof the system initialization (see Section 3.1.3). It can be assumed that the system isinitialized with all necessary keys and that the keys are ready for their usage.

3.2.4 Checking Parameters and Store InformationFor the creation of the overall picture for a complete billing period it is necessary to doa fragmentation to smaller parts reduces of the complexity. This smaller parts can berepresented by a building block.

3.2 Realization 41

This overall picture and the used building block need the knowledge of the inputs values,so, whoever computes this algorithm knows the measurement values, totals, thresholds,and penalties. The transition from this algorithm, where every information is includes asplain text, to a privacy-preserving protocol is done in the next Chapter 4.

Generic Building Block

To design a generic building block, it is necessary to define its functionality. The buildingblock should generate a ticket, compare a value with a threshold and depending on theresult of the comparison, increase a counter by a penalty and append the ticket to theticketlog or leave the ticketlog untouched. The inputs if the building block consists of avalue 𝑎, a threshold 𝑏, a counter 𝑐𝑜𝑢𝑛𝑡𝑒𝑟, a penalty 𝑝𝑒𝑛𝑎𝑙𝑡𝑦, a ticketlog 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔, andsome miscellaneous information 𝑚𝑖𝑠𝑐. The miscellaneous information depends on thecase in which the building block is to be used: it could contain the current position,time, acceleration information, and multiple ticketlogs. The 𝑚𝑖𝑠𝑐 filed is a placeholder,which can later be filled with information. The output of one building block is alwaysthe counter and the ticketlog:

(𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔)← 𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘(𝑎, 𝑏, 𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑝𝑒𝑛𝑎𝑙𝑡𝑦, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔, 𝑚𝑖𝑠𝑐)

A generic building block to compare the value 𝑎 with the threshold 𝑏 is present in Figure3.2.1. The construction is inspired by a possible implementation. The ticket is generatedbefore the comparison, and the counter is always overwritten by the result of an addition.A additional presentation of this algorithm is appended in B.3.Algorithm 3.2.1: Generic BuildingBlock to check a property measurementor total 𝑎 against a threshold 𝑏Input: 𝑎, 𝑏, 𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑝𝑒𝑛𝑎𝑙𝑡𝑦, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔, 𝑚𝑖𝑠𝑐Output: (𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔)

1 begin2 𝑡← constructTicket(𝑎, 𝑏, 𝑚𝑖𝑠𝑐)5;3 if 𝑎 > 𝑏 then4 append 𝑡 to 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔;5 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 := 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 + 𝑝𝑒𝑛𝑎𝑙𝑡𝑦;6 else7 𝑡 := 𝑛𝑢𝑙𝑙;8 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 := 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 + 0;9 return (𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔);

Therefore, every rule has one threshold and one penalty both are predefined. Forevery rule check, a unique ticket 𝑡 is constructed based on several values and the uniquemiscellaneous input.

5It is also possible to construct the ticket only if 𝑎 > 𝑏 and append this to the ticketlog but as presentedhere, the structure is more similar to the secure implementation.


Nomenclature and Dependencies

Before starting to create an overall picture, it is necessary to discuss the different levelsof aggregation. The lowest level is the comparison of a value of a measurement (here:𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒) and a threshold (here: 𝑙).

To realize multiple rules6 for one measurement 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒 each thresh-old 𝑙 has to be checked against this 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒. Thence, the thresh-olds of the rules are denoted as a vector

−→𝑙 := (𝑙1, . . . , 𝑙𝑛) and the measurement

𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒 is a vector−−−−−−−−−−−−−−−→𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒 := ⟨𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒⟩ =

(𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒, . . . , 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒). For each element in the differencevector

−−−−−−−−−−−−−−−→𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒−

−→𝑙 which is greater than zero, the ticket 𝑡 has to be stored.

The tickets of this level are stored in the ticketlog of the data structure from onelevel higher (here: day 𝑑). The ticketlog is named 𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔. For each violation(𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒> 𝑙) the total of the penalties has to be increased. The increasefactor is defined by the violation penalty of the threshold related to the property fromwhich the measurement comes from. Thence, each property 𝒫 defines several thresholdswhich, in turn, a violation penalty for each threshold value. A property could describe’speed’, ’distance’, or other physical quantities with numerical values could be measured.Additionally to the description of type and thresholds, every property 𝒫 has a frequencyin time units7 to control the delay between two measurements.A snapshot for a time unit includes all properties8 without a value indicating are readyto measure or not. Also the PropertySnapshot data structure represents the link betweenthe properties and next higher level (here day).One day 𝑑 includes, as mentioned before, the violation penalty total and a ticketlog. Theday also includes a threshold with a limit and a penalty for its total 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙.As mentioned before, a day has a list of PropertySnapshot, one value per time unitvalues.Multiple days are organized as a list in one month. Like a day, a month has totalof violation penalties for the violation of the daily thresholds. Also the month has aticketlog and a threshold.The billing period is the highest level in this model. It includes a list of months, aticketlog, and a violation penalty total.The billing period, the month, and the day have all a total. These totals are computed

as follows:

6Each rule has exactly one threshold.7This time units have no detailed specification but they could be one second for example.8It is also possible to model only the properties, which are ready to measure, in this snapshot and skip

the non ready properties but this makes it only confusing.

3.2 Realization 43

Billingperiod

ID𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙: int𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔: Ticketlogmonths[]: Month

Month

ID𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙: int𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔: Ticketlog𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑:𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑

𝑚𝑖𝑠𝑐

𝑑𝑎𝑦𝑠[]: Day

Day

ID𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙: int𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔: Ticketlog𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑:𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑

𝑚𝑖𝑠𝑐

𝑠𝑛𝑎𝑝𝑠ℎ𝑜𝑡𝑠[]: PropertySnapshot

PropertySnapshot

𝑝𝑟𝑜𝑝𝑒𝑟𝑡𝑖𝑒𝑠[]: Property

Measurement

ID𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒: int𝑚𝑖𝑠𝑐

Property

ID𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝐷𝑒𝑙𝑎𝑦: int𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦: int𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑠[]: Threshold

Threshold

ID𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒: int,𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑃𝑒𝑛𝑎𝑙𝑡𝑦: int,𝑚𝑖𝑠𝑐

Ticketlog

IDtickets[] : Ticket

Ticket

IDticket

Table 3.2: Data structure for used classes


𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙 :=∑︁

{Month 𝑚: 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙>𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒}

𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.←˒𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑃 𝑒𝑛𝑎𝑙𝑡𝑦

𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 :=∑︁

{ Day 𝑑: 𝑑.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙>𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒}

𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.←˒𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑃 𝑒𝑛𝑎𝑙𝑡𝑦

𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 :=∑︁

{ PropertySnapshot 𝑠 in 𝑑.snapshots:for each Measurement 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒

of property 𝒫 in 𝑠,for each Threshold 𝑙 of property 𝒫 s.t.𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒>𝑙.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒}

𝑙.thresholdViolationPenalty

Owing to the three different and independent comparisons, the loss of detailed informationis accepted to make more privacy. Based on this idea, it is not necessary, to know whichmeasurement value violates which role. Only the count of violations in a defined timeperiod carries the necessary information. This means that it has the same impact, basedon the penalties, regardless of whether one rule with a high penalty is violated or manyrules with low penalties are violated.Table 3.2 lists all data structure elements. A visualization is provided in the Appendixunder B.5.

Overall Algorithm

Based on one building block and the idea which kind of data structure is necessary, it isnow possible to cascade up a whole process of comparisons. , such as one building blockfor each measurement compared with one limit, one for each week, and one for each weekand month such as shown in Figure 3.2.2 and in the Appendix Figure B.4.As mentioned before, different levels of aggregation exists. From the bottom to top, these

levels are between the calculations for one day, the daily calculation and the monthly,and finally the monthly to the billing period. The latter two are simpler than former firstso because here only one value is checked against one threshold at the end of each timeperiod. The first comparison block is more difficult because of the data structure andhow this elements are connected to each other. As Table 3.3 shows, each day has multiplesnapshots, which divides one day into multiple parts with a resolution of one time unit.Each snapshot contains all properties. Every property has a counter which indicatesthe count of time units between two measurements. Also every property has severalthreshold such as every measurement of a property is compared with each threshold ofthis property. Thus, between two snapshots in worst case, the sum of thresholds of eachproperty count comparison has to be done. The assumption here can be made, thatthe ’real’ time needed for this comparison is less than one time unit in the model9. Thefunction 𝑤𝑎𝑖𝑡𝑇 𝑖𝑙𝑙𝑁𝑒𝑥𝑡𝑇 𝑖𝑚𝑒𝑈𝑛𝑖𝑡𝐵𝑒𝑔𝑖𝑛𝑠() stops the algorithm until the next time unit

9This is the same assumption as in Section 3.1.3.

3.3 Example 45

←aggregate

valuesfor

each→

operation store tickets inBillingperiod

↓

Month 𝑚 →if(𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙

?>

𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒)modifies 𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙

→ 𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔

↓

Day 𝑑 →if(𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙

?>

𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒)modifies 𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙

→ 𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔

↓PropertySnapshot 𝑠

↓ ⎫⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎬⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎭

→

Property 𝒫↘

if (property 𝒫 is ready to measure)do measure 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒else skip to next property

↘Threshold 𝑙

↘𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔compare measurement 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒 of

property 𝒫 with threshold 𝑙:

𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒?> 𝑙.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒

modifies 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙

Table 3.3: Context of variable-naming of loops, thresholds, totals, and ticketlogs for theoverall picture in 3.2.2

starts.The complete algorithm for this model with respect to the discussion of the buildingblocks and the time unit is presented in Algorithm 3.2.2.

3.3 ExampleThis example assumes that a billing period has twelve month and every month has 30days. A day is divided into 2,880 time units, whereby each time unit is 30 seconds. Theproperties are ’speed’ in 1𝑚

𝑠 and ’acceleration’ in 0.1 𝑚𝑠2 . The 𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝐷𝑒𝑙𝑎𝑦 for ’speed’

should be 2 (= 60 seconds) and the 𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝐷𝑒𝑙𝑎𝑦 for ’acceleration’ should be 3 (=90seconds). The thresholds for property ’speed’ are 28 and 37 and for ’acceleration’ 1, 2,and 3. The penalties for ’speed’ are 4 and 7 points and for ’acceleration’ 2, 5, 13. So aday has 2,880 PropertySnapshots and each PropertySnapshot has both properties. Also,every day has a violation threshold of 25 and every month has a threshold of 15. Thepenalties should always be 410.With this information it is possible to run through an example:

10The model is designed to have different thresholds and penalties for each day and each month but tokeep it easier they are the same from now on.


The first time, the PropertySnapshot 𝑠 in 𝑑.𝑠𝑛𝑎𝑝𝑠ℎ𝑜𝑡𝑠[] runs through all properties,the property ’speed’ has a 𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 of 2, which is decreased to 1, and property’acceleration’ has a 𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 of 3, which is decreased to 1. Now the algorithmwill wait until the next time unit begins for the next run through all properties of𝑃𝑟𝑜𝑝𝑒𝑟𝑡𝑦𝑆𝑛𝑎𝑝𝑠ℎ𝑜𝑡. At this run the property ’speed’ has a 𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 of 1, whichis decreased to 0, and so it will be checked. First the 𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 counter is resetto 𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝐷𝑒𝑙𝑎𝑦 of property ’speed’ and the speed will be measured. If the speedis 29𝑚

𝑠 , the comparison the the first threshold 28 triggers (29 > 28) but not to thesecond threshold of 37 because 29 ≯ 37. The 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 will be increased by1 · 4 + 0 · 7 = 4 points. Because property ’acceleration’ still has a remaining delay, it willnot be measured but the delay will be decreased by one. In the next round, throughall properties of 𝑃𝑟𝑜𝑝𝑒𝑟𝑡𝑦𝑆𝑛𝑎𝑝𝑠ℎ𝑜𝑡 the property ’speed’ has a 𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 of 2,which is decreased to 1, and property ’acceleration’ has a 𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 of 1, whichis after the decrease zero, so the property ’acceleration’ will be measured. First the𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 will be reset to 𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝐷𝑒𝑙𝑎𝑦 than the acceleration will be measured.Let the acceleration be 3 · 0.1 𝑚

𝑠2 . Because 3 > 1 and 3 > 2 but 3 ≯ 3 only the first twothresholds of the rules are violated, so the penalty is now 1 · 2 + 1 · 5 + 0 · 13 = 7 and the𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 will be increased by 7 to 11. During the rest of the day, no moreviolation are found.After the first day the 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 is still 11 and since 11 ≯ 25, the𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 will not be increased and the 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 will bereset; also the 𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔with the tickets of every rule violation of this day will bereset.Many days with a 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 greater than 25 exist in the current month (theycould be 99, 26, 130, 70, 32) and the 𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 is at 20(= 5 · 4) at the endof the month. This 𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 is greater than the threshold (20 > 15) forthe month, so the 𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 will be increased by 7. During the billingperiod seven out of twelve months have a violation of the 𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 sothe 𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 is at the and of the billing period 49 = 7 · 7. Thisnumber 49 will be published and is the base for the next rate of the insurance plan. If oneparty does not trust the other party, the tickets of the billing period which are stored in𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔 will be published to check the correctness of the computations.

3.4 SummeryAs shown in this chapter, the developed model can be evaluated by a algorithm (Algorithm3.2.2). This algorithm needs several instances of the building block algorithm (Algorithm3.2.1). One requirement of both algorithms is that all inputs are in plain text so whoevercomputes this algorithms is able to read every information, included the measurementvalues, totals, thresholds, and the penalties. To give not one participant — here theinsurer (I) with agent-box (A) and insured (O) with vehicle (V) — all this knowledgein general a trusted third party does the computation. The next chapter (Chapter 4)will use the building block algorithm (Algorithm 3.2.1) and transfers it to a privacy-

3.4 Summery 47

preserving protocol. Also, the overall algorithm (Algorithm 3.2.2) will be transferred toa privacy-preserving protocol, so a trusted third party is not necessary anymore.


Algorithm 3.2.2: Algorithm for continually observing the measurements:OverallPictureInput: Billingperiod 𝑏𝑝Output: 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔/* The typography of 𝑣𝑎𝑙←Function(𝑣𝑎𝑙) is equal to Function(𝑣𝑎𝑙)→ 𝑣𝑎𝑙 and

should only improve the readability. */1 for Billingperiod 𝑏𝑝 do2 reset (𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙);3 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑖𝑛𝑖𝑡𝑖𝑎𝑙𝑖𝑧𝑒();4 foreach Month 𝑚 in 𝑏𝑝.𝑚𝑜𝑛𝑡ℎ𝑠[] do5 reset (𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙);6 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑖𝑛𝑖𝑡𝑖𝑎𝑙𝑖𝑧𝑒();7 foreach Day 𝑑 in 𝑚.𝑑𝑎𝑦𝑠[] do8 reset (𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙);9 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑖𝑛𝑖𝑡𝑖𝑎𝑙𝑖𝑧𝑒();

/* During the day all measurements are checked continually with aresolution of time unit. */

10 foreach PropertySnapshot 𝑠 in 𝑑.𝑠𝑛𝑎𝑝𝑠ℎ𝑜𝑡𝑠[] do11 foreach Property 𝒫 in 𝑠.𝑝𝑟𝑜𝑝𝑒𝑟𝑡𝑖𝑒𝑠[] do12 𝒫.𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦− = 1;13 if 𝒫.𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 ≤ 0 then14 𝒫.𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 = 𝒫.𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝐷𝑒𝑙𝑎𝑦;15 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡← 𝒫.𝑚𝑒𝑎𝑠𝑢𝑟𝑒();16 foreach Threshold 𝑙 in 𝒫.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑠[] do17 checkThreshold(18 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡.𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒, 𝑙.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒19 𝑙.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃𝑒𝑛𝑎𝑙𝑡𝑦, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙20 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔21 GenMisc(𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡.𝑚𝑖𝑠𝑐, 𝑙.𝑚𝑖𝑠𝑐, . . .)22 )→ (𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔);

/* Wait until next time unit begins. */23 waitTillNextTimeUnitBegins();24 checkThreshold(25 𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒,26 𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃𝑒𝑛𝑎𝑙𝑡𝑦, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙27 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔28 GenMisc(𝑑.𝑚𝑖𝑠𝑐, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔. . .)29 )→ (𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔);30 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑐𝑙𝑒𝑎𝑟();31 checkThreshold(32 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒,33 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃𝑒𝑛𝑎𝑙𝑡𝑦,

𝑝𝑏.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙34 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔35 GenMisc(𝑚.𝑚𝑖𝑠𝑐, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔, . . .)36 )→ (𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔);37 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑐𝑙𝑒𝑎𝑟();38 return 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑝𝑢𝑏𝑙𝑖𝑠ℎ()

4 Protocol DescriptionThis chapter deals with designing a building block in privacy-preserving fashion ofthe algorithm of the previous Chapter. Two different protocols are presented for thecomparison of integers. The first protocols compares bitwise, the second uses homomorphiccryptography to compare the integers in one step. Both algorithms are extended to haveshared output. This output will be used to increase the encrypted counter and storean encrypted ticket or blind the counter and erase the ticket. With these algorithms(comparison with shared output, ticket and counter manipulation) it is possible to realizethe building block from of Chapter 3. With the basics of one building block, the wholeprocess can be realized as a cascade and this is shown in the end of this chapter.

4.1 PreliminariesIn this chapter the Paillier cryptosystem (Definition 2.5.4) is used as a homomorphiccryptosystem. A short review of the notation:

∙ 𝑝𝑘 is the public key and 𝑠𝑘𝑎, 𝑠𝑘𝑏 the private keys of Alice and Bob

∙ homomorphic addition of two encrypted values 𝑎 and 𝑏:𝑒𝑛𝑐𝑝𝑘(𝑎 + 𝑏) = 𝑒𝑛𝑐𝑝𝑘(𝑎) � 𝑒𝑛𝑐𝑝𝑘(𝑏) = 𝑒𝑛𝑐𝑝𝑘(𝑎) · 𝑒𝑛𝑐𝑝𝑘(𝑏)

∙ homomorphic multiplication of an encrypted value 𝑎 with a constant integer 𝑘:𝑒𝑛𝑐𝑝𝑘(𝑘 · 𝑎) = 𝑒𝑛𝑐𝑝𝑘(𝑎) �𝑐 𝑘 = 𝑒𝑛𝑐𝑝𝑘(𝑎)𝑘 = 𝑒𝑛𝑐𝑝𝑘(𝑎) · . . . · 𝑒𝑛𝑐𝑝𝑘(𝑎)⏟ ⏞

𝑘-times

It will also be proved, that homomorphic multiplication with a negative integer 𝑘is possible (3.2.2). An XOR operation of two shared bits and a special case of ahomomorphic multiplication (symbol: �) will be defined later in this chapter (B.7 and4.4.1). Instead of the Paillier Cryptosystem any other homomorphic cryptosystem couldbe used which is additvely homomorphic operation, allows to multiply encryptions witha positive and negative constant, and is semantically secure.The symbol ⊥ indicates an empty output. Uppercase characters indicate an encryptionand on uppercase character with an index indicates a partially decrypted encryption.This chapter deals only with comparison of ’greater than’ (>). For multiple rules withdifferent limits for one measurement value, the whole, F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 (see Section 4.5) hasto be used for each rule and each measurement.The construction and the storage of the tickets are simplified. Thus, the generation ofthe tickets depends on the usage of the ticket 𝑡. Storage of an encrypted ticket 𝑇 meansthe appending of the ticket on the ticketlog (see Section 3.1.3).

50 4 Protocol Description

4.1.1 Summary of AssumptionsTo collected all assumptions at one point, they are listed here again:

∙ the insurer (I) defines rules and implements them into the agent-box (A) based onthe insurance plan (Section 3.1.3 and Table 3.1)

∙ a rule is a ’greater than’ (>) comparison of a value with a threshold and has apenalty in case of a violation (Sections 3.1.3, 4.1)

∙ a value is a total or a measurement of a property (Sections 3.1.3 and 3.2.4)

∙ a total describes the sum of penalties of violated rules and has only one threshold(Section 3.2.4)

∙ the agent-box (A) has tamper-resistant storage for its keys (Section 3.1.1)

∙ the vehicle (V) has tamper-resistant storage for keys, totals, and ticketlogs (Section3.1.1)

∙ all communication channels are authentic, available, and provide data integrity(Sections 3.2.1, 3.1.3, 3.1.2, and 3.1.3)

∙ the computing time for every computation is negligible (Section 3.1.3)

∙ insurer (I)/agent-box (A) and vehicle (V)/insured (O) are synchronized, so theyknow when which property/total is checked against how many thresholds (Figure3.3)

The 1 : 1 connection between insurer (I), agent-box (A), vehicle (V), and insured (O)can extend to multiple to multiple connection, but this has no influence to the useddeveloped model. The assumptions of the tamper-resistant storage for both parties andthe assumptions for the communication channels keeps it simpler, so it is not necessaryto take care of external influence by an external party.The insurer (I)/agent-box (A) wants to keep the rules specifying, consisting of thresholdsand penalties for each property, private. The insured (O)/vehicle (V) on his wants tokeep private the measurements, ticketlogs with the tickets and the totals. Finally itcan be assumed that the actors know which value is checked when and with how manythresholds. So they are synchronized (see Figure 3.3).

4.2 Needed Functionalities 51

4.2 Needed FunctionalitiesTo realize one building blocks from Figure 3.2.2 with (⊥, (𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟), 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡))←F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 ((𝑒𝑛𝑐𝑝𝑘(𝑎), 𝑒𝑛𝑐𝑝𝑘(𝑝𝑒𝑛𝑎𝑙𝑡𝑦)), (𝑒𝑛𝑐𝑝𝑘(𝑏), 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟), 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐)),the following functionality is needed:

∙ (𝜎𝑎, 𝜎𝑏)← F𝑐𝑜𝑚𝑝𝑎𝑟𝑒(𝑒𝑛𝑐𝑝𝑘(𝑎), 𝑒𝑛𝑐𝑝𝑘(𝑏)) Compare two encrypted integers

∙ (⊥, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡)← F𝑡𝑖𝑐𝑘𝑒𝑡(𝜎𝑎, (𝜎𝑏, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐)) Save or erase a ticket

∙ (⊥, 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟))← F𝑐𝑜𝑢𝑛𝑡𝑒𝑟((𝜎𝑎, 𝑒𝑛𝑐𝑝𝑘(𝑝𝑒𝑛𝑎𝑙𝑡𝑦)), (𝜎𝑏, 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟))) Increaseor not increase a counter by a penalty

The first function F𝑐𝑜𝑚𝑝𝑎𝑟𝑒 compares the input 𝑎 of the first party and the input 𝑏 ofthe second party and returns the output bits 𝜎𝑎 and 𝜎𝑏 with 𝜎𝑎 ⊕ 𝜎𝑏 = 1⇔ 𝑎 < 𝑏 andthe inversion 𝜎𝑎 ⊕ 𝜎𝑏 = 0 ⇔ 𝑎 ≥ 𝑏. The second function F𝑡𝑖𝑐𝑘𝑒𝑡 computes a ticket 𝑡and append it to the ticketlog if and only if (𝜎𝑎 ⊕ 𝜎𝑏) = 1. In every other case, theticket 𝑡 should be destroyed by removing the information from the ticket. This is equiv-alent to a homomorphic multiplication of an encrypted 𝜎𝑎 ⊕ 𝜎𝑏 and the encryptedticket 𝑡: (⊥, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡) ← F𝑡𝑖𝑐𝑘𝑒𝑡(𝜎𝑎, (𝜎𝑏, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐)) := (⊥, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡 =𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛 ‖ 𝑒𝑛𝑐𝑝𝑘((𝜎𝑎 ⊕ 𝜎𝑏) · 𝑡)). The third function F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 increases the counter𝑐𝑜𝑢𝑛𝑡𝑒𝑟 by 𝑝𝑒𝑛𝑎𝑙𝑡𝑦 if and only if 𝜎𝑎 ⊕ 𝜎𝑏 = 1. This means (⊥, 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟)) ←F𝑐𝑜𝑢𝑛𝑡𝑒𝑟((𝜎𝑎, 𝑒𝑛𝑐𝑝𝑘(𝑝𝑒𝑛𝑎𝑙𝑡𝑦)), (𝜎𝑏, 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟))) := (⊥, (𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟 + (𝜎𝑎 ⊕ 𝜎𝑏) ·𝑝𝑒𝑛𝑎𝑙𝑡𝑦))).By comparing the inputs and outputs of F𝑐𝑜𝑚𝑝𝑎𝑟𝑒, F𝑡𝑖𝑐𝑘𝑒𝑡, and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 the last twofunctions F𝑡𝑖𝑐𝑘𝑒𝑡 and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 are independent of each other, but depending on the outputof F𝑐𝑜𝑚𝑝𝑎𝑟𝑒. Therefore, F𝑐𝑜𝑚𝑝𝑎𝑟𝑒 has to be computed first and then F𝑡𝑖𝑐𝑘𝑒𝑡 and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟.It follows that the inputs for Alice are fresh encryption 𝑒𝑛𝑐𝑝𝑘(𝑎) and fresh encryp-tion 𝑒𝑛𝑐𝑝𝑘(𝑝𝑒𝑛𝑎𝑙𝑡𝑦). The inputs for Bob are 𝑒𝑛𝑐𝑝𝑘(𝑏), 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟), 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛 ={𝑒𝑛𝑐𝑝𝑘(𝑡1), . . .}, and 𝑚𝑖𝑠𝑐. Alice has no output but Bob has as output the modified𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟) and the 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡 = 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛 ‖ 𝑡.

4.2.1 Ticket GenerationEach ticket 𝑡 is generated by the function constructTicket(𝑎, 𝑏, 𝑚𝑖𝑠𝑐). The ticket𝑡 in the plaintext space. The input value 𝑚𝑖𝑠𝑐 is generated by GenMisc(. . .). By thegeneric description of GenMisc(. . .) it is possible to generate 𝑚𝑖𝑠𝑐 from several differentinputs. In the case of comparison a total with a threshold it is necessary to transport theticketlog into the new ticket. So GenMisc uses additionally to some other informationalso the ticketlog to generate 𝑚𝑖𝑠𝑐 without loosing information from the tickets inside ofthe ticketlog. Also the constructTicket function keeps the information of all tickets.Both functions are necessary to guarantee that the generated ticket 𝑡 is in the plaintextspace. The real implementation of constructTicket and GenMisc will not bediscussed in this work.


4.3 Protocol to Compare Two Positive Integers with Paillier:F𝑐𝑜𝑚𝑝𝑃𝑎𝑖𝑙𝑙𝑖𝑒𝑟

The second protocol to compare two positive integers is based on the Paillier cryptosystem.The corresponding functionality is called F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 and provides F𝑐𝑜𝑚𝑝𝑎𝑟𝑒:

(𝜎𝑎, 𝜎𝑏)← F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟(𝑒𝑛𝑐𝑝𝑘(𝑎), 𝑒𝑛𝑐𝑝𝑘(𝑏))

Because F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 uses a subtraction, the result can be less than zero. But negativevalues are not within [0, 𝑛 − 1], so the upper half of the range [0, 𝑛 − 1] is defined asnegative numbers: [︂

⌈𝑛2 ⌉, 𝑛− 1]︂≡

[︂−⌊𝑛2 ⌋,−1

]︂So, the plaintext space has size |

[︀⌈𝑛

2 ⌉, 𝑛− 1]︀| = 𝑛− 1−⌈𝑛

2 ⌉+ 1 = 𝑛−⌈𝑛2 ⌉ = −⌊𝑛

2 ⌋ whichis only the half size of the normal plaintext space size of the Paillier cryptosystem.

4.3.1 Comparing Two Integers using the Kreschbaum ProtocolThe idea in Protocol 4.1 is based on [KT06] to compare two integers with hiding themby multiplication with a random integer 𝑟 and an addition with an other random integer𝑟′. Because 𝑟′ is greater or equal 0 but less the r follows 𝑟 · 𝑏 + 𝑟′ < (𝑟 + 1) · 𝑏. Let𝑚 := 𝑟 · 𝑎 − 𝑟 · 𝑏 + 𝑟′ be, so the relation 𝑎 ≥ 𝑏 ⇔ 𝑟 · 𝑎 ≥ 𝑟 · 𝑏 + 𝑟′ ⇔ 𝑚 ≥ 0 and𝑎 < 𝑏⇔ 𝑟 · 𝑎 < 𝑟 · 𝑏 + 𝑟′ ⇔ 𝑚 < 0 is given.Bob chooses random integer 𝑟 and 𝑟′ and multiplies 𝑟 with an encryption of 𝑎 and with

𝑏 using multiplication with a constant (Definition 2.5.3). Bob homomorphically adds 𝑟′

to the product 𝑟 · 𝑏 to remove the change to guess his 𝑏 in only a few tries by Alice. ThenBob sends the generated and encrypted 𝑚 = 𝑟 · 𝑎− 𝑟 · 𝑏 + 𝑟′ to Alice. In the last step ofProtocol 4.1, Alice decrypts c and computes:

(𝑎 ≥ 𝑏) :=(︂

(𝑚 mod 𝑛) < ⌈𝑛2 ⌉)︂

⇔ (𝑎 ≥ 𝑏) :={︃

0 if 𝑚 < 0⇔ 𝑟 · (𝑎− 𝑏) + 𝑟′ < 0⇔ 𝑎− 𝑏 ≤ −1 < − 𝑟′

𝑟 ≤ 01 if 𝑚 ≥ 0⇔ 𝑟 · (𝑎− 𝑏) + 𝑟′ ≥ 0⇔ 𝑎− 𝑏 ≥ 1 > 𝑟′

𝑟 ≥ 0

The result is 0 if 𝑎 ≥ 𝑏 and 1 if 𝑎 < 𝑏.

4.3.2 Extension to Compare Two Positive Integers with Shared OutputBased on Protocol 4.1 and ideas from [May12], the protocol can be designed in such away, that both parties any knowledge about the result of the comparison. One party getsthe encryption of the result and can use it for the next comparison. Alice and Bob possessthe public key 𝑝𝑘 of a (2,2) threshold cryptosystem of a Paillier instance. For details

4.3 Protocol to Compare Two Positive Integers with Paillier: F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 53

Alice Bobhas private integer 𝑎 has private integer 𝑏

(𝑝𝑘, 𝑠𝑘)← 𝐺𝑒𝑛(1𝑛)𝑒𝑛𝑐𝑝𝑘(𝑎),𝑝𝑘−−−−−−−→

𝑟, 𝑟′ ∈𝑅 N, 0 ≤ 𝑟′ < 𝑟

𝑒𝑛𝑐𝑝𝑘(𝑚) := 𝑒𝑛𝑐𝑝𝑘(𝑎)𝑟 · 𝑒𝑛𝑐𝑝𝑘(−𝑟 · 𝑏 + 𝑟′)= 𝑒𝑛𝑐𝑝𝑘(𝑟 · 𝑎− 𝑟 · 𝑏 + 𝑟′⏟ ⏞

:=𝑚

)

𝑒𝑛𝑐𝑝𝑘(𝑚)←−−−−−−

𝑚 := 𝑑𝑒𝑐𝑠𝑘(𝑒𝑛𝑐𝑝𝑘(𝑚))

and decide 𝑎 ≥ 𝑏 if 𝑚 < ⌈𝑛2 ⌉

Figure 4.1: Comparing two integers (see [KT06])

such as the key generation function (𝑝𝑘, 𝑠𝑘𝑎, 𝑠𝑘𝑏)← 𝐾𝑒𝑦𝐺𝑒𝑛𝑝𝑎𝑖𝑙𝑙𝑖𝑒𝑟(1𝑛) see Section 2.5.5.The protocol generates output bit 𝜎𝑎 for Alice and 𝜎𝑏 for Bob:


Bob decides whether he performs operation 𝑎 > 𝑏 or 𝑎 < (𝑏 + 1) by choosing his outputbit 𝜎𝑏 randomly in {0, 1}. Bob partially decrypts the ciphertext 𝑒𝑛𝑐𝑝𝑘(𝑐) using his shareof the private key 𝑠𝑘𝑏. Alice partially decrypts 𝑒𝑛𝑐𝑝𝑘(𝑐) using it private share 𝑠𝑘𝑎 anduses the result to recover the plaintext.Based on which 𝑚 (𝑚 ≥ 𝑛

2 or 𝑚 < 𝑛2 ), knows the result 𝜎𝑎 of the comparison operation

but does not know which operation B chose. Now, both parties have a part for thecomparison of the inputs, without know if whether 𝑎 < 𝑏 or 𝑎 ≥ 𝑏 holds. The actualresult is the combination of 𝜎𝑎 and 𝜎𝑏 with the F𝑋𝑂𝑅 operation.By using a Paillier homomorphic cryptosystem, it is possible to use negative exponents.An operation 𝑒𝑛𝑐𝑝𝑘(𝑚)−𝑑 can be written as

(︁𝑒𝑛𝑐𝑝𝑘(𝑚)𝑑

)︁−1and the plaintext of 𝑒𝑛𝑐𝑝𝑘(𝑚)𝑑

corresponds to a multiplication of ciphertext 𝑚 with constant integer 𝑑: 𝑒𝑛𝑐𝑝𝑘(𝑚)𝑑 =𝑒𝑛𝑐𝑝𝑘(𝑑 ·𝑚). Now let 𝑒 := 𝑑 ·𝑚. It is necessary to show that the operation 𝑒𝑛𝑐𝑝𝑘(𝑒)−1 is


Alice Bobhas encryption of has encryption ofprivate integer 𝑎 private integer 𝑏

𝑒𝑛𝑐𝑝𝑘(𝑎)−−−−−→

𝜎𝑏 ∈𝑅 {0, 1}𝑟, 𝑟′ ∈𝑅 N, 0 ≤ 𝑟′ < 𝑟

𝑒𝑛𝑐𝑝𝑘(𝑚) :={︃𝑒𝑛𝑐𝑝𝑘(𝑎)𝑟 · 𝑒𝑛𝑐𝑝𝑘(𝑏)−𝑟 · 𝑒𝑛𝑐𝑝𝑘(𝑟′)) if 𝜎𝑏 = 0(𝑒𝑛𝑐𝑝𝑘(𝑏) · 𝑒𝑛𝑐𝑝𝑘(1))𝑟 · 𝑒𝑛𝑐𝑝𝑘(𝑎)−𝑟 · 𝑒𝑛𝑐𝑝𝑘(𝑟′) otherwise

𝑀𝑏 = 𝑑𝑒𝑐𝑠𝑘𝑏(𝑒𝑛𝑐𝑝𝑘(𝑚))

𝑒𝑛𝑐𝑝𝑘(𝑚),𝑀𝑏←−−−−−−−−𝑀𝑎 := 𝑑𝑒𝑐𝑠𝑘𝑎(𝑒𝑛𝑐𝑝𝑘(𝑚))𝑚 := 𝑑𝑒𝑐𝑟𝑒𝑐𝑜𝑣𝑒𝑟(𝑀𝑎, 𝑀𝑏)

𝜎𝑎 :={︃

1 if 𝑚 ≥ ⌈𝑛2 ⌉

0 if 𝑚 < ⌈𝑛2 ⌉

Figure 4.2: Comparing two encrypted integers with shared output (based on [KT06,May12,Foe14])

the multiplicative over the ciphertext space.

𝑒𝑛𝑐𝑝𝑘(𝑑)−1 =(︁𝑔𝑑 · 𝑟𝑛

)︁−1mod 𝑁2

= 𝑔−1·𝑑 ·(︁𝑟−1

)︁𝑛mod 𝑁2

= 𝑔

≥0 and ∈Z𝑁⏞ ⏟ 𝑁 − 1 · 𝑑 ·

(︁𝑟−1

)︁𝑛mod 𝑁2

with: 𝑟′ = 𝑟−1 mod 𝑁2 ⇒ 𝑒𝑛𝑐𝑝𝑘(𝑑)−1 = 𝑔𝑁−1·𝑑 ·(︀𝑟′

)︀𝑛 mod 𝑁2

and 𝑒𝑛𝑐𝑝𝑘(𝑑)−1 · 𝑒𝑛𝑐𝑝𝑘(𝑑) = 1

⇔ 𝑔−1·𝑑 ·(︁𝑟−1

)︁𝑛· 𝑔·𝑑 ·

(︁𝑟′′1

)︁𝑛= 𝑔−𝑑+𝑑 ·

(︁𝑟′′1

)︁𝑛 (︁𝑟′1

)︁𝑛mod 𝑁2

= 𝑔0(︁𝑟′′′1

)︁𝑛mod 𝑁2

It is possible to switch between the protocols for (𝑎 ≥ 𝑏) and ¬(𝑎 ≥ 𝑏). Alice hasthe result of the comparison (𝜎𝑎) of the first and second integer and Bob knows whichcomparison was actually carried out (𝜎𝑏), this means, he knows if 𝑎 is compared with 𝑏or 𝑏 is compared with 𝑎.

4.4 Handling Results 55

4.4 Handling ResultsThe second and third necessary functions for the algorithm shown in Figure 3.2.1 isthe operation of the manipulation of the total and the ticket. As shown in the Section4.3.2, it is possible to compare two input encrypted integers and getting the encryptedresult. By encoding the result of a comparison as 0 or 1, it is possible to erase a value bymultiplication with zero and conserve a value by multiplication with one. The same ideacan be used for increasing a value by addition of one or preserving a value by additionof zero. By the fact of using the Threshold Cryptosystem, it is impossible to distin-guish a blinded (adding a zero or multiplication with a penalty) from a changed chiffretext.

4.4.1 Homomorphic Multiplication with Encrypted, Private Integers:F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛

Alice Bobhas private bit 𝜎𝑎 has private bit 𝜎𝑏

has some encryption 𝑒𝑛𝑐𝑝𝑘(𝑖) of integer 𝑖

𝐼𝜎𝑏:= 𝑒𝑛𝑐𝑝𝑘(0)

𝐼1−𝜎𝑏:= 𝑒𝑛𝑐𝑝𝑘(𝑖)

𝐼0,𝐼1←−−−𝐼 := 𝐼𝜎𝑎

Figure 4.3: Homomorphic multiplication of an integer 𝑖 with an encrypted, shared bit(based on [Foe14]):(𝐼,⊥)← F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛(𝜎𝑎, (𝜎𝑏, 𝑒𝑛𝑐𝑝𝑘(𝑖)))𝐼 = 𝑒𝑛𝑐𝑝𝑘(𝑖) if (𝜎𝑎 ⊕ 𝜎𝑏) = 1 otherwise 𝐼 = 𝑒𝑛𝑐𝑝𝑘(0)

By multiplication of an encrypted integer 𝑖 with 0 it becomes an encrypted 0; bymultiplication with 1, the encrypted integer will be re-randomized. The encryption of0 and the encryption of the ticket are indistinguishable and indistinguishable to theoriginal encryption of the ticket. This idea is based on a protocol in [Foe14].

(𝐼,⊥)← F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛(𝜎𝑎, (𝜎𝑏, 𝑒𝑛𝑐𝑝𝑘(𝑖)))

Bob sends ciphertexts 𝐼0, 𝐼1 as an encryption of 0 and 𝑖, depending on his private bit 𝜎𝑏.Both encryptions are received by Alice and she selects the encryption depending on her𝜎𝑎.


4.4.2 Operations for Involving Ticket 𝑡: F𝑡𝑖𝑐𝑘𝑒𝑡

The construction of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 makes it possible to keep or destroy a ticket 𝑡 bymultiplication with 0 or with 1. The multiplication with 0 generates a encryption of𝑒𝑛𝑐𝑝𝑘(0 · 𝑡) = 𝑒𝑛𝑐𝑝𝑘(0). So the algorithm is defined as

(⊥, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡)← F𝑡𝑖𝑐𝑘𝑒𝑡(𝜎𝑎, (𝜎𝑏, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐))

and is presented in Figure 4.4. The ticket t is generated from the miscellaneous informationand could contain more and other information.

Alice Bobhas private bit 𝜎𝑎 has private bit 𝜎𝑏 and 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛

generates ticket plaintext 𝑡 from 𝑚𝑖𝑠𝑐

𝑇𝜎𝑏:= 𝑒𝑛𝑐𝑝𝑘(0)

𝑇1−𝜎𝑏:= 𝑒𝑛𝑐𝑝𝑘(𝑡)

𝑇0,𝑇1←−−−𝑇 := 𝑇𝜎𝑎 · 𝑒𝑛𝑐𝑝𝑘(0)

𝑇−→append 𝑇 to 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛: 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡 := 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛 ‖ 𝑇

Figure 4.4: Store or erase ticket with respect to private bits (based on [Foe14]):(⊥, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡)← F𝑡𝑖𝑐𝑘𝑒𝑡(𝜎𝑎, (𝜎𝑏, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐))

4.4.3 Operations for Counter 𝑐𝑜𝑢𝑛𝑡𝑒𝑟: F𝑐𝑜𝑢𝑛𝑡𝑒𝑟

Section B.7 deals with the idea of increasing an encrypted value with the result of an XORoperation of shared bits. The XOR operation returns only values in {0, 1}. To designaddition with a penalty 𝑝𝑒𝑛𝑎𝑙𝑡𝑦 the increase by 1 operation could be done 𝑝𝑒𝑛𝑎𝑙𝑡𝑦-timesor the same idea of F𝑡𝑖𝑐𝑘𝑒𝑡 could be used here. F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 requires from one party anencrypted integer and a bit, from the other party only a bit. By changing (and renaming)the inputs and outputs of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛, it becomes:

(𝐼,⊥)← F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛((𝜎𝑎, 𝑒𝑛𝑐𝑝𝑘(𝑖)), 𝜎𝑏)

Alice’s output 𝐼 is either an encryption of 0 or an encryption of 𝑖. Using this encryptionfor the manipulation of the counter 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 it is now possible to build the algorithmF𝑐𝑜𝑢𝑛𝑡𝑒𝑟:

(⊥, 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟))← F𝑐𝑜𝑢𝑛𝑡𝑒𝑟((𝜎𝑎, 𝑒𝑛𝑐𝑝𝑘(𝑝𝑒𝑛𝑎𝑙𝑡𝑦)), (𝜎𝑏, 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟)))

The protocol for F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 is shown in 4.5.

4.5 Protocol for one Building Block: F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 57

Alice Bobhas private bit 𝜎𝑎 has private bit 𝜎𝑏

has encrypted penalty 𝑒𝑛𝑐𝑝𝑘(𝑝) has encrypted counter 𝑒𝑛𝑐𝑝𝑘(𝑐)𝑃𝜎𝑎 := 𝑒𝑛𝑐𝑝𝑘(0)

𝑃1−𝜎𝑎 := 𝑒𝑛𝑐𝑝𝑘(𝑝)𝑃0,𝑃1−−−→

𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟) := 𝑒𝑛𝑐𝑝𝑘(𝑐) · 𝑃𝜎𝑏

store 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟)

Figure 4.5: Manipulation of an encrypted counter by an encrypted penalty with respectto the private bits (based on [Foe14]):(⊥, 𝑒𝑛𝑐𝑝𝑘(𝑐))← F𝑐𝑜𝑢𝑛𝑡𝑒𝑟((𝜎𝑎, 𝑒𝑛𝑐𝑝𝑘(𝑝)), (𝜎𝑏, 𝑒𝑛𝑐𝑝𝑘(𝑐)))

4.5 Protocol for one Building Block: F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘

With the protocols for F𝑐𝑜𝑚𝑝𝑎𝑟𝑒, F𝑡𝑖𝑐𝑘𝑒𝑡, and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟, it is possible to build the finalalgorithm:

F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘( (𝑒𝑛𝑐𝑝𝑘(𝑎), 𝑒𝑛𝑐𝑝𝑘(𝑝𝑒𝑛𝑎𝑙𝑡𝑦)),(𝑒𝑛𝑐𝑝𝑘(𝑏), 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟), 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐))→ (⊥, (𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑛𝑡𝑒𝑟), 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡))

By using F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 as instance of F𝑐𝑜𝑚𝑝𝑎𝑟𝑒. The input of Alice is only her encryptedprivate integer 𝑎 and her encrypted private penalty 𝑝𝑒𝑛𝑎𝑙𝑡𝑦, but she generates no output.Bob’s input is also his encrypted private integer 𝑏 and he loads the encrypted value of𝑐𝑜𝑢𝑛𝑡𝑒𝑟 from his storage and generates the ticket 𝑡. One important feature is that Alicedoes not save or return any results. As shown in Figure 4.6, the protocols F𝑐𝑜𝑚𝑝𝑎𝑟𝑒,F𝑡𝑖𝑐𝑘𝑒𝑡, and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 are combined. Additionally, the private inputs of Alice and Bob arecolored.Alice has her encrypted private input integer 𝑎 and Bob has his encrypted private input𝑏. Both integers are in

[︀0, ⌈𝑛

2 ⌉]︀. The secret key of Alice is 𝑠𝑘𝑎 and the secret key of Bob

is 𝑠𝑘𝑏, both have the public key 𝑝𝑘 and use these keys for a (2,2) homomorphic thresholdcryptosystem (see Section 2.5.5). Bob stores the encryption of 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 by overwrittenthe old encryption of 𝑐𝑜𝑢𝑛𝑡𝑒𝑟, because it is not necessary to keep the old encryptedvalues of 𝑐𝑜𝑢𝑛𝑡𝑒𝑟. However, every encryption 𝑇 of the transformed ticket 𝑡 has to besaved.The first block represents the protocol F𝑐𝑜𝑚𝑝𝑎𝑟𝑒 with the implementation of F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟.Both parties have a private bit 𝜎𝑎 or 𝜎𝑏 after this block. The second block represents the


Alice Bob


has encryption of integer 𝑎 has encryption of integer 𝑏𝑒𝑛𝑐𝑝𝑘(𝑎)−−−−−→

𝜎𝑏 ∈𝑅 {0, 1}

𝑟, 𝑟′ ∈𝑅 N, 0 ≤ 𝑟′ < 𝑟

𝑀 = 𝑒𝑛𝑐𝑝𝑘(𝑚) :={︃𝑒𝑛𝑐𝑝𝑘(𝑎)𝑟 · 𝑒𝑛𝑐𝑝𝑘(𝑏)−𝑟 · 𝑒𝑛𝑐𝑝𝑘(𝑟′) if 𝜎𝑏 = 0(𝑒𝑛𝑐𝑝𝑘(𝑏) · 𝑒𝑛𝑐𝑝𝑘(1))𝑟 · 𝑒𝑛𝑐𝑝𝑘(𝑎)−𝑟 · 𝑒𝑛𝑐𝑝𝑘(𝑟′) otherwise

𝑀𝑏 := 𝑑𝑒𝑐𝑠𝑘𝑏(𝑒𝑛𝑐𝑝𝑘(𝑚))

𝑒𝑛𝑐𝑝𝑘(𝑚),𝑀𝑏←−−−−−−−−

𝑀𝑎 := 𝑑𝑒𝑐𝑠𝑘𝑎(𝑒𝑛𝑐𝑝𝑘(𝑚))

𝑚 := 𝑑𝑒𝑐𝑟𝑒𝑐𝑜𝑣𝑒𝑟(𝑀𝑎, 𝑀𝑏)

𝜎𝑎 :={︃

1 if 𝑚 ≥ ⌈𝑛2 ⌉

0 if 𝑚 < ⌈𝑛2 ⌉


has penalty 𝑒𝑛𝑐𝑝𝑘(𝑝𝑒𝑛𝑎𝑙𝑡𝑦) has counter 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟)

𝑃𝜎𝑎 := 𝑒𝑛𝑐𝑝𝑘(0)

𝑃1−𝜎𝑎 := 𝑒𝑛𝑐𝑝𝑘(𝑝𝑒𝑛𝑎𝑙𝑡𝑦)𝑃0,𝑃1−−−→

𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟) := 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟) · 𝑃𝜎𝑏

store 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟)

(⊥, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡)← F𝑡𝑖𝑐𝑘𝑒𝑡(𝜎𝑎, (𝜎𝑏, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐))

generates ticket 𝑡𝑖𝑐𝑘𝑒𝑡 in plaintext space from 𝑚𝑖𝑠𝑐

𝑇𝜎𝑏:= 𝑒𝑛𝑐𝑝𝑘(0)

𝑇1−𝜎𝑏:= 𝑒𝑛𝑐𝑝𝑘(𝑡𝑖𝑐𝑘𝑒𝑡)

𝑇0,𝑇1←−−−

𝑇 := 𝑇𝜎𝑎 · 𝑒𝑛𝑐𝑝𝑘(0)𝑇−→

append 𝑇 to 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡: 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡 := 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛 ‖ 𝑇

Figure 4.6: Complete algorithm F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 composed of the three building functions.The private inputs and results for Alice and Bob are color for red and blue.

4.6 Transmission of Results 59

F𝑡𝑖𝑐𝑘𝑒𝑡 algorithm with the XOR operation and the homomorphic addition, resulting themultiplication. Both parties need their results (bit 𝜎𝑎 and bit 𝜎𝑏) from the first block asinputs for the second block. After Bob stores and overwrites the re-randomized 𝑐𝑜𝑢𝑛𝑡𝑒𝑟the second block is finished. No result of the second block is needed anymore. The thirdblock represents the F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 algorithm. The inputs of Alice and Bob depend on theresult (bit 𝜎𝑎 and bit 𝜎𝑏) of the first block. After the third block, Bob appends the ticket𝑇 to the ticketlog. Without regard to how ticket 𝑡 is generated, no dependencies areexisting between the second and third block.

4.6 Transmission of ResultsThe function F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 generates an encryption of 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 and several differentencryptions of tickets 𝑡𝑖; one for each run. The tickets, which are describing a ruleviolation are only after the decryption readable for both parties. The other 𝑡𝑖 aremultiplied with a zero and carry no usable information. To decrypt one value, bothparties are involved because of the (2,2) Threshold cryptosystem. But Bob can partiallydecrypt with his private key 𝑠𝑘𝑏 and transmit the original and his partial decryption toAlice. So, Alice can do her part of decryption and read the value.

By using this technique the counter 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 can be evaluated by Alice. In case one

Alice Bobhas 𝑒𝑛𝑐𝑝𝑘(𝑐)𝐶𝑏 := 𝑑𝑒𝑐𝑠𝑘𝑏

(𝑒𝑛𝑐𝑝𝑘(𝑐))𝐶𝑏,𝑒𝑛𝑐𝑝𝑘(𝑐)←−−−−−−−

𝐶𝑎 := 𝑑𝑒𝑐𝑠𝑘𝑎(𝑒𝑛𝑐𝑝𝑘(𝑐))𝑐 := 𝑑𝑒𝑐𝑟𝑒𝑐𝑜𝑣𝑒𝑟(𝐶𝑎, 𝐶𝑏)

𝑐−→

Figure 4.7: Jointly decryption of 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 for evaluation

party, does not trust the other party with respect to the correctness of 𝑐𝑜𝑢𝑛𝑡𝑒𝑟, they canjointly decrypt all 𝑒𝑛𝑐𝑝𝑘(𝑡′𝑖) of every comparison and review the cases where a rule isviolated.

4.7 Overall ProtocolWith the comparing algorithm F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 (Section 4.5) and the transmission tothe encrypted values it is possible to realize the whole process shown as Algorithm3.2.2 and as Protocol 4.8. This model deals with an insurance policy based on the


Insurer (I)/agent-box (A) Insured (O)/vehicle (V)

foreach Threshold in P.thresholds[] do

foreach Property P in s.properties[] do if property is ready measure();

foreach PropertySnapshot s in d.snapshots do

foreach Day d in m.days[] do

foreach Month m in bp.months[] do

for BillingPeriod bp do

foreach Threshold in P.thresholds[] do

foreach Property P in s.properties[] do if property is ready m=measure()

foreach PropertySnapshot s in d.snapshots do

foreach Day d in m.days[] doencpk(d.dailyViolationTotal) =encpk(0); d.dailyTicketlog.initialize();

foreach Month m in bp.months[] doencpk(m.monthlyViolationTotal) =encpk(0); m.monthlyTicketlog.initialize();

for BillingPeriod bp doencpk(bp.billingperiodViolationTotal) =encpk(0); bp.billingperidTicketlog.initialize();

return: (encpk(bp.billingperiodViolationTotal), bp.billingperiodTicketlog.publish());

FBuildingBlock

jointly decrypt bp.billingperiodViolationTotal

review bp.billingperiodTicketlogin case of disagreement by joint decryption

waitTillNextTimeUnitBegins();waitTillNextTimeUnitBegins();

return: (null);

FBuildingBlock

FBuildingBlock

comparingmeasurment valuewith threshold

comparingtotals of monthwith threshold

comparingtotals of daywith threshold

Figure 4.8: Protocol for continually evaluating the measurements: OverallPicture

private thresholds for properties. The agent-box (A) and the vehicle (V) are doing thecalculations together. The Protocol 4.8 has different counters and so different inputsfor F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘. The first building block is the measurement of one property, e.g., thecurrent speed. The vehicle has as private input his speed 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒 and theagent box has as private input the current speed limit 𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒. Because onespeed is checked against several speed limits (thresholds), F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 is called multipletimes. Additionally F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 needs the encrypted penalty from the agent-box(A) and from the vehicle (V) the encrypted total where the result should add to(𝑒𝑛𝑐𝑝𝑘(𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙)), the ticketlog, where the new and encrypted ticket 𝑇 isstored in (𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔), and some miscellaneous information for the generation ofthe ticket (GenMisc(𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡.𝑚𝑖𝑠𝑐, 𝑙.𝑚𝑖𝑠𝑐, . . .))1. Both results are stored in thevehicle and this process is repeated for each measurement, each threshold related toproperty 𝒫, and each snapshot 𝑠.The second use of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 compares 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 with 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒.Because 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 is already encrypted it does not need to be encryptedinside the comparison algorithm, so the algorithm is defined to use encrypted inputs.This is also the reason why F𝑐𝑜𝑚𝑝𝑎𝑟𝑒 accepts only encrypted inputs.

1The function GenMisc can have multiple inputs, also the count is inputs is not defined.

4.7 Overall Protocol 61

The third comparison works the same as the second comparison:

F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘( ( 𝑒𝑛𝑐𝑝𝑘(𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒),𝑒𝑛𝑐𝑝𝑘(𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃𝑒𝑛𝑎𝑙𝑡𝑦)),

( 𝑒𝑛𝑐𝑝𝑘(𝑚𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙),𝑒𝑛𝑐𝑝𝑘(𝑝𝑏.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙),𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔, GenMisc(𝑚.𝑚𝑖𝑠𝑐, . . .)))

→ (⊥, (𝑒𝑛𝑐𝑝𝑘(𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙), 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔)

After this comparison only 𝑒𝑛𝑐𝑝𝑘(𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙) and the 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔should have values; all others are reset by storing a fresh encryption of 0. The 𝑟𝑒𝑠𝑒𝑡()command of the ticketlog deletes all information in the ticketlog.Thus, the second and third comparisons are the reason for the encrypted input of bothparties. Both inputs are encrypted and by using of an protocol, which does not needan internal decryption of these values, it is possible to keep the original inputs private.Every party is able to encrypt his plain text input with the public key 𝑝𝑘 to fulfill therequirement. In the case of using the F𝑐𝑜𝑚𝑝𝐵𝑖𝑡 it seems unnecessary to encrypt the valuesand later decrypt them to reach a binary presentation.At the end of the billing period, the 𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 will be jointly de-crypted, and only if one party distrusts the other party the tickets 𝑇 , with respect to thetickets of the months and the days, are jointly decrypted.


Algorithm 4.7.1: Algorithm for continually evaluating the measurements:OverallAlgorithmInput: Billingperiod 𝑏𝑝Output: 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔/* The typography of 𝑣𝑎𝑙←Function(𝑣𝑎𝑙) is equal to Function(𝑣𝑎𝑙)→ 𝑣𝑎𝑙 and

should only improve the readability. */1 for Billingperiod 𝑏𝑝 do2 𝑒𝑛𝑐𝑝𝑘(𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙) := 𝑒𝑛𝑐𝑝𝑘(0);3 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑖𝑛𝑖𝑡𝑖𝑎𝑙𝑖𝑧𝑒();4 foreach Month 𝑚 in 𝑏𝑝.𝑚𝑜𝑛𝑡ℎ𝑠[] do5 𝑒𝑛𝑐𝑝𝑘(𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙) := 𝑒𝑛𝑐𝑝𝑘(0);6 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑖𝑛𝑖𝑡𝑖𝑎𝑙𝑖𝑧𝑒();7 foreach Day 𝑑 in 𝑚.𝑑𝑎𝑦𝑠[] do8 𝑒𝑛𝑐𝑝𝑘(𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙) := 𝑒𝑛𝑐𝑝𝑘(0);9 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑖𝑛𝑖𝑡𝑖𝑎𝑙𝑖𝑧𝑒();

/* During the day all measurements are checked continually with aresolution of time unit. */

10 foreach PropertySnapshot 𝑠 in 𝑑.𝑠𝑛𝑎𝑝𝑠ℎ𝑜𝑡𝑠[] do11 foreach Property 𝒫 in 𝑠.𝑝𝑟𝑜𝑝𝑒𝑟𝑡𝑖𝑒𝑠[] do12 𝒫.𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 −−;13 if 𝒫.𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 ≤ 0 then14 𝒫.𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 = 𝒫.𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝐷𝑒𝑙𝑎𝑦;15 𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡← 𝒫.𝑚𝑒𝑎𝑠𝑢𝑟𝑒();16 foreach Threshold 𝑙 in 𝒫.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑠[] do

/* agent-box (A) is operation with vehicle (V) */17 F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘(18 (𝑒𝑛𝑐𝑝𝑘(𝑙.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒),19 𝑒𝑛𝑐𝑝𝑘(𝑙.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃𝑒𝑛𝑎𝑙𝑡𝑦)),20 (𝑒𝑛𝑐𝑝𝑘(𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡.𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒),21 𝑒𝑛𝑐𝑝𝑘(𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙),22 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔,23 GenMisc(𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡.𝑚𝑖𝑠𝑐, 𝑙.𝑚𝑖𝑠𝑐, . . .))24 )→ (⊥, (𝑒𝑛𝑐𝑝𝑘(𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙), 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔));

/* Wait until next time unit begins. */25 waitTillNextTimeUnitBegins();

/* agent-box (A) is operation with vehicle (V) */26 F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘(27 (𝑒𝑛𝑐𝑝𝑘(𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒),28 𝑒𝑛𝑐𝑝𝑘(𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃𝑒𝑛𝑎𝑙𝑡𝑦)),29 ((𝑒𝑛𝑐𝑝𝑘(𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙),30 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙,31 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔,32 GenMisc(𝑑.𝑚𝑖𝑠𝑐, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔. . .))33 )→ (⊥, (𝑒𝑛𝑐𝑝𝑘(𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙), 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔));34 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑐𝑙𝑒𝑎𝑟();

/* agent-box (A) is operation with vehicle (V) */35 F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘(36 (𝑒𝑛𝑐𝑝𝑘(𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒),37 𝑒𝑛𝑐𝑝𝑘(𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃𝑒𝑛𝑎𝑙𝑡𝑦)),38 (𝑒𝑛𝑐𝑝𝑘(𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙),39 𝑒𝑛𝑐𝑝𝑘(𝑝𝑏.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙),40 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔,41 GenMisc(𝑚.𝑚𝑖𝑠𝑐, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔. . .))42 )→ (⊥, (𝑒𝑛𝑐𝑝𝑘(𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙), 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔));43 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑐𝑙𝑒𝑎𝑟();44 return 𝑒𝑛𝑐𝑝𝑘(𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙) , 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.𝑝𝑢𝑏𝑙𝑖𝑠ℎ()

5 Analysis

This chapter proves the security (Section 2.4.3) for the protocols in Chapter 4 in thesemi-honest model (Definition 2.4.6). Many of these proofs are based on the underlyingalgorithms, so the references are only mentioned without replaying every detail.

5.1 PreliminariesIf not mentioned otherwise, the parties use a (2,2) threshold cryptosystem instance ofPaillier. The public parameters are 𝑁 , the randomly chosen generator 𝑔 of the groupZ*𝑁 (therefore 𝑜𝑟𝑑(𝑔) = 𝑁). The random selection chooses 𝑛 bits with 0 < 𝑛 ≤ 𝑁 .A re-randomization of the encryption of 𝑎 is equal to a fresh encryption of 0 and ahomomorphic addition of 𝑒𝑛𝑐𝑝𝑘(𝑎) · 𝑒𝑛𝑐𝑝𝑘(0).

5.2 Evaluation of F𝑐𝑜𝑚𝑝𝑃𝑎𝑖𝑙𝑙𝑖𝑒𝑟

(𝜎𝑎, 𝜎𝑏)← F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟(𝑎, 𝑏)

The protocol of F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 is based on the ideas of [May12]. But in the version ofF𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 in this thesis, the negation of 𝑎 > 𝑏 is ¬(𝑎 > 𝑏) = (𝑎 ≤ 𝑏) = (𝑏+1 > 𝑎) [Foe14],because 𝑎, 𝑏 are integers and therefore the last term (𝑏 + 1 > 𝑎) is valid. Every otherstep is almost the same such as in the proof [May12], just by substituting 𝑏 with 𝑏 + 1 inthe case of the comparison of 𝑏 > 𝑎 of [May12].

5.2.1 Correctness and PrivacyBob receives 𝑒𝑛𝑐𝑝𝑘(𝑎) from Alice and randomly selects his bit 𝜎𝑏 from {0, 1}. If 𝜎𝑏 = 0,he runs the protocol of protocol for Yao’s millionaire problem [KT06] and computes𝑒𝑛𝑐𝑝𝑘(𝑚) = 𝑒𝑛𝑐𝑝𝑘(𝑟 · 𝑎− 𝑟 · 𝑏 + 𝑟′). In the case of 𝜎𝑏 = 1 he runs the protocol ¬(𝑎 ≤ 𝑏)with the inputs of (𝑏 + 1, 𝑎). So he calculates now 𝑒𝑛𝑐𝑝𝑘(𝑚) = 𝑒𝑛𝑐𝑝𝑘(𝑟 · (𝑏 + 1)− 𝑟 ·𝑎 + 𝑟′).Alice and Bob jointly decrypt 𝑒𝑛𝑐𝑝𝑘(𝑚) such that only Alice receives 𝑚 (see Definition2.5.5). Alice decides if the first input is greater or equal in comparison to the secondinput. She sets her 𝜎𝑎 to 0 if this is the case and to 1 if the second input is bigger than

64 5 Analysis

the first:

(𝑎 ≥ 𝑏) :=(︂

(𝑚 mod 𝑁) <𝑁

2

)︂

⇔ (𝑎 ≥ 𝑏) :={︃

0 if 𝑚 < 0⇔ 𝑟 · (𝑎− 𝑏) + 𝑟′ < 0⇔ 𝑎− 𝑏 ≤ −1 < − 𝑟′

𝑟 ≤ 01 if 𝑚 ≥ 0⇔ 𝑟 · (𝑎− 𝑏) + 𝑟′ ≥ 0⇔ 𝑎− 𝑏 ≥ 1 > 𝑟′

𝑟 ≥ 0

So Alice knows her input (𝑒𝑛𝑐𝑝𝑘(𝑎)) and can, as intended, decrypt 𝑚 from Bob’s 𝑀𝑏,

𝑎?> 𝑏 selection of 𝜎𝑏 computation of 𝜎𝑎 (𝜎𝑎 ⊕ 𝜎𝑏)1 0 0 01 1 1 00 0 1 10 1 0 1

Table 5.1: Detailed steps for input conditions of F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 in 4.2.The first column (𝑎

?> 𝑏) indicates the result of the comparison 𝑎 > 𝑏 =

¬(𝜎𝑎 ⊕ 𝜎𝑏).

her 𝑀𝑎 and the 𝑒𝑛𝑐𝑝𝑘(𝑚) by using 𝑑𝑒𝑐𝑟𝑒𝑐𝑜𝑣𝑒𝑟 to make the decision if the first input isgrater than the second (𝜎𝑎). Bob knows his input (𝑒𝑛𝑐𝑝𝑘(𝑎)) and his random selection𝜎𝑏. Since the used cryptosystem is additively homomorphic and semantically secure, Bobcan obliviously carry out operations on his input and the ciphertext 𝑒𝑛𝑐𝑝𝑘(𝑎) of Alicewithout knowledge of the plaintexts. As shown in [May12], the operations on the side ofAlice also do not leak information about the private inputs 𝑎 and 𝑏.The correctness of F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 follows from the correctness of [KT06] and the fix, shownin Table 5.1. The comparison of 𝑎 and 𝑏 is encode same such as the negated XORoperation (𝜎𝑎 ⊕ 𝜎𝑏). The role of Alice is encoded by the agent-box (A) and the role ofBob is performed by the vehicle (V). The input of Alice/agent-box (A) 𝑎 is a thresholdand the input of Bob/vehicle (V) is a measurement value or a total.

5.2.2 Amount of Operationsdone by

operation (maximum) Alice Bob# random selection 0 3# homomorphic addition 0 3# homomorphic multiplication with constant, positive integer 0 1# homomorphic multiplication with constant, negative integer 0 1# re-randomization 0 0# encryption 0 1# joint decryption 1 1

Alice only has to participate in the joint decryption.. All other operations are carried

5.3 Evaluation of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 65

out by Bob. The random selections are two times (𝑟, 𝑟′) in plaintext space for positiveintegers and one time (𝜎𝑏) one bit.

5.3 Evaluation of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛

(𝐼,⊥)← F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛(𝜎𝑎, (𝜎𝑏, 𝑒𝑛𝑐𝑝𝑘(𝑖)))

The F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 is based on the NXOR protocol in [Foe14], but used differently in thisthesis. Thus, it is important to prove correctness and privacy of the protocol presentedin this thesis.

5.3.1 Correctness and PrivacyBy comparing each result depending on each possible input with the expected result, thecorrectness is proved with Table 5.2. Every result of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 is the same as theexpected result, so the correctness of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 is proved.Since the use of the (2,2) threshold cryptosystem as a semantic secure cryptosystem

inputs𝜎𝑎 𝜎𝑏 𝐼0 𝐼1 𝜎𝑎 ⊕ 𝜎𝑏 𝐼

0 0 𝑒𝑛𝑐𝑝𝑘(0) 𝑒𝑛𝑐𝑝𝑘(𝑖) 0⊕ 0 = 0 𝑒𝑛𝑐𝑝𝑘(0)0 1 𝑒𝑛𝑐𝑝𝑘(𝑖) 𝑒𝑛𝑐𝑝𝑘(0) 0⊕ 1 = 1 𝑒𝑛𝑐𝑝𝑘(𝑖)1 0 𝑒𝑛𝑐𝑝𝑘(0) 𝑒𝑛𝑐𝑝𝑘(𝑖) 1⊕ 0 = 1 𝑒𝑛𝑐𝑝𝑘(𝑖)1 1 𝑒𝑛𝑐𝑝𝑘(𝑖) 𝑒𝑛𝑐𝑝𝑘(0) 1⊕ 1 = 0 𝑒𝑛𝑐𝑝𝑘(0)

Table 5.2: Correctness proof of 4.3

Alice cannot decrypt by herself the 𝐼0, 𝐼1, or 𝐼. Because of the semantically securecryptosystem, Alice cannot distinguish 𝑒𝑛𝑐𝑝𝑘(0) and 𝑒𝑛𝑐𝑝𝑘(𝑖), received from Bob, and𝑒𝑛𝑐𝑝𝑘(0) and 𝑒𝑛𝑐𝑝𝑘(𝑖) are encoded as 𝐼0 and 𝐼1, respectively. So, she does not knowwhich 𝐼0, 𝐼1 represents the encryption of the ticket 𝑖. By selection between 𝐼0 and 𝐼1 independency of her 𝜎𝑎 she computes 𝐼 := 𝑒𝑛𝑐𝑝𝑘((𝜎𝑎 ⊕ 𝜎𝑏) · 𝑖). Therefore, F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 isprivacy-preserving.Alice has 𝐼 as output of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 and Bob’s output is empty.

66 5 Analysis


operation (maximum) Alice Bob# random selection 0 0# homomorphic addition 0 0# homomorphic multiplication with constant, positive integer 0 0# homomorphic multiplication with constant, negative integer 0 0# re-randomization 0 0# encryption 0 1# joint decryption 0 0

The inputs of Alice 𝜎𝑎 and Bob 𝜎𝑏 control the selection of the 𝐼0, 𝐼1, so only Bob has tocompute one encryption of a zero.

5.4 Evaluation of F𝑡𝑖𝑐𝑘𝑒𝑡 and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟

Both F𝑡𝑖𝑐𝑘𝑒𝑡 and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 are making use of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛. It is therefore only necessaryto look at the additional operations and the transition from F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 to F𝑡𝑖𝑐𝑘𝑒𝑡 andthe transition from F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 to F𝑐𝑜𝑢𝑛𝑡𝑒𝑟.

5.4.1 Correctness and Privacy(⊥, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡)← F𝑡𝑖𝑐𝑘𝑒𝑡(𝜎𝑎, (𝜎𝑏, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐))

Bob generates and encrypts in F𝑡𝑖𝑐𝑘𝑒𝑡 a ticket 𝑡. This ticket is the part input ofF𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 for the encrypted integer by Bob. Alice has the encrypted ticket 𝑇 asoutput of the protocol F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛, re-randomizes it, and sent it to Bob. With the (2,2)threshold cryptosystem both cannot decrypt a ciphertext without the help of the otherparty. It is impossible to link 𝑇0 or 𝑇1 to 𝑇 for Bob because Alice re-randomizes the se-lected ticket and the semantically secure cryptosystem. So, F𝑡𝑖𝑐𝑘𝑒𝑡 is a privacy-preservingprotocol.


For F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 the input of the penalty is already encrypted and the result of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛

has to be homomorphically added to the encrypted total 𝑐𝑜𝑢𝑛𝑡𝑒𝑟. The penalty will beadded the the counter if and only if (𝜎𝑎 ⊕ 𝜎𝑏) = 1, so F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 is correct. By using a (2,2)threshold semantically secure cryptosystem F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 is privacy-preserving. Bob overwritesthe 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟).

5.5 Evaluation of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 67


Alice Bob

operation (maximum) F𝑐𝑜

𝑢𝑛

𝑡𝑒𝑟

F𝑡𝑖

𝑐𝑘𝑒𝑡

F𝑐𝑜

𝑢𝑛

𝑡𝑒𝑟

F𝑡𝑖

𝑐𝑘𝑒𝑡

# random selection 0 0 0 0# homomorphic addition 0 0 1 0# homomorphic multiplication with constant, positive integer 0 0 0 0# homomorphic multiplication with constant, negative integer 0 0 0 0# re-randomization 0 1 0 0# encryption 1 0 0 2# joint decryption 0 0 0 0

In addition to the operations of F𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛, Alice and Bob have to compute theoperations for F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 and F𝑡𝑖𝑐𝑘𝑒𝑡.

5.5 Evaluation of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘

F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 ((𝑒𝑛𝑐𝑝𝑘(𝑎), 𝑒𝑛𝑐𝑝𝑘(𝑝𝑒𝑛𝑎𝑙𝑡𝑦)),(𝑒𝑛𝑐𝑝𝑘(𝑏), 𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟), 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐))→ (⊥, (𝑒𝑛𝑐𝑝𝑘(𝑐𝑜𝑢𝑛𝑡𝑒𝑟), 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡))

To prove the correctness and privacy of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘, it is only necessary to check thetransition between F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟, F𝑐𝑜𝑢𝑛𝑡𝑒𝑟, and F𝑡𝑖𝑐𝑘𝑒𝑡.

5.5.1 Correctness and PrivacyAs proved before, F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟, F𝑐𝑜𝑢𝑛𝑡𝑒𝑟, and F𝑡𝑖𝑐𝑘𝑒𝑡 are correct, if they are consideredindividually. F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 and F𝑡𝑖𝑐𝑘𝑒𝑡 are independent to each other and both leak no infor-mation about their inputs. So it is not necessary to check the transition between them.The transition between F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 needs the 𝜎𝑎 and 𝜎𝑏 from the output ofF𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 as input for F𝑐𝑜𝑢𝑛𝑡𝑒𝑟. Owing to the design of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘, no operation isbetween F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 and F𝑐𝑜𝑢𝑛𝑡𝑒𝑟, so the transition cannot influence the correctness.F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 is between F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 and F𝑡𝑖𝑐𝑘𝑒𝑡. F𝑡𝑖𝑐𝑘𝑒𝑡 needs as input 𝜎𝑎 and 𝜎𝑏 from theoutput of F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟. Also the input of F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 depends of the output of F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟.No party changes 𝜎𝑎 and 𝜎𝑏 (semi-honest model — Definition 2.4.6) and neither 𝜎𝑎 nor𝜎𝑏 are leaked to the other party, this transition cannot influence the correctness.Since no transitions between F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟, F𝑐𝑜𝑢𝑛𝑡𝑒𝑟, and F𝑡𝑖𝑐𝑘𝑒𝑡 influence the correctness,so the correctness of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 follows from the correctness of F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟, F𝑐𝑜𝑢𝑛𝑡𝑒𝑟,

68 5 Analysis

and F𝑡𝑖𝑐𝑘𝑒𝑡. The protocol has the expected output, the aggregated total and the aggre-gated ticketlog.Every transition between F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 to F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 and F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 to F𝑡𝑖𝑐𝑘𝑒𝑡 does notdoes not leak information to the other party. So all operations of the transition areprivacy-preserving by using (2,2) threshold semantic secure cryptosystem. It is not neces-sary to re-randomize output of the protocols F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟, F𝑐𝑜𝑢𝑛𝑡𝑒𝑟, and F𝑡𝑖𝑐𝑘𝑒𝑡 becauseno additional computations are done.Since the protocols F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟, F𝑐𝑜𝑢𝑛𝑡𝑒𝑟, and F𝑡𝑖𝑐𝑘𝑒𝑡 are secure and the transitions arecorrect and do not leak private information, the composition is secure as well and thesecurity of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 follows.


Alice Bob

operation (maximum) F𝑐𝑜

𝑚𝑝𝑎

𝑟𝑒

F𝑐𝑜

𝑢𝑛

𝑡𝑒𝑟

F𝑡𝑖

𝑐𝑘𝑒𝑡

F𝑐𝑜

𝑚𝑝𝑎

𝑟𝑒

F𝑐𝑜

𝑢𝑛

𝑡𝑒𝑟

F𝑡𝑖

𝑐𝑘𝑒𝑡

# random selection 0 0 0 3 0 0# homomorphic addition 0 0 0 3 1 0# homomorphic multiplication with constant, positive integer 0 0 0 1 0 0# homomorphic multiplication with constant, negative integer 0 0 0 1 0 0# re-randomization 0 0 1 0 0 0# encryption 0 1 0 1 0 2# joint decryption 1 0 0 1 0 0

The amount of each operation in F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 is sum of each operation in F𝑐𝑜𝑚𝑝𝑎𝑟𝑒,F𝑐𝑜𝑢𝑛𝑡𝑒𝑟, and F𝑡𝑖𝑐𝑘𝑒𝑡.

5.6 Evaluation of OverallAlgorithmAs shown before, the protocol of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 is secure in the semi-honest model. Theinputs for Alice (agent-box (A)) are the threshold 𝑎 and the penalty 𝑝𝑒𝑛𝑎𝑙𝑡𝑦. Bothare used as an encryption (see Section 4.2), which Bob has not seen before. So Bob(vehicle (V)) can not learn anything, even if Alice has the same thresholds as inputs fordifferent measurements for the same property (see Figure 4.8). The measurements arealso encrypted before they are compared. Even if two different measurements of the sameproperty have the same value, Alice cannot find this out, owing to semantic security (seeFigure 4.8). Bob stores the counters (totals), so Alice will not see them, unless they arejointly decrypted. The ticketlog is also not committed to Alice during a billing period(see Figure 4.8). However, Alice is able to learn the number of tickets inside the ticketlog.But this information need not be protected. Alice takes part in each comparison and foreach comparison Bob generates a ticket, so Alice knows how many tickets are generated.

5.6 Evaluation of OverallAlgorithm 69

So, this information is not private and cannot been leaked by jointly decrypting the𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.As shown ins Section 5.5 F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 is correct and privacy-preserving. Only Bob carriesout operation on the ticketlogs and the totals. So, the transitions between multiple blocksof F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 are privacy-preserving. Alice does not get any information without theinformation she has from the building block F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘. So, OverallAlgorithm isprivacy-preserving.The additional operations are only to control when which comparison is done. These arecorrectly nested loops and with the correctness of F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 follows the correctnessof OverallAlgorithmWith the correctness and the privacy-preserving of the transitions follows the privacy-preserving and the correctness of OverallPicture and OverallPicture is secure.

6 Conclusion

This chapter gives a short summery of the thesis and introduces possible future work.

6.1 SummaryThis work has shown that it is possible to guarantee the same functionality of a nonprivacy-preserving algorithm with a privacy-preserving algorithm in the case of a drivingpattern based insurance plan. Not only are the inputs (such as the driving patternand the classification pattern) kept private, but also the computation is done by bothparties. This follows the idea of Secure Multiparty Computation (SMC). The Pailliercryptosystem is used, which allows the performs of homomorphic operations on theciphertexts and the extension to a (2,2) threshold cryptosystem. The developed protocolis secure, which includes the correctness and privacy-preserving in the semi-honest model.In currently the service provider collects all data from a vehicle, which may in fact bemore data then he actually needs to provide his services. In general a black box isinstalled in each vehicle to gather this data and transmit it to the service provider. Theservice provider evaluates the data and presents only the results to the insurer and theinsured. In this work the gathering, storing and maintenance of this data is performedby the insured with his vehicle. Not only does he have full control over his own data,but also the ability to compute together with the insurer on this data without leakingany information. With the end of the computation, the insurer and the insured have annumeric value which describes the driving pattern of the insurer. This value is abstractedseveral times, so it is impossible to decide which exactly measurement value has influencethe pattern. Also both parties can jointly review each cases, which influence the overalldriving pattern evaluation.

6.2 Future WorkBased on this work, it is possible to extend the presented privacy-preserving protocolby elimination of the assumptions made. Additional comparison operations, such as ‘inset’ or ‘equal’, could also be included in addition to ‘greater than’. The new comparisonoperations would need the same signature to be inserted into F𝑐𝑜𝑚𝑝𝑎𝑟𝑒, so they have asinput the encrypted values and the shared output bits. The model of this work uses anabstract idea of the comparison between a measurement and the thresholds. In a realworld implementation it is necessary to add additional information into the comparison.For example, a fixed speed has a different interpretation in a city than on a highway.Some roads conditions allow a higher speed than others.

72 6 Conclusion

The ticketlog in this work uses two functions to map the additional information (such asother tickets) into the size of a ticket in the plaintext space. In practice it is unrealisticto assume that the information of multiple tickets can be compressed multiple times tothe size of one ticket.Also the model could be extended to deal with malicious adversaries who will not followthe protocol specifics.A real world implementation of this protocol would have to consider the runtime of thecomputations involved. Additionally both parties need to have synchronization methods,e.g. a synchronized clock or a underlying protocol.

This work only discuss the example of a insurer-insured relationship. The idea ofkeeping thresholds, penalties, measurement values private can be extended to othersetting such as the cloud based road hazard detection or the observe critical parametersin untrusted environment.

A Acronyms

3G third generation of mobile telecommunications technology

4G fourth generation of mobile telecommunications technology

BSM Basic Safety Message

CAM Cooperative Awareness Message

CA Certificate Authority

CRL Certificate Revocation List

CRSS Central Road Side Station

DENM Decentralized Environmental Notification Massage

ETSI European Telecommunications Standards Institute

GPRS General Packet Radio Service

GPS Global Positioning System

GSM Global System for Mobile Communications

HMI Human Machine Interface

HSM Hardware Security Module

IEEE Institute of Electrical and Electronics Engineers

IMS Information Management Services

ITS Intelligent Transporting System

LBS Location Based Services

LDM Local dynamic map

MAP MAP - Geometric Intersection Description

MIB Management Information Base

OBU Onboard Unit

PSAP Public-Safety Answering Point

RSS Road Side Station

RSU Road Side Unit

74 A Acronyms

SAM Service Announcement Message

SIB Security Information Base

SMS Short Message Service

SPaT Signal Phase and Timing Message

TACK Temporary Anonymous Certified Key

UMTS Universal Mobile Telecommunications System

VANET Vehicular Ad Hoc Network

WAVE Wireless Access in Vehicular Networks

WLAN Wireless Local Area Network

WSA WAVE service advertisement

eCall emergency call

B Appendix

B.1 Intelligent Transporting System (ITS) Station ReferenceArchitecture

Application

Facilety

Networking &Transport

Access

Managment

Security

MA FA SA

SF

SN

SI

MF

MN

MI

MS

NF

IN

Figure B.1: ITS Station Reference Architecture (based on [ETS10b])

Every actor, e.g., a RSS, a vehicle, the CRSS or some personal ITS subsystem, needsto work with the exchanged information in its own ITS station. The architecture of anITS station is illustrated in Figure B.1. It is significant that security and managementare directly influencing every layer. The highest layer is the application layer, dividedinto three categories: Road Safety, Traffic Efficiency, and other applications.Directly below is the Facilities layer. This layer provides access to generic HMI and datapresentation support. So, all necessary and local information like the Local dynamicmap (LDM) or the current position and time is provided here. Geo-Routing, IPv6, ITSLocal Network, and more transport facilities are on the Networking and Transport Layer.

76 B Appendix

Also, the TCP/UDP and ITS Transport are located here. On the access layer internaland external interfaces are connected, e.g., 3G, Bluetooth, or GPS.All discussed layer are linked to the Management and Security units. The Managementunit mainly manages the communication between the layers by building and managingthe Management Information Base (MIB). The Security unit includes the HSM anddifferent Software modules for, e.g., firewall and intrusion management, authentication,authorization and profile management, identity, crypto key and certificate managementand a common Security Information Base (SIB). This unit will be the focus of this thesis.The interfaces in Figure B.1 are [ETS10b]:

∙ MA interface: interface between the communication and station management entityand the ITS-S applications entity

∙ MF interface: interface between the communication and station management entityand the facilities layer

∙ MI interface: interface between the communication and station management entityand the access layer

∙ MN interface: interface between the communication and station management entityand the networking & transport layer

∙ SA interface: interface between the security entity and the ITS-S application entity

∙ SF interface: interface between the security entity and the facilities layer

∙ SI interface: interface between the security entity and the access layer

∙ SN interface: interface between the security entity and the networking & transportlayer

∙ MS interface: interface between the communication and station management entityand the security entity

∙ IN interface: interface between the access layer and the networking & transportlayer

∙ NF interface: interface between the networking & transport layer and the facilitieslayer

∙ FA interface: interface between the facilities layer and the ITS-S applications entity

B.1.1 Defintion of the Certificate FormatListing B.1 shows a generic format of a certificate.

struct {uint8 version;SignerInfo signer_info<var>;SubjectInfo subject_info;

B.1 Intelligent Transporting System (ITS) Station Reference Architecture 77

SubjectAttribute subject_attributes<var>;ValidityRestriction validity_restriction<var>;Signature siganture;

} Certificate;

Listing B.1: Structure defines how to encode a certificate

The version is an 8-Bit unsigned integer corresponding to the current version of thedocument [ETS13]. The SignerInfo is defined Listing B.2. The Signature field holds thesignature, calculated over all encoded fields with their lengths, from the responsible CA.If reconstruction_value is chosen in the subject_attributes field, the Signature field should beskipped.Note: An opaque field is a block of data, whose content interpretation is not furtherspecified [ETS13]. It is just limited by the length.

struct {SignerInfoType type;select(type){

case self: ;case certificate_digest_with_ecdsap256:

HashedID8 digest;case certificate:

Certificate certificate;case certificate_chain:

Certificate certificate;case certificate_digest_with_other_algorithem:

PublicKeyAlgorithm algorithm;HashedId8 digest;

unknown:opaque info<var>;

}} SignerInfo;

Listing B.2: SignerInfo

enum {self(0),certificate_digest_with_ecdsap256(1),certificate(2),certificate_chain(3),certificate_digest_with_other_algorithm(4),reserved(240..255),(2^8-1)

} SignerInfoType;

Listing B.3: SignerInfoType

struct {SubjectTyp subject_type;opaque subject_name<2^8-1>;

} SubjectInfo;

Listing B.4: SubjectInfo

enum {enrollment_credential(0),authorization_ticket(1),

78 B Appendix

authorization_authority(2),enrollment_authority(3),root_ca(4),crl_signer(5),(2^8-1)

} SubjectType;

Listing B.5: SubjectType

struct {SubjectAttributeType type;select(type){

case verification_key:case encryption_key:

PublicKey key;case assurance_level:

SubjectAssurance assurance_level;case reconstruction_value:

EccPoint rv;case its_adi_list:

IntX its_adi_list<var>;case its_aid_ssp_list:

ItsAidSsp its_aid_ssp_list<var>;case priority_its_aid_list:

ItsAidPriority its_aid_priority_list<var>;case priority_ssp_list:

ItsAidPrioritySsp its_aid_priority_ssp_list<var>;unknown:

opaque other_attribute<var>;}

} SubjectAttribute;

Listing B.6: SubjectAttribute

enum {verification_key(0),encryption_key(1),assurance_level(2),reconstruction_value(3),its_aid_list(32),its_aid_ssp_list(33),priority_its_aid_list(34),priority_ssp_list(35),(2^8-1)

} SubjectAttributeType;

Listing B.7: SubjectAttributeType

opaque SubjectAssurance

Listing B.8: SubjectAssurance

struct {ValidityRestrictionType type;select(type){

case time_end:Time32 end_validity;

case time_start_and_end:Time32 start_validity;

B.1 Intelligent Transporting System (ITS) Station Reference Architecture 79

Time32 end_validity;case time_start_and_duration:

Time32 start_validity;Duration duration

case region:GeographicRegion region

unknown:opaque data<var>;

}} ValidityRestriction;

Listing B.9: ValidityRestriction

enum {time_end(0),time_start_and_end(1),time_start_and_duration(2),region(3),(2^8-1)

} ValidityRestrictionType;

Listing B.10: ValidityRestrictionType

struct {IntX its_aid;opaque service_specific_premissions<var>;

} ItsAidSsp;

Listing B.11: ItsAidSsp

struct {IntX its_aid;uint8 max_priority;

} ItsAidPriority;

Listing B.12: ItsAidPriority

struct {IntX its_aid;uint8 max_priority;opaque service_specific_premissions<var>;

} ItsAidPrioritySsp;

Listing B.13: ItsAidPrioritySsp

To certification revocation is given by choosing crl_signer as value in the field SubjectType.

B.1.2 Security Profiles in ITSThe structure of a secured message has different definitions in [ETS13] and [IEE13]. TheETSI version is shown in Listing B.14.

struct {uint8 protocol_version;uint8 security_profile;HeaderField header_fields<var>;Playload payload_fields<var>;TrailerField trailer_fields<var>;

80 B Appendix

} SecuredMessage;

Listing B.14: SecuredMessage by [ETS13]

The IEEE definds the data format for secured messages as 1609Dot2Data in [IEE13].struct {

uint8 protocol_version;ContentType type;select (type){

case unsecured:opaque data<var>;

case signed, signed_partial_payload, signed_external_payload:SignedData signed_data;

case signed_wsa:SignedWsa signed_wsa;

case encrypted:EncryptedData encrypted_data;

case crl_request:CrlRequest crl_request;

case crl:Crl crl;

case other_value:opaque data<var>;

}} 1609Dot2Data;

Listing B.15: 1609Dot2Data by [IEE13]

Based on the definitions of a secure message, there are some security services [ETS12].The IEEE 1609.2 supports security associations on the fly by using the trust hierarchyand security service applied to the message in the body and content of the public keycertificate. The ETSI definition supports the management of session based securityassociations. Also the nomenclature for the various types of messages is different. TheAmerican IEEE 1609.2 Standard uses BSM as basic message format, while the EuropeanETSI are using CAM. The idea behind both message formats is almost the same, e.g.,fields are named different and values are stored with different units or resolutions.

B.2 Computation ExamplesIn some cases not every property, such as driven distance or speed, can be measureddirectly. So it is necessary to compute them.

B.2.1 Computation of DistanceThe vehicle (V) has to provide information about the distance traveled. If this isimpossible, the distance can be computed from the starting position 𝑠 to the end position𝑒 with Algorithm B.2.1 based on WGS 84 [Mor00].

B.2 Computation Examples 81

Algorithm B.2.1: CalculationByDistanceData: 𝑠 = (𝑠𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒, 𝑠𝐿𝑜𝑛𝑔𝑖𝑡𝑢𝑑𝑒), 𝑒 = (𝑒𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒, 𝑒𝐿𝑜𝑛𝑔𝑖𝑡𝑢𝑑𝑒)Result: 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

1 begin/* some constant parameter */

2 DEG_TO_RAD ←− 0.0174532925199432957692369076848863 EARTH_RADIUS_IN_METERS ←− 6371000.7854 FACTOR_TO_DEGREE ←− 100000005 SCALE_FAC ←− FACTOR_TO_DEGREE · DEG_TO_RAD67 latitudeArc ←− (𝑠𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒 − 𝑒𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒)· SCALE_FAC8 longitudeArc ←− (𝑠𝐿𝑜𝑛𝑔𝑖𝑡𝑢𝑑𝑒 − 𝑒𝐿𝑜𝑛𝑔𝑖𝑡𝑢𝑑𝑒)· SCALE_FAC9 latitudeH ←− sin(latitudeArc·0.5)2

10 longitudeH ←− sin(longitudeArc·0.5)2

1112 tmp ←− cos(𝑠𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒· SCALE_FAC) · cos(𝑒𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒·SCALE_FAC)13

/* the unit of return parameter distance is 1m */14 distance ←− 2 · arcsin(

√latitudeH + tmp · lontitudeH)

B.2.2 Computation of SpeedIt can be assumed, that the measured, current speed of a vehicle (V) is correct and cannot be manipulated by the driver or a third party. A speed measurement is providedonce a second by the vehicle (V). If this is impossible, the speed can be computed by thedriven distance within the last second:

𝑣 = 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 in 𝑚

1𝑠= 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 in 𝑚/𝑠

B.2.3 Computation of Average SpeedThe average speed is the arithmetic mean of every absolute value of 𝑣𝑖:

𝑣average = 1𝑛·

𝑛∑︁𝑖=1|𝑣𝑖| =

|𝑣1|+ . . . + |𝑣𝑛|𝑛

B.2.4 Rule CheckingThe calculation of rule-triggering (see Section 3.1.3) of the rule set speed with threshold 𝑡,count 𝑛, and a allowed speed 𝑣allowed:

∃𝑣𝑖 : ∀𝑣𝑖+𝑗 , 𝑗 ≥ 𝑛 : |𝑣𝑖|+ . . . + |𝑣𝑖+𝑗−1|𝑗

− 𝑣allowed > 𝑣allowed · 𝑡

If the speed limit changes during the measurement, the calculation is using weightedsubcalculations. For example, after 𝑐 seconds, with 0 < 𝑐 < 𝑗, the speed limit changes

82 B Appendix

from 𝑣𝑎1 to 𝑣𝑎2 , and the new calculation is:(︂ |𝑣𝑖|+ . . . + |𝑣𝑖+𝑐−1|𝑐

− 𝑣𝑎1

)︂+

(︂ |𝑣𝑖+𝑐|+ . . . + |𝑣𝑖+𝑗−1|𝑗 − 𝑐

− 𝑣𝑎2

)︂>

(︂𝑐

𝑗· 𝑣𝑎1 + 𝑗 − 𝑐

𝑗· 𝑣𝑎2

)︂· 𝑡

⇔ 1𝑐

𝑖+𝑐−1∑︁𝑘=𝑖

|𝑣𝑘| − 𝑣𝑎1 + 1𝑗 − 𝑐

𝑖+𝑗−1∑︁𝑘=𝑖+𝑐

|𝑣𝑘| − 𝑣𝑎2 >

(︂𝑐

𝑗· 𝑣𝑎1 + 𝑗 − 𝑐

𝑗· 𝑣𝑎2

)︂· 𝑡

generalized with 𝑣𝑎𝑘as speed limit at time 𝑘:∑︀𝑖+𝑗−1

𝑘=𝑖 |𝑣𝑘| − 𝑣𝑎𝑘

𝑗>

∑︀𝑖+𝑗−1𝑘=𝑖 𝑣𝑎𝑘

𝑗· 𝑡

⇔𝑖+𝑗−1∑︁

𝑘=𝑖

|𝑣𝑘| − 𝑣𝑎𝑘>

𝑖+𝑗−1∑︁𝑘=𝑖

𝑣𝑎𝑘· 𝑡

The distance rule set is proved by constantly calculating the driven distance. At00:00:00.000 UTC every day, the counter has to be reset and the value has to besaved.

B.3 Comparison of Actors of State-of-the-Art and new Model


HMI


sign insurance plan

direct communication

requesting data

setup

direct access

Setup

Operation

Finish

Sto

red

data

(a) Actors of State-of-the-Art Model


Privacy-Perserving Protocol HMI


sign insurance plan

setupSetup

Operation

Finish

Sto

red

data

publishing selected data

(b) Actors of new Model

Figure B.2: Comparison between the State-of-the-Art and the our approach of thecommunication

B.4 Generic Building Block and Overall Picture 83

B.4 Generic Building Block and Overall Picture

Program chart — generic building block

get 𝑎, 𝑏, 𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑝𝑒𝑛𝑎𝑙𝑡𝑦, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐

construct ticket1 𝑡 based on (𝑎, 𝑏, 𝑚𝑖𝑠𝑐)

ZZZY

𝑎 > 𝑏��N

append ticket 𝑡 to 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛

overwrite 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 with 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 + 𝑝𝑒𝑛𝑎𝑙𝑡𝑦

erase ticket 𝑡

overwrite 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 with 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 + 0

Figure B.3: Generic building block to check one property 𝑎 against one threshold 𝑏:(𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑜𝑢𝑡)← BuildingBlock(𝑎, 𝑏, 𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑝𝑒𝑛𝑎𝑙𝑡𝑦, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔𝑖𝑛, 𝑚𝑖𝑠𝑐)

1It is also possible to construct the ticket only if 𝑎 > 𝑏 and store this in ticketlog but as presented here,the structure is more to similar to the final implementation.

84 B Appendix

Program chart — Nested building blocks for overall algorithm

for Billingperiod 𝑏𝑝

initialize 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔

foreach Month 𝑚 in 𝑏𝑝.𝑚𝑜𝑛𝑡ℎ𝑠[]

initialize 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔

foreach Day 𝑑 in 𝑚.𝑑𝑎𝑦𝑠[]

initialize 𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔

foreach PropertySnapshot 𝑠 in 𝑑.𝑠𝑛𝑎𝑝𝑠ℎ𝑜𝑡𝑠[]

foreach Property 𝒫 in 𝑠.𝑝𝑟𝑜𝑝𝑒𝑟𝑡𝑖𝑒𝑠[]

foreach threshold 𝑙 in 𝒫.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑠[]

𝒫.𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 −−1

ZZZY𝒫.𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 ≤ 0

��N

𝒫.𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔𝐷𝑒𝑙𝑎𝑦 = 𝒫.𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦𝐷𝑒𝑙𝑎𝑦

𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡← 𝒫.𝑚𝑒𝑎𝑠𝑢𝑟𝑒()

(𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔) ←BuildingBlock(𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡.𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡𝑉 𝑎𝑙𝑢𝑒, 𝑙.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒,𝑙.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃 𝑒𝑛𝑎𝑙𝑡𝑦, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔,𝑚𝑖𝑠𝑐 := (𝑚𝑒𝑎𝑠𝑢𝑟𝑒𝑚𝑒𝑛𝑡.𝑚𝑖𝑠𝑐, 𝑙.𝑚𝑖𝑠𝑐 ,. . . ))

(𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔) ← BuildingBlock(𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙,𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒,𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙,𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃 𝑒𝑛𝑎𝑙𝑡𝑦, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔,𝑚𝑖𝑠𝑐 := (𝑑.𝑚𝑖𝑠𝑐, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑑.𝑑𝑎𝑖𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔. . .))

(𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔) ←BuildingBlock(𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙,𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒,𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙,𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃 𝑒𝑛𝑎𝑙𝑡𝑦, 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔,𝑚𝑖𝑠𝑐 := (𝑚.𝑚𝑖𝑠𝑐, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑚.𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔. . .))

publish 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇 𝑜𝑡𝑎𝑙, 𝑏𝑝.𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔

Figure B.4: Overall algorithm for nested building blocks:(𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔)← BuildingBlock(𝑎, 𝑏, 𝑐𝑜𝑢𝑛𝑡𝑒𝑟, 𝑝𝑒𝑛𝑎𝑙𝑡𝑦, 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔, 𝑚𝑖𝑠𝑐)Each building block expects a property or a total 𝑎, a threshold 𝑏, a counter𝑐𝑜𝑢𝑛𝑡𝑒𝑟, a ticketlog 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔, and some miscellaneous information 𝑚𝑖𝑠𝑐.Each building block returns the counter 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 and the ticketlog 𝑡𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.The overall algorithm returns the 𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇𝑜𝑡𝑎𝑙 and in caseof disagreement the ticketlog 𝑏𝑖𝑙𝑙𝑖𝑛𝑔𝑝𝑒𝑟𝑖𝑜𝑑𝑇 𝑖𝑐𝑘𝑒𝑡𝑙𝑜𝑔.The operations red marked are additional operations.

B.5 Class Diagram of Used Data Structures 85

B.5 Class Diagram of Used Data Structures

86 B Appendix

Thr

esho

ldID th

resh

oldV

alue

: int

thre

shol

dPen

alty

: int

mis

cch

eckT

hres

hold

(inp

ut: i

nt, t

hres

hold

: int

, pen

alty

: int

, tot

al:in

t, tic

ketlo

g: T

icke

tlog,

mis

c):(

tota

l: in

t, tic

ketlo

g: T

icke

tlog)

Mea

sure

men

tID m

easu

rem

entV

alue

: int

mis

c

Prop

erty

ID freq

uenc

yDel

ay: i

ntre

mai

ning

Del

ay: i

ntth

resh

olds

[]: T

hres

hold

mea

sure

():M

easu

rem

ent

Prop

erty

Snap

shot

prop

ertie

s[]:

Pro

pert

y

Day

ID daily

Vio

latio

nTot

al: i

ntda

ilyV

iola

tionT

hres

hold

: Thr

esho

ldda

ilyT

icke

tlog:

Tic

ketlo

gm

isc

snap

shot

s[]:

Pro

pert

ySna

psho

t

Mon

thID m

onth

lyV

iola

tionT

otal

: int

mon

thly

Vio

latio

nThr

esho

ld: T

hres

hold

mon

thly

Tic

ketlo

g: T

icke

tlog

mis

cda

ys[]

: Day

Tic

ketlo

gID tic

kets

[]: T

icke

tst

oreT

icke

t(Ti

cket

): v

oid

initi

aliz

e():

void

clea

r():

void

Bill

ingp

erio

dID bi

lling

peri

odV

iola

tionT

otal

: int

billi

ngpe

riod

Tic

ketlo

g: T

icke

tlog

mon

ths[

]: M

onth

publ

ishV

iola

tionT

otal

(): i

ntpu

blis

hTic

ketL

og()

: Tic

ketlo

g

Tic

ket

ID ticke

tge

nTic

ket(

...):

Tick

et

Figure B.5: Class diagram to demonstrate to relationships between the diffident datastructures

B.6 Protocol to Compare Two Positive Integers Bitwise: F𝑐𝑜𝑚𝑝𝐵𝑖𝑡 87

B.6 Protocol to Compare Two Positive IntegersBitwise: F𝑐𝑜𝑚𝑝𝐵𝑖𝑡

One key functionality is the comparison of two integers without leaking informationof the private integer in F𝑐𝑜𝑚𝑝𝐵𝑖𝑡. The private integer is masked by a function 𝐹 andcompares the result of 𝐹 . The construction of 𝐹 is similar to the Lamport one-timesignature scheme [Lam81]. The function 𝐹 requires a bitwise input for both parties. So,one party generates the function 𝐹 and the other party asks for the values by using anoblivious transfer protocol.This approach utilizes the protocol C of [KG13] to extend it later to a shared output.The corresponding functionality with the extension of shared output and encrypted inputis called F𝑐𝑜𝑚𝑝𝐵𝑖𝑡 and provides the functionality of F𝑐𝑜𝑚𝑝𝑎𝑟𝑒:

(𝜎𝑎, 𝜎𝑏)← F𝑐𝑜𝑚𝑝𝐵𝑖𝑡(𝑒𝑛𝑐𝑝𝑘(𝑎), 𝑒𝑛𝑐𝑝𝑘(𝑏))

B.6.1 Oblivious TransferDefinition B.6.1 (Oblivious Transfer (see [Gol02])) Oblivious transfer is a proto-col where one party Alice (A) transmits part of its input to Bob (B), in such a way thatboth parties are protected: Alice does not learn which part of the input was transmitted,and Bob does not gain any additional knowledge about Alice’s input, besides the transmit-ted information.An 1-out-of-2 Oblivious Transfer protocol is a two party protocol (A,B) such that𝑂𝑢𝑡𝑝𝑢𝑡(𝐴(𝑣0, 𝑣1), 𝐵(𝑐)) = (⊥, 𝑣𝑐).

∙ Alice input: two values 𝑣0, 𝑣1

∙ Bob input: a single bit 𝑐

∙ Alice output: nothing (⊥)

∙ Bob output: 𝑣𝑐

The protocol is secure if the following properties hold:

∙ The combinations {𝑉 𝑖𝑒𝑤𝐴(𝐴(𝑣0, 𝑣1), 𝐵(0))} and {𝑉 𝑖𝑒𝑤𝐴(𝐴(𝑣0, 𝑣1), 𝐵(1))} are in-distinguishable (combination indexed by 𝑣0 and 𝑣1).

∙ There is a simulator 𝑆𝑖𝑚 such that combinations {𝑆𝑖𝑚(𝑐, 𝑣𝑐)} and{𝑉 𝑖𝑒𝑤𝐵(𝐴(𝑣0, 𝑣1), 𝐵(𝑐))} are indistinguishable (combinations indexed by 𝑣0,𝑣1 and 𝑐)

Secure in this case means:

∙ For any (possibly cheating) Alice A’, the combinations {𝑉 𝑖𝑒𝑤′𝐴(𝐴′, 𝐵(0))} and{𝑉 𝑖𝑒𝑤′𝐴(𝐴′, 𝐵(1))} are indistinguishable.

88 B Appendix

∙ For any (possibly cheating) Bob B’, there is an ’ideal’ adversary that simulates theinteraction between B’ and A. Here an ideal adversary is a probabilitic machine thatgiven randomness 𝑟, outputs a query bit 𝑞 = 𝑄(𝑟). Then, on input 𝑣𝑞, it outputsthe simulated view for R’. We require that {𝑆𝑖𝑚(𝑟, 𝑣𝑄(𝑟))} is computationallyindistinguishable from {𝑉 𝑖𝑒𝑤′𝐵[𝐴(𝑣0, 𝑣1), 𝐵′]}

The Protocol B.6 and [NP01] show an implementation of an oblivious transfer protocol.

Alice Bobpublic: 𝑞

has private integers 𝑀0, 𝑀1 has private bit 𝜎 ∈ {0, 1}𝐶 ∈ Z𝑞

𝐶−→𝑘 ∈𝑅 {1, . . . , 𝑞}

𝑝𝑘𝜎 = 𝑔𝑘, 𝑝𝑘1−𝜎 = 𝐶

𝑝𝑘𝜎

𝑝𝑘0←−−

𝑝𝑘1 = 𝐶

𝑝𝑘0𝑟0, 𝑟1 ∈𝑅 Z𝑞

𝐸0 := ⟨𝑔𝑟0 , 𝐻(𝑝𝑘𝑟00 )⊕𝑀0⟩

𝐸1 := ⟨𝑔𝑟1 , 𝐻(𝑝𝑘𝑟11 )⊕𝑀1⟩

𝐸0,𝐸1−−−−→compute: 𝐻((𝑔𝑟𝜎 )𝑘) = 𝐻(𝑝𝑘𝑟𝜎

𝜎 )decrypt 𝑀𝜎 = 𝐻((𝑔𝑟𝜎 )𝑘)⊕𝐻(𝑝𝑘𝑟𝜎

𝜎 )⊕𝑀𝜎

Figure B.6: 1-out-of-2 Oblivious Transfer(see [NP01])

B.6.2 Construction of Order Preserving Function 𝐹

It is required that function 𝐹 is an order preserving function at a point 𝑏 (see DefinitionB.6.3), so [KG13] construction an order preserving function 𝐹 at a point 𝑏.

Definition B.6.2 (Order preserving Function) A function 𝐹 : 𝐴→ 𝐵 where |𝐴| ≪|𝐵| is called an order preserving function if 𝑎 < 𝑏⇔ 𝐹 (𝑎) < 𝐹 (𝑏), ∀𝑎, 𝑏 ∈ 𝐴.

Definition B.6.3 (Order Preserving Function at a Point 𝑏) A function 𝐹 : 𝐴→𝐵 where |𝐴| ≪ |𝐵| is called an order preserving function at a point 𝑏 if for every 𝑥 ∈ 𝐴,𝑥 < 𝑏⇒ 𝐹 (𝑥) < 𝐹 (𝑏) ∧ 𝑥 > 𝑏⇒ 𝐹 (𝑥) > 𝐹 (𝑏).


The function 𝐹 maps the input 𝑥 = (𝑥𝑛, 𝑥(𝑛−1), . . . , 𝑥2, 𝑥1) bitwise to the output using arandom function 𝑓𝑖 : {0, 1} → N.

Definition B.6.4 (rise) We define a set 𝑆 = {𝑖 : 𝑏𝑖 = 0}, (𝑏𝑖 denotes the 𝑖𝑡ℎ leastsignificant bit in the binary representation of value 𝑏). Then, we define (rise)𝑖 to be𝑓𝑖(1)− 𝑓𝑖(0), ∀𝑖 ∈ 𝑆.

Definition B.6.5 (fall) We define a set 𝑌 = {𝑖 : 𝑏𝑖 = 1}, (𝑏𝑖 denotes the 𝑖𝑡ℎ leastsignificant bit in the binary representation of value 𝑏). Then, we define (fall)𝑖 to be𝑓𝑖(1)− 𝑓𝑖(0), ∀𝑖 ∈ 𝑌 .

With the idea of (rise)𝑖 and (fall)𝑖. it is now possible to construct 𝐹 .

Definition B.6.6 (Construction2of F) Choose 𝑙 ∈𝑅 N. Let 𝑛 be the length of thegiven 𝑏, so 𝑏 = (𝑏𝑛, 𝑏𝑛−1, . . . , 𝑏2, 𝑏1) ∈ {0, 1}𝑛.

1. choose ∀𝑖 : 1 ≤ 𝑖 ≤ 𝑛 : 𝑓𝑖(𝑏𝑖) ∈𝑅 N

2. compute𝑣𝑖 :=

∑︁∀𝑗∈𝑆:𝑗<𝑖

(rise)𝑖

and choose ∀𝑖 ∈ 𝑌 : 𝑓𝑖(0) ∈𝑅 (𝑓𝑖(1)− 𝑣𝑖 − 𝑙, 𝑓𝑖(1)− 𝑣𝑖)

3. compute𝑢𝑖 :=

∑︁∀𝑗∈𝑌 :𝑗<𝑖

(fall)𝑖

and choose ∀𝑖 ∈ 𝑆 : 𝑓𝑖(1) ∈𝑅 (𝑓𝑖(0) + 𝑢𝑖, 𝑓𝑖(0) + 𝑢𝑖 + 𝑙)

4. Set 𝐹 (𝑥) := 𝐹 (𝑥𝑛, 𝑥𝑛−1, . . . , 𝑥2, 𝑥1) = 𝑓𝑛(𝑥𝑛) + 𝑓𝑛−1(𝑥𝑛−1) + . . . + 𝑓2(𝑥2) + 𝑓1(𝑥1)

B.6.3 Protocol to Compare Two IntegersBy understanding how to construct 𝐹 and how to realize the OT protocol, it is possibleto compare the two private, positive integer inputs of Alice and Bob bitwise.

By construction, the function 𝐹 compares 𝑎 and 𝑏 in a secure manner in the semi-honest model (see Definition 2.4.6). Owning to the oblivious transfer protocol Bob hasno knowledge, which 𝑓𝑖(𝑎𝑖) Alice needs to compute her 𝐹 (𝑎).

B.6.4 Extension to Shared Output and Encrypted InputThe idea of shared output includes that one party has the knowledge of the result ofthe operation and the other party has the knowledge of the performed operation. It isnecessary that both parties have an output bit to share the output. Alice obtains theplaintext result of the operation and Bob can control which operation is used. Bob canchoose 𝜎𝑏 randomly in {0, 1} which determines the < or ≥ comparison is executed. This

2This is only one possibility to construct the function 𝐹 .

90 B Appendix

Alice Bobhas private integer 𝑎 has private integer 𝑏

𝑎 = (𝑎𝑛, 𝑎𝑛−1, . . . , 𝑎2, 𝑎1) 𝑏 = (𝑏𝑛, 𝑏𝑛−1, . . . , 𝑏2, 𝑏1)𝐹 ← 𝐺𝑒𝑛𝐹 (𝑏)

∀𝑖 : 𝑎𝑖 1-out-of-2 OT𝑟𝑒𝑞𝑢𝑒𝑠𝑡𝑓𝑖(𝑎𝑖)−−−−−−−−→

look up 𝑓𝑖(𝑎𝑖)𝑓𝑖(𝑎𝑖)←−−−

𝐹 (𝑎) =𝑛∑︁

𝑖=1𝑓𝑖(𝑎𝑖) 𝐹 (𝑏) =

𝑛∑︁𝑖=1

𝑓𝑖(𝑏𝑖)

𝐹 (𝑏)←−−−check 𝐹 (𝑎) < 𝐹 (𝑏)

Figure B.7: Comparing two integers bitwiseRecall: 𝐹 (𝑎) < 𝐹 (𝑏)⇔ 𝑎 < 𝑏∧𝐹 (𝑎) > 𝐹 (𝑏)⇔ 𝑎 > 𝑏∧𝐹 (𝑎) = 𝐹 (𝑏)⇔ 𝑎 = 𝑏.

is shown in Figure B.8.In case of 𝑎 = 𝑏⇔ 𝐹 (𝑎) = 𝐹 (𝑏) the value of 𝑏 is leaked to Alice: 𝑎 > 𝑏⇔ 𝐹 (𝑎) > 𝐹 (𝑏),𝑎 = 𝑏 ⇔ 𝐹 (𝑎) = 𝐹 (𝑏), and 𝑎 < 𝑏 ⇔ 𝐹 (𝑎) < 𝐹 (𝑏). To encode these three possiblestates into to a binary state of one bit, the first and second case are merged to one case:𝑎 ≥ 𝑏 ⇔ 𝐹 (𝑎) ≥ 𝐹 (𝑏). By negating of this case ¬(𝑎 ≥ 𝑏 ⇔ ¬(𝐹 (𝑎) ≥ 𝐹 (𝑏)) ⇔ 𝐹 (𝑎) <𝐹 (𝑏)⇔ 𝑎 < 𝑏 with 𝑎 = 𝑏 the decision Alice made is correct, but Bob draws the wrongconclusion (𝑎 < 𝑏 while 𝑎 = 𝑏) makes the final result wrong. Thus, the value of 𝑏 has tobe increased in case of 𝜎𝑏 = 1 to avoid the equal case. This is possible because 𝑎, 𝑏 areintegers, but the plain text space will be reduced by one element. The plaintext space isnot limited by external parameters, so the limitation is not important.By jointly decrypting of 𝑒𝑛𝑐𝑝𝑘(𝑎) and 𝑒𝑛𝑐𝑝𝑘(𝑏) at the beginning of the Protocol B.8, it ispossible to use the binary representation of 𝑎 and 𝑏 which is necessary for the originalprotocol.By extending the original protocol C of [KG13] with shared output it is possible torealize functionality and therefore F𝑐𝑜𝑚𝑝𝐵𝑖𝑡. Now F𝑐𝑜𝑚𝑝𝐵𝑖𝑡 has the required functionalityof F𝑐𝑜𝑚𝑝𝑎𝑟𝑒.

B.6.5 Evaluation of F𝑐𝑜𝑚𝑝𝐵𝑖𝑡

(𝜎𝑎, 𝜎𝑏)← F𝑐𝑜𝑚𝑝𝐵𝑖𝑡(𝑒𝑛𝑐𝑝𝑘(𝑎), 𝑒𝑛𝑐𝑝𝑘(𝑏))


Alice Bobhas encryption of private integer 𝑎 has encryption of private integer 𝑏

𝑒𝑛𝑐𝑝𝑘(𝑏)←−−−−−

𝐵𝑎 := 𝑑𝑒𝑐𝑠𝑘𝑎(𝑒𝑛𝑐𝑝𝑘(𝑏))𝑒𝑛𝑐𝑝𝑘(𝑎),𝐵𝑎−−−−−−−→

𝐴𝑏 := 𝑑𝑒𝑐𝑠𝑘𝑏(𝑒𝑛𝑐𝑝𝑘(𝑎))

𝐴𝑏←−𝐴𝑎 := 𝑑𝑒𝑐𝑠𝑘𝑎((𝑒𝑛𝑐𝑝𝑘(𝑎))) 𝐵𝑏 := 𝑑𝑒𝑐𝑠𝑘𝑏

((𝑒𝑛𝑐𝑝𝑘(𝑏)))𝑎 := 𝑑𝑒𝑐𝑟𝑒𝑐𝑜𝑣𝑒𝑟(𝐴𝑎, 𝐴𝑏) 𝑏 := 𝑑𝑒𝑐𝑟𝑒𝑐𝑜𝑣𝑒𝑟(𝐵𝑎, 𝐵𝑏)

𝑎 = (𝑎𝑛, 𝑎𝑛−1, . . . , 𝑎2, 𝑎1) 𝑏 = (𝑏𝑛, 𝑏𝑛−1, . . . , 𝑏2, 𝑏1)𝜎𝑏 ∈𝑅 {0, 1}𝐹 ← 𝐺𝑒𝑛𝐹 (𝑏 + 𝜎𝑏)

∀𝑖 : 𝑎𝑖 1-out-of-2 OT𝑟𝑒𝑞𝑢𝑒𝑠𝑡𝑓𝑖(𝑎𝑖)−−−−−−−−→

𝑓𝑖(𝑎𝑖⊕𝜎𝑏)←−−−−−−

𝐹 (𝑎) =𝑛∑︁

𝑖=1𝑓𝑖(𝑎𝑖 ⊕ 𝜎𝑏) 𝐹 (𝑏) =

𝑛∑︁𝑖=1

𝑓𝑖(𝑏𝑖 ⊕ 𝜎𝑏)

𝐹 (𝑏)←−−−

𝜎𝑎 ={︃

0 if 𝐹 (𝑎) ≥ 𝐹 (𝑏)1 if 𝐹 (𝑎) < 𝐹 (𝑏)

Figure B.8: F𝑐𝑜𝑚𝑝𝐵𝑖𝑡: comparing two integers with shared output

The protocol for F𝑐𝑜𝑚𝑝𝐵𝑖𝑡 has two parts. The first part is the construction of the𝐹 function and the second is the use of the OT protocol. As shown in [KG13] theconstruction of 𝐹 is correct and returns the expected result for the compare of the twoinput integers. Also the 𝐹 function keeps the privacy of the inputs. The use of an OTprotocol from [NP01] has the benefit, that this protocol is checked for correctness andprivacy. The extention to shared output changes the position of 𝑓𝑖(0) and 𝑓𝑖(1) in thefunction 𝐹 but does not have relevance to the security. With the OT protocol Bob doesnot know which value (𝑓𝑖(0) or 𝑓𝑖(1)) Alice is asking for. The theoretical runtime for 𝐹requires for each party 𝑛 additions and the generation of 2 · 𝑛 times 𝑛−bit long randominputs.But the shared output extension also requires the joint decryption of the input

92 B Appendix

parameters. So Bob can learn the plaintext value of the totals, which might not beintended because he could learn the 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃𝑒𝑛𝑎𝑙𝑡𝑦 and the𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑃𝑒𝑛𝑎𝑙𝑡𝑦. Also he is able to get an idea if he reached𝑚𝑜𝑛𝑡ℎ𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒 and 𝑑𝑎𝑖𝑙𝑦𝑉 𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑.𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉 𝑎𝑙𝑢𝑒.

B.7 Homomorphic Addition with XOR of Two Bits: F𝑋𝑂𝑅

Let Alice and Bob hold private bits 𝜎𝑎 and 𝜎𝑏 respectively then the ideal functionalityfor the privacy-preserving computation of 𝜎𝑎 ⊕ 𝜎𝑏 is given by:

(𝑒𝑛𝑐𝑝𝑘(𝜎𝑎 ⊕ 𝜎𝑏),⊥) ← F𝑋𝑂𝑅(𝜎𝑎, 𝜎𝑏)

The XOR function of 𝜎𝑎⊕𝜎𝑏 can be written as |𝜎𝑎−𝜎𝑏| because of 𝜎𝑎, 𝜎𝑏 ∈ {0, 1} it’s equalto (𝜎𝑎− 𝜎𝑏)2 = 𝜎𝑎− 2 · 𝜎𝑎 · 𝜎𝑏 + 𝜎𝑏. With knowledge of 𝜎𝑏 it is easy to simplify the termswith a case statement. For 𝜎𝑏 = 0 the term will be 𝜎𝑎−2·𝜎𝑎 ·𝜎𝑏+𝜎𝑏 = 𝜎𝑎−2·𝜎𝑎 ·0+0 = 𝜎𝑎

and if 𝜎𝑏 is 1 it is: 𝜎𝑎 − 2 · 𝜎𝑎 · 𝜎𝑏 + 𝜎𝑏 = 𝜎𝑎 − 2 · 𝜎𝑎 · 1 + 1 = −1 · 𝜎𝑎 + 1. In the first caseit is necessary to blind the encryption of 𝜎𝑏, so a fresh encryption of 0 will be used assummand in the addition.

Alice Bobhas as private 𝜎𝑎 has as private 𝜎𝑏

𝑒𝑛𝑐𝑝𝑘(𝜎𝑏)←−−−−−−

𝑒𝑛𝑐𝑝𝑘(𝜎𝑏 ⊕ 𝜎𝑏) :={︃

𝑒𝑛𝑐𝑝𝑘(𝜎𝑏) · 𝑒𝑛𝑐𝑝𝑘(0) if 𝜎𝑎 = 0𝑒𝑛𝑐𝑝𝑘(𝜎𝑏)−1 · 𝑒𝑛𝑐𝑝𝑘(1) else

Figure B.9: XOR Operation on shared bits (based on [May12])

An binary ⊕ can be written as shown as 𝑢⊕ 𝑣 = 𝑢− 2 · 𝑢 · 𝑣 + 𝑣. This is used in Bob’soperation by switching the terms depending on his own 𝜎𝑏. If 𝜎𝑏 equals zero, he only hasto use a fresh3 encryption of zero to blind the value of 𝑒𝑛𝑐𝑝𝑘(𝜎𝑎), or as an alternative, hecould re-randomize the encryption 𝑒𝑛𝑐𝑝𝑘(𝜎𝑎). In the case of 𝜎𝑏 = 1, he has to performthe whole ⊕ operation, written with ·, +, and −. With sending of 𝑒𝑛𝑐𝑝𝑘(𝜎𝑎⊕𝜎𝑏) to Aliceboth parties have an encrypted version of the result if 𝑎 ≥ 𝑏 (coded as 𝜎𝑎 ⊕ 𝜎𝑏 = 0) or𝑎 < 𝑏 (coded as 𝜎𝑎 ⊕ 𝜎𝑏 = 1).Now it is possible to calculate the XOR operation with shared and private input bits ofAlice and Bob. This XOR operation describes the increment factor. So to increase or

3Fresh, in this case, means that the encryption of the zero has a new chosen random part.

B.7 Homomorphic Addition with XOR of Two Bits: F𝑋𝑂𝑅 93

blind the encrypted counter it’s only necessary to perform an homomorphic addition:

𝑒𝑛𝑐𝑝𝑘(𝜎𝑎 ⊕ 𝜎𝑏) � 𝑒𝑛𝑐𝑝𝑘(𝑐) = 𝑒𝑛𝑐𝑝𝑘(𝜎𝑎 ⊕ 𝜎𝑏) · 𝑒𝑛𝑐𝑝𝑘(𝑐)

The implementation in Figure B.10 uses the F𝑋𝑂𝑅 in the first steps and adds the resulthomomorphicly to the encryption of 𝑐. As designed, Alice does not need any storage to

Alice Bobhas as private 𝜎𝑎 has as private 𝜎𝑏

𝑒𝑛𝑐𝑝𝑘(𝜎𝑏)←−−−−−−

𝑒𝑛𝑐𝑝𝑘(𝜎𝑎 ⊕ 𝜎𝑏) :={︃𝑒𝑛𝑐𝑝𝑘(𝜎𝑏) · 𝑒𝑛𝑐𝑝𝑘(0) if 𝜎𝑎 = 0𝑒𝑛𝑐𝑝𝑘(𝜎𝑏)−1 · 𝑒𝑛𝑐𝑝𝑘(1) else

has encrypted counter 𝑒𝑛𝑐𝑝𝑘(𝑐)𝑒𝑛𝑐𝑝𝑘(𝑐)←−−−−−

𝑒𝑛𝑐𝑝𝑘(𝑐) := 𝑒𝑛𝑐𝑝𝑘(𝑐) · 𝑒𝑛𝑐𝑝𝑘(𝜎𝑎 ⊕ 𝜎𝑏)𝑒𝑛𝑐𝑝𝑘(𝑐)−−−−−→

Figure B.10: Addition of XOR of shared bits (based on [May12])

store 𝑒𝑛𝑐𝑝𝑘(𝑐). The sent 𝑒𝑛𝑐𝑝𝑘(𝑐) from Bob to Alice is different to the received 𝑒𝑛𝑐𝑝𝑘(𝑐)because it is blinded with a fresh encryption of 0 or the value of 𝑐 is increased by 1. So tosave one transmission, the first and second message from Bob to Alice can be combinedto one message. But with two messages it is clear where the building parts are comingfrom.

B.7.1 Correctness and PrivacyThe correctness of F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 depends on the two parts. The first part is the AlgorithmB.9 for the XOR operation on the encrypted bits 𝜎𝑎 and 𝜎𝑏. This is shown in Table B.1.The second part is the homomorphic addition. This is per definition of the homomorphicaddition correct and so follows with the correctness of the XOR operation the correctnessof F𝑐𝑜𝑢𝑛𝑡𝑒𝑟.The privacy of all operations in F𝑐𝑜𝑢𝑛𝑡𝑒𝑟 depends on the privacy of the (2,2) thresholdsemantic-secure cryptosystem. There is also no leak of information, of 𝑒𝑛𝑐𝑝𝑘(𝑐) becauseof the new randomization of 𝑒𝑛𝑐𝑝𝑘(𝑐) before the storage. So the loaded ciphertext of

94 B Appendix

𝜎𝑎 𝜎𝑏 steps in B.9 result0 0 𝑒𝑛𝑐𝑝𝑘(0) · 𝑒𝑛𝑐𝑝𝑘(0) = 𝑒𝑛𝑐𝑝𝑘(0 + 0) = 𝑒𝑛𝑐𝑝𝑘(0)0 1 𝑒𝑛𝑐𝑝𝑘(1) · 𝑒𝑛𝑐𝑝𝑘(0) = 𝑒𝑛𝑐𝑝𝑘(1 + 0) = 𝑒𝑛𝑐𝑝𝑘(1)1 0 𝑒𝑛𝑐𝑝𝑘(0)−1 · 𝑒𝑛𝑐𝑝𝑘(1) = 𝑒𝑛𝑐𝑝𝑘(0 · (−1) + 1) = 𝑒𝑛𝑐𝑝𝑘(1)1 1 𝑒𝑛𝑐𝑝𝑘(1)−1 · 𝑒𝑛𝑐𝑝𝑘(1) = 𝑒𝑛𝑐𝑝𝑘(1 · (−1) + 1) = 𝑒𝑛𝑐𝑝𝑘(0)

Table B.1: Detailed steps for every possible input for XOR operation in B.9

𝑒𝑛𝑐𝑝𝑘(𝑐) is only known by Bob at this point and in both cases(𝜎𝑎⊕𝜎𝑏 = 0 and 𝜎𝑎⊕𝜎𝑏 = 1)Alice modifies 𝑒𝑛𝑐𝑝𝑘(𝑐) in a form, Bob cannot distinguish which summand Alice has used.

B.7.2 Amount of Operationsdone by

operation (maximum) Alice Bob# random selection 0 0# homomorphic addition 2 0# homomorphic multiplication with constant positive integer 0 0# homomorphic multiplication with constant negative integer 1 0# re-randomization 0 1# encryption 1 0# joint decryption 0 0

List of Figures

2.1 Death or injury rates in road traffic accidents per million inhabitants . . . 62.2 Categories of Location Service Applications . . . . . . . . . . . . . . . . . 72.3 Communication channels between insurer (I) and insured (O) . . . . . . . 102.4 Intelligent Transporting System: Basic set of applications . . . . . . . . . 132.5 Scenario Illustration by ETSI (based on [ETS10b]) . . . . . . . . . . . . . 152.6 Acquisition of enrollment credentials . . . . . . . . . . . . . . . . . . . . . 17

3.1 Publishing the criteria for the current thresholds . . . . . . . . . . . . . . 313.2 Calculations with help of the agent-box (A) . . . . . . . . . . . . . . . . . 323.3 Protocol for billing process . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4 System (re-)initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.5 Maintenance Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6 Publishing rules for insurance plan . . . . . . . . . . . . . . . . . . . . . . 353.7 Protocol for error reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 383.8 Communication channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Comparing two integers (see [KT06]) . . . . . . . . . . . . . . . . . . . . . 534.2 Comparing two encrypted integers with shared output (based on [KT06,

May12,Foe14]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3 Homomorphic multiplication of an integer 𝑖 with an encrypted, shared bit 554.4 Store or erase ticket with respect to private bits . . . . . . . . . . . . . . . 564.5 Manipulation of an encrypted counter by an encrypted penalty with respect

to the private bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.6 Complete algorithm for F𝐵𝑢𝑖𝑙𝑑𝑖𝑛𝑔𝐵𝑙𝑜𝑐𝑘 . . . . . . . . . . . . . . . . . . . . . 584.7 Jointly decryption of 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 for evaluation . . . . . . . . . . . . . . . . . 594.8 Protocol for continually evaluating the measurements: OverallPicture 60

B.1 ITS Station Reference Architecture (based on [ETS10b]) . . . . . . . . . . 75B.2 Comparison between the State-of-the-Art and the our approach of the

communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82B.3 Generic building block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83B.4 nested building blocks for overall algorithm . . . . . . . . . . . . . . . . . 84B.5 Class diagram to demonstrate to relationships between the diffident data

structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86B.6 1-out-of-2 Oblivious Transfer(see [NP01]) . . . . . . . . . . . . . . . . . . 88B.7 Comparing two integers bitwise . . . . . . . . . . . . . . . . . . . . . . . . 90B.8 F𝑐𝑜𝑚𝑝𝐵𝑖𝑡: comparing two integers with shared output . . . . . . . . . . . . 91

96 List of Figures

B.9 XOR Operation on shared bits (based on [May12]) . . . . . . . . . . . . . 92B.10 Addition of XOR of shared bits (based on [May12]) . . . . . . . . . . . . . 93

List of Tables

2.1 General Car2x Message Format . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Short review of VANET security communication approaches based on

[Bou11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Example rules of insurance plan . . . . . . . . . . . . . . . . . . . . . . . . 363.2 Data structure for used classes . . . . . . . . . . . . . . . . . . . . . . . . 433.3 Context of variable-naming of loops, thresholds, totals, and ticketlogs for

the overall picture in 3.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Detailed steps for input conditions of F𝑐𝑜𝑚𝑝𝑃 𝑎𝑖𝑙𝑙𝑖𝑒𝑟 . . . . . . . . . . . . . . 645.2 Correctness proof of 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

B.1 Detailed steps for every possible input for XOR operation in B.9 . . . . . 94

List of Algorithms

3.2.1 Generic BuildingBlock to check a property measurement or total 𝑎against a threshold 𝑏 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.2 Algorithm for continually observing the measurements: OverallPicture 48

4.7.1 Algorithm for continually evaluating the measurements: OverallAlgorithm 62

B.2.1CalculationByDistance . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

List of Listings

B.1 Structure defines how to encode a certificate . . . . . . . . . . . . . . . . . 76B.2 SignerInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77B.3 SignerInfoType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77B.4 SubjectInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77B.5 SubjectType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77B.6 SubjectAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78B.7 SubjectAttributeType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78B.8 SubjectAssurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78B.9 ValidityRestriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78B.10 ValidityRestrictionType . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79B.11 ItsAidSsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79B.12 ItsAidPriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79B.13 ItsAidPrioritySsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79B.14 SecuredMessage by [ETS13] . . . . . . . . . . . . . . . . . . . . . . . . . . 79B.15 1609Dot2Data by [IEE13] . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Bibliography

[ADMR97] HM Al-Deek, AA Mohamed, and AE Radwan. Operational benefits ofelectronic toll collection: case study. Journal of Transportation Engineering,123(6):467–477, 1997.

[Bou11] Mohamed Salah Bouassida. Authentication vs. Privacy within Vehicular AdHoc Networks. IJ Network Security, 13(3):121–134, 2011.

[Can00] Ran Canetti. Security and composition of multiparty cryptographic protocols.Journal of Cryptology, 13(1):143–202, 2000.

[Com03] European Communities. Directive 2003/558/EC of the European Parliamentand of the Council: On the processing of caller location information in electroniccommunication networks for the purpose of location-enhanced emergency callservices. Official Journal of the European Communities, July 2003.

[Deu13] Deutsche Welle. eCall - ein umstrittener lebensretter - europa - DW.DE -17.06.2013, 2013. http://www.dw.de/ecall-ein-umstrittener-lebensretter/a-16885677, visited 17.10.2013.

[ETS10a] ETSI. TS 102 637-1, (2010-09) Intelligent Transport Systems (ITS), Vehic-ular Communications (VC), Basic Set of Applications, Part 1: FunctionalRequirements. 2010.

[ETS10b] EN ETSI. EN 302 665, 3 (2010-09) Intelligent transport systems (ITS);Communications Architecture. Standard, EN, 2010.

[ETS10c] TCITS ETSI. TS 102 731, (2010-09) Intelligent transport systems (ITS);security; security services and architecture. Standard, TC ITS, 2010.

[ETS12] TS ETSI. TS 102 867, (2012-06) Intelligent transport systems (ITS); Security;Stage 3 mapping for IEEE 1609.2. Standard, TC ITS, 2012.

[ETS13] TS ETSI. TS 103 097, (2013-4) Intelligent transport systems (ITS); Security;Security header and certificate formats. Standard, TC ITS, 2013.

[Fel14] Christian Feld. Eu für Auto-Notrufsystem ab 2015, February 2014. http://www.tagesschau.de/ausland/eu-ecall100.html visited 25.06.2014.

[Foe14] Fabian Foerg. personal communication. unpublished, 2014.

DW.DE

http://www.dw.de/ecall-ein-umstrittener-lebensretter/a-16885677

http://www.dw.de/ecall-ein-umstrittener-lebensretter/a-16885677

http://www.tagesschau.de/ausland/eu-ecall100.html

http://www.tagesschau.de/ausland/eu-ecall100.html

104 Bibliography

[FRM+08] Julien Freudiger, Maxim Raya, E Ma, Frank Kargl, et al. Secure vehicularcommunication systems: design and architecture. IEEE CommunicationsMagazine, 4611:100–109, 2008.

[Gav01] Dariu M Gavrila. Sensor-based pedestrian protection. Intelligent Systems,IEEE, 16(6):77–81, 2001.

[Gle13] Clemens Gleich. Sparkassen-Direktversicherung bietet Blackbox-Tarif anVerwanzt versichert, November 2013. http://heise.de/-2044333 visited12.11.2013.

[GMBK09] Rafal Grzeszczyk, Jerzy Merkisz, Piotr Bogus, and Tomasz Kaminski. Meth-ods and Procedures for Testing the eCall In-Vehicle Unit for the Purpose ofIts Performance Assessment and Certification. In 21st International TechnicalConference on the Enhanced Safety of Vehicles ESV, 2009.

[Gol02] O. Goldreich. CSE208: Advanced cryptography, fall 2002 - lecture 4: Oblivioustransfer for semihonest parties. lecture notes from http://cseweb.ucsd.edu/classes/fa02/cse208/lec4.html, last visit 7.01.14, 2002.

[HDS+10] G Hiertz, Dee Denteneer, Lothar Stibor, Yunpeng Zang, Xavier Pérez Costa,and Bernhard Walke. The IEEE 802.11 universe. Communications Magazine,IEEE, 48(1):62–70, 2010.

[Hec14] Claus Hecking. Notrufsystem ecall: Verräterischer lebensretter, February2014. http://www.spiegel.de/auto/aktuell/ecall-eu-will-automatisches-notrufsystem-fuer-alle-neuwagen-a-955359.html visited 25.02.2014.

[HMRT12] Carmit Hazay, Gert Læssøe Mikkelsen, Tal Rabin, and Tomas Toft. EfficientRSA key generation and threshold paillier in the two-party setting. In Topicsin Cryptology–CT-RSA 2012, pages 313–331. Springer, 2012.

[HW06] William J Horrey and Christopher D Wickens. Examining the impact of cellphone conversations on driving using meta-analytic techniques. Human Factors:The Journal of the Human Factors and Ergonomics Society, 48(1):196–205,2006.

[IEE13] IEEE. IEEE Standard for Wireless Access in Vehicular Environments SecurityServices for Applications and Management Messages. IEEE Std 1609.2-2013(Revision of IEEE Std 1609.2-2006), pages 1–289, 2013.

[KG13] Ashish Kumar and Anupam Gupta. Some Efficient Solutions to Yao’s Million-aire Problem. arXiv preprint arXiv:1310.8063, 2013.

[Kön05] Wolfgang König. Toll collect als forschungsgegenstand. Wirtschaftsinformatik,47(4):241–242, 2005.

http://heise.de/-2044333

http://cseweb.ucsd.edu/classes/fa02/cse208/lec4.html

http://cseweb.ucsd.edu/classes/fa02/cse208/lec4.html

http://www.spiegel.de/auto/aktuell/ecall-eu-will-automatisches-notrufsystem-fuer-alle-neuwagen-a-955359.html

http://www.spiegel.de/auto/aktuell/ecall-eu-will-automatisches-notrufsystem-fuer-alle-neuwagen-a-955359.html

Bibliography 105

[KPB+08] Frank Kargl, Panos Papadimitratos, Levente Buttyan, M Muter, ElmarSchoch, Björn Wiedersheim, Ta-Vinh Thong, Giorgio Calandriello, Albert Held,Antonio Kung, et al. Secure vehicular communication systems: implementation,performance, and research challenges. Communications Magazine, IEEE,46(11):110–118, 2008.

[KT06] Florian Kerschbaum and Orestis Terzidis. Filtering for private collabora-tive benchmarking. In Emerging Trends in Information and CommunicationSecurity, pages 409–422. Springer, 2006.

[Kys12] Jiří Kysela. Identification of telematic and location based services key compo-nents and means of their utilization in telematic systems. Perner’s Contacts,7(4):91–100, 2012.

[Lam81] Leslie Lamport. Password authentication with insecure communication. Com-munications of the ACM, 24(11):770–772, 1981.

[LLZ+08] Xiaodong Lin, Rongxing Lu, Chenxi Zhang, Haojin Zhu, Pin-Han Ho, andXuemin Shen. Security in vehicular ad hoc networks. Communications Maga-zine, IEEE, 46(4):88–95, 2008.

[LP09] Yehuda Lindell and Benny Pinkas. Secure multiparty computation for privacy-preserving data mining. Journal of Privacy and Confidentiality, 1(1):5, 2009.

[LPS08] Yehuda Lindell, Benny Pinkas, and Nigel P Smart. Implementing two-partycomputation efficiently with security against malicious adversaries. In Securityand Cryptography for Networks, pages 2–20. Springer, 2008.

[LSHS07] Xiaodong Lin, Xiaoting Sun, Pin-Han Ho, and Xuemin Shen. GSIS: a secureand privacy-preserving protocol for vehicular communications. VehicularTechnology, IEEE Transactions on, 56(6):3442–3456, 2007.

[LSS05] Kerstin Lemke, Ahmad-Reza Sadeghi, and Christian Stüble. An open approachfor designing secure electronic immobilizers. In Information Security Practiceand Experience, pages 230–242. Springer, 2005.

[Mau14] Hannah Maundrell. Compare black box car insurance, January 2014.http://www.money.co.uk/car-insurance/black-box-insurance.htm visited06.03.2014.

[May12] Daniel A Mayer. Design and Implementation of Efficient Privacy-Preservingand Unbiased Reconciliation Protocols. PhD thesis, Stevens Institute of Tech-nology, 2012.

[May13] Alexander May. Kryptographie II. University Lecture, 2013.

[Mor00] Helmut Moritz. Geodetic reference system 1980. Journal of Geodesy, 74(1):128–133, 2000.

http://www.money.co.uk/car-insurance/black-box-insurance.htm

106 Bibliography

[Ngo14] Emily Ngo. Officials: Auto technology raises privacy issues. Website - Newsday,2014. Available online at http://www.newsday.com/classifieds/cars/officials-auto-technology-raises-privacy-issues-1.7181832; visited on24.02.2014.

[NP01] Moni Naor and Benny Pinkas. Efficient oblivious transfer protocols. In Pro-ceedings of the twelfth annual ACM-SIAM symposium on Discrete algorithms,pages 448–457. Society for Industrial and Applied Mathematics, 2001.

[NWHC09] Lo Nai-Wei and Tsai Hsiao-Chien. A reputation system for traffic safety eventon vehicular ad hoc networks. EURASIP Journal on Wireless Communicationsand Networking, 2009, 2009.

[Ove12] Michael Overstreet. Snapshot by Progressive- What is it and does it work?Website - examiner.com, 2012. Available online at http://www.examiner.com/article/snapshot-by-progressive-what-is-it-does-it-work; visited on02.04.2014.

[Paa04] Christof Paar. Embedded security in automobilanwendungen. ElektronikAutomotive, 1:152, 2004.

[Per14] Malin Persson. Volvo Car Group initiates Scandinavian pilot using cloud-based communication to make driving safer. Website - Volvo Car Group MediaRelations, 2014. Available online at https://www.media.volvocars.com/global/en-gb/media/pressreleases/141041; visited on 19.03.2014.

[PvVT+11] Igor Passchier, Hans van Vliet, Paul Tilanus, Peter Vermaat, Jean Hopkin,Denis Naberezhnykh, Peter Owlett, and Oene Kerstjens. New services enabledby the connected car. SMART 2010/0065, 2011. European Commission - DGInformation Society and Media: Final Report TNO-RPT-2011-01277.

[RH07] Maxim Raya and Jean-Pierre Hubaux. Securing vehicular ad hoc networks.Journal of Computer Security, 15(1):39–68, 2007.

[Sch11] Torsten Schütze. Automotive security: Cryptography for car2x communication.In Embedded World Conference, 2011.

[SD13] UNECE Statistical Division. Number of injury accidents, killed and injured.Website - United Nations, 2013. Available online at http://w3.unece.org/pxweb/database/STAT/40-TRTRANS/01-TRACCIDENTS/; visited on 17.11.2013.

[Sha79] Adi Shamir. How to share a secret. Communications of the ACM, 22(11):612–613, 1979.

[SNE06] Stefan Steiniger, Moritz Neun, and Alistair Edwardes. Foundations of locationbased services. Lecture Notes on LBS, 1, 2006.

http://www.newsday.com/classifieds/cars/officials-auto-technology-raises-privacy-issues-1.7181832

http://www.newsday.com/classifieds/cars/officials-auto-technology-raises-privacy-issues-1.7181832

http://www.examiner.com/article/snapshot-by-progressive-what-is-it-does-it-work

http://www.examiner.com/article/snapshot-by-progressive-what-is-it-does-it-work

https://www.media.volvocars.com/global/en-gb/media/pressreleases/141041

https://www.media.volvocars.com/global/en-gb/media/pressreleases/141041

http://w3.unece.org/pxweb/database/STAT/40-TRTRANS/01-TRACCIDENTS/

http://w3.unece.org/pxweb/database/STAT/40-TRTRANS/01-TRACCIDENTS/

Bibliography 107

[SSBP09] Ahren Studer, Elaine Shi, Fan Bai, and Adrian Perrig. TACKing togetherefficient authentication, revocation, and privacy in VANETs. In Sensor, Meshand Ad Hoc Communications and Networks, 2009. SECON’09. 6th AnnualIEEE Communications Society Conference on, pages 1–9. IEEE, 2009.

[SZC08] Hui Song, Sencun Zhu, and Guohong Cao. Svats: A sensor-network-basedvehicle anti-theft system. In INFOCOM The 27th Conference on ComputerCommunications. IEEE, pages 2128–2136. IEEE, 2008.

[Tra09] Harald Trautsch. eCall-Studie 2007/2008. BMVIT, 2009.

[Vai95] Aimo Vainio. A method for reporting a break-in into a vehicle equipped witha mobile telephone and for monitoring the movements of the vehicle in a plmnsystem, and a mobile telephone to be used in the method, April 12 1995. EPPatent 0,417,944.

[VMG+01] Kirsi Virrantaus, Jouni Markkula, Artem Garmash, Vagan Terziyan, JariVeijalainen, Artem Katanosov, and Henry Tirri. Developing GIS-supportedlocation-based services. In Web Information Systems Engineering, 2001. Pro-ceedings of the Second International Conference on, volume 2, pages 66–75.IEEE, 2001.

[Web97] Barry Webb. Steering column locks and motor vehicle theft: Evaluations fromthree countries. Situational crime prevention: Successful case studies, 2, 1997.

[WWM07] Matthias Wellens, Burkhard Westphal, and Petri Mahonen. Performanceevaluation of IEEE 802.11-based wlans in vehicular scenarios. In VehicularTechnology Conference, 2007. VTC2007-Spring. IEEE 65th, pages 1167–1171.IEEE, 2007.

[YBC+07] Steve Yu, Jason Bergeron, Dennis Cuccaro, David Femino, and Raul Insignares.Remote car controller. Electrical and Computer Engineering UndergraduateCapstone Projects, 2007.

Utilizing Homomorphic Cryptography to Improve Privacy in ... · 2 Background...

Documents

Transcript of Utilizing Homomorphic Cryptography to Improve Privacy in ... · 2 Background...