Maxime Marie Julien

Mohamed Olivier

Ainsi

Hajer, Imen, Maroua, Mohamed, Mouna, Rania, Rim Remercie Amine

Avant de commencer ce mémoire, je tiens à remercier toutes les personnes qui ont contribué, de près ou de loin, à la réussite de cette thèse.

Je souhaite tout d'abord remercier Gildas Avoine et Louis Goubin pour avoir accepté d'être rapporteurs de mes travaux de thèse. J'adresse également mes remerciements à Hervé Chabanne, Maryline Laurent et Aziz Moukrim pour m'avoir fait l'honneur de faire partie de mon jury de thèse.

Je voudrais aussi remercier mon directeur de thèse académique, Abdelmadjid, pour la liberté de travail qu'il m'a laissée pendant ces trois années. En outre, je suis très reconnaissante envers mes deux directeurs de thèse côté Orange, Saïd et Jacques, avec qui j'ai beaucoup apprécié travailler. Je les remercie notamment pour la confiance qu'ils m'ont témoignée, leur disponibilité, leurs remarques constructives et les précieux conseils qu'ils m'ont offerts tout au long de cette thèse, sans jamais rien m'imposer.

J'ai effectué cette thèse à Orange Labs et plus précisément au sein des deux équipes DSS à Paris et NPS à Caen. Je tiens à cet effet à remercier Jean-François et Sébastien pour leur bonne humeur et la bonne ambiance qu'ils maintiennent au niveau des deux équipes. Je souhaite par ailleurs remercier Solenn, avec qui j'ai eu le plaisir de travailler mais aussi de découvrir de nouveaux pays et cultures. J'ai aussi eu l'occasion de travailler avec Nicolas, que je remercie pour sa diligence. Je voudrais également remercier Marc pour avoir pris le temps de relire une partie de ce manuscrit et pour ses remarques pertinentes qui ont permis de l'améliorer. Je tiens également à remercier les différents membres des équipes NPS, DSS mais aussi NST pour tout ce qu'ils ont pu m'apporter et plus particulièrement les doctorants et post-docs, à savoir Alex, Alicia, Bastien, Baptiste, Benjamin, Donald, Ghada,

The set {g 1 , g 2 , . . . , g l } H(m, t)

The hash of the concatenation of m and t

Pr[x]

Probability of the event x q|p -1 q divides p -1 a ← b a is assigned the value b Protocol(U(sk), V(pp)) Interactive protocol between U and V which takes as input sk and pp kG i k exponentiations in the group G i kG j i k j-multi-exponentiations in the group G i ID U

Identifier of a user

U User I Issuer V Verifier A Adversary B Reduction C Challenger A O 1 (x)
The adversary A knows x and can query the oracle O 1 xvii Notation xviii Introduction l'autre) ou unilatérale (i.e. une des deux entités uniquement doit s'authentifier). Actuellement, l'authentification est utilisée partout et dans la vie de tous les jours. Prenons l'exemple d'un utilisateur qui souhaiterait connaître le solde de son compte bancaire en utilisant une application sur son smartphone. Pour ce faire, ce dernier doit d'abord s'authentifier (i.e. prouver qu'il est bien le détenteur de ce compte, ou du moins, qu'il connaît le login/mot de passe correspondant).

Le respect de la vie privée est une propriété moins ordinaire, mais qui ne cesse de gagner de l'intérêt surtout avec l'arrivée prochaine du futur règlement en matière de protection des données à caractère personnel (GDPR). Celui-ci risque, en effet, d'être très contraignant pour les fournisseurs de services et les opérateurs de télécommunications quant à l'utilisation des données de leurs clients. Plus précisément, ce règlement met en avant le principe de minimisation des données qui stipule que seules les informations strictement nécessaires à la réalisation d'une transaction (quelle qu'en soit la nature) devraient être dévoilées (et rien de plus). Par exemple, la seule information que la société d'autoroute à besoin de connaître lorsqu'un automobiliste emprunte les voies de télépéage, c'est le montant total que ce dernier lui doit. Il n'est sans doute pas nécessaire qu'elle ait en plus accès à l'historique précis des ses différents trajets.

A ce jour, plusieurs travaux ont déjà visé à concilier ces deux propriétés. Cependant, cela s'est bien souvent fait au détriment de l'efficacité. Rares sont en effet les solutions qui réussissent à satisfaire les contraintes temporelles strictes de certaines applications et aucune ne semble être adaptée aux dispositifs limités en termes de puissance de calcul et d'espace mémoire telle que la carte SIM.

Contributions

Primitives cryptographiques efficaces. Afin de surmonter les contraintes induites par les capacités de calcul limitées de certains dispositifs M2M et les exigences temporelles de certaines applications M2M, nous avons été conduits à introduire de nouveaux schémas cryptographiques. Nous proposons à cet effet, dans le Chapitre 4 de ce mémoire, cinq nouveaux schémas cryptographiques. Nous introduisons dans un premier temps un nouveau schéma de signature partiellement aveugle dont les signatures ont la particularité de pouvoir être "randomisées" et donc d'être intraçables y compris lorsqu'elles sont présentées à de multiples reprises au même vérificateur. Dans un deuxième temps, nous nous focalisons sur les schémas de code d'authentification de messages (MAC) algébriques qui, contrairement aux schémas MAC classiques, reposent sur des opérations dans des groupes cycliques. Dans ce contexte, nous concevons un nouveau schéma de MAC algébrique que nous avons baptisé MAC BB et qui peut, indifféremment, être utilisé pour caculer un tag sur un unique message ou un bloc de messages. Ensuite, nous proposons un nouveau schéma de MAC dont les tags peuvent être séquentiellement agrégés. Enfin, nous introduisons deux schémas d'attestations anonymes (DAA) pour lesquels tous les calculs sont effectués par la puce TPM (la SIM dans notre contexte) contrairement aux solutions antérieures qui nécessitent de déléguer une partie des calculs à la plateforme hôte embarquant cette puce TPM (typiquement un smartphone ou un PC). Ces cinq schémas cryptographiques sont adaptés aux environnements limités en ressources tels que les cartes SIMs dans la mesure où ils ne nécessitent aucun calcul de couplage (notoirement connus pour être particulièrement coûteux en termes de temps de calcul) par l'équipement M2M.

Dans le reste du mémoire, en nous appuyant sur les schémas proposés dans le chapitre 4, nous construisons quatre protocoles efficaces et préservant la vie privée des utilisateurs (i.e. utilisables en pratique). Ces protocoles consistent en un système de paiement anonyme, un système d'accréditations anonymes, un protocole d'authentification et d'identification anonyme pour l'embedded SIM (eSIM) ainsi qu'un système de vote électronique résistant à la coercition.

Un système de paiement anonyme pratique. Chaum a introduit en 1982 [START_REF] Chaum | Advances in Cryptology: Proceedings of Crypto 82, chapter Blind Signatures for Untraceable Payments[END_REF] le concept de Monnaie électronique (e-cash), équivalent numérique de la monnaie fiduciaire. Depuis, trois types de monnaie électronique ont été définis : transférable, divisible et compacte. Comme son nom l'indique, la monnaie électronique transférable permet, à l'instar de la monnaie fudiciaire, le transfert de pièces entre deux marchands (afin d'acheter des biens) ou entre un marchand et un utilisateur (afin de rendre la monnaie). La monnaie électronique divisible, quant à elle, offre la possibilité de convertir une pièce de valeur faciale importante (10 euros par exemple) en pièces de valeurs inférieures (5 pièces de 2 euros ou 10 pièces de 1 euro par exemple), afin d'éviter les problèmes d'appoint, courants avec la monnaie classique. Quant à la monnaie électronique compacte, elle permet à l'utilisateur de retirer plusieurs pièces en une seule fois, contrairement aux autres monnaies qui ne permettent de retirer qu'une seule pièce à la fois. Dans le chapitre 5, nous proposons un autre type de monnaie électronique que nous appelons private eCash. Ce nouveau type est particulièrement adapté aux applications tels que le transport public, le télépéage et la recharge de véhicules éléctriques, pour lesquelles une même et unique entité fait à la fois office de banque et de marchand. Notre système repose sur le schéma de signature partiellement aveugle introduit dans le chapitre 4. Plus précisément, une pièce de monnaie consiste en une signature partiellement aveugle portant sur une information connue uniquement par l'utilisateur. Grâce à une seule et unique pièce, un utilisateur pourra régler plusieurs "achats", dont le montant peut être variable, et ce de manière intraçable. Ces travaux ont donné lieu à la publication "Private eCash in Practice" [BBD + 16] à FC'16.

Chaum a aussi été à l'origine des accréditations anonymes [START_REF] Chaum | Advances in Cryptology: Proceedings of Crypto 82, chapter Blind Signatures for Untraceable Payments[END_REF] qui sont, depuis, largement répandues. Un système d'accréditations anonymes permet aux utilisateurs d'obtenir des accréditations certifiées (permis de conduire, carte d'étudiant, de sécurité sociale, etc.) auprès d'organisations émettrices (préfecture, mairie, université, etc.) et de prouver ensuite la possession de ces accréditations auprès de fournisseurs de services tout en minimisant l'information dévoilée (comme par exemple prouver que l'on est étudiant et que l'on a moins de 25 ans afin de bénéficier d'un tarif avantageux lors de l'entrée à un musée, et ce sans révéler sa date de naissance ni sa filière). Les accréditations anonymes ont plusieurs applications dont la monnaie électronique et le vote en ligne.

Accréditations anonymes à clés secrètes. Dans le chapitre 6, nous nous intéressons à un type particulier d'accréditations anonymes connues en anglais sous le nom de Keyed-Verification Anonymous Credentials (KVAC) car ces dernières requièrent que le vérifieur connaisse la clé secrète de l'entité qui a délivré l'accréditation. Suivant la même approche que Chase, Meiklejohn and Zaverucha [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF], nous nous basons sur les MACs algébriques, et plus précisément sur notre MAC n BB algébrique introduit dans le chapitre 4, afin de concevoir notre système d'accréditations anonymes à clés secrètes. Notre système permet plusieurs présentations d'une même accréditation, et ce de manière totalement intraçable, tout en étant presque aussi efficace que le système U-Prove de Microsoft (dont les accréditations ne satisfont pourtant pas cette caractéristique). Par ailleurs, il peut facilement être converti, si nécessaire, en un système d'accréditations anonymes classique. Ainsi, un utilisateur pourrait prouver la possession de son accréditation à n'importe quelle entité (même si cette dernière ne connaît pas la clé de l'émetteur). Ces résultats ont été Introduction nouvelle génération de cartes SIM embarquées connue sous le nom d'embedded SIMs (eSIMs). Notre protocole repose essentiellement sur notre schéma d'attestations anonymes, qui est fondé sur le schéma de signature de Boneh-Boyen, décrit dans le chapitre 4. Il vise à permettre l'authentification et l'identification anonyme de l'eSIM auprès d'une entité tierce, indépendante de l'opérateur, connue sous le nom de serveur de découverte. De la sorte, suite à un changement d'opérateur, l'eSIM pourra récupérer à distance son nouveau profil réseau tout en préservant la vie privée de son propriétaire face à un serveur de découverte malhonnête. Un brevet décrivant cette solution a été déposé à l'INPI en novembre 2015 [START_REF] Barki | Procédé d'identification anonyme d'un module de sécurité[END_REF].

Chapter 1 Introduction

Context

The concept of Machine to Machine (M2M) refers to all systems involving connected devices which can communicate with each other, or with a remote server, in an autonomous way (i.e. with no or little human intervention) so as to gather information, notify users of a given event, and even trigger some actions. Thereby, M2M enables a better management of resources and provide users with greater comfort, convenience as well as peace of mind. To date, there have been around 5 billion M2M devices connected to the wireless networks and, according to Ericsson's [START_REF] Ericsson | More than 50 billion connected devices[END_REF] as well as Cisco's estimation [START_REF] Evans | The internet of things, how the next evolution of the internet is changing everything[END_REF], their number is expected to reach 50 billion by 2020.

Unfortunately, an important hurdle that may jeopardize M2M growth and even hinder the massive roll-out of some M2M applications is security. Indeed, the nature of M2M environments and the sensitivity of exchanged data make M2M applications vulnerable to numerous attacks that may be initiated by a malicious service provider, an external adversary or even a fraudulent user. Furthermore, owing to the pervasiveness of M2M devices, a very large amount of personal data can be collected. If not properly protected, it may entail serious privacy concerns. Indeed, recorded information may disclose personal information such as habits and health status. Addressing these security and privacy issues is a quite challenging task particularly due to the heterogeneity of M2M devices, which are mainly inexpensive and resource constrained, and the stringent time constraints of certain applications (e.g. electronic Toll (eToll)).

In this thesis, we mainly focus on M2M applications involving a Secure Element (SE) such as a SIM card, and more specifically on combining two security properties that may seem contradictory at first glance, namely authentication and privacy. Thereby, users can enjoy the benefits of M2M applications while preserving their privacy. Hereinafter, we briefly define these two properties, then we give an overview of our contributions.

Authentication is one of the primary goals of cryptography which enables an entity to check the identity of another one (i.e. it is really what it claims to be) before initiating "real" communication. Usually, an authentication protocol involves two parties, but more parties can be involved as well. Besides, authentication can be mutual (i.e. both parties have to authenticate each other) or unilateral (i.e. only one party needs to be authenticated). Today, authentication is used everywhere. For instance, a user who wants to check his current account balance through an application on his smartphone must first authenticate himself using his login and password.

Privacy is a less common property that has been gaining particular interest in the last decades with the emergence of new technologies that handles users' personal data. More specifically, privacy aims to prevent the disclosure of any irrelevant and unnecessary personal information (e.g.

Chapter 1 : Introduction date of birth, habits) so as to comply with data minimization principles. For instance, a service provider (e.g. an eToll company) does not have to know the details of the different trips that a user has taken, but rather only the associated total charges.

To date, several schemes have aimed to ensure both the privacy and authentication properties. However, existing proposals did not really succeed in satisfying the security and privacy requirements as well as the need for efficiency (so as to meet the stringent time constraints of some applications), whilst being suitable for resource constrained environments like secure elements (e.g. SIM cards).

Contributions

Efficient cryptographic primitives. In order to overcome the constraints stemming from devices limited computational resources and applications stringent time constraints, more efficient cryptographic primitives had to be introduced. With this purpose in mind, we design in Chapter 4 five new cryptographic primitives that are of independent interest. More specifically, we first propose a partially blind signature scheme which enables multiple presentations of the same signature in an unlinkable way. Then, we build an efficient sequential aggregate Message Authentication Code (MAC) scheme. Next, we focus on algebraic MAC schemes which rely on group operations rather than hash functions or block ciphers. In this respect, we design a new algebraic MAC scheme referred to as MAC BB that can be extended to support n messages. Finally, we propose two practical Direct Anonymous Attestation (DAA) schemes where all computations on the platform's side are performed by the Trusted Platform Module (TPM). All proposals are suitable for resource constrained environments such as SIM cards as they require no pairings computations on the user's side.

In subsequent chapters, using the designed primitives as main building blocks, we build four practical privacy-preserving protocols, namely a private eCash system, an efficient coercionresistant electronic voting scheme, an anonymous authentication and identification protocol for embedded SIM (eSIM) as well as a Keyed-Verification Anonymous Credentials (KVAC) system.

Private eCash system. To provide a privacy-preserving digital analogue of hard currency, Chaum introduced in 1982 electronic cash (eCash) [START_REF] Chaum | Advances in Cryptology: Proceedings of Crypto 82, chapter Blind Signatures for Untraceable Payments[END_REF]. Since then, three main types of eCash systems have been defined: transferable, divisible and compact. As their name implies, transferable eCash enables the transfer of coins between two merchants (e.g. to buy goods) or a merchant and a user (e.g. to give back change) whereas divisible eCash allows a user to split a coin of a large value into a few coins so as to overcome change issues. As for compact eCash system, it enables the user to withdraw a set of N coins at once, and then spend them one by one. In Chapter 5, we introduce a new type of eCash system referred to as private eCash This new type is intended for applications, such as eTicketing, electronic Toll (eToll) as well as Electric Vehicle Charging (EVC), which involve a single entity acting as both merchant and bank. To build our eCash system, we use our partially blind signature scheme introduced in Chapter 4 as the main building block. More precisely, a payment token consists of a partially blind signature on a common information and a value only known to the user. Using this unique and reusable token, a user can settle several expenses of different amounts in an unlinkable way. This work resulted in the paper "Private eCash in Practice" [BBD + 16], published at FC'16.

Chaum also envisioned a prevalent privacy-preserving cryptographic primitive known as anonymous credentials [START_REF] Chaum | Advances in Cryptology: Proceedings of Crypto 82, chapter Blind Signatures for Untraceable Payments[END_REF]. The latter allows users to obtain a credential (i.e. driving license, student ID card, etc.) from an issuer and then, later, prove the possession of this credential, in 1.2. Contributions an unlinkable way, without revealing any additional information. Anonymous credentials have several applications including eCash and electronic voting.

Anonymous authentication and identification protocol for embedded SIM. Next, in Chapter 7, we cope with an issue that has arisen at the GSM Association (GSMA) by designing a privacy-preserving authentication and identification protocol for embedded SIM (eSIM). Our protocol, which is based on the BB-based Pre-DAA scheme proposed in Chapter 4, aims to enable the anonymous authentication and identification of an eSIM to a Mobile Network Operator (MNO) independent entity known as Discovery Server (DS). Thereby, following a change of MNO, an eSIM can be remotely provisioned with its new network profile while preserving the privacy of its owner against a malicious DS. This proposal was patented on November, 2015 [START_REF] Barki | Procédé d'identification anonyme d'un module de sécurité[END_REF].

Coercion-resistant remote electronic voting system. Finally, in Chapter 8, we address the coercion-resistance issue of remote electronic voting which stems from the lack of private polling booths. Thus, a voter can be constrained to cast a given vote or to reveal her voting secret. Based on anonymous credentials, we build an efficient coercion-resistant remote electronic voting scheme that is practical for real polls. Furthermore, using our sequential aggregate MAC scheme detailed in Chapter 4, voters credentials can be efficiently updated so as to enable credentials revocation as well multiple elections. These results have been published in the paper "Remote Electronic Voting can be Efficient, Verifiable and Coercion-Resistant" [START_REF] Araújo | Remote electronic voting can be efficient, verifiable and coercion-resistant[END_REF] at VOTING '16. Chapter 2 In this chapter, we briefly recall some of the main current Machine to Machine (M2M) applications, then we review the typical M2M communication architecture proposed by the European Telecommunications Standards Institute (ETSI). We also provide an overview on a new generation of SIM cards, known as embedded SIM (eSIM), that has been standardized by the GSM Association (GSMA) and which will play a significant role in the overall growth of M2M. Next, we present the most important security issues that M2M devices and communications have to face. Finally, we identify M2M characteristics that make the design of new security schemes a challenging task.

M2M Characteristics and Security Issues

Chapter 2 : M2M Characteristics and Security Issues

M2M Applications

Machine to Machine (M2M) is constantly evolving and covering more and more applications that do not only aim to provide users with more convenience and peace of mind but also save energy and enable a better management of assets, traffic, etc. The applications currently proposed can be classified according to the field of application into five categories, namely Automotive, eHealth, Smart Metering, Smart City and Smart Home as shown in Figure 2.1. As stated in [START_REF] Gsma | From concept to delivery: the M2M market today[END_REF], the automotive sector has attracted a lot of attention which led to the emergence of several automotive applications.

It is worth mentioning that, in all these applications, the communication is bidirectional. In fact, the M2M device does not only monitor some events but also receives information such as updates and controls from the application domain. Nevertheless, the Down Link (DL) traffic from the server to the M2M devices is much lower than the Up Link (UL) traffic and generally consists of short control packets unicasted to an M2M device or multicasted to a group of devices [START_REF] Etsi | Machine-to-machine communications (m2m); functional architecture[END_REF].

Automotive

This category encompasses all applications involving a car or a transportation system. To operate, each vehicle has to be equipped with a communication module which generally includes a Global Positioning System (GPS) and a SIM (or eSIM) card enabling a bidirectional communication.

Here is a list of the main applications.

-Emergency Call (eCall) [START_REF]ecall: automated emergency call for road accidents mandatory in cars from 2015[END_REF][START_REF]3GPP. ecall data transfer; in-band modem solution[END_REF] aims to provide rapid assistance to motorists whenever an accident occurs. Via action of in-vehicle sensors, it automatically triggers an emergency voice call and sends some key information about the accident. The European Commission stated that eCall will be mandatory in cars as of April 2018.

-Electronic Toll (eToll) eliminates the delays and queue lines at tollbooths since it enables users to pay for the toll fares with no need to stop.

-Pay-As-You-Drive (PAYD) is a new kind of customized insurance where the charges are computed based on where, when and how the user drives.

-Fleet Management improves efficiency and allows a better management of assets as it enables continuous track of their position and state.

-Stolen Vehicle Tracking (SVT), also known as Stolen Vehicle Recovery, offers vehicle owners peace of mind as it allows them to track their vehicle if it is ever stolen.

eHealth

eHealth applications enable the remote monitoring of people's health and fitness information through the recording of a set of indicators such as blood pressure and heart rate. To do so, a set of sensors must be worn by the user. Due to their limited resources, these sensors forward the collected data to a gateway, generally a smartphone, which handles their transmission to the remote server where healthcare professionals and users can visualize them. Thus, it is similar to Body Sensor Networks (BSNs) except that the communication is bidirectional and may be a manyto/from-one communication. Hereinafter, we briefly describe the most important applications.

-Remote Patient Monitoring (RPM) enables the remote management of diseases by periodically collecting and reporting patients' physiological vital signs values (e.g. gas, water and electricity).

-Fitness Information Management aims to report the fitness records of the user during exercise in order to subsequently provide him with a feedback.

-Elderly, Children and Herds Tracking enable the localization of children, elderly people and herds as well as the monitoring of their vital signs and activity level.

Smart Metering

As their name implies, these applications are related to smart meters. They aim to enable a better and more efficient management (and use) of water, gas and electricity. In what follows, we detail the main smart metering applications.

-Smart Meters enable both users and resource supplier to remotely read the metering values. Moreover, they allow the remote activation and disabling of supply.

-Smart Grid (SG) [FFK + 11] enables a two-way exchange of energy and information between the power plant and whatever consumes or produces energy. Thereby, the available energy is properly managed with low losses and high levels of quality of supply.

-Electric Vehicle Charging (EVC) allows users to locate the nearest available charging station and book a time slot if needed. So, it can also be considered as an automotive application. Within a Smart Grid, EVC enables a better management of energy as it directs users to certain stations and remotely configures the mode of charging according to the power demand and supply.

Smart City

This category includes "green" applications whose goal is to save energy. To reduce costs, several gateways are deployed all over the relevant area (e.g. a city) in order to aggregate and transmit the data collected by the different sensors.

-Smart Parking provides drivers with an efficient way to quickly find the nearest available parking space. Thereby, it cuts congestion and avoids waste of time and gas.

-Smart Waste Management enables the avoidance of several unnecessary journeys as it sends a notification whenever a container is nearly full.

-Smart Street Lighting enables the setting of the lighting level according to the sensed values.

-Air Pollution Monitoring allows an efficient and continuous measurement of the air quality.

Chapter 2 : M2M Characteristics and Security Issues -Traffic Information enables a driver to be aware of the traffic conditions and warning messages related to the area in which he is driving. Deployed cameras could be used to detect red light violations and even compute cars speed. They can also help automatically manage traffic lights so as to improve the traffic flow in the city.

-Inventory Management optimizes delivery schedules and allows a more efficient re-stocking.

Vending machines and networked printers are good examples showing the benefits of such application.

Smart Home

Smart Home applications, also known as Smart Home, encompasses applications providing customers with more convenience and a higher quality of life by enabling the remote detection or execution of certain tasks.

-Remote Control of Appliances enables the remote or automatic turn on/off of a set of devices as well as the control of their status.

-Intrusion Detection notifies the user whenever someone comes in (or goes out) the relevant area (e.g. an office, a house, etc.) and enables the detection of any risky situation.

-Leak Detection aims to detect gas or water leaks as well as fire.

ETSI M2M Architecture

M2M has attracted the attention of some Standards Development Organizations (SDO). In particular, the ETSI mainly aimed to design a common M2M architecture whose primary goal is to foster the development of network independent applications and ensure the interoperability of M2M services. In this section, we provide an overview of the typical M2M architecture and the corresponding interfaces proposed by the ETSI in the Technical Specifications (TS) 102 690 [START_REF] Etsi | Machine-to-machine communications (m2m); functional architecture[END_REF] and 102 921 [START_REF] Etsi | Machine-to-machine communications (m2m); mia, dia and mid interfaces[END_REF].

High Level Architecture

From a functional point of view, the M2M architecture can be split into three interlinked domains; namely, device domain, network domain and application domain. In what follows, we briefly introduce them.

• Device domain consists of the set of devices involved in M2M applications. Some of these devices are equipped with specific sensing technology as it is the case with body sensors while other devices simply record current values. Once the necessary data is gathered, the M2M device forwards it through the network domain towards the remote server. This domain is also referred to as M2M domain.

• Network domain consists of a set of heterogeneous access networks enabling the device domain and the application domain to communicate. Among these access networks, we note UTRAN, GERAN, satellite, xDSL, WiMAX, WLAN, etc.

• Application domain includes the servers where data collected by the M2M devices or other network nodes are stored. These real-time data is made available to legitimate users through a variety of M2M applications thereby enabling remote monitoring and sending of control instructions to M2M devices. As shown in Figure 2.2, the communication between the M2M device and the network domain is either direct or via a gateway through the use of an M2M area network. The latter provides connectivity between the M2M gateway and the M2M devices by relying on short range wireless technologies such as ZigBee, Bluetooth Low Energy (BLE), etc. To enable direct communication, the M2M device ought to be equipped with a communication module enabling it to access the network via mobile or fixed line and perform authentication, registration and management procedures by itself. If it is not the case, especially when dealing with constrained devices such as sensors, all these procedures are performed by the M2M gateway on behalf of the device.

ETSI M2M Architecture

Service Capability Layer

In TS 102 690 [START_REF] Etsi | Machine-to-machine communications (m2m); functional architecture[END_REF], ETSI provides an M2M architecture with a generic set of capabilities. More precisely, it introduces a Service Capability Layer (SCL) that has been designed to work with REpresentational State Transfer (REST) compliant architecture style. SCL has an important role in the ETSI M2M architecture since it provides functions that are to be shared between the different applications and exposes them in the form of features through a set of open interfaces (e.g., via an API). As it hides the complexity of underlying networks, the SCL simplifies application development thereby fostering the development of network independent new services. It also aims to ensure the interoperability of M2M services and to facilitate the deployment of vertical applications.

Among the defined SCLs, there is a service capability layer called SEC (for security) which handles the M2M service bootstrapping and the key establishment. Generic Communication (GC) is another service capability responsible for securing data exchanges and application delivery. There must exists an SCL in both device and network/application domains. In the device domain, the SCL is either inside the M2M device itself (DSCL for Device SCL) or within the gateway (GSCL for Gateway SCL) as shown in the figure 2.3. The SCL within the network/application domain is referred to as NSCL for Network SCL.

M2M Interfaces

To enable communications between the different M2M entities, four different interfaces have been introduced [START_REF] Etsi | Machine-to-machine communications (m2m); functional architecture[END_REF] (see Figure 2.3). They are defined as follows:

• dIa is the interface linking the application and the SCL located in the device domain (except for the case 3 where the SCL is in the network domain). As it is shown in Figure 2.3, we may have three scenarios. In the first case, the Device Application (DA) and the Service Capability Layer (DSCL) are within the same device. While in the second, there is no service capability implemented in the device and this latter resides in the gateway (GSCL).

Chapter 2 : M2M Characteristics and Security Issues

In the third case, which is used when dealing with non-ETSI compliant devices, the dIa connects the DA and the NSCL.

• mId is the interface linking two service capabilities, one residing in the network domain (NSCL) and the other in the device or the gateway domain DSCL/GSCL.

• mIa is the interface between the NSCL and the application residing in the network domain, referred to as Network Application (NA). The functions supported by the NSCL are exposed to the network application via this interface.

• mIm is an inter-domain interface which enables two NSCLs located in two different network domains to communicate. To illustrate the role of each of these entities, we consider the case of a Smart Home owner who would like to remotely turn on his heater. To do so, through his mobile phone, he accesses the NA and sends the request to the NSCL which, in its turn, will forward it to the corresponding GSCL to finally be received by the DA residing in the heater. Note that all these exchanges are imperceptible to the user.

ETSI Key Hierarchy

Along with the M2M architecture and the corresponding interfaces, the ETSI standardization body also proposed a key hierarchy where each set of provisioned M2M device/gateway holds an M2M root key (K mr ). There are three different ways enabling the provisioning of the root key to the M2M device or gateway. The first consists in pre-provisioning it in a secure manner during manufacture or deployment whereas, in the second, the root key is derived from mobile network authentication credentials based on the Authentication and Key Agreement (AKA) protocol using either Generic Bootstrapping Architecture (GBA) [START_REF]3GPP, 3rd Generation Partnership Project. Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture[END_REF] or Extensible Authentication Protocol (EAP) [START_REF] Aboda | Extensible Authentication Protocol (EAP)[END_REF] based procedures. In the last case, the M2M root key is provisioned in an access network independent procedure through the use of either EAP over Protocol for carrying Authentication for Network Access (PANA) [IET08] or Transport Layer Security (TLS) [START_REF] Rescorla | Transport Layer Security (TLS) Renegotiation Indication Extension[END_REF] over the Transmission Control Protocol (TCP). From the root key, an M2M connection key (K mc ) is derived. The K mc key is used to secure the mId interface which links the DSCL/GSCL and the NSCL. At each new M2M service connection procedure, a new K mc key is calculated.

Unfortunately, ETSI architecture has not been widely adopted and it does not seem like it is going to happen any time soon. In fact, the M2M market is still highly fragmented with several vertical solutions designed in a separate and independent way.

Embedded SIM

The GSM Association (GSMA) also looked into potential M2M issues and more precisely into the problem of provisioning SIM cards, that are soldered in the M2M device, with their new subscription profiles. This led to the design of a new generation of SIM cards, called embedded SIM, that we introduce in the following section.

Embedded SIM

Some M2M devices, like smart meters for example, are not designed in a way enabling the removal or replacement of the SIM card. In fact, the SIM is either hardly accessible or even soldered into the M2M device at its manufacture. Besides, in use cases such as vending machines where a large number of devices are deployed in different locations, the replacement of all SIM cards following the change of network operator subscription can be quite costly. These two cases raised a new issue: how can one change the subscription associated to a SIM card while keeping the same chip and level of security as classical SIM cards. To tackle this problem, the GSMA designed a new generation of SIM cards known as embedded UICC (eUICC) or embedded SIM (eSIM) along with an architecture for Over-The-Air (OTA) remote SIM provisioning. Thereby, an eSIM can be remotely provisioned with its new network profile at every change of subscription or device ownership. Hereinafter, we give an overview on the eUICC and remote SIM provisioning architectures as well as the registration notification, profile generation and download procedures.

eUICC Architecture

The particular features of an eUICC are essentially its support of a remote provisioning functionality and its capability to store several Mobile Network Operator (MNO) profiles as shown in Figure 2.4. Though an eSIM may contain many profiles, only one profile can be enabled at a time and the eSIM behaves as if it contains no other profile. When a profile is active, the device can connect to the MNO defined in this profile. The different profiles may be classified in three main categories:

-Test profile which can only be used when the device is in test mode.

-Provisioning profile is automatically enabled in the cases where no other profile is enabled.

It aims to provide connectivity for the sole purpose of downloading a new operational profile. Once done, it is automatically disabled.

-Operational profile is a conventional profile that includes, amongst other, a Network Access Application (NAA) enabling the eUICC registration to the Mobile Network (MN) as well as associated security credentials (secret keys, algorithms, certificates, etc). From a user and device perspective, an operational profile can be seen as a profile of a classical SIM card (i.e. it has the same structure and functions as a regular SIM card).

Each eUICC profile is installed within a distinct Security Domain (SD) [START_REF]GlobalPlatform Card Specification V2.3[END_REF] known as Issuer Security Domain Profile (ISD-P) and uniquely identified by its Integrated Circuit Card Identifier (ICCID). A profile ICCID is equivalent to the ICCID of a classical UICC [START_REF] Etsi | Smart Cards; UICC-Terminal interface[END_REF]. An additional identifier, referred to as Embedded UICC Identifier (EID), is used as the unique physical identifier of the eUICC. The EID, which is not modifiable, plays a significant role in the remote SIM provisioning architecture described below. Note that, in this section, we only provide the information necessary to clearly understand our proposal described in Chapter 7. For more details about the eUICC architecture, we refer the reader to [START_REF]SGP.02 Remote Provisioning Architecture for Embedded UICC[END_REF][START_REF]SGP.22 Remote SIM Provisioning Technical Specification[END_REF].

GSMA Remote SIM Provisioning Architecture

To enable the remote provisioning of an eSIM with its new operational profile, the GSMA introduced a functional architecture [START_REF]SGP.01 Embedded SIM Remote Provisioning Architecture[END_REF]GSM16b] called remote SIM provisioning architecture as well as its corresponding technical specifications [START_REF]SGP.02 Remote Provisioning Architecture for Embedded UICC[END_REF][START_REF]SGP.22 Remote SIM Provisioning Technical Specification[END_REF]. This architecture involves five main entities, namely the eUICC, the MNO, the eUICC Manufacturer (EUM), the Subscription Manager-Data Preparation+ (SM-DP+) and the Subscription Manager-Discovery Server (SM-DS). In what follows, we briefly introduce each entity and its role within the remote SIM provisioning architecture illustrated in Figure 2.5.

-eUICC Manufacturer (EUM): it is the entity responsible for the issuance of eUICCs.

It must also provide each manufactured eUICC with a certificate that will subsequently enable it to be authenticated.

-eUICC: it is uniquely identified by its eUICC Identifier (EID) and can hold several profiles. It also contains a set of Local Profile Assistant (LPA) Services which provide access to the data and services required by the LPA functions. They consist of a Local User Interface (LUI), a Local Profile Download (LPD) and a Local Discovery Service (LDS). More precisely, the LUI enables the user to perform local profile management whereas the LDS is responsible for the retrieval of notifications sent by the SM-DP+ and stored in the SM-DS. If a profile package is available for a given eUICC, it is the LDP that handles its download from the SM-DP+. As shown in Figure 2.5, depending on the implementation, the LPA functions may be either in the eUICC itself or in the device containing the eUICC. In the sequel, for the sake of clarity, we will use the term LPA to refer to either LPD, LUI or LDS.

-Mobile Network Operator (MNO): whenever the user takes out a new subscription or changes the one associated to an eUICC, the MNO orders the SM-DP+ to generate or manage the corresponding profile.

-Subscription Manager-Data Preparation+ (SM-DP+): it is responsible for the creation, management and protection of profiles upon the request of the MNO. It must also ask for the creation of the target ISD-P in the eUICC and handle the secure delivery of the profile through the LPA. Furthermore, when there is a pending action (profile download or management) for a specific eUICC, it ought to transmit a notification along with the associated EID to the SM-DS. -Subscription Manager-Discovery Server (SM-DS): it is an MNO-independent third party that mainly aims to respond to LPA requests asking whether there is a pending action for a given eUICC or not. Besides, in the cases where the eUICC is not configured with a default SM-DP+, the SM-DS allows the eUICC (in particular, its LPA) to determine which SM-DP+ holds its new profile. Sometimes, a default SM-DS may not be configured in the eUICC either. If so, the logical location of the default SM-DS is recovered based on the eUICC Identifier (EID).

Procedures Description

In what follows, we briefly review the procedures that are chronologically triggered, whenever the user takes out a new subscription, in order to provide the corresponding eUICC with its new network profile.

1. Protected Profile Generation Procedure: it is the first procedure that the MNO triggers further to a new subscription. More specifically, the MNO provides the SM-DP+ with the profile description and asks it to generate and securely store the corresponding profile as shown in Figure 2.6-(1). Once the profile is created, the SM-DP+ informs the MNO, which registers the profile in its operator system.

2. Notification Registration Procedure: once the profile is generated, the SM-DP+ transmits a notification registration to the SM-DS. It mainly consists of the EID of the target eUICC, the address of the SM-DP+ and a unique identifier (Notification-ID). Upon receiving this notification, the SM-DS stores it and acknowledge its receipt (see Figure 2.6 -(2)).

3. Discovery Request Procedure: if there is no SM-DP+ address configured in the eUICC, the LDS triggers the discovery request procedure by sending a request to the eUICC. Upon its receipt, the eUICC generates an eUICC authorisation (that will enable its authentication to the SM-DS) using its private key. It is transmitted along with the address of the default SM-DS and the eUICC identifier (EID) to the LDS. These latters are forwarded to the

Store Notification

Conf irm Registration 5. Notification De-Registration Procedure: once the eUICC downloads its new profile, the SM-DP+ triggers this procedure so that the SM-DS can discard notifications that are not useful anymore (see Figure 2.6 -(4)).

← ----------------------- (4) Notification De-Registration Procedure SM-DP+ SM-DS Send De-register N otif ication ------------------------→ Delete relevant notification Conf irm De-registration ←-----------------------
(

) Discovery Request Procedure eUICC LDS SM-DS SM-DP+ Discovery Request ←------------------ Create Authorisation Send Authorisation, EID, -------------------→ def ault SM -DS address SM -DP + Request --------------→ Check Authorisation SM -DP + address ← -------------- ←-M utual 3

M2M Security Issues

Although M2M have not induced new threats, it has however amplified the existing ones since, in the case of M2M applications, these threats may not only lead to financial losses but could also jeopardize human lives (e.g. if an attacker alters the information transmitted by the eCall application or a sensor in the case of eHealth applications). Indeed, as they rely on the fusion of heterogeneous networks, M2M communications have to cope with all the security threats of other network-based communications. Besides, similarly to Wireless Sensor Networks (WSNs), M2M devices are generally deployed in reachable locations and expected to operate for extended periods. This makes them particularly vulnerable to several physical attacks conducted against 2.4. M2M Security Issues the device hardware and software [CSS + 09]. Furthermore, sensed data, which are forwarded to a remote server through wireless or wired networks, may also be subject to several threats. Last but not least, attacks against the proper functioning of the system can also be performed.

In this section, we present the main threats against M2M communications and devices while classifying them in three categories depending on the targeted entity; namely the M2M device, the proper functioning of the system or the exchanged data. These categories are respectively referred to as physical, logical and data attacks. One can also classify the potential attacks as active or passive according to whether they disrupt the operations of M2M applications or not.

Physical Attacks

This first category includes the different attacks that target the physical layer as well as M2M devices hardware and software. Hereinafter, we describe the most important ones.

-Side channel attacks [START_REF] Lawson | Side-channel attacks on cryptographic software[END_REF]: M2M devices are generally deployed in reachable locations where adversaries can easily access them and perform side channel attacks. These attacks could be based on either power consumption, timing information, fault or electromagnetic leaks. Using one (or a combination) of these techniques, the attacker's goal consists in recovering the user's secret key. In fact, if he manages to retrieve the key used to encrypt exchanged information, he would be able to decrypt all the exchanged data.

-Software modification and malwares: Software modifications can be performed by an adversary, or even a malicious user, so as to alter the proper operations of the M2M device and service. Malicious users may do so to reduce the amount of charges that they have to pay. Such misbehaviour could be noticed when dealing with smart metering or eToll applications. Note that these attacks may be conducted even without physical access to the M2M device since software updates can be performed Over The Air (OTA). The impact of such threats worsens when it comes to eHealth or automotive applications especially if the adversary succeeds in taking the control of the device.

-Destruction or theft of the M2M device: As they are deployed in reachable locations, M2M devices (or the SIM cards included within them) can be easily stolen or destroyed. It is, however, worth mentioning that the stealing of eSIMs is not possible as they are generally welded to the M2M device (see Section 2.3).

Logical Attacks

This category encompasses attacks that may target the proper functioning of the system without making any changes to the device software. In what follows, the most significant threats are briefly described.

-Impersonation: An adversary may try to spoof the identity of any of the entities involved in an M2M application (i.e. back-end server, M2M device or a gateway and so forth). Such attack may lead to important financial losses and could even endanger human lives (e.g. eHealth applications). Indeed, an adversary who succeeds in spoofing a smart meter identity can make its owner pay for the adversary's charges. It is even worse if the adversary manages to impersonate the server as he would be able to remotely control the associated M2M devices. Through identity spoofing, the adversary can also launch other attacks (e.g. spread malwares) and cause Denial of Service as explained in what follows.

-Denial of Service (DoS) [START_REF] Yu | Fool me if you can: Mimicking attacks and anti-attacks in cyberspace[END_REF]: Most M2M devices are battery powered. Thus, an adversary may cause application failure by repeatedly broadcasting meaningless packets that will prematurely drain the device battery. Such attacks may be conducted, for example, when dealing with intrusion detection applications in order to prevent the user from being notified. Furthermore, DoS attacks may also intend to cause the unavailability of resources.

For most applications, this may lead to significant financial losses and it can even result in blackouts when dealing with smart grid. Note that all the involved entities may be subject to a DoS attack whether it be the device, the gateway, the underlying infrastructure or even the remote server.

-Relay attacks: An adversary may conduct a relay attack to make an entity believe that it is in the vicinity of the sender or receiver. This attack may target the device, gateway or the network domain. Adversaries generally use such an attack in order to get the response corresponding to a given challenge. It may be a challenge sent by a user's smart lock, for example. By providing a correct answer to the challenge, the adversary unlocks the smart lock and can thus access the user's home.

Data Attacks

This category includes the threats that may target the exchanged information. Among the main attacks, we note privacy attacks, data modification and false information injection as well as selective forwarding/interception presented below.

-Eavesdropping: It is a passive attack (i.e. the effective operations of an M2M application are not disrupted) during which the attacker attempts to learn sensitive information. Usually, such an attack is difficult to detect. Besides, the large amount of data exchanged by M2M applications encourages attackers to eavesdrop communications as collected data could be used for commercial or fraud purposes.

-Privacy attacks [START_REF] Jawurek | Sok: Privacy technologies for smart grids -a survey of options[END_REF]: Owing to the pervasiveness of M2M devices and applications, malicious parties can invade user's privacy by linking M2M devices or the transiting information to individuals. This may enable the disclosure of personal information such as habits, health condition, religion, and so forth. Indeed, if the device Media Access Control (MAC) address indicates that it is a heart monitoring device, for example, then the adversary will know that its owner suffers from heart problems. Furthermore, some applications such as Pay-As-You-Drive (PAYD) insurance or electronic Toll (eToll), which keep a record of user's localization information, entail serious privacy concerns as they enable the adversary (which could be the service provider) to track users' journeys.

-Data modification and false information injection: Gathered information can be compromised during its transmission as well as at rest on a device or an application server. If we consider the case of eHealth (respectively eCall applications), the modification of measured values (localization information) can endanger people's lives. As regards to false data injection attacks [START_REF] Yu | False data injection attacks in smart grid: Challenges and solutions[END_REF], they mainly cause financial losses. Further to a fake eCall, for example, the emergency services would be called upon and get to a place without real need.

-Selective forwarding/interception: An adversary may intercept and delay or drop some of the transmitted packets. The impact of such a threat depends on the content of the dropped packets. If the dropped information originates from a sensitive application, such as eHealth or eCall, the impact of such a threat can be quite significant.

Security Requirements

To prevent the threats that M2M communications and devices may face, a set of security properties should be guaranteed. They mainly consists of:

M2M Characteristics and Key Challenges

-Authentication: it may refer to either entity authentication or data origin authentication. More precisely, entity authentication enables communicating parties to check that the other entity is really who it claims to be whereas data origin authentication, as it name implies, ensures that a message really originates from a given entity.

-Confidentiality: it protects the content of gathered as well as exchanged information by preventing them from being read by unauthorized entities such as eavesdroppers.

-Device and Data Integrity: it keeps devices as well as, transiting and stored, data from being altered by any illegitimate entity.

-Availability: it ensures that authorized entities can always have access to a given information (or application) whenever needed.

-Non-repudiation: it makes sure that an entity cannot subsequently falsely deny a given action (e.g. sending a packet, triggering a given command, etc).

-Privacy: it prevents the disclosure of any sensitive or personal information such as habits and health status.

The different cryptographic primitives aiming to ensure at least one of these properties will be detailed further on (see Section 3.3).

M2M Characteristics and Key Challenges

Withstanding the security threats listed above is by no means an easy task owing to the different characteristics and challenges of M2M communications and devices. Indeed, the specific nature of M2M networks generally comprising thousands of devices, that are left unattended and expected to operate for several years, makes securing them a tricky task. Among these challenges, we identify the following:

-Scalability: A top concern when dealing with M2M communications is scalability. Indeed, the produced data as well as the network traffic will rise as the number of devices increases, thus leading to scalability issues. Let us consider, for example, the case of several devices trying to simultaneously perform network authentication. Since current mobile technologies have not been designed to withstand such a large number of devices, this would probably entail network congestion. Therefore, the design of scalable authentication mechanisms is crucial particularly in the case of real-time applications. Furthermore, some applications (e.g. city automation) involve a large number of M2M devices that usually secure their communications using the same key. In such case, a scalable key management scheme that enables the establishment/update of the shared key following membership changes (join/leave of devices) is required. In contrast, in the case of pairwise keys, a large number of keys has to be stored (i.e. a distinct key associated to each device). An efficient M2M security scheme ought to achieve a better trade-off between performances, security and number of required keys.

-Devices heterogeneity: Devices capabilities in terms of processing and energy vary a lot, ranging from very resource constrained devices such as sensors and actuators to more powerful devices like smartphones. Thus, when designing a security mechanisms, one must take into account the characteristics of the different devices. It would be even better if the designed scheme could leverage the capabilities of more powerful devices.

Chapter 2 : M2M Characteristics and Security Issues -Resource constraints: Due to their low cost, most M2M devices suffer from resource constraints (energy, storage and computing). These constraints make both energy efficiency and lightweight design fundamental features of any scheme aiming to secure M2M communications.

-Various types of end-to-end communications: The end-to-end communication differs from an M2M application to another. Indeed, we may have one-to/from-one, one-to/frommany as well as many-to/from-many communications. Thus, the security mechanisms must be suitable for both peer-to-peer and group communications.

-Delay constraints/real-time communication: Some M2M applications such as eHealth or eCall are life-critical and thus sensitive to delay. Therefore, the set-up of a security mechanism must not impact the Quality of Service (QoS) of the corresponding applications.

-Limited bandwidth: Given bandwidth scarcity and the expected number of M2M devices, the additional overhead related to, e.g., the key generation and authentication mechanisms should be minimized to the fullest extent possible.

-Access Control: Within the same application, we may have two or more stakeholders with different access rights. It is, therefore, essential to limit access to gathered data to only authorized stakeholders (i.e. one should not be able to read any data that he is not allowed to).

-Robustness: The M2M devices are sometimes deployed in unreachable areas which requires the security mechanisms to be fault tolerant. Moreover, in other cases, M2M devices may be easily accessible by malicious parties. Consequently, tamper resistant hardware is recommended for certain applications. It is obvious that the characteristics and requirements of M2M applications make the design of a security scheme a challenging task. Unfortunately, it does not seem feasible to set up a solution that is suitable for all the applications due to their different characteristics and requirements as shown in Table 2.1. It is worth emphasizing that the availability of the application and integrity of exchanged data are always required. Confidentiality is also essential except when dealing with some smart city applications such as air pollution monitoring. Besides, almost all devices suffer from limited computational resources.

It is also noteworthy to mention that applications characteristics vary a lot depending on the scenario. Let us, for example, consider smart metering applications. Indeed, water and gas meters are subject to energy constraints while it is not the case of electricity smart meters as they are connected to the mains supply. Similarly, some fleet management applications require 2.7. Conclusion privacy-preserving solutions (e.g. when dealing with car rental). Nevertheless, it is not the case of all fleet management applications (e.g. public transport vehicles).

Conclusion

In this chapter, we first presented the most important M2M applications. Then, we reviewed both ETSI M2M architecture as well as the eSIM concept and the associated remote SIM provisioning architecture proposed by the GSMA. We also addressed the challenges and threats that arise when dealing with M2M communications and devices along with M2M characteristics that makes it challenging to design new security schemes. Due to the heterogeneity of devices and the different requirements associated to each application, a single security solution cannot be both optimal and suitable for all applications.

In this thesis, we focus on M2M devices that include a SIM card and more precisely on two security properties, namely authentication and privacy. Before detailing the designed cryptographic primitives and protocols, we introduce, in the following chapter, the main mathematical tools and building blocks required all along this thesis. In this chapter, we introduce the main mathematical tools and cryptographic building blocks used in this thesis. We start by presenting groups and fields as well as the classical computational assumptions upon which we rely to prove the security of our proposed schemes and protocols. Then, we define the concept of provable security and some of the widely used security models. Finally, we formally present the necessary cryptographic primitives while briefly recalling the cryptographic schemes that we will use to design our new schemes and protocols. - - -1 G ∈ H.

Preliminaries

Associativity: ∀ (x, y, z) ∈ G 3 , (x • y) • z = x • (y • z).
Inverse: ∀ x ∈ G, ∃ y ∈ G such that x • y = y • x = e.
-∀ (x, y) ∈ H 2 , x • y ∈ H. -∀ x ∈ H, x -1 ∈ H.
For simplicity, in the sequel, the group (G, •) will be denoted by G. Any subgroup of a group is itself a group.

Definition 3.3.

-Commutativity: A group G is abelian or commutative if the binary operation is commutative i.e. ∀(x, y) ∈ G 2 , x • y = y • x.

-Subgroup generated by an element: Let x be an element of the group G, the set {x n , n ∈ Z}, denoted by x , is called the subgroup generated by x

-Cyclic group: A group G is cyclic if G is generated by a single element i.e. ∃x ∈ G such that G = x . x is called generator of G.
-Finite group: A group G is finite if G, as a set, is finite.

-Order of a group: The number of elements of a finite group G, denoted by |G|, is called the order of G.

-Order of an element: The order of an element x of a group G, denoted by |x|, is, when the subgroup x is finite, the order of this subgroup i.e. the least positive integer n such that x n = 1.

Any group of prime order is cyclic and any element x ∈ G other than 1 G is a generator of G. Throughout this thesis, we only consider abelian finite groups for which the multiplicative notation (binary operation •) is frequently replaced by the additive notation (binary operation +) and 1 G is replaced by 0 G .

Fields

Definition 3.4 (Ring). A ring (A, +, •) consists of a nonempty set A and two binary operations + : A × A → A and • : A × A → A satisfying the following properties.

-(A, +) is an abelian group.

-Multiplicative associativity:

∀ (x, y, z) ∈ A 3 , (x • y) • z = x • (y • z).
-Distributive multiplication over addition:

∀ (x, y, z) ∈ A 3 , x • (y + z) = x • y + x • z and (x + y) • z = x • z + y • z If (A, +, •
) is also multiplicatively commutative, then it is called a commutative ring. (A, +, •) is said to be unitary if it includes an identity element 1 A for the binary operation "•" that is different from the identity element 0 A of the binary operation "+".

Preliminaries

Definition 3.5 (Field). A field (K, +, •) consists of a nonempty set K and two binary operations + : K × K → K and • : K × K → K satisfying the following properties.

-(K, +, •) is a unitary ring.

-Multiplicative inverse:

Let K * denote K\{0 K }. ∀ x ∈ K * , ∃ y ∈ K * such that x•y = y•x = 1 K .
y is unique and denoted by x -1 .

A field (K, +, •) is finite if K is a finite set. As a result, K * , •) is a group. |K|, the number of elements of K, is the order of the field. If (K, +, •) is commutative as a ring, then it is called a commutative field. A field characteristic is, when it exists, the smallest positive integer n such that 1 + 1 + . . . + 1 n times = 0. If there is no such n, then the field is said to have a characteristic equal to 0. Any finite field (K, +, •) also called Galois field, satisfies the following properties:

-(K, +, •) is commutative.
-The multiplicative group (K * , •) is cyclic.

-The order of (K, +, •) is a power of a prime. This means that it is of the form p n where p is the characteristic and n is an integer such that n ≥ 1. Conversely, for each prime integer p and any positive integer n ≥ 1, there exists exactly one (up to an isomorphism) finite field (K, +, •) such that |K| = p n . Such a field is denoted by F p n . Thus, if p is prime,

F p = Z p .
It is however noteworthy to mention that F p n = Z p n when n > 1 as Z p n is not a field.

Elliptic Curves

During the eighties, Miller [START_REF] Victors | Use of elliptic curves in cryptography[END_REF] and Koblitz [START_REF] Koblitz | Elliptic curve cryptosystems[END_REF] independently introduced Elliptic Curve Cryptography (ECC) whose security relies on the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP). ECC has attracted a lot of attention as it provides the same security levels as non-ECC cryptography but with much smaller parameters such as key and modulus sizes. Hence, it enables memory and energy savings as well as faster computations. Since it requires less resources, it is better suited for resource constrained environments such as smart cards.

Definition 3.6 (Elliptic Curve over a finite field). An elliptic curve E over a finite field F p n consists of a point at infinity O along with the set of pairs (x, y) verifying the following Weierstrass equation:

E : y 2 + a 1 xy + a 3 y = x 3 + a 2 x 2 + a 4 x + a 6 where a 1 , a 2 , a 3 , a 4 , a 6 ∈ F p n
If the prime number p = 2, 3, the Weierstrass equation can be simplified as follows:

y 2 = x 3 + a • x + b where (a, b) ∈ F 2 p n and 4a 3 + 27b 2 = 0.
The condition 4a 3 + 27b 2 = 0 ensures that the curve is non-singular. In particular, this means that we can compute the tangent at every point, except O, to the curve. Otherwise, the curve is said singular.

From an algebraic point of view, an elliptic curve is an abelian group with the point at infinity O defined as the identity element and the addition operation, denoted +, defined as follows.

Definition 3.7 (Addition law). Let P and Q be two different points on the elliptic curve E(F p n ).

-The inverse of P = (x P , y P ) = O is denoted by -P whose coordinates are (x P , -y P ) ∈ E(F p n ). Additionally, -O = O, P + OP and O + P = P . -If P = -Q, the line through P and

Q intersects the curve E in a third point R = (x R , y R ) ∈ E(F p n ) \ O.
-R is equal to the sum of P and Q (see Figure 3.1).

One can easily show that the addition law verifies all the required properties and that (E(F p n ), +) is an abelian group. The addition law of the group (E(F p n ), +) can also be described algebraically. The sum of the points P = (x P , y P ) = O and

Q = (x Q , y Q ) = O is the point R = (x R , y R ) with x R = λ 2 -x P -x Q and y R = λ(x P -x R ) -y P
where λ is defined as:

-λ = y Q -y P x Q -x P if P = ±Q and P, Q = O -λ = 3x 2 P +a 2y P if P = Q and P = O 3.1.1.

Bilinear Maps

Bilinear maps, also known as pairings, first came to prominence in 1991 with the famous attack of Menezes, Vanstone and Okamoto [MVO91, MOV93], known as MOV reduction, where they were used to solve the elliptic curve discrete logarithm problem on some elliptic curves E(F p k ) having a small so-called "embedding degree" k. Later, in 2000, Joux [START_REF] Joux | A one round protocol for tripartite diffie-hellman[END_REF] presented the first positive application (for cryptographic rather than cryptanalytic purposes) of bilinear maps. Indeed, he proposed a one-round 3-party Diffie-Hellman key agreement protocol that relies on the use of bilinear maps. Following the work of Joux, many cryptographers started investigating the possibility of using bilinear maps. This led to the design of several revolutionary and powerful cryptographic schemes such as the Identity Based Encryption scheme of Boneh and Franklin [START_REF] Boneh | Advances in Cryptology -CRYPTO 2001: 21st Annual International Cryptology Conference[END_REF] and the short signature scheme of Boneh, Lynn and Shacham [START_REF] Boneh | Advances in Cryptology -ASIACRYPT 2001: 7th International Conference on the Theory and Application of Cryptology and Information Security Gold Coast[END_REF]. Hereinafter, we provide a formal definition of a bilinear map.

Definition 3.8 (Bilinear Map). Let G 1 , G 2 and G T be multiplicative cyclic groups of prime order p. We say that the function e : G 1 × G 2 → G T is a bilinear map if it satisfies the following properties:

3.1. Preliminaries -Bilinearity: ∀g ∈ G 1 , g ∈ G 2 and a, b ∈ Z p , e(g a , gb ) = e(g, g) ab .

-Non-degeneracy:

∀g ∈ G 1 and g ∈ G 2 , if e(g, g) = 1 G T then g = 1 G 1 or g = 1 G 2 .
-Computability: The mapping e is efficiently computable. (We will define "efficiently computable" in Section 3.1.2.2).

A pairing is called

symmetric if G 1 = G 2 .
Otherwise, it is said to be asymmetric. Note that G 1 and G 2 are always isomorphic. Two examples of well-known pairings are the Weil [START_REF] Weil | Sur les fonctions algébriques de constantes finies[END_REF] and Tate pairings [START_REF] Rück | A remark concerning m-divisibility and the discrete logarithm in the divisor class group of curves[END_REF].

Usually, the groups G 1 , G 2 and G T are chosen as follows. G 1 and G 2 are subgroups of an elliptic curve whereas G T is a subgroup of a finite field. A careful choice of the elliptic curve enables an efficient and secure implementation of pairings. Galbraith, Paterson and Smart [START_REF] Galbraith | Pairings for cryptographers[END_REF] classified bilinear maps in three types depending on the existence (or not) of computable isomorphism(s) between G 1 and G 2 :

-Type I : There exist two efficiently computable isomorphisms φ 1 :

G 1 → G 2 and φ 2 : G 2 → G 1 .
-Type II : There exists an efficiently computable isomorphism from φ : G 1 → G 2 but none in the reverse direction.

-Type III : There is no efficiently computable isomorphism between G 1 and G 2 in either direction.

Type III pairings are known to provide better performances than type I and type II pairings. Besides, in type III pairings, several computational assumptions hold while it is not the case with type I or type II pairings.

Basic Functions and Complexity Definitions

In this section, we briefly recall some basic complexity definitions and present some particular functions widely used in cryptography such as hash functions.

Turing Machines

In 1936, Alan Turing introduced a machine known today as Turing machine [START_REF] Turing | On computable numbers, with an application to the Entscheidungsproblem[END_REF]. These machines can simulate any computer algorithm regardless of its complexity. To date, they have been the most widely used model of computation in both computability and complexity theory. Roughly speaking, a Turing machine consists of:

-A tape, that extends infinitely to the right, divided into cells. Each cell stores a symbol belonging to a finite set called the tape alphabet and which contains a blank symbol.

-A tape head that can move along the tape (to the right or, if possible, to the left), one cell per move. It can also read the cell it is currently scanning and replace the cell symbol by another one.

-A finite set of states which contains three special states, namely a start state, an accept state, and a reject state.

-A finite set of instructions. Depending on its current state and the symbol it is reading, the "tape head" writes a new symbol in the cell it is scanning (which may be the same symbol), moves to the left or to the right (or possibly stays at the current cell), and enters a new state.

Chapter 3 : Mathematical Tools and Cryptographic Building Blocks More formally, a Turing machine is defined as follows.

Definition 3.9 (Turing Machine). A Turing machine is a 7-tuple T = (Σ, Q, σ, δ, ∆, q 0 , F) where -Σ is a finite and non-empty set of alphabet symbols.

-Q is a finite and non-empty set of states.

-σ : Q × Σ → Σ is the writing function.

-δ: Q × Σ → Q is the state changing function.

-∆: Q × Σ → {L, R} is the transition function where L is a left shift and R is a right shift.

-q 0 ∈ Q is the initial state.

-F ⊂ Q is the set of final states.

For a given input x, a Turing machine can have several types of complexity classes. In this thesis, we mainly focus on time complexity, denoted by T M (x), which is commonly estimated through the total count of the number of Turing machine steps from the initial to the final state.

Basic Complexity Definitions

An algorithm A is said to be of polynomial time complexity if there exists a polynomial p(.) such that, given any input x ∈ {0, 1} * , the running time of A is upper bounded by p(|x|) where |x| is the size of the input x. More formally, polynomial time complexity is defined as follows.

∃n 0 ∈ N, ∃c ∈ N * , such that ∀n ≥ n 0 , T M (n) ≤ n c
In the complexity theory framework, if an algorithm A is of polynomial time then it is considered as efficient and a problem is said to be hard if there is no known polynomial time algorithm that can solve it. Definition 3.11 (Negligible Function). A function : N → R is negligible if it vanishes faster than the reciprocal of any polynomial. That is,

∀c > 0, ∃k 0 > 0 such that ∀k ≥ k 0 , (k) < 1 k c
Thereby, we get the following two definitions of negligible and overwhelming probabilities. Definition 3.12 (Negligible Probability). Let P be a probability that depends on a positive integer k (the security parameter). P is said to be negligible if it is a negligible function of k. Definition 3.13 (Overwhelming Probability). A probability P is said to be overwhelming if the probability 1 -P is negligible.

Preliminaries

One-way Function

One-way functions are a fundamental tool for cryptography. They are easy to compute in one direction but hard to invert. More formally, a one-way function is defined as follows.

Definition 3.14 (One-way Function). Let f : {0, 1} * → {0, 1} * be a function. f is said to be a one-way function if it satisfies the following two properties:

-Efficiency: There exists an efficient algorithm that, given any x ∈ {0, 1} * as input, outputs f (x).

-Hardness to invert: There is no efficient algorithm that can invert f . More formally, for any efficient algorithm A (also known as adversary), it holds that, for all sufficiently large k, the following probability is negligible.

Pr[x ← {0, 1} k ; y ← f (x); x ← A(1 k , y) : f (x ) = y]

Hash Function

A hash function is a special one-way function that maps input strings of arbitrary length {0, 1} * to short fixed length output strings {0, 1} k where k is a security parameter. A specific kind of hash functions known as cryptographically secure hash functions is widely used in cryptography.

Compared to ordinary hash functions, these hash functions ensures some additional security properties and can be defined as follows.

Definition 3.15 (Cryptographically secure hash function). A hash function H : {0, 1} * → {0, 1} k , where k is a security parameter, is said to be cryptographically secure if it meets the following three properties:

-Pre-image resistance (one-way): Given y ∈ {0, 1} k , the probability that an adversary finds a value x such that H(x) = y is negligible. That is, the following probability is negligible.

Pr[y ← {0, 1} k ; x ← A(1 k , y) : y = H(x)]
-Second pre-image resistance: Given x ∈ {0, 1} * , the probability that an adversary finds a value x = x such that H(x) = H(x ) is negligible. That is,

Pr[x ← {0, 1} * ; x ← A(1 k , x) : H(x ) = H(x) and x = x]
is negligible. This property is also known as weak collision resistance.

-Collision resistance: The probability to find two distinct values x,x ∈ {0, 1} * such that

H(x) = H(x ) is negligible. That is, Pr[(x , x) ← A(1 k ) : H(x ) = H(x)]
is negligible. This property is also known as strong collision resistance.

Several hash functions have already been proposed such as MD5, SHA1, SHA256 and SHA3. However, only few of them are still considered as cryptographically secure. In this thesis, only cryptographically secure hash functions are used.

Chapter 3 : Mathematical Tools and Cryptographic Building Blocks

Pseudo-Random Function

A function is called pseudo-random if there exists no efficient algorithm that can distinguish between the output of this function and a random value.

Definition 3.16 (Pseudo-random function family). Let m and l be two polynomial functions, k a security parameter and R k the set of functions:

{0, 1} m(k) → {0, 1} l(k)
The family F k = {F s } s∈{0, 1} k is defined as the set of functions with an index s (F k ⊆ R k ). F k is called a pseudo-random function family if it satisfies the following two properties:

-Efficiency: ∀ s ∈ {0, 1} k and x ∈ {0, 1} m(k) , there exists an efficient algorithm F such that F (s, x) = F s (x).

-Pseudo-randomness: For any adversary A such that the number of its requests to F is polynomially limited, the following probability (where

R ∈ R k ) is negligible. |Pr[x ← {0, 1} m(k) : A(F s (x)) = 1] -Pr[x ← {0, 1} m(k) : A(R(x)) = 1]|

Computational Hardness Assumptions

In this thesis, we rely on a set of classical computationally hard assumptions that are defined in a cyclic group of prime order. These latter will enable us to prove the security of the designed schemes/protocols as subsequently explained in section 3.2. Hereinafter, we recall the computational assumptions that we use. Depending on the context, the multiplicative or additive notation for groups will be used.

Definition 3.17 (Discrete Logarithm (DL) Assumption). Let G be a cyclic group of prime order p and g a generator of G. The Discrete Logarithm assumption states that, given y ∈ G, it is hard to find the integer x ∈ Z p such that g x = y. The integer x corresponds to the discrete logarithm of y in the base g and is usually denoted by x = log g (y).

Definition 3.18 (One-More Discrete Logarithm (OMDL) Assumption). Let G be a multiplicative group of prime order p, g a generator of G, O 1 a challenge oracle that returns a random element Y ∈ G and O 2 a discrete logarithm oracle with respect to the base g. The One-More Discrete Logarithm assumption states that, after t queries to O 1 (where t is chosen by the adversary) and at most t -1 queries to O 2 , it is hard to retrieve the discrete logarithms of all received t elements.

Definition 3.19 (Decisional Diffie-Hellman (DDH) Assumption). Let G be a cyclic group of prime order p. The Decisional Diffie-Hellman assumption states that, given a generator g ∈ G, two elements g a , g b ∈ G and a candidate X ∈ G, it is hard to decide whether X = g ab or not.

The DDH assumption can also be defined as follows:

Definition 3.20 (Decisional Diffie-Hellman' (DDH ) Assumption). Let G be a cyclic group of prime order p. The Decisional Diffie-Hellman' assumption states that, given two generators g, h ∈ G and two elements g a , h b ∈ G, it is hard to decide whether a = b or not.

Definition 3.21 (Gap Diffie-Hellman (GDH) Assumption). Let G be a cyclic group of prime order p. The Gap Diffie-Hellman assumption states that, given a generator g ∈ G, two elements g a , g b ∈ G and with the help of a DDH oracle (which indicates whether a given quadruple (g, h, g a , g b ) ∈ G 4 is a valid Diffie-Hellman quadruple or not), it is hard to compute the element C = g ab ∈ G.

Preliminaries

Lysyanskaya, Rivest, Sahai and Wolf put forth in [START_REF] Lysyanskaya | Pseudonym Systems[END_REF] the LRSW assumption so as to prove the security of their anonymous credential system. Their assumption, defined hereinafter, is proven in the generic group model (introduced in Section 3.2.3.3). Definition 3.22 (LRSW Assumption). Let G be a cyclic group of prime order q and g be a generator of G. The LRSW assumption states that, given X 0 = g x 0 , X 1 = g x 1 and an oracle O LRSW X 0 ,X 1 that takes on input a message m ∈ Z q and outputs A = (a, a x 1 , a x 0 +mx 0 x 1 ) such that a is randomly chosen, it is hard to compute A = (a , a x 1 , a x 0 +mx 0 x 1 ) for another value a , if m has not been queried to the oracle O LRSW X 0 ,X 1 .

To prove the security of their signatures schemes, Pointcheval and Sanders [START_REF] Pointcheval | Short Randomizable Signatures[END_REF] introduced two new assumptions which are variants of the classical LRSW assumption in type-3 bilinear groups. In what follows, we recall the first assumption which is proven secure in the generic group model (see Section 3.2.3.3). Definition 3.23 (Assumption 1). Let (G 1 , G 2 , G T , p, e) be a bilinear group setting of type 3, with h and h two generators of G 1 and G 2 respectively, which are of prime order p. The assumption 1 states that, given (h, X 1 , h, X0 , X1 ) where X 1 = h x 1 , X0 = hx 0 and X1 = hx 1 such that x 0 ,x 1 ∈ R Z * p and having an unlimited access to an oracle O 1 which, on input m ∈ Z p , chooses a random u ∈ G 1 and outputs the pair P = (u, u x 0 +mx 1 ), it is hard to efficiently generate a valid pair P , with u = 1 G 1 , for a new m * that has not been queried to O 1 . Definition 3.24 (eXternal Diffie-Hellman (XDH) Assumption). Let G 1 , G 2 and G T be three cyclic groups of prime order p and e : G 1 × G 2 → G T a bilinear map. The eXternal Diffie-Hellman assumption, denoted by XDH, states that the DDH assumption holds in G 1 .

To prove the security of their short signature scheme (cf. Section 3.3.2.5), Boneh and Boyen [START_REF] Boneh | Short Signatures Without Random Oracles[END_REF] introduced, in 2004, the q-Strong Diffie-Hellman (q -SDH) assumption. Since then, it has been used as an underlying basis to prove the security of several pairing-based protocols. This assumption is defined as follows. Definition 3.25 (q-Strong Diffie-Hellman (q -SDH) Assumption). Let G 1 and G 2 be two cyclic groups of prime order p, generated by g 1 and g 2 respectively. In the bilinear group pair (G 1 , G 2 ), the q-Strong Diffie-Hellman assumption states that, given (g 1 , g y 1 , g y 2 1 , . . . , g y q 1 , g 2 , g y

2 ) ∈ G q+1 1 × G 2 2
as input, it is hard to output a pair (x, g

1 y+x 1 ) ∈ Z p \ {-y} × G 1 .
It is noteworthy to mention that, when G 1 = G 2 , the pair (g 2 , g x 2 ) is redundant as it can be computed by raising (g 1 , g x 1 ) to a random power.

The q -SDH assumption is believed to be hard even in gap-DDH groups, i.e. groups in which there is an efficient test to determine, with probability 1, on input (g, h, g x , h y ) if x = y mod p or not. For instance, a cyclic group G 1 equipped with a symmetric bilinear map is a good example of a gap-DDH group since one can verify if the quadruple (g, h, g x , h y ) is a DH quadruple by checking if e(g, h y ) = e(g x , h).

It has been proven in [START_REF] Fuchsbauer | Transferable constantsize fair e-cash[END_REF] that the hardness of the q -SDH assumption in gap-DDH groups implies the one of the gap q -SDH -III assumption defined as follows.

Definition 3.26 (Gap q-Strong Diffie-Hellman (gap q -SDH -III) Assumption.). Let G be a cyclic group of prime order p. The Gap q-Strong Diffie-Hellman assumption states that, given (g, h, g y ) ∈ G 3 and q distinct triplets (r i , m i , A i = (g m i h)

1 y+r i ) ∈ Z 2
p × G and having access to a DDH oracle (that indicates whether a given quadruple (g, h, g x , h y ) ∈ G 4 is a DH quadruple or not), it is hard to output a new triple (r, m, A = (g m h)

1 y+r ) where (r, m) ∈ Z 2 p .
Chapter 3 : Mathematical Tools and Cryptographic Building Blocks Definition 3.27 (q-Decisional Diffie-Hellman Inversion (q -DDHI) Assumption). Let G be a cyclic group of prime order p. The q-Decisional Diffie-Hellman assumption states that, given a generator g ∈ G and the values (g, g α , g α 2 , . . . , g α q ) ∈ G q+1 , for a random α ∈ Z q and a candidate X ∈ G, it is hard to decide whether X = g 1 α or not.

Definition 3.28 (Decisional Composite Residuosity (DCR) Assumption). The DCR assumption states that it is hard to distinguish Z n n 2 from Z * n 2 where Z n n 2 = {z ∈ Z * n 2 such that ∃y ∈ Z * n 2 : z = y n mod n 2 }, the set of n th residues.

Provable Security

Whenever designing a new cryptographic primitive, it is of utmost importance to prove its security, in a complexity theory sense, by showing that it is hard to break by a well-defined class of attackers. Such a proof provides useful confidence in the protocol security.

Usually, cryptographers follow three steps to prove the security of a scheme: 1. Define the set of security properties that ought to be met to ensure the security of the scheme.

2. Specify the computational hardness assumption(s) to be considered.

3. Reduce the security of the scheme to this (these) hard problem(s) defined through computational hardness assumption(s).

Hereinafter, we define what is meant by "reduce the security of the scheme".

Reductionist Security

The concept of provable security was first introduced by Goldwasser and Micali [START_REF] Goldwasser | Probabilistic encryption[END_REF] in 1984 to prove the security of an asymmetric encryption scheme. Typically, the security of a cryptographic scheme (or the fact that it ensures a given security property) is formally proven by reducing the problem of breaking its security to the problem of breaking an underlying known hard problem such as those defined in section 3.1.3. This simply means that if an adversary A can break a security property of a scheme, then he can be used as subroutine to solve a hard problem. Shortly afterwards, in a joint work with Rivest [START_REF] Goldwasser | A digital signature scheme secure against adaptive chosen-message attacks[END_REF], they provided the definition of security for a digital signature scheme. Unfortunately, even though they are polynomial, the reductions are computationally costly and completely unpractical. Thus, improvements were required. It was in this spirit that Bellare and Rogaway introduced, in 1996, the concept of exact security [START_REF] Bellare | Advances in Cryptology -EUROCRYPT '96: International Conference on the Theory and Application of Cryptographic Techniques Saragossa[END_REF]. This approach aims to explicitly and accurately estimate the computational complexities of adversarial tasks. Following this work, Ohta and Okamoto proposed the reduction technique known as concrete security [START_REF] Ohta | On concrete security treatment of signatures derived from identification[END_REF] which provide more efficient security results. More recently, the concept of practical security was introduced by Pointcheval [START_REF] Pointcheval | Practical security in public-key cryptography[END_REF].

To sum up, if we consider an adversary A reaching his goal within time t and a reduction which solves the hard problem within t = f (t), three security concepts can be defined:

-Asymptotic security: f is polynomial (bounded by a t polynomial).

-Exact security: f is explicit.

-Practical security: f is "small" (e.g. linear).

Provable Security

Game-based and Simulation-based Security

There are two prevalent types of security proofs, namely game-based and simulation-based. The former, as its name implies, involves a game (or experiment) between a challenger C and an adversary A, whereas the latter relies on an ideal functionality. In what follows, we give a brief overview on both game-based and simulation-based security.

Game-based Security

In the game-based approach, which is widely used, a security property is formalized through a game, also called security experiment, between an efficient adversary A and a challenger C. To model the adversary's real capabilities, we provide him access to a set of oracles and his goal is to solve the game with non-negligible probability. The difference between the adversary's probability of wining the game and the probability of wining the game through random guessing is known as the adversary's advantage. A security property is satisfied as long as the adversary's advantage of wining the corresponding game is negligible.

To simplify game-based security proofs and make them more easily verifiable, Shoup [?] suggested in 2004 a new approach for carrying out reductionist security proofs. His technique, commonly referred to as game hopping technique, consists in organizing a proof as a sequence of games. Hereinafter, we briefly describe it.

Shoup's game hopping technique. It is useful in the case of complex cryptographic protocols (e.g. group key establishment protocols) and works as follows. First, the real attack game (Game 0) with respect to a given adversary is formally defined. Then, a sequence of games (Game 1,. . .,Game n) are constructed such that the adversary cannot detect the changes between two consecutive games. The last game (Game n) is constructed so that the probability that the event S n occurs is negligibly close to the target probability (either 0 or 1 2 ). Let S i denote the event that an adversary wins Game i. By construction, Pr[S i ] is negligibly close to Pr[S i+1 ]. Thus, the probability that event S 0 occurs is negligibly close to the probability of the event S n . Thereby, one can conclude and prove the security of the scheme. It is however worth mentioning that, depending on the real attack game, this technique may be sometimes difficult to apply.

Simulation-based Security

Simulation-based security, in the sense of secure two/multi-party computation, rely on the realideal world paradigm. More precisely, in addition to the real world, one considers an ideal world where an ideal functionality, denoted by F, is defined such that all interactions between the different parties and the adversary, in the ideal world, are made via F. In such a setting, a protocol is considered secure if the view of the protocol execution in the real world, denoted view Real , is computationally indistinguishable from the view of the functionality execution in the ideal world, denoted by view Ideal . By definition, everything goes well in the ideal world and no attack will succeed. Thus, to prove the security of a protocol, one must build a simulator S that will emulate a probabilistic polynomial time adversary in the ideal world.

Simulation-based proofs present a significant advantage over game-based proofs as they lead to "composable" notions of security. That is, if one uses a set of protocols independently proven secure (through simulation-based proofs) as building blocks of a complex protocol, then the resulting "composed" protocol is secure [START_REF] Canetti | Universally composable security: A new paradigm for cryptographic protocols[END_REF].

Security Models

A security proof mainly depends on the underlying security model. A scheme proven secure in a given security model may be insecure in another one. Indeed, the security model specifies the Chapter 3 : Mathematical Tools and Cryptographic Building Blocks set of security properties that should be fulfilled to ensure the security of the scheme (i.e. what it actually means to be secure).

To get efficient and practical schemes that are proven secure, one must sometimes make some ideal assumptions. One way consists in proving that the scheme is secure in an ideal setting (e.g. in the random oracle model) rather than in the standard model. It is, however, worth to mention that a security proof in an idealized model does not provide the same level of security guarantees as a proof in the standard model. Hereinafter, we briefly define those two models as well as the generic group model.

Random Oracle Model (ROM)

In cryptography, one of the most widely accepted ideal models is the random oracle model whose concept was first introduced by Fiat and Shamir [START_REF] Fiat | How to prove yourself: Practical solutions to identification and signature problems[END_REF] in 1986. Later, in 1993, it was formalized by Bellare and Rogaway [START_REF] Bellare | Random oracles are practical: A paradigm for designing efficient protocols[END_REF]. The basic idea of the random oracle model is to assume that hash functions behave like ideal random functions. Thereby, whenever an adversary wants to compute the output of a hash function, he needs to query a random oracle. Indeed, a security proof in the random oracle model does not depend on a specific hash function as this latter is replaced by a random oracle whose output is indistinguishable from the output of a perfectly random function. When queried twice with the same input, the random oracle outputs the same value it previously returned for that input. If a real attacker against a scheme proven secure in the ROM succeeds, then he has necessarily exploited a weakness of the hash function.

Standard Model

The random oracle model has been subject to a lot of criticism due to its limitations. Canetti, Goldreich and Halevi showed in [START_REF] Canetti | The random oracle methodology, revisited (preliminary version)[END_REF][START_REF] Canetti | On the random-oracle methodology as applied to length-restricted signature schemes[END_REF] the impossibility of implementing random oracles. Indeed, some schemes proven secure in the random oracle model turned out to be totally insecure when implemented with any hash function. Therefore, cryptographers had to define a new model that does not rely on any idealized assumption so as to prove the security of new schemes. Such a model is referred to as the Standard Model. This model allows to achieve much stronger security guarantees as schemes security relies solely on computational assumptions. Unfortunately, this comes at the cost of less efficient schemes.

Generic Group Model (GGM)

The generic group model [START_REF] Nechaev | Complexity of a determinate algorithm for the discrete logarithm[END_REF][START_REF] Shoup | Advances in Cryptology -EUROCRYPT '97: International Conference on the Theory and Application of Cryptographic Techniques[END_REF][START_REF] Maurer | Proceedings, chapter Abstract Models of Computation in Cryptography[END_REF] is another idealized model which assumes that the relevant group has no special structure or feature that can be exploited by an adversary. Indeed, in this model, the adversary must query an oracle to perform any group operation. The generic group model is usually used to define the security level provided by new computational hardness assumptions as well as new cryptosystems.

Cryptographic primitives

In this section, the main cryptographic primitives required throughout this thesis are formally defined. We first address a symmetric key cryptographic primitive, namely Message Authentication Code (MAC), then move to the asymmetric setting and more precisely digital signature, public key encryption, commitments and proofs of knowledge.

Message Authentication Code

Message Authentication Code, commonly known as MAC, is one of the most basic cryptographic primitives. It is a symmetric technique that provides message authentication as well as message

Cryptographic primitives

integrity by simply appending a tag, referred to as MAC, to the corresponding message. This MAC is computed using a secret key sk that is shared between the sender and the receiver. In what follows, we provide a more formal definition of a MAC scheme.

Definition 3.29 (Message Authentication Code). A Message Authentication Code (MAC) scheme consists of the following four algorithms:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the public parameters pp.

-KeyGen(pp) : a probabilistic algorithm, on input the public parameters pp, outputs a secret key sk.

-MAC(pp, sk, m) : an algorithm, on input the public parameters pp, a message m ∈ {0, 1} * as well as the secret key sk, outputs a valid tag τ .

-Verify(pp, sk, m, τ ) : a deterministic algorithm, on input the public parameters pp, the secret key sk, a message m and a tag τ , outputs either 1 ( accept) or 0 ( reject).

A message authentication code scheme must satisfy the following two properties:

-Authenticity: Anyone holding the secret key sk that has been used to generate a MAC can verify its validity.

-Integrity: If any changes are made to the original message m, then the MAC becomes invalid (with overwhelming probability).

-Validity: If the tag τ is valid with respect to both m and sk, then Verify(pp, sk, m, τ ) should output 1 (with overwhelming probability).

To date, several MAC schemes have already been proposed. Some of them are deterministic while others are probabilistic. Hereinafter, we define both types as well as the condition under which each one of them is considered secure.

Deterministic MAC schemes

When considering a deterministic MAC scheme, for a given message m, there exists a sole valid authentication tag τ . Typically, a deterministic MAC should be unforgeable under chosen message attack (UF-CMA). That is, it should be hard for an adversary A, that can make MAC queries, to produce a valid tag τ on a message m that has not been queried. Figure 3.2 provides a more formal definition of the UF-CMA experiment. The security experiment between a challenger C and an adversary A mainly consists of the following three steps:

-Pre-Query: C executes the Setup and KeyGen algorithms to get pp as well as the secret key sk.

-Query: During this phase, A can query the OMAC oracle to obtain the tag τ associated to a given message m.

-Output: Eventually, A outputs a pair (m , τ ). He wins the game if the τ is a valid tag on message m (i.e. Verify(pp, sk, m , τ ) = 1) and the message m has not already been queried to OMAC.

The adversary's success probability, which is commonly called advantage of the adversary and denoted Adv UF-CMA

A (1 k ), is defined as Adv UF-CMA A (1 k ) = Pr[Exp UF-CMA A (1 k ) = 1].
Chapter 3 : Mathematical Tools and Cryptographic Building Blocks In the case of a probabilistic MAC scheme, contrary to a deterministic one, several valid tags may correspond to a given message m. When considering such a MAC scheme, the desired security notion is stronger than the one for deterministic MACs as the adversary can also make verification queries. More specifically, it is known as unforgeable under chosen message and verification attack (UF-CMVA). That is, it is hard for an adversary, that can make MAC as well as Verify queries, to provide a valid pair (τ, m) such that the message m has not already been queried to the MAC oracle. The UF-CMVA security experiment is the same as the UF-CMA one except that the third step is replaced by

Exp UF-CMA A (1 k ) 1. pp ← Setup(1 k ) 2. sk ← KeyGen(pp) 3
3. (m, τ ) ← A OMAC,OVerify (pp)
As for the adversary advantage, it is defined as

Adv UF-CMVA A (1 k ) = Pr[Exp UF-CMVA A (1 k ) = 1]
. A yet stronger security notion for probabilistic MACs, denoted sUF-CMVA, exists. In such variant, the adversary wins even if m has already been queried to the OMAC oracle, provided that the oracle did not output the pair (m, τ ).

Two probabilistic algebraic MAC schemes, which are constructed using a cyclic group and proven UF-CMVA secure under the DDH assumption, have recently been proposed by Chase, Meiklejohn and Zaverucha [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF]. Hereinafter, we detail the MAC GGM scheme upon which we rely to design our private eCash system described in Chapter 5.

MAC GGM

A particular feature of the MAC GGM scheme is that the issuer and the verifier of the MAC are actually the same entity and thus share a set of keys. Besides, they can optionally publish some public parameters associated to their secret keys without jeopardizing the scheme security. In what follows, the MAC GGM construction is reviewed by explaining how to produce a MAC on n distinct messages (m 1 , . . . , m n ):

-Setup(1 k ) creates the system public parameters denoted pp = (G, q, g, h) where G is a cyclic group of prime order q, a k-bit prime, and g, h are two random generators such that log g h is unknown.

-KeyGen(pp) randomly selects a secret key sk

= → x = (x 0 , x 1 , . . . , x n ) ∈ R F n+1 q
and a value x0 ∈ R F q to build a commitment C x 0 = g x 0 h x0 to the secret value x 0 (see section 3.3.4). Denoted by iparams, (C x 0 , X 1 = h x 1 , . . . , X n = h xn ) corresponds to the issuer's public parameters.

Cryptographic primitives

-MAC(pp, sk, → m) produces an authentication tag (u, u ) on → m = (m 1 , . . . , m n ) ∈ F n q where u ∈ R G\{1} and u = u x 0 +x 1 m 1 +•••+xnmn .
-Verify(pp, sk, → m, (u, u )) checks the validity of the tag with respect to the message → m. The tag is accepted only if u = 1 and u = u x 0 +x 1 m 1 +•••+xnmn .

As previously mentioned, the MAC GGM scheme has been proven unforgeable under chosen message and verification attack (UF-CMVA), in the generic group model, under the DDH assumption.

Digital Signature

The idea of digital signatures was put forth by Diffie and Hellman [START_REF] Diffie | New directions in cryptography[END_REF] in 1976. Similarly to a MAC, a digital signature aims to ensure the authenticity as well as the integrity of a message. However, unlike a MAC, given a message m and a signature σ, anyone must be able to verify the validity of the signature using the signer's public key. Furthermore, only the entity holding the private key, namely the signer, should be able to compute such a digital signature. Definition 3.30 (Digital signature scheme). A digital signature scheme consists of the following four algorithms:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the system public parameters pp.

-KeyGen(pp) : a probabilistic algorithm, on input the public parameters pp, outputs a pair of keys (sk, pk) where sk is the private key and pk is the associated public key.

-Sign(pp, sk, m) : an algorithm, on input the public parameters pp, a message m ∈ {0, 1} * as well as the private key sk, outputs a digital signature σ on the message m (such a signature will be said "valid").

-Verify(pp, pk, m, σ) : a deterministic algorithm, on input the public parameters pp, the public key pk, a message m and a signature σ, outputs 0 or 1.

A digital signature scheme must satisfy the following three properties:

-Validity: Given a digital signature σ on a message m generated using the private key sk, the output of Verify algorithm using the associated public key pk will be equal to 1.

-Integrity: A digital signature protects the integrity of the message. Precisely, if any change is made to the original signed message m, then the output of Verify algorithm will be equal to 0 with overwhelming probability.

-Non-repudiation: A signer that has signed a message cannot falsely deny it afterwards. Precisely, given a digital signature σ generated using the private sk, then the output of Verify algorithm will be equal to 1 with overwhelming probability.

Possible forgeries and attacks. Depending on the attacker's goal, we can distinguish four types of attacks against a digital signature scheme:

-Total break : The adversary can recover a user's private key from his public key. Thereby, he is able to produce a valid signature on any message of his choice.

-Universal forgery (UF): The adversary can generate a valid signature σ on any message m without knowing the corresponding private key.

Chapter 3 : Mathematical Tools and Cryptographic Building Blocks -Selective forgery (SF): The adversary, who has no knowledge of the signer's private key, can produce a valid signature σ on a message m that he chose prior to the attack.

-Existential forgery (EF): The adversary, who has no knowledge of the signer's private key, can create a valid signature σ on a message m of his choice. The message could be absolutely meaningless.

The attacks can also be classified into three categories according to the type of information the attacker holds and the means at his disposal:

-No Message Attack (NMA): the attacker only knows the public key of the signer.

-Known Message Attack (KMA): the attacker knows the public key of the signer as well as a set of valid message/signature pairs.

-Adaptive Chosen Message Attack (CMA): this attacker is stronger than previous ones as he knows the public key of the signer and can obtain a signature on any message of his choice.

A cryptographic scheme which resists to attack XX with respect to the category YY is said to be XX-YY. Usually, a digital signature scheme is considered secure if it is EUF-CMA i.e. existentially unforgeable under chosen message attack. This means that, even an adversary that can query a signature of some messages of his choice should not be able to produce a signature σ on a message m that has not been queried. Figure 3.3 provides a more formal definition of the EUF-CMA experiment. The advantage of the adversary In what follows, we define some variants of basic digital signatures, namely group signatures, blind signatures and aggregate signatures.

Adv EUF-CMA A (1 k ) is defined as Adv EUF-CMA A (1 k ) = Pr[Exp EUF-CMA A (1 k ) = 1]. Exp EUF-CMA A (1 k ) 1. pp ← Setup(1 k ) 2. (sk, pk) ← KeyGen(pp, pk)

Group Signature

Introduced by Chaum and van Heijst [START_REF] Chaum | Advances in Cryptology -EUROCRYPT '91: Workshop on the Theory and Application of Cryptographic Techniques[END_REF] in 1991, a group signature enables any group member to sign a message on behalf of the group in an anonymous manner. Thereby, the identity of the signer is kept secret. Sometimes, an exceptional circumstance may require to revoke the anonymity of a given signature (i.e. to recover the identity of the signer). To this end, some systems introduce several designated trusted authorities, commonly called revocation authorities. These authorities can also selectively revoke group membership of a given member. Definition 3.31 (Group signature scheme). A group signature scheme often involves three stakeholders:

1. A group manager that handles user's registration to the group.

2.

Group members that must first register with the group manager in order to be able to generate anonymous group signatures on behalf of the group.

3. A revocation authority that can lift the anonymity of a given signature to recover the signer's identity.

It consists of the following six algorithms and protocols:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the system public parameters pp.

-KeyGen(pp) : a probabilistic algorithm, on input the public parameters pp, outputs the public key of the group gpk, the manager secret key sk gm as well as the key of the revocation authority sk ra .

-Join : an interactive protocol between a user and the group manager which, on input pp and gpk, outputs to the user a group secret key gsk u as well as a group membership certificate ζ.

-Sign(pp, m, ζ, gsk u ) : a probabilistic algorithm, on input a message m ∈ {0, 1} * , a membership certificate ζ as well as a user's group secret key gsk u , outputs a group signature σ on the message m.

-Verify(pp, m, σ, gpk) : a deterministic algorithm, on input a group signature σ as well as the group manager public key gpk, outputs 0 or 1.

-Open(m, σ, sk ra , gpk) : a deterministic algorithm, on input a valid group signature, the corresponding message m and the group public key gpk, outputs the identity of the group member who produced the signature σ.

In addition to the previously defined security properties that any digital signature scheme must satisfy, a group signature scheme must also fulfill the following three security properties [START_REF] Bellare | Topics in Cryptology -CT-RSA 2005[END_REF]:

-Anonymity: Except the revocation authority, no one should be able to lift the anonymity of a signature or link two signatures produced by the same signer. Thereby, this property also captures the intuitive informal notion of unlinkability [START_REF] Ateniese | Proceedings, chapter Some Open Issues and New Directions in Group Signatures[END_REF].

-Traceability: Even a set of colluding group members cannot produce a valid group signature without the Open algorithm being able to return the identity of one of the colluding members.

-Non-frameability: No one, even a coalition between a set of users and the group manager, should be able to falsely accuse an honest group member of signing a message. This property covers the intuitive informal notions of exculpability and framing. Besides, together with the traceability property, it captures both the unforgeability and coalition-resistance security requirements [AT99].

Direct Anonymous Attestation (DAA)

Brickell, Camenisch and Chen [START_REF] Brickell | Direct anonymous attestation[END_REF] introduced in 2004 a particular group signature scheme known as Direct Anonymous Attestation (DAA) that does not support signature opening capabilities, but instead, ensures the linkability of certain signatures. More precisely, a tag is appended to the signature so as to enable the linkability of signatures (i.e. attestations) created with the same private key and with respect to the same basename, denoted by bsn.

This privacy-preserving authentication protocol was initially intended for a particular hardware module, known as Trusted Platform Module (TPM) (e.g. a secure element in a smartphone), to allow its remote authentication to an external party (e.g. a service provider) whilst preserving the privacy of its owner. Usually, part of the attestation computation is delegated to the host embedding it (i.e. PC or smartphone), which is generally much more powerful but untrustworthy. In [BFG + 13], Bernhard et al. introduced a special DAA scheme where the TPM performs all the computations and none is delegated to the host. The latter is referred to as Pre-DAA.

In this thesis, we will mainly focus on Pre-DAA schemes. Hereinafter, we first provide a formal definition of Pre-DAA schemes, followed by their security and privacy requirements. Definition 3.32 (Pre-Direct Anonymous Attestation (Pre-DAA) scheme). A Pre-Direct Anonymous Attestation (DAA) scheme usually involves two stakeholders:

1. An issuer I (i.e. group manager) that handles the issuance of TPM's group signing keys.

2. TPMs (i.e group members) that must hold a valid group signing key in order to be able to generate anonymous attestations.

It consists of the following nine algorithms and protocols:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the system public parameters pp.

-IKeyGen(pp) : a probabilistic algorithm, on input the public parameters pp, outputs the public/private key pair (gmsk, gmpk) of the issuer.

-UKeyGen(pp, i) : a probabilistic algorithm, on input the public parameters pp and a TPM's identifier i, outputs the secret key sk i of the TPM.

-Join(pp, gmpk, gmsk, i, sk i ) : an interactive protocol between a TPM and the issuer which, on input pp, gmpk, gmsk as well as the TPM's secret key sk i , outputs to the TPM group signing key gsk i .

-GSign(pp, m, gsk i , bsn) : a probabilistic algorithm, on input a message m ∈ {0, 1} * , a TPM secret key sk i as well as its group signing key gsk i and a basename bsn, outputs an anonymous signature σ on the message m and with respect to bsn.

-GVerify(pp, m, bsn, σ, gmpk) : a deterministic algorithm, on input a group signature σ, a message m, a basename bsn as well as the issuer's public key gmpk, outputs 0 or 1.

-Identify T (T , sk i ) : a deterministic algorithm, on input a transcript T resulting from the execution of the Join protocol and a secret key sk i , outputs 1 if T has been produced using sk i . Otherwise, it returns 0.

-Identify S (σ, m, bsn, sk i ) : a deterministic algorithm, on input a signature σ, a message m, a basename bsn and a secret key sk i , outputs 1 if the signature σ on m and for bsn could have been produced using the secret key sk i . Otherwise, it returns 0.

-Link(gmpk, σ, m, σ , m , bsn) : a deterministic algorithm, on input two signatures σ and σ , two messages m and m as well a basename bsn, outputs 1 if both σ and σ are valid signatures on, respectively, m and m with respect to the same basename bsn = ⊥ and were produced by the same TPM (i.e. using the same sk i ). Otherwise, it returns 0.

Cryptographic primitives

Security and Privacy Models. Hereinafter, we recall the different properties that a pre-DAA scheme [BFG + 13] must satisfy to be secure whilst preserving user's privacy. For that, a pre-DAA scheme must ensure four security properties, namely correctness, traceability, non-frameability as well as anonymity. In what follows, we formally define them through a set of experiments between a challenger C and a PPT adversary A. We distinguish two sets of users: HU, the set of honest users and CU, the set of corrupted users (whose secret key sk i and group signing key gsk i are known to the adversary). We also define three lists: S, the list of all queries to the signing oracle; C, the list of queries to the challenge oracle; and T, the list of transcript views associated to the different executions of the Join protocol. To model the capabilities of the adversary A, we give him access to some oracles defined as follows:

-OAdd(i) is an oracle used by A to create a new honest user identified by i.

-OAddCorrupt(i) is an oracle used by A to create a new corrupted user identified by i. His secret key is known to A.

-OJoin I (i) is an oracle that executes the issuer's side of the Join protocol. This oracle will be used to simulate the execution of the Join protocol between an, honest or corrupted, user u i and an honest issuer.

-OJoin U (i) is an oracle that executes the user's side of the Join protocol. This oracle will be used by A acting as a malicious issuer. The adversary provides the oracle with an honest user's identifier i. If the latter accepts, A gets a transcript view T of the protocol execution, that is saved in T.

-OCorrupt(i) is an oracle used by A to corrupt the user identified by i. Thus, A gets both the secret key sk i and the group signing key gsk i of user i. Concurrently, i is moved from HU to CU.

-OGSign(i, m, bsn) is an oracle used by A to obtain a signature on m and for bsn produced by the honest user i. Concurrently, the triple (i, m, bsn) is saved in S.

-OCH b (i 0 , i 1 , bsn, m) is an oracle used by A to obtain a signature σ on m by i b .

The four security and privacy requirements of a pre-DAA are defined as follows:

Correctness. This property ensures the proper functioning of the system. A Pre-DAA scheme provides correctness if the following four statements are met: (1) the issued group signing key gsk i is valid; (2) a valid signature is accepted by the verifier V; (3) a valid signature can be traced to the correct sk i ; and (4) two signatures produced by the same user (i.e. same key sk i ) and for the same bsn are linkable. Besides, it is noteworthy to mention that each transcript T resulting from the execution of the Join protocol must have a unique sk i associated to it.

Traceability. Roughly speaking, traceability requires the following two statements to be met. Indeed, no adversary should be able to produce: (1) a valid signature which cannot be traced to a secret key that has been committed to during an execution of the Join protocol; or (2) two unlinkable signatures for the same basename and under the same secret key. Thus, as shown in Figure 3.4, the traceability experiment consists of two subgames. In the first subgame (i.e. steps 3 and 4), the issuer is assumed to be honest whereas, in the second one (i.e. steps 5, 6 and 7), the issuer as well as all users are assumed to be corrupted. The advantage Adv trace A (1 k ) of the adversary is defined as Pr[Exp trace A (1 k ) = 1]. A pre-DAA scheme satisfies the traceability property if this advantage is negligible for any PPT adversary A.

Chapter 3 : Mathematical Tools and Cryptographic Building Blocks

Exp trace A (1 k ) 1. pp ← Setup(1 k ), HU ← ∅, CU ← ∅, T ← ∅ 2. (gmpk, gmsk) ← IKeyGen(pp)
A (1 k ) = |Pr[Exp anon-b A (1 k ) = b] -1/2|. A
pre-DAA scheme is considered anonymous if this advantage is negligible for any PPT adversary. Non-frameability. Informally, non-frameability requires the following two statements to be satisfied. Indeed, no adversary should be able to output: (1) a signature that can be traced to a given user i who has not produced a signature on the corresponding message/basename pair; or (2) two signatures that are linkable even though they should not. Thus, as shown in Figure 3.6, the non-frameability experiment also consists of two subgames. In the first subgame (i.e. steps 3 and 4), the adversary's goal is to frame an honest user whereas, in the second one (i.e. steps 44 3.3. Cryptographic primitives 5 to 9), he has control over all users as well as the issuer. The advantage Adv non-fram A (1 k ) of the adversary is defined as Pr[Exp non-fram A (1 k ) = 1]. A pre-DAA scheme satisfies the non-frameability requirement if this advantage is negligible for any PPT adversary A.

Exp anon-b A (1 k ) 1. pp ← Setup(1 k ), HU ← ∅, CU ← ∅, S ← ∅, C ← ∅ 2. (gmpk, gmsk) ← IKeyGen(pp) 3. b ←-A O (gmpk,
Exp non-fram A (1 k ) 1. pp ← Setup(1 k ), HU ← ∅, CU ← ∅, S ← ∅

Blind Signature

Blind signature, which was also proposed by Chaum [START_REF] Chaum | Advances in Cryptology: Proceedings of Crypto 82, chapter Blind Signatures for Untraceable Payments[END_REF], is a variant of classical digital signatures that allows a receiver R to get a signature of a message without revealing any information about it to the signer S.

Definition 3.33 (Blind signature scheme). A blind signature scheme consists of the following four algorithms:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the system public parameters pp.

-KeyGen(pp) : a probabilistic algorithm, on input the public parameters pp, outputs a pair of keys (sk, pk) where sk is the private key of the signer and pk is the associated public key.

-Sign(pp, sk, m ) : an interactive protocol, on input the public parameters pp, a blinded version m of a message m ∈ {0, 1} * as well as the private key sk, outputs a digital signature σ on the message m.

-Verify(pp, pk, m, σ) : a deterministic algorithm, on input the public parameters pp, the public key pk, a message m and a signature σ, outputs either 0 or 1.

A blind signature scheme should satisfy two additional security properties:

-One-more Unforgeability: it should be impossible for the receiver R to obtain L + 1 signatures after at most L signing requests.

Chapter 3 : Mathematical Tools and Cryptographic Building Blocks -Unlinkability (also called Blindness): the signed message must remain secret to the signer and the latter should not be able to (1) link two message/signature pairs (i.e. decide whether two signatures were produced by the same signer or not), or (2) link a message/signature pair to a specific execution of the protocol Sign (i.e. identify for whom a given signature was issued).

Sometimes, in use cases like electronic Cash (eCash) for example, the signer S may want to add some information to the blind signature such as a date, a validity period or even an amount.

To address this issue, Abe and Fujisaki [START_REF] Abe | How to date blind signatures[END_REF] proposed in 1996 an extension of blind signature known as partially blind signature.

Partially blind signatures. A partially blind signature allows the receiver of the signature R and the signer S to agree on a common information info to be added to the blind signature of a message m.

Definition 3.34 (Partially blind signature scheme). More formally, a partially blind signature scheme consists of the following four algorithms:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the system public parameters pp.

-KeyGen(pp) : a probabilistic algorithm, on input the public parameters pp, outputs a pair of keys (sk, pk) where sk is the private key of the signer and pk is the associated public key.

-Sign(pp, sk, m , info) : an interactive protocol, on input the public parameters pp, a blinded version m of a message m ∈ {0, 1} * , a common information info that the receiver and the signer agreed on as well as the private key sk, outputs a digital signature σ on both m and info.

-Verify(pp, pk, m, info, σ) : a deterministic algorithm, on input the public parameters pp, the public key pk, a message m, a common information info and a signature σ, outputs either 0 or 1.

The additional security properties that a partially blind signature scheme must meet are the same as those of a blind signature scheme (i.e. one-more unforgeability and unlinkability).

Aggregate Signature

In 2003, Boneh, Gentry, Lynn and Shacham [START_REF] Boneh | Aggregate and verifiably encrypted signatures from bilinear maps[END_REF] introduced a particular case of digital signature, denoted aggregate signature, that additionally supports aggregation. Indeed, an aggregate signature scheme allows to aggregate n signatures on n distinct messages produced by n signers into a single compact signature. Along with the n messages, the resulting signature will convince the verifier that the n messages were, indeed, signed by the n signers.

Definition 3.35 (aggregate signature scheme). An aggregate signature scheme consists of the following five algorithms:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the system public parameters pp.

-KeyGen(pp) : a probabilistic algorithm, on input the public parameters pp, outputs the users' private/public key pairs {(sk i , pk i )} i=n i=1 .

-Sign(pp, sk i , m i ) : an algorithm, on input the public parameters pp, a message m i as well as a private key sk i , outputs a signature σ i on m i .

Cryptographic primitives

-Aggregation(pp, {m i , σ i } i=n i=1 ) : an algorithm, on input n distinct messages → m = (m 1 , m 2 , . . . , m n ) and the corresponding signatures (σ 1 , σ 2 , . . . , σ n ), outputs a unique signature σ on → m.

-Verify(pp, {pk i , m i } i=n i=1 , → m , σ) : a deterministic algorithm, on input n messages (m 1 , . . . , m n ), a signature σ and n public keys (pk 1 , . . . , pk n ), outputs either 0 or 1.

A specific type of aggregate signatures, where the signatures are sequentially (rather than independently) created, is called Sequential aggregate signature. Indeed, as its name implies, the final signature is generated sequentially with each signer signing the aggregate signature in turn. Definition 3.36 (Sequential aggregate signature scheme). A sequential aggregate signature scheme consists of the following four algorithms:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the system public parameters pp.

-KeyGen(pp) : a probabilistic algorithm, on input the public parameters pp, outputs the users' private/public key pairs {(sk i , pk i )} i=n i=1 .

-AggSign(pp, σ, m n , sk n ) : an algorithm, on input the public parameters pp, an aggregate signature σ on a set of messages (m 1 , m 2 , . . . , m n-1 ) as well as the private key sk n and a message m n , outputs a signature σ on

→ m = (m 1 , m 2 , . . . , m n ).
-Verify(pp, {pk i , m i } i=n i=1 , σ ) : a deterministic algorithm, on input a signature σ , n messages (m 1 , . . . , m n ) and n public keys (pk 1 , . . . , pk n ), outputs either 0 or 1. Security Model. A sequential aggregate signature scheme must be existentially unforgeable under chosen message attacks (EUF-CMA). That is, no adversary should be able to forge an aggregate signature, on a set of messages of his choice, by a set of users whose secret keys are not all known to him. More precisely, the corresponding security experiment between a challenger C and an adversary A consists of the following four steps:

-Setup: C initializes a key list KeyList as empty. By running the Setup and KeyGen algorithms, he respectively defines the system public parameters pp and the signing/verification key pair (sk * , pk * ). A is provided with the verification key pk * .

-Join Queries: A adaptively requests to append the public keys pk i to the list KeyList.

-Aggregate signatures Queries: A adaptively asks for aggregate signatures on at most q messages (m 1 , . . . , m q ) under the challenge public key pk * . More precisely, for each query, A provides an aggregate signature σ i on the block of messages (m i,1 , . . . , m i,r i ) under the public keys (pk i,1 , . . . , pk i,r i ) all belonging to KeyList. In response, C returns the aggregate signature on (m i,1 , . . . , m i,r i , m i ) produced using sk * .

-Output: Eventually, A outputs an aggregate signature σ on the messages (m * 1 , . . . , m * r ) under the public keys (pk 1 , . . . , pk r ). He wins the game if the following three conditions are met:

• Verify(pp, {pk i , m * i } i=n i=1 , σ) = 1; • For all pk j = pk * , pk j ∈ KeyList;
• For some j * ∈ {1, . . . , r}, pk * = pk j * and m * j * has not already been queried to the signing oracle (i.e. for i ∈ {1, . . . , q}, m i = m * j * ).

The adversary's success probability, which is commonly called advantage of the adversary and denoted Adv UF-CMA

A (1 k ), is defined as Adv UF-CMA A (1 k ) = Pr[Exp UF-CMA A (1 k ) = 1].
Chapter 3 : Mathematical Tools and Cryptographic Building Blocks

Used Digital Signature Schemes

To design our protocols, we use three well-known digital signature schemes, namely RSA, Schnorr and Boneh-Boyen signature schemes. In this section, we briefly recall them.

RSA. Rivest, Shamir and Adleman signature scheme [START_REF] Rivest | A method for obtaining digital signatures and public-key cryptosystems[END_REF], which relies on the hash and sign concept, is defined as follows:

-KeyGen(1 k ): Selects two distinct k-bit prime integers p and q, then chooses an integer e that is co-prime with φ(n) = (p -1)(q -1) where φ is Euler's totient function. Next, it determines d = e -1 mod φ(n). The signer's private key is (n, d) and the corresponding public key consists of the pair (n, e).

-Sign(m, d, n, e): To sign a message m, the signer computes σ = m d mod n. It returns σ as the digital signature on m.

-Verify(m, σ, n, e): A signature σ is valid only if m = σ e mod n.

Schnorr. The Schnorr signature [Sch90, Sch91] is an efficient discrete logarithm-based signature scheme and works as follows:

-Setup(1 k , 1 k ): Generate the system public parameters pp = (p, q, Z p , g, H) where p and q are two prime integers such that q|p -1, p > 2 k and q > 2 k , whereas g ∈ Z * p and H is a hash function.

-KeyGen(pp): Chooses a random x ∈ Z * q and computes y = g x mod p. The signer's private key is x and the corresponding public key is y.

-Sign(pp, x, m): To sign a message m ∈ {0, 1} * , the signer first selects a random a ∈ R Z q .

Then, he computes t = g a mod p, c = H(m, t) and s = a + cx mod q. The signature on the message m is σ = (s, c).

-Verify(pp, σ, m, X): Given a pair (s, c) and a message m, the verifier computes t = g s y -c mod p and checks whether c ? = H(m, t ). If so, the signature is valid.

Boneh-Boyen. Using Boneh and Boyen signature scheme, subsequently denoted BB, one may prove the knowledge of a signature on a message without revealing neither the signature nor the message. The two original BB signature variants, proposed in [START_REF] Boneh | Short Signatures Without Random Oracles[END_REF], fulfil different security properties but both rely on the use of pairings. There is, however, a variant [START_REF] Canard | New results for the practical use of range proofs[END_REF] where no pairing computations are required. Thereby, BB signatures may also be used when dealing with constrained environments that cannot handle pairing computations such as SIM/UICC cards. In the sequel, we describe the most efficient variant of the two original BB schemes as well as the one without pairing.

Boneh-Boyen signature

-Setup(1 k ): Generates the system public parameters pp = (G 1 , G 2 , G T , p, e)
where G 1 , G 2 and G T are three cyclic groups of prime order p and e :

G 1 × G 2 → G T is a bilinear map.
-KeyGen(pp): Chooses two random generators g ∈ G 1 and g ∈ G 2 as well as a random y ∈ Z p . The signer's private key is y and the corresponding public key consists of (g, g, Ỹ , z) where Ỹ = gy and z = e(g, g).

-Sign(pp, m, y): Given the private key y and a message m ∈ Z p , this algorithm returns the signature σ = g 1 y+m on the message m.

Cryptographic primitives

-Verify(pp, σ, m, g, Ỹ , z): To verify the validity of a signature σ with respect to a message m, the verifier checks whether e(σ, Ỹ gm ) ? = z. If so, the signature is valid and the algorithm outputs 1. Otherwise, it returns 0.

Boneh-Boyen signature without pairing -Setup(1 k ): Generates the system public parameters pp = (G, p) where G is a cyclic group with prime order p and such that the DDH problem is hard in G.

-KeyGen(pp): Chooses two random generators g 1 , g 2 ∈ G as well as a random y ∈ Z p . The signer's private key is y and the corresponding public key is Y = g y 2 .

-Sign(pp, m, y): The signature σ on a message m ∈ Z p consists of A = g

1 y+m 1 along with a Zero-Knowledge Proof of Knowledge π (see section 3.3.5) defined as π = PoK {α : Y = g α 2 ∧ A α = g 1 A -m }.
-Verify(pp, σ, m, Y ): To verify the validity of a signature A on a message m, the verifier checks the validity of the proof π. If so, the signature is valid and the algorithm outputs 1.

Otherwise, it returns 0.

Remark 1. By definition, A = g

1 y+m 1
. This implies that A y = g 1 A -m . Since the group G is not equipped with a bilinear map (i.e. it is not a gap-DDH group), the signer has to additionally prove that the signature is valid with respect to m. To this end, he provides a Zero-Knowledge Proof of Knowledge π (see Section 3.3.5) that the discrete logarithm of (g

1 A -m ) in the base A is equal to the discrete logarithm of Y in the base g 2 (i.e. π = PoK {α : Y = g α 2 ∧ A α = g 1 A -m }).
Such proof of equality of discrete logarithms has been introduced by Chaum and Pedersen in [START_REF] Chaum | Advances in Cryptology -CRYPTO' 92: 12th Annual International Cryptology Conference[END_REF]. Thus, if π is valid, then so is the signature A.

Theorem 3.1. The Boneh-Boyen signature scheme without pairings is existentially unforgeable under chosen message attack, in the random oracle model, assuming that the q-Strong Diffie-Hellman (q -SDH) assumption holds. [CCJT14]

Public Key Encryption

Encryption mainly aims to provide the confidentiality of exchanged information by ensuring that only the sender and the legitimate receiver(s) can know the message content. Until 1976, all encryption schemes were symmetric (i.e. the same key is used for encryption and decryption). However, Diffie and Hellman's seminal paper "New directions in cryptography" revolutionized the world of cryptography by introducing the concept of public-key cryptography. Unlike secret key schemes, a public key encryption scheme relies on the use of a public/private key pair. The public key of the receiver, known to everyone, is used to encrypt the message while his private key, which should be kept secret, allows the legitimate receiver to decrypt the received ciphertext to recover the message.

Definition and Security Requirements

Definition 3.37 (Public key encryption scheme). More formally, a public key encryption scheme is defined through the following four algorithms:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the system public parameters pp.

-KeyGen(pp) : a probabilistic algorithm, on input the public parameters pp, outputs a pair of keys (sk, pk) where pk is the public key of the user and sk is the associated private key.

-Enc(pp, m, pk) : an algorithm, on input a message m ∈ {0, 1} * and a public key pk, outputs a ciphertext c.

-Dec(pp, c, sk) : a deterministic algorithm, on input a ciphertext c as well as a private key sk, outputs the corresponding plaintext (i.e. the message m).

A public key encryption scheme must satisfy the following two properties:

-Validity: a message encrypted using a public key pk must be properly decrypted using the corresponding private key sk.

-Confidentiality: a ciphertext reveals no useful information about the encrypted message unless if one knows the corresponding private key.

Similarly to digital signature schemes, and as it is the case of any cryptographic scheme, the security level ensured by a public key encryption scheme is defined according to the attacker goal's and the means at his disposal.

Possible attacks. If we consider an adversary who aims to recover the plaintext corresponding to a given ciphertext, then we distinguish the following two attacks:

-Total break : Given the public key of a user, the adversary manage to recover the corresponding private key. Thereby, he is able to decrypt and retrieve the plaintext associated to any encrypted message.

-Partial break : The adversary recovers the plaintext corresponding to a given ciphertext without learning the private key.

Sometimes, the adversary is less ambitious and his goal may simply consists in breaking one of the following security properties:

-One-Wayness (OW): an attacker, that does not possess the private key, cannot recover the whole plaintext corresponding to a given ciphertext.

-Indistinguishability (IND): an attacker is unable to distinguish the ciphertexts of two different messages. In other words, given two messages of the same length and a ciphertext c, he cannot determine which message has been encrypted. This security property is also known as semantic security.

-Non-Malleability (NM): given the ciphertext c of an unknown message m, an attacker cannot produce a ciphertext c of a message m such that the two plaintexts m and m are related to each other.

The attacks can also be classified into three categories according to the type of information the attacker holds and the means at his disposal:

-Chosen Plaintext Attack (CPA): the adversary can obtain the ciphertext of any plaintext of his choice. This is possible since the encryption key is publicly known.

-Chosen Ciphertext Attack (CCA1): the adversary can recover the plaintexts corresponding to some chosen ciphertexts without knowing the associated private key. This is made possible by providing him access to a decryption oracle that he can only query until the receipt of the challenge.

-Adaptive Chosen Ciphertext Attack (CCA2): the adversary has access to a decryption oracle even after the receipt of the challenge. Thereby, he can retrieve the plaintext of any ciphertext (except the challenge, obviously) and adapt his queries throughout his attack.

Cryptographic primitives

Threshold Encryption Schemes

In a threshold cryptosystem [START_REF] Yvo | Threshold cryptosystems[END_REF], the public key and the corresponding private key are cooperatively generated by n parties. Then, the private key is shared among them. To decrypt a ciphertext, at least t (which corresponds to the threshold) out of n parties must collaborate. Indeed, t out of n shares of the private key are necessary to recover the whole key.

Used Public Key Encryption Schemes

Hereinafter, we review the main public key encryption schemes that we used to design our privacypreserving protocols, namely ElGamal and Paillier encryption schemes.

ElGamal. The ElGamal public key encryption scheme [START_REF] El | A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms[END_REF] is defined as follows:

-Setup(1 k ): generates the system public parameters pp = (G, p, g) where G is a cyclic group with prime order p and g is a random generator of G.

-KeyGen(pp): randomly chooses the private key sk ∈ Z * p and computes the corresponding public key pk = g sk mod p ∈ G. Modified ElGamal. This variant of ElGamal encryption scheme was introduced by Jarecki and Lysyanskaya [START_REF] Law | Adaptively secure threshold cryptography: Introducing concurrency, removing erasures[END_REF] and is defined as follows:

-Setup(1 k ): generates the system public parameters pp = (G, p) where G is a cyclic group with prime order p.

-KeyGen(pp): randomly chooses y 1 , y 2 ∈ R Z * p and g 1 , g 2 ∈ R G. The private key sk is defined as sk = (y 1 , y 2 ) and the corresponding public key pk = (g 1 , g 2 , h = g y 1 1 g y 2 2 ).

-Enc(pp, pk, m):

randomly selects a random s ∈ Z * p . The encryption of a message m ∈ G consists of the triplet (c 1 , c 2 , c 3 ) where c 1 = g s 1 mod p, c 2 = g s 2 mod p and c 3 = m • h s .
-Dec(pp, sk, c 1 , c 2 , c 3 ): using the private key sk, it decrypts the ciphertext (c

1 , c 2 , c 3 ) by computing m = c 3 c y 1 1 c y 2 2 .
The modified ElGamal scheme is also semantically secure under the DDH assumption. Hereinafter, we provide a proof sketch which is taken almost verbatim from [START_REF] Juels | Coercion-resistant electronic elections[END_REF].

Proof (sketch). Let us assume that there exists a PPT algorithm A which can break the semantic security of the Modified ElGamal encryption scheme. Then, there exists an algorithm B that breaks the DDH assumption. To prove this claim, we construct B as follows. B receives on input from its challenger C a quadruple (g 1 , g 2 , h 1 , h 2 ) of the DDH problem and has to determine whether it is a DH quadruple or not. So, B constructs the public key for the Modified ElGamal scheme as follows. It chooses x 1 and x 2 at random, sets h = g x 1 1 g x 2 2 . Then, it provides A with (g 1 , g 2 , h) as the challenge parameters of the Modified ElGamal scheme.

Given two messages m 0 and m 1 (that A has output and wants to be challenged on), B proceeds as follows. First, it flips a random bit b. Then, it computes the ciphertext of m b as

(h k 1 , h k 2 , mh kx 1 1 h kx 2 2 )
where k is chosen at random. If the given quadruple is a DH one, then the ciphertext has the right distribution. Indeed, for some k ,

h k 1 = g k 1 , h k 2 = g k 2 and (h x 1 1 h x 2 2 ) k = h k .
Otherwise (if it is not a DH quadruple), then one can easily check that A gets no information at all about the encrypted message (as, to decrypt the ciphertext, A must know the secrets x 1 and x 2 which are information theoretically hidden by h). -Enc(pk, m):

selects a random r ∈ Z * n . The encryption c of a message m ∈ Z n is computed as c = g m P r n mod n 2 .
-Dec(sk, c): decrypts the ciphertext c to recover m by computing m = (c λ mod n 2 )-1 n µ mod n.

The Paillier cryptosystem is semantically secure against chosen plaintext attacks (IND-CPA) under the Decisional Composite Residuosity (DCR) assumption.

Commitment

Commitments are quite useful in cryptography as they allow an entity to commit to a message m without revealing it. Once the commitment generated, the committing party must not be able to modify the committed message (i.e. claim that she has committed to a different message). Besides, she may sometimes need to open the commitment so as to ensure that she has really committed to a given message. To this end, the committing party must provide some additional information. Hereinafter, we provide a more formal definition.

Definition and Security Requirements

Definition 3.38 (Commitment). More formally, a commitment scheme consists of the following three algorithms:

-Setup(1 k ) : a probabilistic algorithm, on input an integer k, outputs the system public parameters pp.

-Commit(pp, m) : a probabilistic algorithm, on input a message m and the public parameters pp, outputs a commitment C to a message m as well as some opening information R required for the verification of the validity of the commitment.

-Open(pp, m, C, R) : a deterministic algorithm, on input a message m, a commitment C and the opening information R, outputs either 0 or 1 depending on the validity of C with respect to m and R.

A commitment scheme should meet the following two security requirements:

Cryptographic primitives

-Hiding: a commitment should not reveal any information about the committed message m. More formally, given two messages m 1 and m 2 and a commitment C to one of them, an adversary should not be able to tell which message has been committed to.

-Binding: a commitment C should be bound to the original message m so that the committing entity is unable to modify m afterwards. More formally, an adversary should not be able to output a commitment C along with two distinct pairs (m, r) and (m , r ) such that Open(pp, m, C, r) = Open(pp, m , C, r ) = 1.

It is worth mentioning that a commitment scheme cannot be both perfectly hiding and perfectly binding. In what follows, we recall one of the widely used commitment schemes, namely the Pedersen's commitment [START_REF] Pryds | Advances in Cryptology -CRYPTO '91: Proceedings, chapter Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing[END_REF].

Pedersen's Commitment

The Pedersen's commitment scheme works as follows:

-Setup(1 k ): takes as input an integer k and outputs the system public parameters pp = (G, p, g, h) where G is a cyclic group of prime order p and g and h are two random generators of G.

-Commit(pp, m): given a message m ∈ Z p , it randomly selects a value r ∈ Z p . Then, it computes C = g m h r as the commitment to m. The algorithm returns (C, r).

-Open(pp, m, C, r): given C, m and r as input, this algorithm checks whether C ? = g m h r . If so, it outputs 1 and 0 otherwise. The Pedersen's commitment is perfectly hiding but only computationally binding under the DL assumption.

Indeed, given a commitment C m = g m h r , every possible m is equally likely to be the value committed in C m . Indeed, if we consider m, m and a value r, ∃r such that g m h r = g m h r . Indeed, if we denote by a the discrete logarithm of h in the base g (i.e. h = g a , with a = 0), then r = m-m +ra a . Consequently, C m leaks no information about m which proves that the Pedersen's commitment is perfectly hiding.

Let us now explain why the binding property only holds under the DL assumption. To do so, we consider a committing party which is able to retrieve a, the discrete logarithm of h in the base g (i.e. h = g a ). Thus, it can select another message m ∈ Z * p and compute the corresponding r such that m + ra = m + r a (i.e. g m h r = g m h r ). Thereby, the Pedersen's commitment C m can be opened to two distinct pairs (m, r) and (m , r ) which makes it not binding anymore.

Proofs of Knowledge

The notion of Zero-Knowledge interactive proofs was put forward by Goldwasser, Micali and Rackoff in 1985 [START_REF] Goldwasser | The knowledge complexity of interactive proof-systems[END_REF]. Such proofs enable a prover P to convince a verifier V that a given statement is valid without revealing anything else. Shortly after that, Feige, Fiat and Shamir [FFS] introduced the concept of Zero Knowledge Proof of Knowledge, denoted ZKPK, where the prover also convinces the verifier that he knows a secret satisfying a given statement without revealing anything else about it. Since then, ZKPKs have been widely used to design various protocols such as Schnorr's identification protocol described hereinafter. But first, we formally define zero-knowledge proofs of knowledge and recall the different properties that they must satisfy.

Chapter 3 : Mathematical Tools and Cryptographic Building Blocks 3.3.5.1 Zero-Knowledge Proof of Knowledge Definition 3.39 (Zero Knowledge Proof of Knowledge). A Zero Knowledge Proof of Knowledge (ZKPK), is an interactive protocol between a prover P and a verifier V, which meets the following three requirements:

-Completeness: a valid prover, i.e. knowing the secret s, should be accepted by an honest verifier with overwhelming probability.

-Soundness: a malicious prover, i.e. that does not know any secret verifying the statement R, should be rejected by an honest verifier with overwhelming probability. This means that, using any prover accepted with overwhelming probability, it should be possible to build a Turing machine, called knowledge extractor, that is able to retrieve a valid secret s .

-Zero Knowledge: the verifier knows nothing about the secret s except that it satisfies the statement R and that it is known to the prover. In other words, ∀ V, one should be able to build a simulator S whose output is indistinguishable from the transcript of the interactions between an honest prover P and V.

In the sequel, we will use the usual notation PoK{α, β : statement about α, β} introduced by Camenisch and Stadler [START_REF] Camenisch | Proof systems for general statements about discrete logarithms[END_REF] and where Greek letters correspond to the secrets known to the prover P. Besides, we will only consider proofs that fulfill the zero-knowledge requirement with respect to an honest verifier. Such zero-knowledge proofs are called honest-verifier ZKPKs and, as shown below, they can be easily turned into non-interactive ZKPKs. It is also noteworthy to mention that there exists a generic technique that transforms honest-verifier ZK proofs into ZK proofs with respect to any verifier [START_REF] Damgård | Honest verifier vs dishonest verifier in public coin zero-knowledge proofs[END_REF]. An honest-verifier ZKPK consists of three main rounds, namely commitment, challenge and response. Hereinafter, we provide more details about these three rounds through the review of Schnorr's identification protocol.

Schnorr's protocol. Schnorr's identification protocol, proposed in [START_REF] Schnorr | Advances in Cryptology -EUROCRYPT '89: Workshop on the Theory and Application of Cryptographic Techniques[END_REF], allows a prover to convince a verifier of his knowledge of the discrete logarithm x, in the base g, of a public value y (i.e. it enables the generation of the proof PoK{α : y = g α }). The protocol works as follows.

-Setup(1 k ): Generate the system public parameters pp = (p, q, Z p , g) where p and q are two prime integers such that q|p -1 and q > 2 k , whereas g ∈ Z * p .

-KeyGen(pp): Selects x ∈ R Z * q as the prover's private key. The associated public key is y = g x mod p.

-Interactions(pp, P(x), V(y)): The prover P, who holds the secret x, and the verifier V engage in the following three round protocol:

1. Commitment: P randomly chooses a ∈ R Z q , then produces the commitment t = g a mod p. The witness t is sent to V.

2.

Challenge: once V receives t, it chooses a random challenge c ∈ Z p and transmits it to P.

3.

Response: upon the receipt of the challenge c, P computes s = a + cx mod q and provides it to V.

The verifier is convinced that P really knows the secret x only if t = g s y -c mod p.

Cryptographic primitives

OR Proofs of knowledge. An OR zero knowledge proof of knowledge enables the prover to convince the verifier that he knows a secret satisfying one statement among several ones without revealing which statement is met. If we consider the case of a prover knowing the discrete logarithm of one of two values in the base g, then the proof is denoted PoK{α : y = g α ∨ y = g α }.

The interactions between the prover and the verifier are as follows:

-Commitment: P randomly chooses a ∈ R Z q , then produces the commitment t = g a mod p corresponding to the statement that is valid. For the other statement, the commitment is computed as t = g s y -c mod p where c and s are selected at random. Both t and t are sent to V.

-Challenge: Once V receives t and t , it chooses a random challenge c ∈ Z q and forwards it to P.

-Response: P computes C = c ⊕ c and s = a + Cx mod q then provide V with (C, c , s, s ).

The verifier is convinced that P really knows the discrete logarithm of y or y only if c = C ⊕ c , t = g s y -C mod p and t = g s y -c mod p.

Designated Verifier Proof (DVP). Introduced by Jakobsson, Sako and Impagliazzo [START_REF] Jakobsson | Advances in Cryptology -EUROCRYPT '96: International Conference on the Theory and Application of Cryptographic Techniques Saragossa, chapter Designated Verifier Proofs and Their Applications[END_REF], a Designated Verifier Proof (DVP) is a particular ZKPK that only convinces the intended verifier and is completely useless for anyone else. A DVP mainly consists of a proof that either "I know the private key associated to the designated verifier public key" or the given statement R is true. Thus, upon the receipt of the proof, the designated verifier will be convinced that the statement R is valid whereas anyone else has no means to know if it is the case since the intended verifier can always prove himself to be the designated verifier. All he has to do is prove the knowledge of the private key associated to the designated verifier public key.

Non-Interactive Zero-Knowledge Proof of Knowledge

In 1986, Fiat and Shamir [FS87, PS00] introduced a technique enabling to convert a three round honest verifier ZKPK into a non-interactive ZKPK denoted NIZKPK. The main idea consists in letting the prover compute the challenge c instead of having the verifier select it at random. More precisely, P computes it as the output of a hash function H : {0, 1} * → Z p taking as input the commitment t and the involved public values. Hereinafter, we convert Schnorr's interactive protocol into a non-interactive one using Fiat-Shamir heuristic. The Setup and KeyGen algorithms remain the same whereas the Interactions protocol is updated as follows:

-Commitment: P randomly chooses a ∈ R Z q , then produces the commitment t = g a mod p. The witness t is sent to V.

-Challenge: P computes the challenge c = H(t, g, y).

-Response: Given the challenge c, P computes s = a + cx mod q and provides the tuple (t, c, s) to V. Upon their receipt, the verifier first computes t = g s y -c mod p. V is convinced that P really knows the secret x only if c = H(t , g, y).

The obtained NIZKPK may also be turned into a signature scheme commonly called signature of knowledge and denoted SoK. For that, the prover has just to add the corresponding message m to the input of the hash function (i.e. replace the challenge by c = H(m, t) and compute everything else as described above). Actually, this is how a Schnorr's signature as detailed in Section 3.3.2.5 is created.

Chapter 3 : Mathematical Tools and Cryptographic Building Blocks

Conclusion

In this chapter, we first recalled the required mathematical tools as well as the computational hardness assumptions that we rely on in this thesis. Then, we gave an overview on the concept of provable security. Finally, we formally defined the main cryptographic primitives needed in this thesis and reviewed the constructions of the used schemes such as the recent algebraic MAC scheme due to Chase et al. [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF].

In the next chapter, we introduce new cryptographic schemes that either provide an additional feature that was not supported by previous proposals, or simply improve their efficiency. Afterwards, in Chapters 5-6, using our designed schemes as building blocks, we propose four privacy-preserving protocols that are suitable for resource constrained environments such as SIM cards while achieving a good trade-off between efficiency and the required security and privacy requirements.

Chapter 4 To cope with the various constraints stemming from devices with limited computational resources and applications stringent time constraints, more efficient cryptographic primitives need to be introduced. In this respect, we propose in this chapter five new efficient cryptographic primitives, that are of independent interest, and formally prove that they meet the expected security requirements. More precisely, they consist of a partially blind signature scheme [BBD + 16], an algebraic MAC scheme [START_REF] Barki | Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials[END_REF], a sequential aggregate Message Authentication Code (MAC) scheme [START_REF] Araújo | Remote electronic voting can be efficient, verifiable and coercion-resistant[END_REF], and two pre-Direct Anonymous Attestations (Pre-DAA) schemes. The introduced primitives are used as the main building blocks of our practical privacy-preserving protocols detailed in subsequent chapters.

Design of Efficient Cryptographic Primitives Contents

A Perfectly Unlinkable Partially Blind Signature Scheme

As previously mentioned in Section 3.3.2.3, a partially blind signature scheme allows the receiver of the signature R and the signer S to agree on a common information info to be added to the blind signature of a message m. Thereby, S can keep some control over the signed message by adding an expiration date or a validity period for example. In what follows, we detail our new partially blind signature scheme which enables multiple presentations of the same signature in an unlinkable way.

Scheme Description

Our partially blind signature scheme, which is based on the MAC GGM scheme due to Chase et al. [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF] (reviewed in Section 3.3.1.3), works as follows:

Setup(1 k ) creates the system public parameters denoted by pp = (G 1 , G 2 , G T , q, g, h, h, e) where G 1 , G 2 , G T are three cyclic group of prime order q, a k-bit prime, and g, h are two random generators of G 1 such that log g h is unknown, h is a random generator of G 2 and e : G 1 × G 2 → G T is a Type-3 bilinear map. In the sequel, all computations on exponents are computed modulo q.

KeyGen(pp) randomly selects

→ x = (x 0 , x 1 , . . . , x n ) ∈ R Z n+1 q
as the signer's private key, denoted by sk, and picks a value x0 ∈ R Z q to build a commitment C x 0 = g x 0 h x0 to the secret x 0 . Denoted by iparams, (C x 0 , X 1 = h x 1 , . . . , X n = h xn , X0 = hx 0 , . . . , Xn = hxn ) corresponds to the signer's public parameters.

Sign(R(

→ m), S(sk), inf o, pp, iparams) is an interactive protocol between a receiver R who wants to get a signature on a block of messages → m = (m 1 , . . . , m n ) and a signer S who holds sk and acts as the signer. The partially blind signature on m and inf o is produced as follows:

1. Blind: R sends the common value info, a commitment C→ m = h r X m 1 1 . . . X mn n to the block of messages → m = (m 1 , m 2 , . . . , m n ) where r ∈ R Z * q as well as a ZKPK π 1 ensuring that the commitment is well-formed. The proof π 1 is defined as

π 1 = P oK{α 1 , α 2 , . . . , α n , β : C→ m = h β X α 1 1 . . . X αn n }. 2. CSign: Before signing the commitment C→ m , S first checks the validity of π 1 . If so, he computes u = u x 0 (C→ m (X n ) info ) b where b ∈ R Z * q and u = h b .
Then, he provides R with the partially blind signature ((u, u ), info) as well as a ZKPK π 2 proving that u = u x 0 +x 1 m 1 +...+x n-1 m n-1 +xn(mn+info) h br . π 2 is defined as

π 2 = P oK{α, β, γ : u = u α (C→ m (X n ) info ) β ∧ C x 0 = g α h γ ∧ u = h β }.
3. Retrieval: Upon their receipt, R first checks the validity of π 2 . If so, it unblinds (u, u ) to retrieve the signature σ = (u, u ) = (u, u u r ) = (u, u x 0 +x 1 m 1 +...+x n-1 m n-1 +xn(mn+info) ) on both → m and info.

Receiver R

Signer S Private input: m 1 , . . . , mn Private input: Verify(pp, iparams, → m, info, σ) checks the validity of the digital signature σ = (u, u ) with respect to a message → m and a common information info. This algorithm works differently depending on whether the verifier holds (x 1 , . . . , x n ) or not. If so, the signature is valid only if u = 1 and u = u x 0 +x 1 m 1 +...+x n-1 m n-1 +xn(mn+info) . Otherwise, the verifier relies on pairing computations so as to check the validity of σ. More precisely, the signature is valid only if u = 1 and e(u, X0 ) • e(u, X1 ) m 1 • e(u, X2 ) m 2 • • • e(u, Xn ) mn+info = e(u , h).

x 0 , x 1 , . . . , xn Choose r, a 1 , a 2 , . . . , an, b 1 R ← Z * q Compute C→ m ← h r X m 1 1 . . . X mn n t 1 ← h b 1 X a 1 1 . . . X an n Compute c = H(Ch, t 1 ) Ch ←---------------- Choose Ch ∈ R Z * q ∀i ∈ {1, . . . , n}, s i ← a i + cm i mod q C→ m , π 1 =(c,s 1 ,...,sn,s) -----------------→ Compute t 1 = h s X s 1 1 . . . X sn n (C→ m ) -c and s ← b 1 + cr mod q Check H(Ch, t 1 ) ? = c and Choose b R ← Z * q Compute u ← h b Compute u ← u x 0 (C→ m (Xn) info ) b Choose a 1 , a 2 , a 3 R ← Z * q Compute t 1 ← u a 1 (C→ m X inf o n ) a 2 t 2 = g a 1 h a 3 , t 3 ← h a 2 and c 1 ← H(t 1 , t 2 , t 3 ) Compute t 1 ← u s 1 (C→ m X inf o n ) s 2 u -c 1 (u,u ),π 2 =(c 1 ,s 1 ,s 2 ,s 3 ) ← -----------------Compute s 1 ← a 1 + c 1 x 0 mod q t 2 ← g s 1 h s 3 (Cx 0 ) -c 1 and t 3 ← h s 2 u -c 1 Compute s 2 ← a 2 + c 1 b mod q Check H(t 1 , t 2 , t 3 ) ? = c 1 Compute s 3 ← a 3 + c 1 x0 mod q Compute u ← u u r

Security Analysis

As mentioned in section 3.3.2.3, a partially blind signature scheme should provide one-more unforgeability and unlinkability. Hereinafter, we prove that our partially blind signature scheme fulfills these two properties. It is even perfectly unlinkable.

Theorem 4.1. Our partially blind signature scheme is one-more unforgeable, in the random oracle model, under the assumption 1 (see Section 3.23).

Proof (sketch). In the sequel, OPBS will refer to an oracle that, on input a block of messages → m = (m 1 , m 2 , . . . , m n ) hidden using a Pedersen's commitment, outputs a partially blind signature σ = (u, u ) on → m and info. Let A be an adversary against the one-more unforgeability of our partially blind signature PBS scheme. Using A as a subroutine, we construct a reduction B against the assumption 1. The adversary A succeeds only if, after L signature queries to the OPBS oracle, he manages to output, with non negligible probability, L + 1 valid ( → m, info, σ) tuples on distinct messages and such that ∀i, j ∈ {1, . . . , L + 1}, j = i,

→ m i + -→ info i = → m j + -→
info j where -→ info i = (0, 0, . . . , 0

(n-1) times , info i ).
Let C denote the challenger of the game. B receives on input from C the parameters pp = (q, G 1 , G 2 , G T , e) as well as (h, X 1 = h x 1 , . . . , X n = h xn , h, X0 = hx 0 , X1 = hx 1 , . . . , Xn = hxn ) and has access to the oracle O 1 which, on input → m ∈ Z n q , outputs a pair P = (u, u x 0 +x 1 m 1 +...+xnmn ) where u ∈ R G 1 . B can choose g and C x 0 at random. Indeed, ∀x 0 ∈ Z q , ∃x 0 ∈ Z q such that C x 0 = g x 0 h x0 . Then, it provides A with (pp, h, g, h, C x 0 , X 1 , X 2 , . . . , X n , X0 , X1 , . . . , Xn ) and, through queries to O 1 , it perfectly simulates A's requests to the OPBS oracle. More precisely, B uses the replay technique as well as the soundness property of π 1 to retrieve the values of r and → m = (m 1 , m 2 , . . . , m n ). Then, it calls on the oracle O 1 with → m = (m 1 , m 2 , . . . , m n + info) as input to get a valid pair (u, u = u x 0 +m 1 x 1 +...+(mn+info)xn ). Thus, B can compute (u, u = u u r ), a partially blind signature on → m and info. As for π 2 , B can perfectly simulate it in the random oracle model. Therefore, B provides A with (u, u ) as well as π 2 .

Eventually, after L calls to OPBS, A returns with non negligible probability L + 1 valid ( → m, info, σ) tuples such that ∀i, j ∈ {1, . . . , L + 1}, j = i,

→ m i + -→ info i = → m j + -→
info j where -→ info i = (0, 0, . . . , 0 Theorem 4.2. Our partially blind signature scheme is perfectly unlinkable.

Proof (sketch). The view of the signer upon an execution of the protocol Sign consists of a Pedersen's commitment C→ m = h r X m 1 1 . . . X mn n , a proof π 1 and the computed pair (u = h b , u = u x 0 +m 1 x 1 +...+(mn+inf o)xn h br ).

The proof π 1 is a classical variant of Schnorr's proof of knowledge of a discrete logarithm (c.f. Section 3.3.5.1) which is an honest verifier ZKPK. Therefore, it does not reveal any information on r and the m i 's. Besides, the Pedersen's commitment is perfectly hiding (c.f. Section 3.3.4.2). Therefore, neither C→ m nor π 1 leaks any information about → m. Consequently, only the pair (u, u ) may help the adversary A link a valid message/signature pair to a specific execution of the Sign protocol.

Let us consider a randomized version (v = ũl , v = (ũ ) l ) of a valid signature (ũ, ũ ) on the set of messages (m 1 , m 2 , . . . , m n + info) distinct from (m 1 , m 2 , . . . , m n + info). For any such pair (v, v ), there exists l , r such that v = u l and C→

m = h r X m 1 1 . . . X m n n . Let u = u u r , then v = (u ) l .
Therefore, (v, v ) could also have been obtained during the signing session that led to the transcript (C→ m , π 1 , u, u ). Consequently, our partially blind signature is perfectly unlinkable.

An Improved Algebraic MAC Scheme

In this section, we design a new algebraic MAC scheme which relies on a pairing-free variant of the Boneh-Boyen's signature scheme [START_REF] Canard | New results for the practical use of range proofs[END_REF]. Unlike Chase et al. algebraic MAC schemes [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF], our proposal only requires a sole secret key regardless of the number of messages to be signed. Furthermore, MACs generated using our scheme may be publicly verifiable. In what follows, we detail our construction which can be applied to both a single message as well as a block of messages.

Scheme Description

MAC BB

Our algebraic MAC scheme for a single message m, referred to as MAC BB , is defined through the following four algorithms:

Setup(1 k ) creates the system public parameters pp = (G, p, h, g 0 , g 1 , g) where G is a cyclic group of prime order p, a k-bit prime, and h, g 0 , g 1 , g are four random generators of G.

KeyGen(pp) selects a random value y ∈ R Z p as the issuer's private key and optionally computes the corresponding public key Y = g y 0 .

MAC(m, y) picks two random values r, s ∈ R Z p and computes A = (g m 1 g s h)

1 y+r . The MAC on a message m consists of the triple (A, r, s). A,r,s,y) checks the validity of the MAC (A, r, s) with respect to the message m. The MAC is valid only if (g m 1 g s h)

Verify(m,

1 y+r = A.

MAC n

BB

Our algebraic MAC scheme can be generalized to support a block of n messages (m 1 , . . . , m n ). This extension is referred to as MAC n BB and works as follows:

Setup(1 k ) creates the system public parameters pp = (G, p, g 1 , g 2 , . . . , g n , h, g 0 , g) where G is a cyclic group of prime order p, a k-bit prime, and h, g, g 0 , g 1 , . . . , g n are random generators of G.

KeyGen(pp) selects a random value y ∈ R Z p as the issuer's private key and optionally computes the corresponding public key Y = g y 0 .

4 . . . g mn n g s h)

1 y+r = A.
One particular feature of our algebraic MAC scheme is that anyone can verify the validity of a given MAC by himself (i.e. without neither knowing the private key y nor querying the Verify algorithm). Indeed, a MAC on → m = (m 1 , . . . , m n ) consists of the triple (A, r, s) such that A = (g m1 1 g m 2 2 . . . g mn n g s h)

1 y+r . This implies that A y+r = g m 1 1 g m 2 2 . . . g mn n g s h and hence, B = g m 1 1 g m 2 2 . . . g mn n g s h • A -r = A y . Therefore, if the issuer of the MAC also provides a ZKPK defined as π = PoK{γ : B = A γ ∧Y = g γ 0 }, then its receiver will be convinced that the MAC is valid.

Furthermore, unlike both algebraic MAC schemes due to Chase et al. [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF], the issuer does not have to hold as many private keys as messages but rather a sole private key regardless of the number of messages.

Security Analysis

Security of MAC BB

Theorem 4.3. Our MAC BB scheme is sUF-CMVA 1 secure under the gap q -SDH -III assumption.

Proof (sketch). Let A be an adversary who breaks the sUF-CMVA security of our MAC BB scheme with non-negligible probability. Using A, we construct a reduction B against the q -SDH assumption in gap-DDH groups (which implies the gap q -SDH -III assumption). A can ask for tags on any message of his choice and receives the corresponding tags (A i , r i , s i ) for i ∈ {1, . . . , q} where q denotes the number of requests to the OMAC oracle. Eventually, A outputs his forgery (A, r, s) for the message m. We distinguish the following two types of forgeries:

• Type-1 Forger: an adversary that outputs a valid tag (A, r, s) on m such that (A, r) = (A i , r i ) for all i ∈ {1, . . . , q}.

• Type-2 Forger: an adversary that outputs a valid tag (A, r, s) on m such that (A, r) = (A j , r j ) for some j ∈ {1, . . . , q} and (m, s) = (m j , s j ).

We show that, regardless of their type, both adversaries can be used to break the gap q -SDH assumption. However, the reduction works differently for each type of forger. Consequently, B initially chooses a random bit c mode ∈ {1, 2} which indicates its guess for the type of forgery that A will output.

If c mode = 1: B receives on input from its q -SDH challenger, denoted by C, the public parameters (g 0 , g 1 , h) and the public key Y = g y 0 as well as q random, and distinct, triplets

(A i , r i , m i ) such that A i = (g m i 1 h) 1 r i +y for i ∈ {1, . . . , q}.
As it is against the gap q -SDH -III assumption, B has access to a DDH oracle, denoted by ODDH, that decides whether a given quadruple (g, h, g x , h y ) is a valid Diffie-Hellman quadruple (i.e. whether x ? = y mod p) or not. B also randomly chooses v ∈ R Z p and computes g = g v

1 . Thereby, it can provide A with the public parameters (g 0 , g 1 , h, g, Y ) and answer his requests as follows:

-OMAC requests: given m as input, B first picks one of the received triplets (A i , r i , m i ) that has not already been used. Then, it computes s i such that m+vs i = m i . Finally, it provides A with the triplet (A i , r i , s i ) which is a valid MAC on m (i.e. A y+r i i = g m 1 g s i h). Thereby, the simulation of this oracle is perfect.

-OVerify requests: given a quadruple (A, r, s, m), B first verifies that A = 1 and computes B = A -r g m 1 g s h. Then, it provides the quadruple (g 0 , A, Y, B) as input to the ODDH oracle so as to know if it is valid or not. B forwards the oracle's answer to A, thus perfectly simulating OVerify.

Eventually, after q queries to OMAC and q v queries to OVerify, A outputs his forgery (A, r, s) on m such that it breaks the sUF-CMVA security of our MAC BB scheme. Using these values, B computes m = m + sv and outputs its forgery (A, r, m), thus breaking the q -SDH assumption with the same advantage as A.

If c mode = 2: A Type-2 adversary A is rather used, as a subroutine, to construct a reduction B against the DL problem. In such case, B receives on input from its DL challenger, denoted by C, the challenge (g 1 , H = g v 1 ). Its goal is to find the value v. For this purpose, it first randomly chooses (y, g 0 , h) ∈ R Z p × G 2 and computes Y = g y 0 . B also sets g as g = H. Thereby, it can provide A with the public parameters (g 1 , g 0 , h, g, Y ) and answer his requests as follows:

-OMAC requests: as it holds y, B can generate a valid MAC (A, r, s) on any queried message m. To do so, it simply computes A = (g m 1 g s h)

1 y+r where r, s ∈ Z * p .

-OVerify requests: given a quadruple (A, r, s, m), B computes à = (g m 1 g s h)

1 y+r . To check its validity, and answer A's query, B verifies whether à ? = A.

Eventually, after q queries to OMAC and q v queries to OVerify, A outputs his forgery (A, r, s) on m such that he breaks the sUF-CMVA security of our MAC BB scheme. By assumption, (A, r) is equal to one of the (A j , r j ) output by the OMAC oracle following A's request for some j ∈ {1, . . . , q}. Since (A, r) = (A j , r j ), then A y+r j j = g m j 1 g s j h = A y+r = g m 1 g s h and so, g m j 1 g s j = g m 1 g s . We therefore necessarily have s j = s, otherwise this would imply that m = m j (contradicting the fact that we have supposed (m, s) = (m j , s j )). Thereby, g = g ( m-m j s j -s ) 1

. Using the values (m, m j , s, s j ), B can recover v, hence breaking the DL problem. If B can break the DL problem, then it can break the q -SDH problem (by finding the discrete logarithm y of g y in the base g).

B can guess which type of forgery a particular adversary A will output with probability 1/2. So, B can break the gap q -SDH problem with probability ε/2 where ε is the probability that A breaks the sUF-CMVA security of our MAC BB scheme. Therefore, under the gap q -SDH assumption, our MAC BB scheme is sUF-CMVA secure.

Security of MAC n

BB

Theorem 4.4. Our MAC n BB scheme is sUF-CMVA secure under the assumption that MAC BB is sUF-CMVA.

Proof (sketch). Let A be an adversary who breaks the unforgeability of our MAC n BB scheme with non-negligible probability. Using A, we construct an algorithm B against the unforgeability of MAC BB . A can ask for tags on blocks of messages

→ m 1 = (m 1 1 , . . . , m 1 n ), → m 2 = (m 2 1 , . . . , m 2 n ), . . . ,
→ m q = (m q 1 , . . . , m q n ) and receives the corresponding tags (A i , r i , s i ) for i ∈ {1, . . . , q}. Eventually,

An Improved Algebraic MAC Scheme

A outputs his forgery (A, r, s) for the block of messages → m = (m 1 , . . . , m n ). We differentiate two types of forgers:

• Type-1 Forger: an adversary that outputs a forgery where (A, r, s) = (A i , r i , s i ) for i ∈ {1, . . . , q}.

• Type-2 Forger: an adversary that outputs a forgery where (A, r, s) = (A i , r i , s i ) for some i ∈ {1, . . . , q} and (m 1 , . . . , m n ) = (m i 1 , . . . , m i n ).

We show that any of these two forgers can be used to forge MAC BB tags. The reduction works differently for each type of forger. Therefore, B initially chooses a random bit c mode ∈ {1, 2} that indicates its guess for the type of forgery that A will emulate.

If c mode = 1: B receives on input from its MAC BB challenger, denoted by C, the public parameters (g 0 , g 1 , g, h) as well as the public key Y = g y 0 . Then, B constructs the public parameters for A as follows: for i ∈ {2, . . . , n}, B chooses α i ∈ R Z * p and computes g i = g α i 1 . The parameters g 0 , g 1 , g, h and Y are the same as those sent by C. B can answer A's requests as follows:

-OVerify requests: when A sends a verify request to B on (A, r, s) and a block of messages (m 1 , . . . , m n ), B computes M = m 1 + α 2 m 2 + . . . + α n m n . Then, it queries its MAC BB Verify oracle on (A, r, s, M ) and forwards the oracle's answer to A.

-OMAC requests: when A sends a tag request to B on the block of messages (m 1 , . . . , m n ), B queries the

MAC BB oracle on M = m 1 + α 2 m 2 + . . . + α n m n . Thus, B obtains the tag (A i , r i , s i ). It sends back (A i , r i , s i ) to A which is a valid MAC n BB tag on (m 1 , . . . , m n ).
Eventually, A outputs his forgery (A, r, s) on the block of messages (m 1 , . . . , m n ). Using these values, B directly outputs its MAC BB forgery (A, r, s) on M = m 1 + α 2 m 2 + . . . + α n m n . Therefore, B breaks the unforgeability of MAC BB with the same advantage as A.

If c mode = 2: In this case, A is rather used as a subroutine to construct a reduction B against the DL problem. B receives on input from its DL challenger, denoted by C, the challenge (g, H = g v ). The goal of B consists in finding the value of v. For that purpose, it first randomly chooses (y, g 0 , h) ∈ R Z p × G 2 and computes Y = g y 0 . Then, it chooses I ∈ {1, . . . , n} and (n -1) random values α i ∈ Z * p . It computes, for i = I, g i = g α i and defines g I = H. B can answer A's requests as follows:

-OVerify requests: when A sends a verify request to B on (A, r, s) and a block of messages -OMAC requests: as it holds y, B can generate a valid MAC (A, r, s) on any queried block of messages (m 1 , . . . , m n ). To this end, it chooses r, s ∈ R Z * p and computes A = (g m 1 1 . . . g mn n g s • h)

→ m = (m 1 , . . . , m n ), B computes à = (g m 1 1 . . . g mn n g s • h)
1 y+r .
Eventually, A outputs his forgery (A, r, s) on a block of messages → m = (m 1 , . . . , m n ). By assumption, (A, r, s) is equal to one of A's requests, let us say (A i , r i , s i ), but it is a forgery on a new block of messages. Therefore, (m i 1 , . . . , m i n ) = (m 1 , . . . , m n ) (one can easily show that there is at least one difference between the two blocks of messages). So, with probability 1 n , m i I = m I . Thus, since (A, r, s) = (A i , r i , s i ), we have g m 1 1 g m 2 2 . . . g mn n = g

m i 1 1 g m i 2 2 . . . g m i n n . Hence, the discrete logarithm v of H = g I in the base g is equal to: v = n j =I α j (m j -m i j ) m i I -m I
. Therefore, B can find v

A New Sequential Aggregate MAC Scheme

Upon their receipt, U 2 first verifies the validity of π 1 . If so, he computes the sequential aggregate MAC σ 2 = (w, w ) = (u t2 , (u u m 2 x 2 ) t 2 ) on both m 1 and m 2 where t 2 ∈ R Z * q . U 2 also builds a ZKPK π 2 defined as π 2 = PoK{α, β :

w = u α ∧ w = (u u m 2 β ) α ∧ X 2 = h β }.
Verify(pp, σ 2 , m 1 , m 2 , sk 1 , sk 2 ) checks whether σ 2 = (w, w ) is a valid aggregate of the MAC of U 1 on m 1 and U 2 on m 2 . More precisely, it verifies if u = 1 and w ? = w x 0 +m 1 x 1 +m 2 x 2 .

Security Analysis

Theorem 4.5. Our sequential aggregate MAC scheme is existentially unforgeable under chosen message and verification attacks (EUF-CMVA), in the random oracle model, under the assumption that MAC GGM is UF-CMVA secure.

Proof (sketch). In the sequel, we consider the setting proposed by Lu et al. [LOS + 06] where, in order to add a new public parameter pk (associated to a secret key sk) to KeyList, the users must first prove the knowledge of the associated secret key sk. Thereby, the reduction will be able to answer all the adversary's MAC queries. Consequently, during Join queries (see Section 3.3.2.4), whenever A requests to add a public parameter pk to KeyList, he must additionally prove the knowledge of the associated secret key sk.

Let A be an adversary against the EUF-CMVA security of our sequential aggregate MAC scheme. Using A as a subroutine, we construct a reduction B against the UF-CMVA security of the MAC GGM scheme 2 . B receives on input from its challenger, denoted by C, the public parameters of the MAC GGM scheme (pp, C x 0 = g x 0 h x , X 1 = h x 1 ) and has access to two oracles: OMAC GGM and OVerify. OMAC GGM provides it with a valid MAC GGM on any message of its choice whereas OVerify allows it to check the validity of any (message, MAC) pair. So, B queries OMAC GGM on the message m = 03 and receives σ 0 = (u, u = u x 0 ), a MAC on 0. Then, it sets g = u, Y 0 = u and sk * = x 1 (which is unknown to it) and provides A with pp = (G, q, g, h, Y 0 ) as well as X 1 , the public parameter associated to sk * . Next, B initializes the key list KeyList as empty, and through queries to the OMAC GGM and OVerify oracles, it perfectly simulates A's requests as follows:

-OJoin requests: whenever A asks B to add a public parameter pk i to the key list KeyList, B rewinds A so as to extract the associated secret key sk i . Next, it appends pk i to KeyList and saves the pair (pk i , sk i ) (B will subsequently require it to simulate aggregate MACs).

-OAggMAC requests: to answer A's query for an aggregation of a message m i to the aggregate MAC σ i = (u i , u i ) on M i = (m i,1 , . . . , m i,l ) under the secret keys SK i = (sk i,1 , . . . , sk i,l ), B proceeds as follows. First, B verifies the validity of σ i (it aborts if it is not valid). To do so, it

computes u i = u i u -j=l j=1 sk i,j m i,j i
, then queries the OVerify oracle on input (u i , u i ) and the message m = 0. If so (i.e. OVerify returns 1), B queries the OMAC GGM oracle on m i as input. Thereby, it obtains σ = (u, u ). Since all the public parameters P K i = (pk i,1 , . . . , pk i,l ) belong to KeyList, then B knows all the associated secrets SK i = (sk i,1 , . . . , sk i,l ). Consequently, B selects a random t ∈ Z q and computes σ = (u t , (u u j=l j=1 sk i,j m i,j ) t ) that it returns to A. The latter is a valid aggregate MAC on the block of messages (m i,1 , . . . , m i,l , m i ).

-OVerify requests: to verify whether σ i = (u i , u i ) is a valid sequential aggregate MAC on M i = (m i,1 , . . . , m i,l ) under the set of keys SK i = (sk i,1 , . . . , sk i,l ) corresponding to the public parameters P K i = (pk i,1 , . . . , pk i,l ), B proceeds as follows. It first computes

u i = u i u -j=l j=1,sk i,j =sk * sk i,j m i,j i
. Then, it calls on the OVerify oracle on input (u i , u i ). The answer is forwarded to A, hence perfectly simulating this oracle.

Eventually, A outputs with non negligible probability a sequential aggregate MAC σ * = (σ * 1 , σ * 2 ) on the block of messages M * = (m * 1 , . . . , m * l ) under SK * = (sk 1 , . . . , sk l ) such that he breaks the EUF-CMVA security of our sequential aggregate MAC scheme. A's forgery is successful only if the following three conditions hold: (1) Verify(σ * , M * , SK * ) = 1; (2) for all sk j = sk * , there exists an associated pk j ∈ KeyList; and (3) for some j * ∈ {1, . . . , l}, sk j = sk * and m * j * has not been queried to the OMAC GGM oracle. The condition (1) means that σ * is a valid sequential aggregate MAC, whereas (2) implies that B knows all the secret keys sk i for i ∈ {1, . . . , l} except sk * . Thereby, B can recover a valid

MAC σ = (σ * 1 , σ * 2 σ * 1 -sk j =sk * sk j m * j ) = (σ * 1 , (σ * 1 )
x 0 +m * j * x 1 ) on a message m * j that has never been queried to the OMAC GGM oracle. Hence, B can break the UF-CMVA security of MAC GGM . Therefore, our sequential aggregate MAC scheme is EUF-CMVA secure, in the random oracle model, under the assumption that MAC GGM is UF-CMVA.

Practical Pre-Direct Anonymous Attestation Schemes

As previously mentioned in Section 3.3.2.2, Direct Anonymous Attestation (DAA) is a privacypreserving authentication protocol initially introduced so as to allow the anonymous authentication of Trusted Platform Modules (TPMs) (e.g. a secure element in a smartphone), to an external party (e.g. a service provider). Thereby, the TPM can be remotely authenticated whilst preserving the privacy of its owner.

This cryptographic protocol, and some of its extensions such as Intel's Enhanced Privacy ID (EPID) [START_REF] Brickell | Enhanced privacy id: A direct anonymous attestation scheme with enhanced revocation capabilities[END_REF][START_REF] Brickell | Enhanced privacy ID from bilinear pairing for hardware authentication and attestation[END_REF], have been widely deployed in millions of chips. Usually, part of the attestation computation is delegated to the host embedding it (i.e. PC or smartphone), which is generally much more powerful. However, in use cases related to M2M and IoT, the host may be as resource constrained as the TPM. Furthermore, any malware residing in the host may enable the tracking of the TPM owner.

In [BFG + 13], Bernhard et al. proposed a DAA scheme, referred to as Pre-DAA, where all the computations on the user's side are performed by the TPM. However, similarly to [START_REF] Brickell | Enhanced privacy id from bilinear pairing for hardware authentication and attestation[END_REF], their proposal requires pairing computations on the user's side. Thus, it is inappropriate for SIM cards as they do not support such heavy computations.

In this subsection, we propose two Pre-DAA schemes where all computations on the platform side are carried out by the TPM. Both schemes are suitable for resource constrained devices like SIM cards as they require no pairing computations on the platform side. The first scheme is built upon MAC GGM [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF] whereas the second is based on a pairing-free variant of the Boneh Boyen's signature scheme [START_REF] Canard | New results for the practical use of range proofs[END_REF]. In what follows, we detail both proposals which involve three main entities: an issuer I, a user U (more precisely, his platform P) and some verifiers V, and formally prove their security.

Schemes Description

MAC GGM -based Pre-DAA Scheme

Our first Pre-DAA scheme, which is based on MAC GGM , works as follows:

Setup(1 k ) creates the system public parameters denoted by pp = (G 1 , G 2 , G T , p, g, h, h, H, e)

where G 1 , G 2 and G T are three cyclic groups of order p, a k-bit prime, g, h are two random generators of G 1 whereas h is a random generator of G 2 , H is hash function H : {0, 1} * → G 1 4.4. Practical Pre-Direct Anonymous Attestation Schemes (that will be considered as a random oracle in the security proof) and e : G 1 x G 2 → G T is a Type-3 bilinear map.

IKeyGen(pp) randomly chooses x 0 , x 1 ∈ R Z * p . Then, it sets the issuer's private key gmsk as gmsk = (x 0 , x 1 ). The associated public key is gmpk = (C x 0 = g x 0 h x0 , X 1 = h x 1 , X0 = hx 0 , X1 = hx 1 ) where x0 ∈ R Z * p . UKeyGen(pp, i) outputs the private/public endorsement key pair (esk i , epk i ) of user i which will be subsequently used to authenticate him. It also selects a random values s 1 ∈ R Z * p as the secret key of user i, denoted sk i . Join(i, esk i , gmsk) allows a new user i to join the group and get his group signing key gsk i . To this end, he computes C s 1 = X s 1 1 a commitment to his secret s 1 . The user also builds a ZKPK π 1 defined as π 1 = PoK{α : C s 1 = X α 1 }. Once done, he provides the issuer with C s 1 as well as the proof π 1 . Upon their receipt, the issuer first verifies the validity of the proof π 1 . Then, he picks b ∈ R Z * p and generates a pair (u, u ) associated to s 1 where u = h b and u = u x 0 C b s 1 = u x 0 +s 1 x 1 . Finally, the user is provided with (u, u ) along with a ZKPK π 2 defined as

π 2 = PoK{α, β, γ : u = h α ∧ u = u β C α s 1 ∧ C x 0 = g β h γ }.
If the proof π 2 is valid, the user sets his group signing key as gsk i = (u, u ).

GSign(gsk i , sk i , m, bsn) enables the group member i, holding sk i and gsk i , to generate an anonymous signature σ on a message m ∈ {0, 1} * and for the basename bsn. The signature is computed as follows. First, the user randomly selects l ∈ R Z * p and computes gsk l i = (w, w ), a randomized version of his group signing key, where w = u l and w = (u ) l . Then, he computes c 1 = w s 1 and T = H(bsn) s 1 . A signature on m and for bsn consists of σ = (w, w , c 1 , T, π 3 ) where π 3 = PoK{α :

c 1 = w α ∧ T = H(bsn) α }.
GVerify(gmpk, m, bsn, σ) checks the validity of a signature σ with respect to a message m and a basename bsn. The signature is valid only if w = 1, e(w, X0 ) • e(c 1 , X1 ) = e(w , h) and the verification of the proof π 3 succeeds. If so, the algorithm returns 1. Otherwise, it outputs 0.

Identify T (T , sk i ) returns 1 if the transcript T resulting from the execution of the Join protocol has been produced with the secret key sk i = s 1 (i.e. if C s 1 is a commitment to s 1 ). Otherwise, it returns 0.

Identify S (σ, m, bsn, sk i ) returns 1 if the signature σ on the message m could have been produced using the secret key sk i = s 1 (i.e. if T = H(bsn) s 1 ). Otherwise, it returns 0.

Link(gmpk, σ, m, σ , m , bsn) returns 1 if both σ and σ are valid signatures on, respectively, m and m with respect to the same basename bsn = ⊥ and were produced by the same user (i.e. if T = T ). Otherwise, it returns 0.

Possible extension. Our MAC GGM -based Pre-DAA scheme can be extended to support more than one secret (or a secret and some attributes). Hereinafter, we detail the extension in the case of two secrets.

Setup(1 k ) creates the system public parameters denoted by pp = (G 1 , G 2 , G T , p, g, h, h, H, e) where G 1 , G 2 and G T are three cyclic groups of order p, a k-bit prime, g, h are two random generators of G 1 whereas h is a random generator of G 2 , H is hash function H : {0, 1} * → G 1 (that will be considered as a random oracle in the security proof) and e : G 1 x G 2 → G T is a Type-3 bilinear map.

IKeyGen(pp) randomly chooses x 0 , x 1 , x 2 ∈ R Z * p . Then, it sets the issuer's private key gmsk as gmsk = (x 0 , x 1 , x 2 ). The associated public key is gmpk

= (C x 0 = g x 0 h x0 , X 1 = h x 1 , X 2 = h x 2 , X0 = hx 0 , X1 = hx 1 , X2 = hx 2 ) where x0 ∈ R Z * p .
UKeyGen(pp, i) outputs the private/public endorsement key pair (esk i , epk i ) of user i which will be subsequently used to authenticate him. It also selects two random values s 1 , s 2 ∈ R Z * p . The secret key of user i is defined as sk i = (s 1 , s 2 ). Join(i, esk i , gmsk) allows a new user i to join the group and get his group signing key gsk i .

To this end, he selects r ∈ R Z * p then computes C s 1 = X s 1 1 h r , C s 2 = X s 2 2 and C = h s 1 , three commitments to his secrets s 1 and s 2 . The user also builds a ZKPK π 1 defined as

π 1 = PoK{α, β, γ : C s 1 = X α 1 h β ∧ C s 2 = X γ 2 ∧ C = h α }.
Once done, he provides the issuer with C s 1 , C s 2 and C as well as the proof π 1 and a signature S = Sign esk i (C s 1 , C s 2 , C) on them computed using esk i . Upon their receipt, the issuer first verifies the validity of the signature and the proof π 1 . Then, he picks b ∈ R Z * p and generates a pair (u, u ) associated to both s 1 and s 2 where u = h b and u = u x 0 (C s 1 C s 2 ) b . Finally, the user is provided with (u, u ) along with a ZKPK π 2 defined as

π 2 = PoK{α, β, γ : u = h α ∧ u = u β (C s 1 C s 2 ) α ∧ C x 0 = g β h γ }.
If the proof π 2 is valid, the user sets his group signing key as gsk i = (u, u = u u r ) = (u, u x 0 +s 1 x 1 +s 2 x 2 ). GSign(gsk i , sk i , m, bsn) enables the group member i, holding sk i and gsk i , to generate an anonymous signature σ on a message m ∈ {0, 1} * and for the basename bsn. The signature is computed as follows. First, the user randomly selects r 1 ∈ R Z * p and computes gsk r 1 i = (w, w ), a randomized version of his group signing key, where w = u r 1 and w = (u ) r 1 . Then, he randomly selects z 1 , z 2 , z 3 ∈ R Z * p and computes

c 1 = w s 1 h z 1 , c 2 = w s 2 h z 2 , c = w g z 3 , V = g -z 3 X z 1 1 X z 2 2
and T = H(bsn) s 1 . A signature on m and for bsn consists of σ = (w, c 1 , c 2 , c , V, T, π 3 ) where

π 3 = PoK{α, β, γ, λ, φ : c 1 = w α h γ ∧ c 2 = w β h λ ∧ V = g -φ X γ 1 X λ 2 ∧ T = H(bsn) α }.
GVerify(gmpk, m, bsn, σ) checks the validity of a signature σ with respect to a message m and a basename bsn. The signature is valid only if w = 1, e(w, X0 )•e(c 1 , X1 )•e(c 2 , X2 ) = e(c V, h) and the verification of the proof π 3 succeeds. If so, the algorithm returns 1. Otherwise, it outputs 0.

Identify T (T , sk i ) returns 1 if the transcript T resulting from the execution of the Join protocol has been produced with the secret key sk i = (s 1 , s 2 ) (i.e. if C s 1 , C s 2 and C are commitments to s 1 and s 2 ). Otherwise, it returns 0.

Identify S (σ, m, bsn, sk i ) returns 1 if the signature σ on the message m could have been produced using the secret key sk i = (s 1 , s 2 ) (i.e. if T = H(bsn) s 1 ). Otherwise, it returns 0.

Link(gmpk, σ, m, σ , m , bsn) returns 1 if both σ and σ are valid signatures on, respectively, m and m with respect to the same basename bsn = ⊥ and were produced by the same user (i.e. if T = T ). Otherwise, it returns 0.

BB-based Pre-DAA Scheme

Our second Pre-DAA scheme, which is based on a pairing-free variant of the Boneh Boyen's signature scheme [START_REF] Canard | New results for the practical use of range proofs[END_REF], is a direct variant of our KVAC system [START_REF] Barki | Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials[END_REF] subsequently detailed in Chapter 6. It is noteworthy to mention that shortly after we designed this pre-DAA scheme, Camenisch et al. proposed a similar scheme [START_REF] Camenisch | Anonymous attestation using the strong diffie hellman assumption revisited[END_REF].

Our BB-based Pre-DAA scheme works as follows:

Setup(1 k ) creates the system public parameters pp = (G 1 , G 2 , G T , p, g 0 , g 1 , g 2 , h, f, g0 , H, e) where G 1 , G 2 and G T are three cyclic groups of order p, a k-bit prime, (h, g 0 , g 1 , g 2 , f ) are five random generators of G 1 whereas g0 is a random generator of G 2 , H is hash function H : {0, 1} * → G 1 (that will be considered as a random oracle in the security proof) and e : G 1 x G 2 → G T is a Type-3 bilinear map.

IKeyGen(pp) randomly chooses y ∈ R Z * p as the issuer's private key and computes the associated public keys Y = g y 0 and W = gy 0 . UKeyGen(pp, i) outputs the private/public endorsement key pair (esk i , epk i ) of user i which will be subsequently used to authenticate him. It also picks two random values s 1 , s 2 ∈ R Z * p . The secret key of user i is defined as sk i = (s 1 , s 2 ). Join(i, esk i , gmsk) allows a new user i to join the group and obtain his group signing key gsk i .

To this end, he computes C s 1 = g s 1 1 and C s 2 = g s 2 2 , two commitments to his secrets s 1 and s 2 respectively. The user also builds a ZKPK π 1 defined as π 1 = PoK{α, β :

C s 1 = g α 1 ∧ C s 2 = g β 2 }
. Once done, he provides the issuer with C s 1 and C s 2 as well as the proof π 1 and a signature S = Sign esk i (C s 1 , C s 2 ) on them produced using the private key esk i . Upon their receipt, the issuer first verifies the validity of the signature and the proof π 1 . Then, he picks r, s ∈ R Z * p and computes A = (C s 1 C s 2 g s 2 h) 1 y+r . He also builds a ZKPK π 2 to ensure that A is well-formed. π 2 is defined as

π 2 = PoK{γ : B = A γ ∧ Y = g γ 0 } where B = C s 1 C s 2 g s 2 h • A -r = A y .
Finally, the user is provided with (A, r, s ) along with the proof π 2 . If π 2 is valid, the user sets his group signing key as gsk i = (A, r, s u ) where s u = s 2 + s is only known to U.

GSign(gsk i , sk i , m, bsn) enables the group member i, holding sk i and gsk i , to anonymously sign a message m ∈ {0, 1} * and with respect to the basename bsn. The signature σ is computed as follows. First, the user randomly selects l, t ∈ R Z * p and computes B 0 = A l , a randomized version of his group signing key. Then, he computes

C = g ls 1 1 g lsu 2 h l B -r 0 = A l y = B y 0 , E = C 1 l f t
as well as T = H(bsn) s 1 . An anonymous signature on m and for bsn consists of σ = (B 0 , C, E, T, π 3 ) where

π 3 = PoK{α, β, λ, δ 1 , δ 2 , θ, γ : E = C α f β ∧ E • h -1 = g δ 1 1 g δ 2 2 • B λ 0 • f β ∧ C = E θ f γ ∧ T = H(bsn) δ 1 }.
GVerify(gmpk, m, bsn, σ) checks the validity of a signature σ with respect to a message m and a basename bsn. The signature is valid only if e(C, g0 ) = e(B 0 , W ) and the verification of the proof π 3 succeeds. If so, the algorithm returns 1. Otherwise, it outputs 0.

Identify T (T , sk i ) returns 1 if the transcript T resulting from the execution of the Join protocol has been produced with the secret key sk i = (s 1 , s 2 ) (i.e. if C s 1 and C s 2 are commitments to respectively s 1 and s 2 ). Otherwise, it returns 0.

Identify S (σ, m, bsn, sk i ) returns 1 if the signature σ on the message m could have been produced using the secret key sk i = (s 1 , s 2 ) (i.e. if T = H(bsn) s 1 ). Otherwise, it returns 0.

Link(gmpk, σ, m, σ , m , bsn) returns 1 if both σ and σ are valid signatures on, respectively, m and m with respect to the same basename bsn = ⊥ and were produced by the same user (i.e. if T = T ). Otherwise, it returns 0.

Efficiency Comparison

In Table 4.1, we compare the efficiency of our two pre-DAA schemes with that of the most efficient DAA schemes. More precisely, we provide the total estimated cost of generating a signature as well as the computational cost of verifying it, since they are the most time critical phases. We use the following notation: kG i and kG j i respectively denote k exponentiations in the group G i and k j-multi-exponentiations in the group G i whereas kP refers to k pairing computations. When attributes are supported, n, r and u are used to denote the total number of attributes, the number of revealed attributes and the number of unrevealed ones respectively.

As shown in Table 4.1, LRSW-based DAA schemes are more efficient than q -SDH-based schemes. More specifically, our MAC GGM -based scheme have the most efficient signing operation. Furthermore, aside from [START_REF] Camenisch | Anonymous attestation using the strong diffie hellman assumption revisited[END_REF] which was introduced just after our BB-based pre-DAA scheme, all others q -SDH-based DAA schemes require the platform to perform either pairing computations or computations in G 2 (or G T ). Thus, unlike our BB-based pre-DAA scheme, they are not suitable for SIM cards (since the latter cannot handle such computations). It is also worth mentioning that, as stated in [START_REF] Camenisch | Anonymous attestation using the strong diffie hellman assumption revisited[END_REF], the ZKPKs associated to the schemes [BL10, Che10, CU15] are flawed (they do not really prove the possession of a valid membership credential).

LRSW based DAA schemes

Schemes Sign Verify CPS10 [CPS10] 7G 1 2G 2 1 , 4P CU15-1 [CU15] 7+n+u G 1 2G 1 , 2G n 1 , 2G r 1 , 2G u 1 , 6P CDL16-1 [CDL16c] 9G 1 2G 2 1 , 4P Our MAC GGM -based scheme 6G 1 2G 2 1 , 3P q-SDH based DAA schemes Schemes Sign Verify CF08 [CF08] 3G 1 , 2G T , 2G 2 1 , 1P 1G 2 1 , 2G 3 1 , 1G 5 T , 3P Ch10 [Che10] 3G 1 , 1G T , 1G 3 T 1G 2 1 , 1G 2 2 , 1G 4 T , 1P BL10 [BL10] 3G 1 , 1G 2 1 , 1G T , 1P 1G 2 1 , 1G 2 2 , 1G 4 T , 1P CU15-2 [CU15] 5G 1 , 1G 2+u 1 , 2P 1G 2 1 , 1G 4+n 1 , 2P CDL16-2 [CDL16b] 4G 1 , 1G 2+u 1 , 1G T , 1P 1G 2 1 , 1G 2 2 , 1G 4+n T , 1P CDL16 4 [CDL16a] 5G 1 , 2G 2 1 , 1G 2+u 1 1G 2 1 , 1G 3 1 , 1 G 5+n 1 , 2P Our BB-based scheme 3G 1 , 4G 2 1 , 1G 3+u 1 1G 2 1 , 2G 3 1 , 1G 4+u 1 , 1G r+1 1 , 2P

Security Analysis

In this section, we formally prove that our two pre-DAA schemes provide the expected security properties (i.e. correctness, traceability, non-frameability and anonymity) in the random oracle model. As usual, correctness follows by inspection. Proof (sketch). Let A be an adversary who breaks the traceability requirement of our MAC GGMbased Pre-DAA scheme with non-negligible probability. As mentioned in section 3.3.2.2, we distinguish the following two types of forgers:

• Type-1 Forger: An adversary that manages to output a signature σ that cannot be traced to a secret key previously queried to the OJoin I oracle.

• Type-2 Forger: An adversary that outputs two signatures σ 0 and σ 1 under the same secret sk i and for the same basename bsn, and yet are unlinkable.

In what follows, we show that a Type-1 forger can be used as a subroutine to construct an algorithm B against the assumption 1, whereas Type-2 forgery cannot happen. Initially, B chooses a random bit c mode ∈ {1, 2} that indicates its guess for the type of forgery that A will output.

If c mode = 1: B receives on input from its challenger, denoted by C, the public parameters (G 1 , G 2 , G T , e, p, h, h) as well as X 1 = h x 1 , X 2 = h x 2 , X0 = hx 0 , X1 = hx 1 and X2 = hx 2 . As it is against the assumption 1, B has access to the oracle O 1 which, on input m 1 , m 2 ∈ Z p , outputs the pair P = (t, t x 0 +m 1 x 1 +m 2 x 2 ) where t ∈ R G 1 . B chooses the generator g and the value of C x 0 at random. Thereby, it can provide A with the public parameters pp of the scheme and answers his (i.e. A's) requests as follows:

4.4. Practical Pre-Direct Anonymous Attestation Schemes -OAdd(i) requests: B creates a new user i and picks two random values s 1 ∈ R Z * p as his secret key sk i . B also generates user's i public/private endorsement key pair denoted by (esk i , epk i ).

-OAddCorrupt(i) requests: B does nothing.

-OJoin I (i) requests: Upon the receipt of C s 1 , C s 2 , C, the proof π 1 and the signature Sign, B first checks the validity of both Sign and π 1 . If so, it uses the soundness property of π 1 to recover s 1 , s 2 and r. Then, it queries the O 1 oracle on s 1 and s 2 to obtain the pair (u, u = u x 0 +s 1 x 1 +s 2 x 2 ). As it knows r, B can compute u = u u r . Besides, in the ROM, π 2 can be perfectly simulated using standard techniques. Thereby, B can answer A's request by providing him with the pair (u, u ) as well as the proof π 2 .

-OCorrupt(i) requests: B provides A with the secret key sk i and the group signing key gsk i of user i.

-OGSign(i, m, bsn) requests: As it holds both sk i and gsk i , B can generate a signature on m and for bsn, that it returns to A.

Eventually, A outputs with non-negligible probability a valid triple (σ, m, bsn) such that the signature σ was produced using an sk i that is not associated to any of the calls to the OJoin I oracle. Using the soundness of π 3 , B extracts s 1 and s 2 as well as w = c g -z 3 . Thus, B obtains a valid pair (w, w = w x 0 +s 1 x 1 +s 2 x 2 ) on the pair (s 1 , s 2 ) that has never been queried to the O 1 oracle. Consequently, using A, B can break the assumption 1.

If c mode = 2: A eventually outputs (σ 0 , m 0 , σ 1 , m 1 , bsn, sk) such that σ 0 and σ 1 are valid signatures on respectively m 0 and m 1 , and for the same basename bsn. Besides, the two signatures were produced using sk (as, by definition, both Identify S (σ 0 , m 0 , bsn, sk) and Identify S (σ 1 , m 1 , bsn, sk) output 1). Owing to the completeness of the proof π 3 , the tags T 0 and T 1 associated to respectively σ 0 and σ 1 are necessarily defined as T 0 = H(bsn) s 1 and T 1 = H(bsn) s 1 . Therefore, we have T 0 = T 1 . By definition, A wins if the output of Link(gmpk, σ 0 , m 0 , σ 1 , m 1 , bsn) is 0 (i.e. T 0 = T 1 ). Thus, such forgery can never occur. Therefore, if A can break the traceability property of our MAC GGM -based Pre-DAA scheme, then B can break assumption 1 with the same probability. Thus, under the assumption 1, our Pre-DAA scheme provides the traceability requirement in the ROM. Theorem 4.7. Our MAC GGM -based pre-DAA scheme is non-frameable, in the ROM, under the one-more discrete logarithm (OMDL) assumption.

Proof (sketch). Let A be an adversary against the non-frameability requirement of our MAC GGMbased Pre-DAA scheme. As previously mentioned in section 3.3.2.2, we distinguish the following two types of forgeries:

• Type-1 Forger: An adversary that manages to output a signature σ on m and for bsn that is traced to a specific user that has never produced such a signature.

• Type-2 Forger: An adversary that outputs two signatures σ 0 and σ 1 that are linkable even though they should not (i.e. they were either produced with different sk i or with respect to two distinct basenames).

In what follows, we show that a Type-1 forger can be used to construct a reduction B against the OMDL assumption whilst a Type-2 forgery cannot happen. Initially, B chooses a random bit c mode ∈ {1, 2} that indicates its guess for the type of forgery that A will output.

Chapter 4 : Design of Efficient Cryptographic Primitives

If c mode = 1: B receives on input from its challenger C a random instance (h u 1 , h u 2 , . . . , h un ) of the OMDL problem where h is a random generator of G 1 . As it is against the one-more DL assumption, B has access to a DL oracle. The adversary A picks three random values x 0 , x 1 , x 2 ∈ R Z * p as the issuer's private key and publishes the associated public key gmpk = (C

x 0 = g x 0 h x0 , X 1 = h x 1 , X 2 = h x 2 , X0 = hx 0 , X1 = hx 1 , X2 = hx 2 ) where x0 ∈ R Z * p .
B answers A's requests as follows:

-OAdd(i) requests: B creates a new user u i and randomly selects s i 2 ∈ R Z * p . Using its input of the OMDL problem, it sets s i 1 such as C i = h s i 1 = h u i . The user's secret key is defined as

sk i = (s i 1 , s i 2 )
where s i 1 is unknown to both B and A. B also generates u i 's public/private endorsement key pair denoted by (esk i , epk i ).

-OAddCorrupt requests: B does nothing.

-

OJoin U (i) requests: B computes C s i 2 = X s i 2 2 and sets C i = h u i . The value of C s i 1 can be randomly chosen. Indeed, ∀s i 1 ∈ Z p , ∃r ∈ Z p such that C s i 1 = h r X s i 1 1 .
Since B holds esk i , then it can compute the signature S. As for π 1 , B can perfectly simulate it in the random oracle model. If the protocol does not abort, B obtains a valid group signing key gsk i = (u, u ) associated to sk i = (s i 1 , s i 2 ), where s i 1 is unknown to both A and B, as well as the proof π 2 . Using the soundness property of π 2 , B retrieves the value of b (required to simulate the OGSign oracle).

-OCorrupt(i) requests: B calls on the DL oracle with h u i as input. Thereby, it recovers u i = s i 1 . Thus, it can provide A with the secret key sk i = (s i 1 , s i 2 ) along with the group signing key gsk i of user i.

-OGSign(i, m, bsn) requests: As it holds s i 2 and gsk i , B can compute most of the required values except c 1 , T and the proof π 3 . Using b, which was extracted during the run of Join U from π 2 , B sets c 1 = C br 1 i h z 1 = w s i 1 h z 1 where z 1 ∈ R Z * p . To compute T , B proceeds as follows: it randomly selects l ∈ R Z * p and sets H = H(bsn) = h l . Thus, T = H(bsn) u i = C l i . During subsequent calls to OGSign on input the same i and bsn, B returns the same value T . As for π 3 , it can be easily simulated in the ROM. Hence, B can perfectly simulate the GSign algorithm.

Eventually, after d calls to the OCorrupt oracle, A outputs with non negligible probability a valid signature σ on m and for bsn such that Identify S (σ, m, bsn, sk i ) outputs 1 whereas the user holding sk i has never produced a signature on that m and for bsn. By definition of the experiment, we know that the corresponding user is honest. Thus, the value u i associated to the user's unknown secret s i 1 is still in the input of the OMDL problem. Using the soundness property of π 3 , B retrieves the associated secrets s i 1 and s i 2 where s i 1 = u i . Thus, B recovers u i , the discrete logarithm of the challenge h u i . By outputting u i along with the d secrets {u j } j=d j=1 that it has obtained by querying the DL oracle, B breaks the OMDL assumption.

If c mode = 2: A eventually outputs two valid signatures σ 0 and σ 1 , on respectively m 0 and m 1 , that are linkable even though they should not. That is, they were either generated using two different keys (sk 0 and sk 1 ) or/and are for different basenames (bsn 0 and bsn 1 ).

Let sk b = (s b 1 , s b 2 ) denote the key used to generate σ b and sk = (s 1 , s2 ) the key output by A. If A's attack against the non-frameability property is successful, then this implies that condition 6 of the non-frameability experiment is true. In particular, owing to the completeness of π 3 , we have

T 0 = H(bsn 0 ) s 0 1 and T 1 = H(bsn 1 ) s 1 1 (4.1)
Chapter 4 : Design of Efficient Cryptographic Primitives -OGSign(i, m, bsn) requests: C uses sk i and gsk i to generate a signature σ on m and for bsn, that it returns to A.

Eventually, A chooses (i 0 , i 1 , bsn, m) that he provides as input to OCH b . The oracle outputs a signature σ produced by user b. A's goal is to guess the value of b. Even after receiving his challenge, A can still query the OAdd, OAddCorrupt, OJoin U , OCorrupt and OGSign oracles but with some restrictions. More precisely, he cannot call the OCorrupt oracle on i 0 or i 1 . Besides, he is not allowed to query the OGSign oracle with either (i 0 , m, bsn) or (i 1 , m, bsn) as input. Otherwise, he would trivially win the game.

So, A eventually outputs his guess b . Let S 0 be the event that b = b in Game 0 (i.e. the event that A wins Game 0) and S 1 denote the event that b = b in Game 1. We have

Adv anon-b A (1 k ) = |Pr[Exp anon-b A (1 k ) = b] -1/2| = |Pr[S 0 ] -1/2|.
We construct the Game 1 as follows:

Game 1: It is the same game as Game 0 except that we replace T = H(bsn) s b 1 by a random value and simulate the proof π 3 . Such a proof can be easily simulated in the ROM using classical techniques. Under the XDH assumption, A cannot detect this change. In fact, one can easily construct a XDH distinguisher D with an advantage of solving the XDH problem, denoted by

Adv XDH , satisfying |Pr[S 0 ] -Pr[S 1 ]| ≤ Adv XDH (1 k ).
In Game 1, the challenger provides no information (in a strong information theoretic sense) about the bit b to the adversary A. This is due to the perfectly hiding property of the Pedersen's commitment (see Section 3.3.4.2). Let us consider a valid signature (w, c 1 , c 2 , c , V ). For any group signing key gsk i = (ũ, ũ ), there exists l, z1 , z2 , z3 such that w

= ũl , w = (ũ ) l, c 1 = w s1 h z1 , c 2 = w s2 h z2 , c = w g z3 and V = g -z 3 X z1 1 X z2 2 .
Besides, the only value involving the user's secret key and computed in a non-perfectly hiding way (i.e. T = H(bsn) s b 1 ) was replaced by a random value. Therefore, Pr[S 1 ] = 1/2. Thus, we have

Adv anon-b A (1 k ) = |Pr[Exp anon-b A (1 k ) = b] -1/2| = |Pr[S 0 ] -Pr[S 1 ]| ≤ Adv XDH (1 k )
Consequently, under the XDH assumption, the adversary's advantage is negligible. Therefore, we conclude that our MAC GGM -based Pre-DAA scheme satisfies the anonymity requirement under the XDH assumption.

Security of our BB-based Pre-DAA Scheme

Theorem 4.9. Our BB-based pre-DAA scheme is traceable, in the ROM, under the q -SDH assumption.

Proof (sketch). Let A be an adversary who breaks the traceability requirement of our BB-based Pre-DAA scheme with non-negligible probability. As previously, we distinguish the following two types of forgers:

• Type-1 Forger: An adversary that manages to output a signature σ that cannot be traced to a secret key previously queried to the OJoin I oracle.

• Type-2 Forger: An adversary that outputs two signatures σ 0 and σ 1 under the same secret sk i and for the same basename bsn, and yet are unlinkable.

In what follows, we show that a Type-1 forger can be used as a subroutine to construct an algorithm B against the q -SDH assumption, whereas Type-2 forgery cannot happen. Initially, B chooses a random bit c mode ∈ {1, 2} that indicates its guess for the type of forgery that A will output.

Practical Pre-Direct Anonymous Attestation Schemes

If c mode = 1: Let A be a Type-1 Forger. Using A, we construct a reduction B against the q -SDH assumption. A can ask for a group signing key on any secret of his choice and receives in response one of the tuples (A i , r i , s i ) for i ∈ {1, . . . , q}, where q denotes the number of requests to the OJoin I oracle. Eventually, A outputs his forgery (σ, m, bsn) that cannot be linked to any of the secret keys previously queried to the OJoin I oracle. We distinguish the following two types of forgeries:

• Type-1.1 Forger: an adversary that outputs a valid signature (σ, m, bsn) on m such that the associated group signing key gsk = (A, r, s u ) satisfies (A, r) = (A i , r i ) for all i ∈ {1, . . . , q}.

• Type-1.2 Forger: an adversary that outputs a valid signature (σ, m, bsn) on m such that the associated group signing key gsk = (A, r, s u ) satisfies (A, r) = (A j , r j ) for some j ∈ {1, . . . , q} whereas sk = sk j .

Hereinafter, we show that both types of adversaries can be used to break the q -SDH assumption. However, the reduction works differently for each type of forger. Consequently, B initially chooses a second random bit c mode ∈ {1, 2} which indicates its guess for the type of forgery that A will output.

If c mode = 1: B receives on input from its q -SDH challenger, denoted by C, the public parameters (G 1 , G 2 , G 3 , e, p, g 0 , g0 , h), the public keys Y = g y 0 and W = gy 0 as well as q random, and distinct, triplets (A i , r i , m i ) such that A i = (g m i 0 h) 1 r i +y for i ∈ {1, . . . , q}. B randomly chooses u, v ∈ R Z p , then computes g 1 = g v 0 and g 2 = g u 0 whereas f is chosen at random. Thereby, B can provide A with the scheme public parameters pp and answer A's requests as follows:

-OAdd(i) requests: B creates a new user i and picks two random values s 1 , s 2 ∈ R Z * p as his secret key sk i . B also generates the public/private endorsement key pair of user i denoted by (esk i , epk i ).

-OAddCorrupt(i) requests: B does nothing.

-OJoin I () requests: Upon the receipt of C s 1 , C s 2 , the proof π 1 and the signature Sign, B first checks the validity of both Sign and π 1 . If so, it uses the soundness property of π 1 to recover s 1 and s 2 . Then, B picks one of the received triplets (A i , r i , m i ) that has not already been used and computes s i such that vs 1 + u(s 2 + s i ) = m i . Finally, it provides A with the triple (A i , r i , s i ) and simulates the proof π 2 . Thus, the user's gets the group signing key gsk i = (A i , r i , s u ) where s u = s 2 + s i .

-OCorrupt(i) requests: B provides A with the secret key sk i and the group signing key gsk i of user i.

-OGSign(i, m, bsn) requests: As it holds both sk i and gsk i , B can generate a signature on m and for bsn, that it returns to A.

Eventually, A outputs with non-negligible probability a valid triple (σ, m, bsn) such that the signature σ was produced using an sk i that has never been involved in any of the calls to the OJoin I oracle. Using the soundness of π 3 , B extracts s 1 , s u , r and l. Thereby, B retrieves the corresponding group signing key (A, r, s u ). By assumption, (A, r) = (A i , r i ) for all i ∈ {1, . . . , q}. Therefore, B outputs (A, r, m) where m = vs 1 + us u as his forgery, hence breaking the q -SDH assumption with the same advantage as A.

If c mode = 2: A Type-1.2 adversary A is rather used, as a subroutine, to construct a reduction B against the DL problem. In such case, B receives on input from its DL challenger, denoted by C, the challenge (g 2 , H = g v 2 ). Its goal is to find the value v. For this purpose, it first randomly chooses (y, h, g 0 , f, g0 ) ∈ R Z p × G 3 1 × G 2 and computes Y = g y 0 and W = gy 0 . B also sets g 1 as g 1 = H. Thereby, it can provide A with the public parameters (h, g 0 , g 1 , g 2 , f, g0 , Y, W ) and answer his requests as follows:

-OAdd(i) requests: B creates a new user i and picks two random values s 1 , s 2 ∈ R Z * p as his secret key sk i . B also generates the public/private endorsement key pair of user i denoted by (esk i , epk i ).

-OAddCorrupt(i) requests: B does nothing.

-OJoin I () requests: Upon the receipt of C s 1 , C s 2 , the proof π 1 and the signature Sign, B first checks the validity of both Sign and π 1 . If so, it uses the soundness property of π 1 to recover s 1 and s 2 . Then, as it holds y, B can generate a valid group signing key

gsk i = (A i , r i , s i u = s 2 + s i ) where s i , r i ∈ R Z * p and A i = (g s 1 1 g s 2 +s i 2 h)
1 y+r i . Finally, it builds π 2 and provides it to A along with gsk i .

-OCorrupt(i) requests: B provides A with the secret key sk i and the group signing key gsk i of user i.

-OGSign(i, m, bsn) requests: As it holds both sk i and gsk i , B can generate a signature on m and for bsn, that it returns to A.

Eventually, after q queries to OJoin, A outputs his forgery (σ, m, bsn) such that it breaks the traceability requirement of our BB-based Pre-DAA scheme. By assumption, the associated group signing key gsk = (A, r, s u ) satisfies (A, r) = (A j , r j ) for some j ∈ {1, . . . , q}. Since (A, r) = (A j , r j ), then A

y+r j j = g s j 1 1 g s j 2 +s j 2 h = A y+r = g s 1 1 g s 2 +s
2 h and so, g

s j 1 1 g s j 2 +s j 2 = g s 1 1 g s 2 +s 2 .
We have s j 1 = s 1 (otherwise the signature output by A would be traced to the user j). Therefore,

g 1 = g ( s j 2 +s j -s 2 -s s 1 -s j 1 ) 2
. Using the values (s 1 , s j 1 , s 2 , s j 2 , s , s j ), B can recover v which is equal to (

s j 2 +s j -s 2 -s s 1 -s j 1
), hence breaking the DL problem. If B can break the DL problem, then it can break the q -SDH problem (by finding the discrete logarithm y of Y = g y 0 in the base g 0 ).

If c mode = 2: A eventually outputs (σ 0 , m 0 , σ 1 , m 1 , bsn, sk) such that σ 0 and σ 1 are valid signatures on respectively m 0 and m 1 , and for the same basename bsn. Besides, the two signatures were produced using sk = (s 1 , s 2 ) (as, by definition, both Identify S (σ 0 , m 0 , bsn, sk) and Identify S (σ 1 , m 1 , bsn, sk) output 1). Owing to the completeness of the proof π 3 , the tags T 0 and T 1 associated to respectively σ 0 and σ 1 are necessarily defined as T 0 = H(bsn) s 1 and T 1 = H(bsn) s 1 . Therefore, we have T 0 = T 1 . By assumption, A wins if the output of Link(gmpk, σ 0 , m 0 , σ 1 , m 1 , bsn) is 0 (i.e. T 0 = T 1 ). Thus, such forgery can never occur. Therefore, if A can break the traceability property of our BB-based Pre-DAA scheme, then B can break the q -SDH assumption. Thus, under the q -SDH assumption, our Pre-DAA scheme provides the traceability requirement in the ROM. Theorem 4.10. Our BB-based pre-DAA scheme is non-frameable, in the ROM, under the onemore discrete logarithm (OMDL) assumption.

Practical Pre-Direct Anonymous Attestation Schemes

Proof (sketch). Let A be an adversary against the non-frameability requirement of our BB-based Pre-DAA scheme. As previously mentioned in Section 3.3.2.2, we distinguish the following two types of forgeries:

• Type-1 Forger: An adversary that manages to output a signature σ on m and for bsn that is traced to a specific user that has never produced such a signature.

• Type-2 Forger: An adversary that outputs two signatures σ 0 and σ 1 that are linkable even though they should not (i.e. they were either produced with different sk i or for two distinct basenames).

In what follows, we show that a Type-1 forger can be used to construct a reduction B against the OMDL assumption whilst a Type-2 forgery cannot happen. Initially, B chooses a random bit c mode ∈ {1, 2} that indicates its guess for the type of forgery that A will output.

If c mode = 1: B receives on input from its challenger C a random instance (g u 1 , g u 2 , . . . , g un ) of the OMDL problem where g is a random generator of G 1 . As it is against the one-more DL assumption, B has access to a DL oracle. The adversary A picks a random value y ∈ R Z * p as the issuer's private key and publishes the associated public keys Y = g y 0 and W = gy 0 where g 0 and g0 are random generators of G 1 and G 2 respectively. B sets g 1 = g whilst the remaining generators are chosen at random. B answers A's requests as follows:

-OAdd(i) requests: B first randomly chooses s i 2 ∈ R Z * p . Then, using its input of the OMDL problem, it sets s i 1 such as

C s i 1 = g s i 1 1 = g u i .
The user's secret key is defined as sk i = (s i 1 , s i 2 ) where s i 1 is unknown to B. B also generates the public/private endorsement key pair of user i denoted by (esk i , epk i ).

-OAddCorrupt(i) requests: B does nothing.

-OJoin U (i) requests:

B sets C s i 1 = g u i and computes C s i 2 = g s i 2
2 . Then, it computes S using esk i . As for π 1 , B can perfectly simulate it in the random oracle model. If the protocol does not abort, B obtains the triplet (A, r, s ) which corresponds to the membership credential (A, r, s u = s i 2 + s ) on s i 1 which is unknown to both A and B.

-OCorrupt(i) requests: B calls on the DL oracle with g u i as input. Thereby, it can recover u i = s i 1 and provide A with the secret key sk i = (s i 1 , s i 2 ) along with the group signing key gsk i of user i.

-OGSign(i, m, bsn) requests: As it holds s u and A, B can directly compute

B 0 = A l where l ∈ R Z * p . As for C, it is computed as C = (g u i g su 2 h) l B -r 0 . Using C, B computes E = C 1 l f t where t ∈ R Z * p . To compute T , B chooses b ∈ Z * p and sets H(bsn) = g b . Consequently, T = H(bsn) s i 1 = (g u i ) b .
For subsequent requests with the same i and bsn, B uses the same tag T . As regards to the proof π 3 , it can be easily simulated in the ROM using classical techniques. Hence, B can perfectly simulate the GSign algorithm.

Eventually, after d calls to the OCorrupt oracle, A outputs with non negligible probability a valid signature σ on m and for bsn, such that Identify S (σ, m, bsn, sk i ) outputs 1 whilst the user holding sk i = (s i 1 , s i 2 ) has never produced a signature on that m and for bsn. By definition of the experiment, we know that the corresponding user is honest. Thus, the u i associated to the user's unknown secret s i 1 is still in the input of the OMDL problem. Using the soundness property of π 3 , B retrieves the associated secrets s i 1 and s i 2 where s i 1 = u i . Thereby, B outputs u i along with the d secrets {u j } j=d j=1 that it has previously obtained by querying the DL oracle, hence breaking the OMDL assumption. , then builds π 1 to obtain the group signing key gsk i .

-OCorrupt(i) requests: C provides A with the secret key sk i and the group signing key gsk i of user i.

-OGSign(i, m, bsn) requests: C uses sk i and gsk i to generate a signature σ on m and for bsn, that it returns to A.

Eventually, A chooses (i 0 , i 1 , bsn, m) that he provides as input to the oracle OCH b . The oracle outputs a signature σ produced by user b. A's goal is to guess the value of b. Even after receiving his challenge, A can still query the OAdd, OAddCorrupt, OJoin U , OCorrupt and OGSign oracles but with some restrictions. More precisely, he cannot call the OCorrupt oracle on i 0 or i 1 . Besides, he is not allowed to query the OGSign oracle with either (i 0 , m, bsn) or (i 1 , m, bsn) as input. Otherwise, he would trivially win the game.

So, A eventually outputs his guess b . Let S 0 be the event that b = b in Game 0 (i.e. the event that A wins Game 0) and S 1 denote the event that b = b in Game 1. We have

Adv anon-b A (1 k ) = |Pr[Exp anon-b A (1 k ) = b] -1/2| = |Pr[S 0 ] -1/2|.
We construct the Game 1 as follows:

Game 1: It is the same game as Game 0 except that we replace T = H(bsn) s b 1 by a random value and simulate the proof π 3 . Such a proof can be easily simulated in the ROM using classical techniques. Under the XDH assumption, A cannot detect this change. In fact, one can easily construct a XDH distinguisher D with an advantage of solving the XDH problem, denoted by

Adv XDH , satisfying |Pr[S 0 ] -Pr[S 1 ]| ≤ Adv XDH (1 k ).
In Game 1, the challenger provides no information (in a strong information theoretic sense) about the bit b to the adversary A. This is due to the zero-knowledge property of π 3 and the fact that, for all B 0 = A l , there exist A , l such that B 0 = A l . Moreover, C is simply equal to B y 0 , so it does not reveal any additional information. Therefore, Pr[S 1 ] = 1/2. Thus, we have

Adv anon-b A (1 k ) = |Pr[Exp anon-b A (1 k ) = b] -1/2| = |Pr[S 0 ] -Pr[S 1 ]| ≤ Adv XDH (1 k )
Consequently, under the XDH assumption, the adversary's advantage is negligible. Thus, we conclude that our BB-based Pre-DAA scheme satisfies the anonymity requirement under the XDH assumption.

Conclusion

In this chapter, we introduced five new cryptographic primitives that are of independent interest and formally proved their security. In subsequent chapters, we show how they can be used to build privacy-preserving protocols. More precisely, we rely on our partially blind signature scheme to design a practical private eCash system intended for applications such as electronic Toll (eToll) and Electric Vehicle Charging (EVC). Then, based on our pairing-free BB-based algebraic MAC scheme, we construct a practical Keyed-Verification Anonymous Credentials (KVAC) system suitable for resource constrained environments such as SIM cards. Our KVAC system can be easily turned into an efficient public key anonymous credentials system. As regards to our Pre-DAA schemes, they are used as the main building block of an anonymous authentication and identification protocol for eSIMs. Finally, our sequential aggregate MAC scheme is used to build an efficient coercion-resistant remote electronic voting scheme that enables multiple elections and credentials revocation. In this chapter, we propose a private eCash system intended for applications that involve a single entity acting as both merchant and bank such as electronic Toll (eToll), electronic Ticketing (eTicketing) and EVC (Electric Vehicle Charging). Our proposal relies on our partially blind signature scheme introduced in Section 4.1 so as to allow multiple presentations of the same signature (payment token) in an unlinkable way. Thereby, users can settle expenses of different amounts using a single reusable payment token. Our eCash system also enables identity as well as token revocations under exceptional circumstances. To show its efficiency even in constrained environment, we implemented it on a GlobalPlatform [START_REF]GlobalPlatform Card Specification V2.3[END_REF] compliant SIM card. In particular, a transaction can be performed in just 205 ms. We also formally proved the security of our proposal in the random oracle model. The results [BBD + 16] presented in this chapter have been published in the paper "Private eCash in Practice" as part of the proceedings of the conference FC'16.

Electronic Cash (eCash)

Electronic Cash (eCash), introduced by Chaum [START_REF] Chaum | Advances in Cryptology: Proceedings of Crypto 82, chapter Blind Signatures for Untraceable Payments[END_REF], is the digital analogue of hard currency where users withdraw electronic coins from a bank and subsequently spend them to merchants. Later, each merchant deposits the received coins to the bank.

Using eCash, user's anonymity is protected both from the bank and merchants. More precisely, eCash prevents the following pairs of events from being linked: a withdrawal and a spending or two spendings by the same user. However, owing to its digital nature, eCash can be easily duplicated and hence, fraudulently spent more than once. Thus, eCash protocols must be designed in a way that enables the detection of "double-spending" and the identification of defrauders.

To be as attractive and user friendly as possible, the user's side of an eCash system is sometimes implemented on a mobile device or even a smart card. Therefore, protocols have to comply with both the limited resources of such environments as well as the stringent delay constraint arising from transactions requirements.

In this chapter, we propose a privacy-preserving electronic payment system for applications such as electronic Toll (eToll) and Electric Vehicle Charging (EVC) which significantly invade user's privacy. Indeed, transactions records may disclose user's location at a given time and reveal personal information such as work, health status or habits. To design our protocol, we leverage a common feature to all these applications: they involve a single entity acting as both bank and merchant. We refer to eCash systems suitable for these particular use cases as Private eCash.

Related Work

Recently, several schemes have addressed the privacy issue in the case of eToll, EVC and public transport. Unfortunately, they have not completely succeeded in finding a good tradeoff between the security as well as privacy requirements, flexibility and performance. In the sequel, we only focus on schemes related to eCash although other approaches exist in the literature [PBB09, BRT + 10, MMCS11].

Public transport users' privacy was tackled in [START_REF] Rupp | P4R: Privacypreserving pre-payments with refunds for transportation systems[END_REF], [START_REF] Milutinovic | Privacypreserving public transport ticketing system[END_REF] and [ALT + 15]. In the first two proposals, users pay for their trips through the use of payment tokens that are worth the highest possible fare. As fares have different values, a refund process is set up to guarantee the accurate charging of users. However, to ensure user's anonymity with respect to the transport company, the scheme of Rupp et al. [START_REF] Rupp | P4R: Privacypreserving pre-payments with refunds for transportation systems[END_REF] entails heavy verifications (i.e. pairing computations) that constrained devices such as SIM cards cannot handle. The proposal of Milutinovic et al. [START_REF] Milutinovic | Privacypreserving public transport ticketing system[END_REF] is also computationally expensive and less efficient than [START_REF] Rupp | P4R: Privacypreserving pre-payments with refunds for transportation systems[END_REF] as refunds are separately collected on distinct refund tokens. Arfaoui et al. [ALT + 15] protocol meets the stringent delay requirement and is efficient even when implemented in constrained environment. It is also the only one allowing anonymity revocation under exceptional circumstances. Nevertheless, their scheme does not enable flexible prices which limits its use.

As regards to EVC user's privacy, it was addressed by Au et al. [ALF + 14]. However, their scheme requires costly ZKPK and is not suitable for time-sensitive applications.

Finally, Day et al. [START_REF] Day | SPEcTRe: spotchecked private ecash tolling at roadside[END_REF] proposed two privacy-preserving payment systems for eToll. The first one only provides partial privacy as it relies on spot checks that record some of the user's spatio-temporal information in order to enable the detection and identification of defrauders. Furthermore, through an exhaustive search on tokens, it is possible to trace all users' trips. In contrast, the second proposal provides full anonymity and enables double spending detection. Unfortunately, to be efficient, users have to hold a large number of tokens where each one can only be used at a specific time. Besides, similarly to eCoupons [START_REF] Liu | An efficient privacy-preserving e-coupon system[END_REF], both proposals do not allow flexible prices, which we believe to be an important issue.

Private eCash System

Framework: The eToll use case 5.3 Private eCash System Framework: The eToll use case

Stakeholders

In the case of the eToll application, our private eCash system involves three main entities: a user U, a toll company T C and a revocation authority RA. The toll company manages a set of tollbooths with which it shares a set of keys → x = (x 0 , x 1 , x 2 ). Besides, it provides each registered user U with a badge that will perform all computations on his behalf. In the sequel, excepted otherwise mentioned, T C will refer to both the toll company and tollbooths. The term user will interchangeably refer to a user and his badge. For security reasons, the role of RA is distributed among several authorities which must collaborate in order to revoke the anonymity of a user or a payment token.

Trust Assumptions and Performance Requirements

Trust assumptions. None of the entities involved in such systems can be fully trusted since each one of them has some incentives to cheat. Only the user's badge is subject to the limited trust assumption that all the computations it performs are correct. Nevertheless, any attempt to cheat by tampering it must be detected.

Performance requirement. To be effective and suitable for most use cases, the eCash must meet a stringent delay constraint. In fact, a transaction must be performed in at most 300 ms [START_REF]White Paper: Mobile NFC in Transport[END_REF]. This requirement must be fulfilled whilst taking into account the limited computational capabilities of SIM cards which, we recall, cannot handle heavy computations and, in particular, pairing computations.

System Framework

To model an eToll pricing system, six different phases are required: (1) A Setup phase enables the initialization of the public parameters and the generation of required keys. (2) The Registration phase, as its name implies, allows a user to register to the eToll system. (3) The Token Issuance phase provides legitimate users with a unique reusable payment token. (4) During Access Control, a user uses his payment token to be granted access at tollbooths. (5) The Toll Computation phase allows the computation of the user's bill based on his current token value. Finally, (6) the Revocation phase, which may be triggered under exceptional circumstances, enables user's anonymity and token revocations. These six phases can be modelled through the following set of algorithms and protocols.

1. The Setup phase, which aims to initialize the system parameters as well as the required keys, consists of the following two algorithms:

-PubParam(1 k ): On input a security parameter k, this probabilistic algorithm outputs the system public parameters pp. -KeyGen(pp): On input the system public parameters pp, this probabilistic algorithm outputs the private/public key pairs of the different entities: the toll company is provided with (sk tc , pk tc ) and the revocation authority gets (sk ra , pk ra ). The toll company is also provided with a set of private keys → x = (x 0 , x 1 , x 2 ) that are shared with the tollbooths.

Registration

-UKeyGen(pp, ID u ): On input a user's identifier ID u as well as the public parameters pp, this probabilistic algorithm outputs a private/public key pair (sk u , pk u ) associated to ID u .

-Register(U(ID u , pk u ), T C(DB REG )): This is an interactive protocol between the toll company T C and a user U. At the end of this protocol, the toll company registers the new user and saves his identifier as well as his public key within the database of registered users denoted DB REG .

Token Issuance

TokenIssue(U(sk u , pk ra ), T C( → x , DB REG ), N max ): This is an interactive protocol between the toll company T C and a user U. At the end of this protocol, the user receives a payment token T , worth M , that will enable him to take at most N max trips. Concurrently, the transcript view of the protocol execution (transc TI ) is saved in the database DB REG .

Access Control

AccessControl(U(T, pk ra ), T C(sk tc , → x , DB AC ), v): This is an interactive protocol between a tollbooth T C and a user U who provides his payment token T to be granted access at a tollbooth. If the token is valid and the toll fare v < M , the tollbooth updates T to add the refund associated to the current transaction (i.e. M -v). Otherwise, it outputs ⊥ and aborts. Concurrently, the transcript view transc AC of the protocol execution is saved in a database denoted by DB AC .

Toll Computation

TollCompute(U(T ), T C( → x , DB REG )): This algorithm, which is executed by the toll company, takes as input the current token held by the user. According to its value, it outputs the overall toll charges the user U owes to the toll company.

6. Revocation: Two different revocations, namely user's anonymity and token revocations, may be exceptionally triggered. Both are performed by the revocation authority RA upon a court order or a legitimate request of the toll company T C.

-IDRetrieve(transc AC , sk ra , DB REG ): This deterministic algorithm takes as input the private key of the revocation authority, an anonymous access control transcript view transc AC and the registration database DB REG . It outputs the identifier ID u of the user who performed this transaction.

-TokenRevoc(ID u , transc TI , sk ra ): This deterministic algorithm takes as input a user's identifier ID u , the private key sk ra of the revocation authority as well as a transcript view of an execution of TokenIssue. It outputs all the valid tags T i that can be generated by the user whose identifier is ID u .

Security and Privacy Models

In this section, we define the different properties that a private eCash system must satisfy to be both secure and privacy-friendly, namely correctness, unforgeability, non-frameability and unlinkability. They are formalized through a set of experiments that involve games between a challenger C and a Probabilistic Polynomial Time (PPT) adversary A. We distinguish two sets of users, namely HU and CU. The former corresponds to the set of registered honest users whose private keys are unknown to A while CU denotes the set of corrupted users for whom A knows both the public and private keys. To model the capabilities of A, we give him access to several oracles defined as follows:

-ORegister(ID u ) is an oracle used by A to create a new honest user identified by ID u and generate his pair of keys. The challenger runs the UKeyGen algorithm and provides A with the public key pk u while keeping sk u secret. The identity ID u and the associated public key pk u will be added to the set HU.

Security and Privacy Models

-ORegisterCorrupt(ID u ) is an oracle that enables A to create a new corrupted user with a pre-defined pair of keys (sk u , pk u ). The user identified by ID u is added to the set CU.

Only his public key pk u is known to the challenger.

-OCorrupt(ID u ) is an oracle used by A to corrupt the honest user identified by ID u . Upon the execution of this oracle, the challenger provides A with the corresponding secret key sk u . Furthermore, the user identified by ID u is moved from HU to CU.

-OTokenIssue U (ID u ) is an oracle that executes the user's side of the TokenIssue protocol. This oracle will be used by A acting as a malicious T C. The adversary provides the oracle with an honest user's identifier ID u . If the corresponding user accepts the protocol, the adversary gets a transcript view transc TI of the protocol execution.

-OTokenIssue T C () is an oracle that executes the T C's side of the TokenIssue protocol. This oracle will be used to simulate the protocol execution between a corrupted or honest user and an honest T C. Even though the adversary always sees the transcript view transc TI of the protocol execution, the issued token is known to A only if the simulated user is corrupted.

-OAccessControl U (ID u , v) is an oracle which executes the user's side of the AccessControl protocol. It will be used by A acting as a malicious T C. If the user accepts the protocol, the adversary gets a transcript view transc AC of the AccessControl protocol execution with an associated toll fare equal to v. Concurrently, transc AC is saved in both DB u and DB AC .

-OAccessControl T C () is an oracle that executes the T C's side of the AccessControl protocol. It simulates the protocol execution between an honest or corrupted user and an honest T C. The transcript view transc AC is saved in DB AC .

-OIDRetrieve(transc AC ) is an oracle that executes the RA's side of the IDRetrieve protocol. The adversary A, who acts as T C, provides a valid anonymous transcript view transc AC and gets, in return, the identity ID u of the user who performed this transaction.

-OTokenRevoc(ID u , transc TI ) is an oracle that executes the RA's side of the protocol TokenRevoc. The adversary A, who acts as T C, provides the identifier ID u of a user U as well as a transcript view of the execution of the TokenIssue protocol by this user. This oracle will return all the tags T i that can be generated by this user.

-OTollCompute(ID u ) is an oracle that returns the total amount that the user identified by ID u owes to T C.

Security Model

To be secure, a private eCash system should ensure three properties: correctness, unforgeability and non-frameability. In what follows, we provide both informal as well as formal definitions of these properties.

Correctness. As usual, correctness, which ensures the proper functioning of the system, is primordial. In our case, correctness is satisfied if the following four statements are met: (1) the user's registration went well; (2) the provided tokens are valid; (3) the final bill corresponds exactly to the fees associated to the users' trips; (4) the revocation authority can always identify the user who initiated a given AccessControl transcript view.

Unforgeability. Informally, unforgeability requires that no entity, even a set of colluding malicious users, can (1) perform the AccessControl protocol without the revocation authority being able to retrieve the identity of the corresponding user (i.e. such that IDRetrieve outputs ⊥), (1 k ) = 1]. A private eCash system satisfies the unforgeability property if this advantage is negligible for any PPT adversary A.

Exp unforg A (1 k ) 1. (pp, (sktc, pktc), → x , (skra, pkra)) ← Setup(1 k ), HU ← ∅, CU ← ∅, DBAC ← ∅ 2. {T k } k=no k=1 ←-A O () where O = {ORegister, OCorrupt, ORegisterCorrupt, OTokenIssue T C , OAccessControl T C , OIDRetrieve, OTokenRevoc, OTollCompute} and {T k } is a set of n 0 tokens.
3. If one of the provided tokens T k is not valid, then it is discarded.

4. If ∃transc AC ∈ DBAC such that IDRetrieve(transc AC , DBREG, skra) = ⊥, then return 1.

If nv

k=1 TollCompute(T k ) < #DBAC i=1 Charge(transc i AC ), where Charge(transc i AC ) corresponds to the toll charge associated to the transcript view transc i AC , #DBAC denotes the number of transcripts in DBAC and nv is the number of valid tokens, then return 1. ]. An eToll system satisfies the non-frameability property if this advantage is negligible for any PPT adversary A.

Return 0

Exp non-fram A (1 k ) 1. (pp, (sktc, pktc), → x , (skra, pkra)) ← Setup(1 k ), HU ← ∅, CU ← ∅, DBu ← ∅ 2. TranscAC i ←-A O (sktc, → x , skra, DBAC, DBREG) where O = {ORegister, OCorrupt, ORegisterCorrupt, OTokenIssue U , OAccessControl U } 3. If TranscAC i is not valid or IDRetrieve(transcAC i , DBREG, skra) = ⊥ then return 0.

Privacy Model

To be privacy-friendly, a private eCash system must additionally ensure unlinkability. Hereinafter, we define this property first in an informal, then, in a formal manner.

Unlinkability. Roughly speaking, the unlinkability property requires that, aside from the revocation authority, no entity (even with the help of malicious users) can (1) link an AccessControl transcript to a specific execution of the TokenIssue protocol; (2) link two AccessControl transcripts performed by the same user, not necessarily identified; (3) link an AccessControl transcript to a specific execution of the TollCompute protocol. Note that the unlinkability property implies the anonymity one (i.e. an unlinkable system is necessarily anonymous). Informally, the anonymity property ensures that, apart from the revocation authority, no entity (even with the help of malicious users) should be able to retrieve the identity of the user who performed a given AccessControl.

Exp unlink-b A (1 k ) 1. (pp, (sktc, pktc), → x , (skra, pkra)) ← Setup(1 k ), HU ← ∅, CU ← ∅ 2. (u 0 , u 1 , v 0 , v 1 ) ← A O (sktc, →
x , DBAC, DBREG) where O = {ORegister, ORegisterCorrupt, OCorrupt, OTokenIssue U , OAccessControl U , OIDRetrieve, OTokenRevoc, OTollCompute} and v 0 , v 1 are two toll fares.

3. If u 0 or u 1 ∈ CU then output ⊥.

For

i ∈ {0, 1}, (T i , transcTI i ) ← TokenIssue(C(sku i , pkra), A( → x , DBREG), Nmax) 5. transcb ← AccessControl(C(T 1 , pkra), A(sktc, → x , DBAC), v b ) where b ∈ {0, 1} and transc 1-b ← AccessControl(C(T 0 , pkra), A(sktc, → x , DBAC), v 1-b ) 6. b ← A O (sktc, →
x , DBAC, DBREG, transcTI b , transcTI 1-b , transcb, transc 1-b ) where O = {ORegister, ORegisterCorrupt, OCorrupt, OTokenIssue U , OAccessControl U , OIDRetrieve, OTokenRevoc, OTollCompute * } such that OTollCompute * denotes a restricted access to OTollCompute to the cases specified above. To achieve his goal, an adversary A may corrupt all users except two users: u 0 and u 1 . He can also collude with the toll company and get its private keys (i.e. sk tc and → x ). Besides, A can query the IDRetrieve protocol on any transcript of his choice excluding both challenge transcripts (i.e. transc b and transc 1-b ) where b ∈ {0, 1} and he can call the TokenRevoc protocol on any identifier, apart from ID u 0 and ID u 1 . A has also access to the TollCompute protocol. However, to ensure that statements (2) and (3) hold, A's access to the TollCompute protocol is restricted to some particular cases. More precisely, he can only query it if the following three conditions are met:

-(i) the toll fares associated to both challenge transcripts are equal (i.e. v 0 = v 1 ); -(ii) during the challenge phase, the overall toll charges corresponding to all calls to the oracle OAccessControl are the same for u 0 and u 1 ; -(iii) during the challenge phase (including the challenge transcript), u 0 used exactly the same set of generators g i as u 1 (i.e. for example, if {g 1 , g 2 , g 5 , g 9 } were used by u 0 , then A cannot query OTollCompute unless u 1 has only used {g 1 , g 2 , g 5 , g 9 }).

These restrictions may seem excessive at first glance, but a closer look reveals that they are rather fair and reflect the actual capabilities of a real adversary. Indeed, in a real deployment, the group of users that have taken the same number of trips while using the same set of g i (s) will be quite large. Thus, a given user will remain anonymous among a large group of users. Furthermore, as shown in [START_REF] Rupp | Cryptographic theory meets practice: Efficient and privacy-preserving payments for public transport[END_REF], an aggregate amount should not enable the retrieval of the different trips taken by the user.

(1 k ) = |Pr[Exp unlink-b A (1 k ) = b] -1/2|
. An eToll system is considered unlinkable if this advantage is negligible for any PPT adversary A.

We emphasize that the unlinkability property defined above is slightly weaker than the classical full-unlinkability1 property as we aimed to achieve a better trade-off between privacy and efficiency. It is, however, worth mentioning that full-unlinkability can be achieved by simply adding some randomness through the use of a pseudo-random function as in [ALT + 15]. Such change slightly deteriorates the system performances since the modified scheme will additionally require a set membership proof. Nevertheless, it still remains efficient enough for the targeted applications.

Our Private eCash System

Overview

To benefit from the eToll service, a user must first register to obtain a badge that will perform all computations on his behalf. At the beginning of each billing period, registered users receive a unique reusable token generated using our partially blind signature scheme detailed in Section 4.1. The obtained token is worth the highest possible fare and can be reused at most N max times. To be granted access at tollbooths while preserving his anonymity, the user provides a randomized version of his token. Concurrently, as toll fares are generally different, the user's token is updated in a blinded way, using our partially blind signature scheme, to add the refund amount associated to the transaction. At the end of the billing period, users are charged according to their token value. Such a post-payment approach prevents them from refilling a prepaid account with a large amount of money. Nevertheless, if a user does not return his token, he will pay the maximal allowed amount which corresponds to N max times the highest fare.

Description of the Protocols

As previously mentioned, our private eCash system consists of six main phases, namely setup, Registration, Token Issuance, Access Control, Toll Computation and Revocation. Below, we explain these phases and detail the main protocols in Figures 5.4, 5.5 and 5.6.

Setup

Let pp = (G, g, h, q, g R , N max , {g i } Nmax i=1 ) denote the system public parameters where G is a cyclic group of prime order q and (g, h, g R , {g i } Nmax i=1 ) a set of random generators. N max indicates the allowed number of reuses of a token and could be set according to user's needs. Each user U is also provided with a pair of keys (sk u , pk u ) that identifies him and which are subsequently used to generate the Schnorr signature.

The toll company shares the secret key → x := (x 0 , x 1 , x 2 ) with tollbooths, that are denoted by T C as well. The associated public parameters are C x 0 := g x 0 h x0 , a commitment to x 0 where x0 ∈ R Z * q , and X 1 := h x 1 , X 2 := h x 2 . T C is also provided with a pair of keys (sk tc , pk tc ) used to sign transaction data.

The revocation authorities jointly generate two pairs of keys: (sk ra , pk ra ) of the threshold ElGamal encryption scheme and (sk rp , pk rp ) of the threshold Paillier cryptosystem. Paillier's encryption scheme is used as an extractable commitment scheme (see [START_REF] Hufschmitt | Fair blind signatures revisited[END_REF]) to satisfy the unforgeability requirement, even in a concurrent setting, where an adversary is allowed to interact with T C in an arbitrarily interleaving (concurrent) manner. Let g E and g P be two generators of 5.5. Our Private eCash System G. ElGamal keys are defined as sk ra := x T ∈ Z * q and pk ra := (g E , X T := g x T E ). Paillier pair of keys consists of sk rp := (a, b) and pk rp := (g P , n := ab) where a and b are two different random primes such that |a| = |b| and gcd(ab, (a -1)(b -1)) = 1. The private keys are shared among RAs [START_REF] Fouque | Sharing decryption in the context of voting or lotteries[END_REF] and at least t of them should cooperate to identify the user or revoke a token.

Registration

To use the service, U must provide T C with his public key pk u and a ZKPK proving the knowledge of the secret key sk u . If the proof is valid, U receives a personal badge B u including a SIM card. It allows U to anonymously use the service. Moreover, pk u is saved in a dedicated database denoted by DB REG .

Token Issuance

The token issuance phase occurs at the beginning of each billing period upon a signed request (using Schnorr's signature scheme) of a registered user. During this phase, T C provides U with a permission token T := (u, u := u x 0 +x 1 su+x 2 m ). It is a partially blind signature on the unknown message s u = s + s and the common information m corresponding to the refund amount, initially set to 0. In fact, s u is a secret value only known by U: it involves a secret s ∈ R Z * q chosen by U and hidden from T C and s ∈ R Z * q chosen by T C and provided to U. The token is worth the highest possible toll fare M and can be reused N max times. Two ZKPKs π 1 and π 2 ensure that exchanged values are well-formed (see Figure 4.2). Concurrently, (g s , s , D) is saved in DB REG where D is a Paillier encryption of s used so as to enable the revocation of a payment token.

User U

Toll Company T C Public Input: pp, X 1 , X 2 and Cx 0 Public Input: pp, pku and M Private Input: sku Private Input: DBREG, x 0 , x 1 and x 2

Choose r, r 1 , s

R ← Z * q Compute C ← h r X s 1 , W = g s , D = g s P r n 1 Build π 1 = PoK{α, β, γ : C = h α X β 1 C,W,D,π 1 ----------→ Check π 1 ∧ W = g β ∧ D = g β P γ n } Choose s , b R ← Z * q Compute u ← h b Compute u ← u x 0 (CX s 1 ) b Check π 2 g s ,(u,u ),π 2 ← ---------- Build π 2 = PoK{α, β, γ : u = h α Compute u ← u u r and T ← (u, u ) ∧ u = u β (CX s 1 ) α ∧ Cx 0 = g β h γ } m ← 0, F ← {g i } Nmax i=1 Compute S 1 = Sign(W, g s , D) S 1 -----------→ Check S 1 su ← s + s s ← ---------- Save (W , D, s , S 1 ) in DBREG

Access Control

To be granted access at tollbooths, U provides a randomized (and blinded) version of his token T and an ElGamal encryption E of g su along with a ZKPK π 3 proving that these values are wellformed. Upon their receipt, T C checks if the token is valid and has not been overspent (i.e. used more than N max times). To this end, whenever reaching a tollbooth, B u randomly chooses a g i among the set F of unused ones. The selected g i is then removed from F to prevent over-spending of a token. If checks succeed, U receives an updated token T with a new m aggregating all the refunds collected so far. This new token is computed using our partially blind signature scheme with a common value equal to the current refund amount. Due to delay constraint, the associated ZKPK π 4 cannot be instantly verified. Thus, U is also provided with S, an RSA signature with a short public verification exponent, of all the received values. S can be quickly verified upon receipt

Toll Computation

At the end of the billing period, U shows his randomized token T and a tag T g := g su R to be charged for all his trips. The tag ensures that U has not already asked for a refund during that period. Based on the refund amount m, T C computes the user's charges and saves T g in DB REG . More precisely, the different exchanges between U and T C are depicted in Figure 5.6.

User U

Toll Company T C Public Input: pp and X 1 Public Input: pp Private Input: T := (u, u ), m, su Private Input:

x 0 , x 1 , x 2 and DBREG Choose l, r, z 1 R ← -Z * q Compute R ← u l , R ← (u ) l Compute c ← R g r , c 1 ← R su h z 1 Compute V ← g -r X z 1 1 , Tg ← g su R Build π 5 = PoK[α, β, γ : Tg = g α R m,R,c ,c 1 ---------→ V, Tg ,π 5 Check if V ? = R x 0 +mx 2 c x 1 1 c ∧ c 1 = R α h β ∧ V = g -γ X β 1 ]
Check π 5 and Tg / ∈ DBREG Save Tg in DBREG If a user's token has been used less than N max times, a specific process is triggered so as to emulate their use with no associated charges. Thereby, U will only pay for the trips he took. Let us consider the case where N max = 30 whereas the user only took 28 trips (g 8 and g 12 have not been used for example). In such a case, the user will perform a "special" access control where he shows a randomized version of his token and provides the set of tags that have not been used: T 8 and T 12 in our example. It is noteworthy to mention that this process, which is detailed in Figure 5.7, must be run prior to the execution of the Toll Computation protocol.

Revocation

Two different revocations may be triggered under exceptional circumstances: the revocation of user's anonymity or tokens. In the former, the goal is to identify the user who performed a given of the toll company whereas B selects the key pair (sk tc , pk tc ). Regarding the key pairs of Paillier and ElGamal encryption schemes (i.e (sk ra , pk ra ) and (sk rp , pk rp )), they can be chosen either by B or A. B provides A with (X 1 , X 2 , C x 0 ) and answers its requests as follows:

-ORegister(ID u i ): B randomly chooses the user's secret key sk u i ∈ Z * q and computes the associated public key pk u i = g sku i that it transmits to A.

-ORegisterCorrupt(ID u i ): B does nothing.

-OCorrupt(ID u i ): B provides A with the associated private key sk u i .

-OTokenIssue T C (): Using the replay technique and the soundness property of π 1 , B recovers the secret values s and r. Then, it randomly selects s ∈ R Z * q and calls on the OMAC oracle on the message s u = s + s to obtain the pair (u, u ). Thereby, it can provide A with the pair (u, u = u u r ) and the corresponding s . As for the proof π 2 , B can perfectly simulate it in the random oracle model.

-OAccessControl T C (): Using the replay technique and the soundness property of π 3 , B recovers the secrets s u , m, t, z 1 , z 2 and r associated to the values provided by the adversary. It can thus compute the corresponding token (w, w ). Through the call to the OVerify oracle, B verifies the validity of the token (w, w ). If (w, w ) is a valid MAC on (s u , m) for an s u that has not been queried to the OMAC oracle, then abort (as (w, w , s u , m) is a valid forgery of MAC GGM ). Otherwise, provided that (w, w ) is valid, B calls on the OMAC oracle on (s u , m + m ) to get the pair (y, y = y x 0 +sux 1 +(m+m )x 2 ). Thus, it can provide A with the pair (y, y = y y t ). Regarding the proof π 4 , B can perfectly simulate it in the random oracle model. Since it holds the private key sk tc , B can produce the RSA signature S. Consequently, B can perfectly simulate the AccessControl protocol for A.

-OTollCompute(ID u i ): Using the replay technique and the soundness property of π 5 , B recovers the secret value r and hence, the token T = (R, R ) associated to the values provided by A. Through the call to the OVerify oracle with T as input, B verifies the validity of the provided token. If so, it returns the overall toll charges associated to it.

The adversaries against the unforgeability requirement of our eCash system can be classified in two different categories according to the way they proceed to achieve their goals:

• Type 1: An adversary that manages to perform an AccessControl such that the corresponding transcript view transc AC cannot be linked to a registered user (i.e. RA is unable to revoke user's anonymity).

• Type 2: An adversary that figures out a way to pay less charges than what he has to.

Hereinafter, we show that both forgers can be used to break the UF-CMVA security of the MAC GGM . As the reduction works differently for the two types of forgers, B initially chooses f type ∈ {1, 2} at random. The latter corresponds to its guess of the type of forgery A will output.

If f type =1: Eventually, the adversary A succeeds with non negligible probability in performing an AccessControl such that the associated transcript view transc AC cannot be linked to a registered user. That is, having transc AC as input, the protocol IDRetrieve returns ⊥ (i.e. an unknown identifier). Two cases are possible:

-Case 1: The plaintext g s u encrypted in E is associated to a token generated during a call to the oracle OTokenIssue T C but no corresponding signature S 1 has been provided. This means that the adversary did not receive the value s , where s u = s + s , from the

Security Analysis

OTokenIssue T C oracle. We know from the Forking Lemma and the soundness property of π 3 that A necessarily knows s u as well as s (as he chose it). Hence, he can recover s = s u -s. Since the oracle OTokenIssue T C did not reveal s but only provided g s , then the adversary A could be used to extract Discrete Logarithms. Consequently, under the DL assumption, this case can only happen with negligible probability.

-Case 2: The plaintext g s u encrypted in E does not correspond to a token that has been issued during an OTokenIssue request. Thus, s u has not been queried to the OMAC oracle either. Using the Forking Lemma and the soundness property of π 3 , B can extract with non negligible probability the secrets associated to transc ACi , namely (s u , m, w, w ). Thus, B returns to its challenger the pair (w, w ), which corresponds to a valid MAC on (s u , m), that has not been obtained following a call to OMAC. Thereby, B breaks the UF-CMVA security of the MAC GGM scheme.

If f type =2: Eventually, after n calls to the OTokenIssue oracle, A outputs, with non negligible probability,

n v valid tokens {T k } k=nv k=1 such that nv k=1 TollCompute(T k ) < #DBAC j=1 Charge(transc j AC )
where Charge(transc j AC ) corresponds to the toll charge associated to the transcript view transc j AC . The following three cases may enable this type of forgery:

-Case 1: The adversary figures out a way to use at least one of the issued tokens more than N max times, with non negligible probability. Let (s 1 , s 2 , . . . , s n ) denote the n secrets submitted to the OTokenIssue oracle. Typically, there should be n × N max distinct pairs (s u i , g j ) where i ∈ {1, . . . , n} and j ∈ {1, . . . , N max }. Let L denote the set of legitimate pairs (s u i , g j ). Thus, there is at least a transcript transc AC ∈ DB AC whose associated pair (s u , g ) does not belong to L. Since g necessarily belong to {g j } j=Nmax j=1 (otherwise transc AC would not be considered valid), then s u ∈ {s 1 , s 2 , . . . , s n }. Consequently, s u has not been queried to the OTokenIssue oracle. This implies that no call to the OMAC oracle has had s u as input neither. In such case, B picks a random transcript transc k AC among the database DB AC . The probability that it selects transc AC is 1 #DB AC where #DB AC denotes the number of transcripts in DB AC . Using the Forking Lemma and the soundness property, B can extract with non negligible probability the secrets associated to transc AC , namely (s u , m, w, w ). Thus, B returns to its challenger the pair (w, w ), which corresponds to a valid MAC on (s u , m), that has not been obtained following a call to OMAC. Thereby, B breaks the UF-CMVA security of the MAC GGM scheme with non negligible probability.

-Case 2: At least one of the transcript views transc AC corresponding to the adversary's calls to OAccessControl did not involve a token issued following a call to OTokenIssue. This case is similar to a type-1 case-2 adversary which can be used to break the UF-CMVA security of the MAC GGM scheme.

-Case 3: At least one of the n v valid tokens, T * = (u * , u * ), provided by A was not issued following a call to the OAccessControl or OTokenIssue protocols (i.e. the adversary has succeeded in forging a valid token). Let s u * and m * be respectively the secret and the refund amount associated to T * . This case implies that no call to the OMAC oracle has been made by B with the pair (s u * , m * ) as input. Thus, B picks a random token T k among the set of valid tokens provided by A. The probability that it selects T * is 1 n v

. Using the Forking Lemma and the soundness property, B can extract with non negligible probability the secrets associated to T * , namely (s u * , m * , u, u ). Thus, B returns to its challenger the pair (u, u ), which corresponds to a valid MAC on (s u * , m * ), that has not been issued during Chapter 5 : A Practical Private eCash System a call to OMAC. Thereby, B breaks the UF-CMVA security of the MAC GGM scheme with non negligible probability.

Non-frameability

Theorem 5.2 (Non-frameability). Our eCash system provides the non-frameability property, in the random oracle model, under the discrete logarithm DL assumption.

Proof (sketch). Let A be an adversary against the non-frameability requirement of our eCash system. Using A, we construct a reduction B against the discrete logarithm (DL) assumption. Depending on the way they proceed to break the non-frameability property of our system, we can distinguish the following two types of adversaries:

• Type 1: An adversary that is able to recover the secret s u associated to a token that was issued following a call to OTokenIssue U .

• Type 2: An adversary that succeeds in generating a valid Schnorr signature S 1 on behalf of an honest user. Thereby, he can impersonate him and obtain as many valid tokens as he wants to.

The reduction works differently for each kind of adversary. Therefore, B initially chooses a value A type ∈ {1, 2} at random. The latter corresponds to its guess of the way A will break the non-frameability of our system (i.e. the type of adversary).

If A type =1: This means that the adversary is able to recover the secret s u associated to a token that was issued following a call to OTokenIssue U . In such case, we assume that B (which acts as A's challenger) receives on input from its challenger C the pair (g, g s ) where g is a random generator of G. The adversary A chooses the private keys → x = (x 0 , x 1 , x 2 ) of the toll company as well as ElGamal pair of keys (sk ra , pk ra ) whereas B selects the Paillier pair of keys (sk rp , pk rp ). B also picks (N max + 1) random values (α, β 1 , . . . β Nmax ) ∈ R Z * q and sets h = g α and g i = g β i , ∀i ∈ {1, . . . , N max }. The other generators are randomly chosen. B constructs the public parameters pp for A and answers its requests as follows:

-ORegister(ID u i ): B randomly selects the user's secret key sk u i and computes the associated public key pk u i .

-ORegisterCorrupt(ID u i ): B does nothing.

-OCorrupt(ID u i ): B provides A with the corresponding private key sk u i .

-OTokenIssue U (ID u i ): B first selects two random values δ i and λ i then, using its input g s of the DL problem, it sets W = g δ i s+λ i = g s i . The values C ∈ R Z * q and D ∈ R Z n 2 can be randomly chosen. Indeed, ∀s i , ∃ r, r 1 such that C = h r X s i 1 and D = g s i p r n 1 . As for π 1 and S 1 , B can perfectly simulate them in the random oracle model. If the protocol does not abort, B obtains a valid token such that the associated s u i is defined as s u i = s i + s i where s i is randomly chosen by A (and also known to B) while s i = δ i s + λ i is unknown to both B and A.

-OAccessControl U (ID u i , v): As it holds (u, u ) and knows m, B can easily simulate the different values involved in the execution of the AccessControl protocol except c 1 = w su i h z 1 , T i = g

su i i and A = h t X su i 1 X m 2 .
More precisely, it randomly chooses l, z 1 , z 2 , r, d ∈ R Z q and computes c = (u ) l g r , V = g -r X z 1 1 X z 2 2 as well as c 2 = w m h z 2 , e 1 = g d E and e 2 = g s i g s i X d T .

Security Analysis

As regards to A, it is randomly generated since for all (s u i , m), there exists t such that A = h t X su i 1 X m 2 . As for the other values, they are computed as c 1 = ((g s i ) α h s i ) bl h z 1 = w su i h z 1 and T i = (g s i g s i )

β i = g su i i
where b is recovered from π 2 using the replay technique and the soundness property. Regarding the PoK π 3 , B can perfectly simulate it using standard techniques.

Eventually, A outputs with non negligible probability a valid transcript transc ACi of an execution of the AccessControl protocol such that, on input transc ACi , the IDRetrieve protocol outputs an identifier ID u i ∈ HU along with a Schnorr signature S 1 proving that a token issued for the user ID u i was involved in the generation of transc ACi . As defined in the experiment, transc ACi must not have produced following a call to OAccessControl U (ID u i ).

It follows from the Forking Lemma that if A is able to produce such a valid transcript Transc AC , then it can produce two valid transcripts Transc AC1 and Transc AC2 . Thereby, using the replay technique and the soundness property of π 3 , B can extract the associated secret values (s u i , m, u, u ). Given s u i and s i , B retrieves s i = s u i -s i . Since it knows the values of δ i and λ i , it can recover s the discrete logarithm of the received challenge g s , hence breaking the DL assumption.

If A type =2: We are dealing with an adversary that succeeds in generating a valid Schnorr signature S 1 on behalf of an honest user. Thus, he can impersonate him and obtain as many valid tokens as he wants to. To get a better reduction, we use the one-more discrete logarithm OMDL assumption. It is, however, worth mentioning that the non-frameability property of our eCash system can also be proven under the DL assumption. We assume that the challenger C provides B with a random instance (g sk 1 , g sk 2 , . . . , g skn ) of the OMDL problem where g is a random generator of G. As it is against the one-more DL assumption, B has access to a DL oracle and, similarly to the previous case, it acts as A's challenger in the non-frameability experiment. A chooses the private keys → x = (x 0 , x 1 , x 2 ) of the toll company while ElGamal and Paillier pair of keys can be chosen either by B or A. B constructs the public parameters pp for A and answers its requests as follows:

-ORegister(ID u i ): B answers A's request using his input of the one-more discrete logarithm problem. More precisely, it sets the user public key as pk u i = g sk i .

-ORegisterCorrupt(ID u i ): B does nothing.

-OCorrupt(ID u j ): B calls on the DL oracle with pk u j as input. Thereby, it can provide A with the corresponding private key sk j .

-OTokenIssue U (ID u i ): B randomly selects s ∈ R Z * q and computes the required values involved in the execution of the TokenIssue protocol. As regards to the proof π 1 and the Schnorr signature S 1 , B can perfectly simulate them in the random oracle model.

-OAccessControl U (ID u i , v): B holds the token (u, u ) issued for ID u i as well as the associated secrets s u i and m. Thus, it can perfectly simulate the different values involved in the execution of the AccessControl protocol.

Eventually, after d calls to the OCorrupt oracle, the adversary A outputs a valid transcript view Transc AC of the execution of the AccessControl protocol such that it breaks the nonframeability requirement of our eCash system. We know by the definition of the experiment that the corresponding user is honest. Consequently, the oracle OCorrupt has not been queried with this user's identifier as input. This implies that the associated public key pk u i = g sk i is still in the input of the OMDL problem. As previously mentioned, this type of adversary succeeds if he manages to produce a valid Schnorr signature S 1 , enabling him to get a valid payment token.

It follows from the Forking Lemma that if A is sufficiently powerful to produce a Schnorr signature S 1 then, it can produce two Schnorr signatures with non-negligible probability. Using the replay technique, B is able to extract the private key sk i used to generate the Schnorr signature. Thereby, B outputs sk i along with the d secret keys {sk u j } j=d j=1 that it has received by querying the DL oracle. Hence, B breaks the one-more discrete logarithm problem.

Unlinkability

Theorem 5.3 (Unlinkability). Our private eCash system is unlinkable, in the random oracle model, under the Decisional Composite Residuosity DCR, the Decisional Diffie Hellman DDH and the q-Decisional Diffie-Hellman Inversion q -DDHI assumptions.

Proof (sketch). In the sequel, we prove the unlinkability of our eCash system under a slightly weaker model than the one presented in 5.4.2. More precisely, we consider the same experiment except that, during the challenge phase, the adversary A is not provided access to the OIDRetrieve oracle. The corresponding requirement is denoted Unlinkability'. It should be stressed, however, that in the case of a real deployment, the access to the revocation functionalities is carefully controlled. Consequently, Unlinkability' is rather a reasonable requirement.

Nevertheless, it is worth mentioning that our eCash system would satisfy the original unlinkability requirement provided that we replace the ElGamal encryption scheme, which is only IND-CPA secure, by an IND-CCA2 secure encryption scheme. As it is well-known, the double encryption of the same plaintext under an IND-CPA encryption scheme and the use of a simulation sound proof of equality of plaintexts lead to an IND-CCA2 encryption scheme [START_REF] Naor | Public-key cryptosystems provably secure against chosen ciphertext attacks[END_REF]. Thereby, if we use the double ElGamal encryption scheme which was proven IND-CCA2 [START_REF] Fouque | Advances in Cryptology -ASIACRYPT 2001: 7th International Conference on the Theory and Application of Cryptology and Information Security Gold Coast[END_REF] instead of the classical one, our system would fulfil the original unlinkability requirement.

Furthermore, we consider the case where the different generators {g i } i=Nmax i=1 are computed as the output of a pseudo-random function introduced by Dodis and Yampolskiy [START_REF] Dodis | A verifiable random function with short proofs and keys[END_REF]. In particular, for a user holding a token associated to a secret s u , they are defined as g i = g 1 su+i+1 , ∀i ∈ {1, . . . , N max }. With such an assumption, an adversary can have access to the OTollCompute oracle regardless of the set of generators used (during the challenge phase) when querying the OAccessControl U oracle on u 0 and u 1 . Thus, A's access to the OTollCompute oracle during the challenge phase is henceforth restricted to the cases where v b = v 1-b , the number of calls to OAccessControl U on u 0 and u 1 are equal, and the overall toll charges associated to all these calls are the same for u 0 and u 1 .

Let A be an adversary against the unlinkability requirement of our eCash system. A is said to be a Type-(i, j) distinguisher where i ≤ N max -1 and j ≤ N max -1 if, during the challenge phase, it makes at most i calls to OAccessControl U on u 0 and j calls to OAccessControl U on u 1 . It is clear that a Type-(i, j) distinguisher is, in particular, a Type-(N max -1, N max -1) distinguisher ∀i ≤ N max -1 and ∀j ≤ N max -1. Thus, without loss of generality, we may focus solely on Type-(N max -1, N max -1) adversaries.

So, in the sequel, we assume that A is a Type-(N max -1, N max -1) adversary. Using Shoup's game hopping technique [START_REF] Shoup | Sequences of games: a tool for taming complexity in security proofs[END_REF], where proofs are organized as sequences of games, we prove that our eCash system satisfies the Unlinkability' requirement. Hereinafter, we provide a high level description of the initial game (Game 0) along with brief descriptions of the transitions between successive games.

Game 0: It corresponds to the real attack game with respect to an efficient adversary A.

The Challenger C randomly chooses the system public parameters pp = (G, g, h, q, g R , N max ), the keys → x = (x 0 , x 1 , x 2 ) and sk tc of the toll company as well as both revocation authorities pair 5.6. Security Analysis of keys (i.e. (sk ra , pk ra ) and (sk rp , pk rp )). C provides A with both → x = (x 0 , x 1 , x 2 ) and sk tc , and answers A's requests as follows:

-ORegister(ID u i ): C randomly chooses sk u i ∈ Z * q and computes the public key pk u i = g sku i that it forwards to A.

-ORegisterCorrupt(ID u i ): C does nothing.

-OCorrupt(ID u i ): C provides A with the secret key sk u i .

-OTokenIssue U (ID u i ): C chooses a random value s i ∈ Z * q and proceeds normally to obtain a token on s u i = s i + s i . To generate the Schnorr signature S 1 , it uses the secret key sk u i .

-OAccessControl U (ID u i , v): C uses the token issued during OTokenIssue U (ID u i ) and the associated secrets s u i and m, as well as a generator g i (that has not already been used) to perform an access control whose corresponding toll fare is v.

-OTollCompute(ID u i ): C returns the overall toll charges that ID u i owes to T C.

The adversary A selects two honest users u 0 and u 1 as well as two toll fares v 0 and v 1 that he returns to the challenger C. The latter first runs the TokenIssue protocol with u 0 and u 1 as input and provides the corresponding transcript views, transc TI0 and transc TI1 to A. Then, C picks a random bit b ∈ {0, 1} and runs the AccessControl protocol with respectively (u 1 , v b ) and (u 0 , v 1-b ) as input. The corresponding transcripts transc b and transc 1-b are also sent to A whose goal is to guess the value of b (i.e. figure out which user performed the AccessControl that costs v 0 (or v 1 ) with a probability non negligibly better than 1 2 ). After receiving the challenge (i.e. during the challenge phase), A can still query the ORegister, ORegisterCorrupt, OCorrupt, OTokenIssue U , OAccessControl U , OTokenRevoc and OTollCompute oracles but with some restrictions. More precisely, A can neither query the OCorrupt oracle on ID u 0 or ID u 1 , nor the OTokenRevoc oracle on (ID u 0 , transc TI0 ) or (ID u 1 , transc TI1 ). Moreover, A's access to the OTollCompute oracle on ID u 0 and ID u 1 is restricted to the cases where v b = v 1-b , the number of calls to OAccessControl U on u 0 and u 1 are equal, and the overall toll charges associated to all these calls are the same for u 0 and u 1 . Otherwise, the adversary could easily win the game.

Eventually, A outputs a bit b . Let S 0 denote the event that b = b in Game 0 (i.e. the event that A wins Game 0) and S i denote the event that b = b in Game i. We have Adv unlink-b

A (1 k ) = |Pr[Exp unlink-b A (1 k ) = b] -1/2| = |Pr[S 0 ] -1/2|.
We construct the following sequence of games while preventing the adversary from detecting the changes between two successive games: Game(0,1-b,b): It is the same game as Game (0,1-b) except that, when executing the AccessControl protocol with u b , we replace the value of the tag T b i by a random value. Then, we simulate the proof π b 3 . Such a proof can be easily simulated in the random oracle model through the use of classical techniques. Under the q-DDHI assumption, the adversary cannot detect such change. In fact, one can easily construct a q -DDHI distinguisher D with an advantage of solving the q -DDHI problem, denoted by Adv q-DDHI , that satisfies |Pr[S (0,1-b) ] -Pr[S (0,1-b,b) ]| ≤ Adv q-DDHI (1 k ).

Game(0,1-b,1-b): It is the same game as Game (0,1-b,b) except that, when executing the AccessControl protocol with u 1-b , we replace the tag T 1-b i by a random value. Then, we simulate the proof π 1-b 3 . Such a proof can be easily simulated in the random oracle model through the use of standard techniques. Under the q -DDHI assumption, the adversary cannot detect this change. In fact, one can easily construct a q -DDHI distinguisher D with an advantage of solving the q -DDHI problem, denoted by Adv q-DDHI , satisfying

|Pr[S (0,1-b,b) ] -Pr[S (0,1-b,1-b) ]| ≤ Adv q-DDHI (1 k ).
Let Game 1 be the same game as Game(0,1-b,1-b). It results from the above that

|Pr[S 0 ] -Pr[S 1 ]| ≤ 2 × (Adv DDH (1 k ) + Adv q-DDHI (1 k ))
We proceed similarly for each of the adversary's calls to the OAccessControl U protocol on ID u 0 and ID u 1 . Thereby, for k = 1 to (N max -1), we construct the following sequence of games: . Let Game k+1 be the same game as Game(k,1-b,1-b). It results from the above that

|Pr[S k+1 ] -Pr[S k ]| ≤ 2 × (Adv DDH (1 k ) + Adv q-DDHI (1 k ))
Following the same reasoning, Game N max -1 is the same game as Game(N max -2,1-b,1-b). However, in the latter game, the challenger C provides no information (in a strong information theoretic sense) about the bit b to the adversary A. This is due to the fact that all values involving the user's secret s u i and that are not computed in a perfectly hiding way (i.e. ElGamal ciphertext and the tag T i ) have been replaced by random ones. Thus, Pr[S Nmax-1 ] = 1/2. Therefore, we can set an upper bound for the adversary's advantage Adv unlink-b A (1 k ). In fact,

Adv unlink-b A (1 k ) = |Pr[Exp unlink-b A (1 k ) = b] -1/2| = |Pr[S 0 ] -Pr[S Nmax-1 ]|.
It results from the above that:

|Pr[S 0 ] -Pr[S Nmax-1 ]| ≤ Nmax-1 j=0 |Pr[S j ] -Pr[S j+1 ]| ≤ 2N max × (Adv DDH (1 k ) + Adv q-DDHI (1 k ))

In this chapter, based on our algebraic MAC scheme MAC n

BB introduced in Section 4.2, we propose a practical Keyed-Verification Anonymous Credentials (KVAC) system that provides multi-show unlinkability of credentials and whose presentation proof is of complexity O(1) in the number of group elements. Through slight modifications (solely on the verifier side), our KVAC system can be easily turned into a public-key credentials system so that anyone can verify credentials validity. Our proposal is almost as efficient as Microsoft's U-Prove anonymous credentials (which does not ensure multi-show unlinkability) and many times faster than IBM's Idemix while being suitable for resource constrained environments such as SIM cards. To show its efficiency and suitability for real-world use cases, we implemented it on a standard NFC SIM card. In particular, the presentation of a credential with 3 attributes can be performed in only 88 ms. This work has resulted in the publication "Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials" [START_REF] Barki | Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials[END_REF] at SAC 2016.

Anonymous Credentials

Introduced by Chaum [START_REF] Chaum | Security without identification: Transaction systems to make big brother obsolete[END_REF], anonymous credentials systems allow users to obtain a credential from an issuer and then, later, prove possession of this credential, in an unlinkable way, without revealing any additional information. This primitive has attracted a lot of interest as it complies with data minimization principles that consist in preventing the disclosure of irrelevant and unnecessary information. Typically, an anonymous credentials system is expected to enable users to reveal a subset of the attributes associated to their credentials while keeping the remaining ones hidden. For instance, a service provider only needs to know that a user is legitimate (i.e. he is authorized to access the service) without yet being able to collect personal information such as address, date of birth, etc.

Potential applications of anonymous credentials are numerous, including e-cash [HZB + 13], public transport and electronic toll (for authentication purposes). In such applications, the system efficiency is an important requirement especially as it is usually deployed on constrained environments like smart cards.

Furthermore, it is desirable that an anonymous credentials system provides multi-show unlinkability. That is, one can prove possession of the same credential several times in an unlinkable manner. However, when it is intended for eCash applications, credentials should be one-show to prevent double spending of coins.

In this chapter, we aim to design an anonymous credentials system that provides multi-show unlinkability while being both efficient and suitable for resource constrained environments like SIM cards (that cannot handle pairing computations). To this end, we rely on our algebraic MAC scheme introduced in 4.2 to construct a practical Keyed-Verification Anonymous Credentials (KVAC) system whose presentation proof is of complexity O(1) in the number of group elements. Next, we explain how to turn our KVAC system into a public key credential system through the use of pairings solely on the verifier side. Then, we provide efficiency and complexity evaluations as well as timings results of the implementation of our proposal on an NFC SIM card. Finally, we formally prove the security of our KVAC system under classical assumptions.

Related Work

One of the most prevalent anonymous credentials systems is Microsoft's U-Prove [START_REF] Paquin | U-Prove Technology Overview V1.1[END_REF][START_REF] Paquin | U-Prove cryptographic specification V1.1 (Revision 3)[END_REF] which is based on a blind signature scheme due to Brands [START_REF] Brands | Untraceable off-line cash in wallet with observers[END_REF]. It is quite efficient, as it works in prime-order groups, and supports the selective disclosure of attributes. Nevertheless, U-Prove does not provide multi-show unlinkability unless the user uses a different credential at each proof of possession. Besides, to date, its security has not been formally proven.

A slightly less efficient anonymous attribute-based credentials system has been proposed by Baldimsti et al. [START_REF] Baldimtsi | Anonymous credentials light[END_REF]. Their proposal, which relies on an extension of Abe's blind signature scheme [START_REF] Abe | A secure three-move blind signature scheme for polynomially many signatures[END_REF], is proven secure in the Random Oracle Model (ROM) under the DDH assumption. Recently, Fuchsbauer et al. [START_REF] Fuchsbauer | Practical round-optimal blind signatures in the standard model[END_REF] introduced another anonymous credentials system that is proven secure in the standard model. However, similarly to U-Prove, both systems are one-show (i.e. credential presentations are linkable if a credential is used more than once).

IBM's Identity Mixer, commonly known as Idemix [START_REF] Ibm | Specification of the identity mixer cryptographic library[END_REF], is built on Camenisch-Lysyanskaya (CL) signature scheme [START_REF] Camenisch | An efficient system for non-transferable anonymous credentials with optional anonymity revocation[END_REF][START_REF] Camenisch | A signature scheme with efficient protocols[END_REF]. Unlike previously reviewed credentials systems, Idemix credentials provide multi-show unlinkability but at the cost of a less efficient proof of possession.

Keyed-Verification Anonymous Credentials Systems

Indeed, the used CL signatures are based on the Strong RSA assumption [START_REF] Baric | Collision-free accumulators and fail-stop signature schemes without trees[END_REF]. This implies large RSA parameters which make Idemix unsuitable for constrained devices. Despite this, Vullers et al. focused in [START_REF] Vullers | Efficient selective disclosure on smart cards using idemix[END_REF] on the implementation of Idemix on MULTOS smart cards. Using a 1024-bit modulus, their implementation enables the presentation of a credential with three attributes, one of which is undisclosed, in 1 second. Moreover, Piedra et al. [START_REF] De La Piedra | Towards a full-featured implementation of attribute based credentials on smart cards[END_REF] addressed smart cards limited Random Access Memory (RAM) issues by proposing a RAM-efficient implementation of Idemix. Thereby, smart cards can support Idemix credentials with more than 5 attributes. Unfortunately, even with these implementation improvements, timing results far exceed the time constraints of some use cases, which limits the use of Idemix in practice.

Camenisch and Lysyanskaya introduced in [CL04] an efficient signature scheme defined in bilinear groups and used it to construct an anonymous credentials system. Shortly afterwards, Akagi et al. [START_REF] Akagi | An efficient anonymous credential system[END_REF] provided a more effective Boneh Boyen-based anonymous credentials system. Recently, Camenisch et al. [START_REF] Camenisch | Composable and modular anonymous credentials: Definitions and practical constructions[END_REF] proposed a Universally Composable (UC) secure anonymous credentials system that provides multi-show unlinkability and whose presentation proof is of constant size. Nevertheless, these three proposals require the prover to compute pairings and/or perform computations in G 2 . Thus, they cannot be implemented on SIM cards as the latter cannot handle such heavy computations.

Recently, Chase et al. [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF] have opted for the use of symmetric key primitives, instead of digital signatures, so as to achieve better performances. More precisely, they used algebraic Message Authentication Codes (MACs), that relies on group operations rather than block ciphers or hash functions, as the main building block of their credentials system. Their two proposals, denoted MAC GGM and MAC DDH , assume that the issuer of the credential and the verifier share a secret key. In such a setting, the anonymous credentials system is referred to as Keyed-Verification Anonymous Credentials (KVAC). Unfortunately, their presentation proofs, for n unrevealed attributes, are of complexity O(n) in the number of group elements. Moreover, when credential blind issuance is required, their KVAC systems do not provide perfect anonymity as they rely on ElGamal encryption to hide attributes.

As pointed out in [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF], one can switch between the use of public-key and keyed-verification anonymous credentials which are more efficient. For that, whenever interacting with a new entity, the user proves the possession of a publicly verifiable credential (such as a driving license anonymous credential issued by a government on a set of attributes) and gets back a keyedverification credential on the same attributes without disclosing them. Thus, during subsequent interactions with that entity, the user will use the keyed-verification credential for better efficiency.

Keyed-Verification Anonymous Credentials Systems

In this section, we first define Keyed-Verification Anonymous Credentials (KVAC) systems as well as their requirements. Next, we detail our new KVAC system that is built upon our MAC n BB scheme.

Overview on KVAC systems

A keyed-verification anonymous credentials system is defined through the following algorithms which involve three entities: a user U, an issuer I and a verifier V.

Setup(1 k ) creates the system public parameters pp, given a security parameter k.

CredKeyGen(pp) generates the issuer's private key sk, which is shared with V, and computes the corresponding public key pk.

BlindIssue(U( → m, s), I(sk)) is an interactive protocol between a user U who wants to get an anonymous credential on a set of attributes → m = (m 1 , . . . , m n ) and a secret value s, without revealing them, and the issuer I who holds the private key sk. If the protocol does not abort, the user gets a credential σ.

Show(U(s, σ, → m, φ), V(sk, φ)) is an interactive protocol between U, who wants to prove that he holds a valid credential on attributes → m satisfying a given set of statements φ, and V, holding the private key sk, whose goal is to check that it is actually true.

Security Model

In addition to the usual correctness property, a KVAC system should satisfy four security properties, namely unforgeability, anonymity, blind issuance and key-parameter consistency. Roughly speaking, they are defined as follows:

-Unforgeability: it should be infeasible for an adversary to generate a valid ZKPK that convinces a verifier that he holds a credential satisfying a given statement, or a set of statements, when it is not actually true;

-Anonymity: the presentation proof produced during the protocol Show reveals nothing else aside from the statement φ being proven;

-Blind issuance: BlindIssue is a secure two-party protocol for generating credentials on the user's attributes;

-Key-parameter consistency: an adversary should not be able to find two secret keys that correspond to the same issuer's public key.

Hereinafter, we provide more formal definitions of these security properties. It is worth mentioning that the security model described below is taken almost verbatim from [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF]. For the sake of simplicity, the security model defines the correctness, unforgeability and anonymity properties in a particular setting where the attributes associated to issued credentials are known to the issuer. This requires an additional secure two party blind issuing protocol that allows a user to obtain credentials, on undisclosed attributes, identical to those provided by an issuer which knows all attributes.

In the sequel, ShowVerify refers to the part of the credential presentation phase (i.e. Show protocol) that is run on the issuer side. We also require two additional algorithms described as follows:

Issue(sk, → m) generates a credential on known attributes → m = (m 1 , . . . , m n ) using the secret key sk. It is run directly if the issuer is trusted to behave honestly and all attributes are revealed. Otherwise, BlindIssue should be used to get credentials with some hidden attributes.

CredVerify(sk,

→ m, σ) verifies, using the secret key sk, that the credential σ is valid with respect to → m. As it reveals both the credential and its attributes, it is never run (for user's privacy protection purposes). Instead, it is used to define the set of valid credentials for attributes (m 1 , . . . , m n ) under sk.

Correctness

Let Φ be the set of statements supported by a credentials system and U be the universe of attribute sets. A KVAC system (CredKeyGen, Issue, CredVerify, Show, ShowVerify) satisfies correctness,

Proof of possession of a credential

We describe an instantiation of our presentation protocol using non-interactive Schnorr-like proofs. As in [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF], our protocol does not include proof of any additional predicates φ, but outputs a commitment H on the attributes which may be used as input to further proof protocols.

Hereinafter, we detail the ZKPK π 3 = PoK{α, β, λ, δ 1 , . . . , δ n+1 , γ, θ :

E = C α f β ∧ H = g δ 1 1 . . . g δn n g δ n+1 B λ 0 f β ∧ C = E θ f γ } where E = C 1/l f t , H = E • h -1 = g m 1 1 g m 2 2 . . . g mn n g su B -r/l 0 f t and C = E l f -tl . Prover Verifier Private Input: → m = (m 1 , . . . , mn), l, t su and r Choose a 1 , a 2 , . . . , a n+6 R ← Z * q Compute t 1 ← C a 1 f a 2 t 2 ← g a 3 1 g a 4 2 . . . g a n+2 n g a n+3 B a n+4 0 f a 2 t 3 ← E a n+5 f a n+6 Compute c = H(Ch, t 1 , t 2 , t 3 ) Ch ← ---------- Choose Ch ∈ R Z * p Compute R 1 ← a 1 + c/l, R 2 ← a 2 + ct c,R 1 ,...,R n+6 ----------→ Compute t 1 = C R 1 f R 2 E -c for i ∈ {1, . . . , n}, R i+2 ← a i+2 + cm i t 2 = g R 3 1 . . . g R n+2 n g R n+3 B R n+4 0 f R 2 H -c R n+3 ← a n+3 + csu, R n+4 ← a n+4 -cr l t 3 = E R n+5 f R n+6 C -c R n+5 ← a n+5 + cl, R n+6 ← a n+6 -ctl Check if c = H(Ch, t 1 , t 2 , t 3 )
Proof. The completeness of the protocol follows by inspection. The soundness follows from the extraction property of the underlying proof of knowledge2 . In particular, the extraction property implies that for any prover P * that convinces V with probability ε, there exists an extractor which interacts with P * and outputs (α, β, λ, δ 1 , . . . , δ n+1 , γ, θ) with probability poly(ε). Moreover, if we assume that the extractor inputs consists of two transcripts i.e. (G, g, h, f, B 0 , C, E, c, c, R 1 , . . . , R n+6 , R1 , R2 , . . . , Rn+6 ), the witness can be obtained by computing

α = R 1 -R1 c-c ; β = R 2 -R2 c-c ; δ i = R i+2 -Ri+2 c-c , ∀i ∈ {1, . . . , n}; δ n+1 = R n+3 -Rn+3 c-c ; λ = R n+4 -Rn+4 c-c ; θ = R n+5 -Rn+5 c-c , γ = R n+6 -Rn+6 c-c
; (all the computations are done mod p). The extractor succeeds when (c -c) in invertible in Z p . We know that H

= E • h -1 = g δ 1 1 . . . g δn n g δ n+1 B λ 0 f β so E = g δ 1 1 . . . g δn n g δ n+1 B λ 0 f β h. We also know that E = C α f β so C α f β = g δ 1 1 . . . g δn n g δ n+1 B λ 0 f β h and then C α = g δ 1 1 . . . g δn n g δ n+1 B λ 0 h. (6.1) Since C = B y 0 , we have B αy 0 = g δ 1 1 . . . g δn n g δ n+1 B λ 0 h and B αy-λ 0 = g δ 1 1 . . . g δn n g δ n+1 h. (6.2)
If α = 0, (8.9) implies that

(B α 0 ) y-λ α = g δ 1 1 . . . g δn n g δ n+1 h. ( 6

.3)

Let A = B α 0 , r = -λ α , s u = δ n+1 and m i = δ i for i ∈ {1, . . . , n}. If α = 0, (6.3) implies that the prover knows a valid MAC n BB , (A, r, s u ) on a block of messages (m 1 , . . . , m n ). Note that y -λ α = 0, otherwise this would imply that the prover knows y which would be equal to λ α .

Chapter 7

An Anonymous Authentication and Identification Protocol for eSIM To cope with a real issue that has arisen at the GSM Association (GSMA), we propose in this chapter a privacy-preserving protocol enabling the anonymous authentication and identification of an eSIM to a Mobile Network Operator (MNO) independent third party known as Subscription Manager-Discovery Server (SM-DS). Thereby, following a switch of MNO, an eSIM can be remotely provisioned with its new network profile whilst protecting the privacy of its owner against a malicious discovery server. Our protocol relies on our BB-based Pre-DAA scheme (detailed in Section 4.4) which is suitable for SIM cards as it requires no pairing computations on the platform side. A variant of this proposal was patented on November 23, 2015 [START_REF] Barki | Procédé d'identification anonyme d'un module de sécurité[END_REF].

Embedded SIM (eSIM)

As mentioned in Chapter 2, some M2M devices (e.g. smart meters) are not designed in a way enabling the removal or replacement of the SIM card as the latter is either hardly accessible or welded in the device at its manufacture. Thus, there is no way to switch from one network operator to another. Furthermore, if one decides to change the subscription associated to several devices deployed in different locations, then the replacement of all SIM cards can be quite costly.

To cope with this issue and provide more flexibility, the GSMA introduced a new generation of SIM cards referred to as embedded SIM (eSIM), or eUICC, which enables the change of the subscription associated to a SIM card while keeping the same chip and level of security as classical Chapter 7 : An Anonymous Authentication and Identification Protocol for eSIM SIM cards. The GSMA also proposed an architecture for Over-The-Air remote SIM provisioning with their new network profiles (see Section 2.3.2 for details). This architecture involves a Mobile Network Operator (MNO) independent third party known as Subscription Manager-Discovery Server (SM-DS) which mainly aims to provide an eSIM with the address of a server, called Subscription Manager-Data Preparation+ (SM-DP+), that has generated its new profile [GSM16b]. Thereby, the eSIM can get in touch with it to download its new network profile. Indeed, the role of the SM-DS consist in routing the eSIM, or the device embedding it, to the right SM-DP+ so as to download its new profile and install it. To do so, the SM-DS maintains a correspondence table according to the EIDs.

However, if no privacy-preserving mechanisms are set up, the SM-DS would be able to trace the eSIM subscription changes all along its life cycle, hence entailing some privacy concerns. To prevent this, we propose in this chapter a privacy-preserving protocol that enables the discovery server (i.e. SM-DS) to anonymously authenticate and identify the relevant eSIM. Thereby, it can provide the eSIM with the address of the corresponding SM-DP+ without knowing with which eSIM it is currently interacting (i.e. without knowing the unique identifier, denoted by EID, of the eSIM).

System Framework

As detailed in Section 2.3.2, the remote SIM provisioning architecture involves four main stakeholders, namely an embedded SIM (eSIM) (also known as eUICC) which is uniquely identified by its eUICC identifier referred to as EID, a mobile network operator (MNO), a Subscription Manager-Data Preparation (SM-DP+), and an MNO independent third party known as Subscription Manager-Discovery Server (SM-DS). It is noteworthy to mention that the eUICC Manufacturer (EUM) is also indirectly involved as it handles the issuance of the membership certificate that enables the authentication of the eSIM to the SM-DS and SM-DP+.

The main steps that take place whenever the user changes the subscription associated to an eSIM are as follows (more details are provided in Section 2.3.3):

1. Profile Generation: The MNO asks a specific SM-DP+ to generate the eSIM new profile. The latter will be securely stored until its download by the corresponding eSIM. 3. Discovery Request: The eSIM queries its default SM-DS to know whether there is a pending new profile for it. If so, after authenticating, and identifying, the eSIM, the SM-DS provides it with the address of the SM-DP+ that has generated its new profile.

4. Profile Download : The eSIM contacts the relevant SM-DP+ so as to download its new profile. After mutually authenticating each other, the eSIM is finally securely provided with its new network profile.

5. Notification De-Registration: Following a successful profile download, the SM-DP+ notifies the SM-DS. Thus, the latter can delete the corresponding notification as it is no longer useful.

Requirements

In this section, we define the different requirements that an anonymous authentication and identification protocol for eSIM must fulfill. The latter are classified in two categories: security requirements and functional requirements.

In the sequel, we make the following assumption: the SM-DS is assumed to be honest but curious. That is, the SM-DS correctly follows the protocol but may try to learn some additional information from received notifications and requests.

Security requirements

The security properties that an anonymous authentication and identification protocol shall satisfy are as follows:

-Consistency: A discovery request sent by a legitimate eSIM (for which a new profile has been generated by an SM-DP+) must necessarily match with one of the notifications stored in the default SM-DS.

-Unlinkability: The SM-DS should not be able to (1) link the different subscription changes associated with the same eSIM (i.e. same EID), or (2) retrieve the EID of the eSIM that generated a given discovery request.

Functional requirements

In addition to the security requirements stated above, the protocol must fulfil the following two functional requirements:

-Efficiency: The privacy-preserving protocol must not negatively impact the user's experience. Therefore, it ought to be as efficient as the original protocol (which entails some privacy issues).

-No-pairings: The protocol is intended for eSIMs which, we recall, cannot handle pairing computations (or even computations in either G 2 or G T ). Therefore, the proposed solution should not require any pairing computations on the eSIM side.

Chapter 7 : An Anonymous Authentication and Identification Protocol for eSIM

Discovery Request

To download its new profile, the eSIM must first know which SM-DP+ holds it (i.e. the address of the SM-DP+ that has generated it). To this end, it generates an anonymous profile request that it transmits to the discovery server (SM-DS).

A request initiated at a given date, d c , consists of the tag T = H(d c ) EID along with a signature σ on it. To generate σ, the eSIM proceeds as if it is creating a BB-based Pre-DAA signature with respect to the basename bsn = d c and for m = ∅. More specifically, the eSIM randomly picks l, t ∈ Z * p and computes B 0 = A l , a randomized version of its membership certificate. Then, it computes C = (g EID

1 g su 2 h) l B -r 0 = B y 0 and E = C 1 l f t . Thus, σ is defined as σ = (B 0 , C, E, π 3 ) where π 3 = PoK{α, β, λ, δ 1 , δ 2 , θ, γ : E = C α f β ∧ H = E • h -1 = g δ 1 1 g δ 2 2 • B λ 0 • f β ∧ C = E θ f γ ∧ T = H(d c ) δ 1 }.
Upon the receipt of a profile request, the SM-DS first verifies that e(C, g0 ) = e(B 0 , W ). If so, it checks the validity of the proof π 3 . The request is considered valid only if both checks succeed. In such case, the SM-DS queries its database to verify whether there is an entry with the same tag T = H(d c ) EID . If it is the case, it provides the eSIM with Add SM -DP + , the address of the corresponding SM-DP+, from which it can download its new profile. Otherwise, the discovery request is discarded.

Security Analysis

The security of our anonymous authentication and identification protocol mainly relies on the security of our BB-based Pre-DAA scheme (see Section 4.4.3). Hereinafter, we state the assumptions under which our protocol satisfies the required security properties.

-Consistency. It follows by inspection. Indeed, if the same EID is used to generate both the set S and the discovery request, then one of the elements of S will be equal to the tag T = H(d c ) EID included in the discovery request.

-Unlinkability. The sets S and S sent to the SM-DS following two subscription changes associated with the same eSIM are respectively defined as S = {H(d s ) EID , H(d s + 1) EID , . . . , H(d s + M ax) EID } and S = {H(d s ) EID , H(d s + 1) EID , . . . , H(d s + M ax) EID } where d s and d s are the corresponding dates of subscriptions. Therefore, under the DDH assumption and as long as the eSIM does not make two subscription changes within M ax days1 , our anonymous authentication and identification protocol ensures the first condition in the ROM. In fact, if two subscription changes are made within M ax days, then the default SM-DS will receive two sets S and S such that S ∩ S = ∅. Thus, the SM-DS will be able to link the eSIM subscription changes. As for the second condition, it follows from the anonymity property of our Pre-DAA scheme as the signature produced in our anonymous authentication and identification protocol is exactly the same as the one of the BB-based Pre-DAA scheme. We recall that our Pre-DAA scheme ensures anonymity in the ROM under the XDH assumption (see Section 4.4.3). Therefore, our protocol provides unlinkability, in the ROM, under the XDH assumption.

Performance Assessment

To show the efficiency and suitability of our protocol for SIM cards, we implemented the eSIM side of the Discovery Request protocol on an NFC-enabled standard SIM card. Hereinafter, we provide the details of our testbed environment and the corresponding timing results.

Testbed Environment

The eSIM side of the Discovery Request protocol was implemented on a Javacard 2.2.2 SIM card, GlobalPlatform 2.2 compliant, embedded in a Samsung galaxy S3 NFC smartphone. We used the same card as in Chapter 5 (i.e. its only particularity, compared to javacard specifications, is some additional API provided by the card manufacturer enabling operations in modular and elliptic curve arithmetic). The SM-DS side of the Discovery Request protocol was run on a PC (Intel Xeon CPU, 3.70GHz). The communication between the SIM card in the smartphone and the PC was done in NFC using a standard PC/SC reader (an Omnikey 5321). Finally, for the implementation, we used a 256-bit prime "pairing friendly" Barreto-Naehrig elliptic curve.

Implementation Results

Table 7.1 below gives timing results of the implementation of the Discovery Request protocol both in the case where the smartphone is switched on or off. The protocol is split into two parts so as to provide better performance results: an off-line part that can be run in advance by the card and an on-line part that needs to be performed on-line as it depends on the verifier's challenge. The Signature generation (by card) refers to the total time, from the applet selection to the request reception, including the sending of the challenge Ch and the basename bsn (i.e. d c in this use case) by the verifier (i.e. SM-DS), but excluding the proof verification. Battery-On denotes a switched on phone whereas Battery-Off refers to a powered-off phone either by the user, or because the battery is flat. In this latter situation, as stated by NFC standards, NFC-access to the SIM card is still possible, but with deteriorated performances.

Off-line computations are assumed to be automatically launched by the smartphone (Battery-On) following a signature generation and in anticipation for the next one. It is worth mentioning that all computations on the SIM side are entirely performed by the card. In fact, the smartphone is only used to trigger the protocol and to power the card. As regards to On-line computations, they refer to the calculation of the values T and t 4 , the hash c as well as R 1 , . . . , R 7 involved in the proof π 3 . They can be potentially carried out even with a battery-off phone (provided that they are triggered from an external card reader). In our implementation, we assumed that bsn (i.e. the current date d c in this use case) is not known in advance but rather provided to the card on-line. Consequently, the card has two scalar multiplications to compute on-line. For use cases where the bsn can be known in advance, these multiplications may be included in the off-line computation part, hence resulting in much better performances. Indeed, one scalar multiplication on our card takes around 60 ms.

Conclusion

Using our BB-based Pre-DAA scheme introduced in Section 4.4 as main building block, we proposed an anonymous authentication and identification protocol for embedded SIMs. Our 121 Chapter 7 : An Anonymous Authentication and Identification Protocol for eSIM scheme aims to enable the authentication of an eSIM to an MNO independent entity known as Discovery Server while preserving the privacy of its owner. Thereby, we show one of the potential applications of our practical Pre-DAA schemes which require no pairing computations (or even computations on G 2 or G 3 ) on the platform side.

In the next chapter, based on our sequential aggregate MAC scheme, we design an efficient coercion-resistant electronic scheme where voter's credentials can be efficiently updated so as to enable credentials revocation as well as votes in multiple elections. In this chapter, we propose a new coercion-resistant remote electronic voting scheme suitable for real polls as, unlike previous proposals, it has linear time complexity. Our scheme relies on credentials generated based on the algebraic MAC GGM scheme due to Chase et al [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF]. Through the use of our sequential aggregate MAC scheme introduced in Section 4.3, voters' credentials can be efficiently updated so as to enable credentials revocation and allow eligible electors to vote in subsequent elections.

This work has been published in the paper "Remote Electronic Voting can be Efficient, Verifiable and Coercion-Resistant" [ABBT16] at VOTING'16.

Remote Electronic Voting

Internet voting offers a better voting experience since voters can cast their votes from their computers or even their smartphones. By eliminating the need to visit polling places, it may attract more voters and thus increase voter turnout. In addition, it improves the efficiency of vote tallying.

These benefits motivated countries such as Estonia and Switzerland to adopt it in real world elections. However, it is still not widely spread. This is particularly due to many inherent concerns such as selective DDoS attacks on the election server, malware attacks on the voter client as well as risks entailed by the lack of private polling booths [US 15].

In this work, we mainly focus on the latter concern while assuming that the voting devices are trustworthy; therefore, votes will be cast-as-intended. Indeed, adversaries may leverage the lack of private polling booths to perform coercion or vote-selling attacks. Consequently, electronic voting schemes ought to address this issue that remained a challenge for many years.

To this end, Juels, Catalano and Jakobsson (JCJ) [START_REF] Juels | Coercion-resistant electronic elections[END_REF] introduced an essential property known as coercion-resistance. It considers the different actions that a coercer could undertake, namely constrain a voter to cast a given vote, force her to reveal her private voting credential and subsequently vote on her behalf, or keep her from voting. They also proposed the first coercion-resistant scheme based on anonymous credentials. To be able to vote, an eligible voter is beforehand provided with a valid credential. Under coercion, she can use a fake credential instead of her valid one. Thereby, she deceives any adversary about her true vote intention as a coercer is unable to distinguish the fake credential from the valid one. Unfortunately, JCJ's scheme is inefficient for large scale voting scenarios as, for N ballots, the complexity of the tallying is in O(N 2 ).

To cope with this issue, we propose an efficient coercion-resistant voting scheme which has linear time complexity and thus, is suitable for real polls. Our scheme relies on credentials generated based on the recent algebraic MAC scheme due to Chase et al. [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF]. We prove that, even though a part of our credentials are made publicly known, a coercer is unable to distinguish a valid credential from a fake one. Furthermore, our scheme allows talliers to check credentials validity even though they are encrypted. Using our sequential aggregate MAC scheme introduced and proven secure in Section 4.3, eligible voters' credentials can be efficiently updated to allow them to vote in new elections. Credentials of voters who are no longer eligible to vote can be revoked as well. Thanks to these improvements, coercion-resistance is obtained almost for free as the proposed scheme is just slightly slower than non coercion-resistant classical mix-net based voting schemes.

Related Work

To enhance JCJ's voting system [START_REF] Juels | Coercion-resistant electronic elections[END_REF] and provide linear time tallying, some coercion-resistant schemes were then proposed. In what follows, we briefly review the most promising proposals.

Araújo, Foulle and Traoré [START_REF] Araújo | A practical and secure coercion-resistant scheme for remote elections[END_REF] were the first to propose a coercion-resistant electronic voting scheme that achieves linear time complexity. Nevertheless, their proposal does not support multiple elections. Indeed, at each new election, the voter has to visit the registration place in order to obtain her credential associated to the new poll.

To address this shortcoming, Araújo and Traoré [AT13] later proposed another scheme that allows credentials revocation and multiple elections. To issue a new credential, their scheme requires the registration authorities to jointly generate a BBS [START_REF] Boneh | Short Signatures Without Random Oracles[END_REF] group signature. Unfortunately, up to now, there is no practical solution to compute such a signature in a distributed manner, which makes the scheme impractical for real polls. It is, however, noteworthy to mention that they also proposed a generic technique to identify valid, but illegitimate, voting credentials that a majority of colluding registrars could compute. Even though such an event is unlikely, their generic technique applies to other voting schemes including the one that we introduce in this chapter.

Remote Electronic Voting System Framework

Finally, Clark et al. [START_REF] Clark | Selections: Internet voting with over-the-shoulder coercion-resistance[END_REF] and Spycher et al. [START_REF] Spycher | A new approach towards coercion-resistant remote e-voting in linear time[END_REF] proposed two different approaches to tackle the coercion-resistance issue. However, both schemes do not really have linear time complexity. They truly achieve it only if the level of anonymity is lowered. More specifically, a voter's ballot is indistinguishable from a small set of ballots and not from all the received ones.

Remote Electronic Voting System Framework

In this section, we first introduce the different parties involved in an electronic voting scheme. Then, we indicate the assumptions that are made in this work. Next, we give an overview of the five phases of our remote electronic voting scheme.

Stakeholders

A remote electronic voting system involves as participants a set of registration authorities R known as registrars, a set of tallying authorities T referred to as talliers and a set of voters V. For security reasons, the roles of both registrars and talliers are generally distributed among a large group of authorities. Thus, they must collaborate in order to generate a new credential or tally the votes (i.e. none of them can generate a new credential or decrypt a vote on his own).

Assumptions

In this work, we assume that the voting device (i.e. PC or smartphone) is trusted. Thus, electors' votes will be cast-as-intended. That is, the vote encrypted in the received ballot matches the elector's choice.

Our voting scheme also makes use of a Bulletin Board (BB), which is a publicly accessible memory with an appendive-write access (i.e. one can only append data to BB, but he is not allowed to erase or overwrite existing data).

System Framework

Our coercion-resistant voting scheme mainly consists of five main phases, namely Setup, Registration, Voting, Pre-Verification and Tallying. (1) During the Setup phase, election parameters as well as required keys are generated. (2) To be able to vote, an eligible voter must register through a Registration phase. After proving her identity, she receives a unique and valid credential (associated to a secret s) that is issued by the registration authorities. (3) Later, during Voting phase, the voter uses her credential and the secret s to generate a ballot that she sends via an anonymous channel. (4) Before tallying votes, a Pre-Verification phase is carried out to remove both erroneous ballots as well as duplicate votes. (5) Once done, the tallying authorities perform the Tallying phase where valid votes are decrypted so as to compute election result and publish them on the Web Bulletin Board (WBB).

These five phases can be modelled through the following algorithms and protocols:

1. Setup aims to initialize the system parameters as well as the required keys. It consists of the following two algorithms:

-PubParam(1 k ): On input a security parameter k, this probabilistic algorithm outputs the system public parameters pp.

-KeyGen(pp): On input the system public parameters pp, this probabilistic algorithm outputs the private/public key pairs of the tallying and the registration authorities: the talliers share the private/public key pair (sk T , pk T ) whereas the registrars obtain (sk R , pk R ), which is also shared among talliers. Roughly speaking, coercion-resistance ensures that a voter can deceive the coercer about her true vote intention by making him believe that she behaved as instructed while it was actually not the case. Furthermore, it guarantees that no voter can obtain any information proving for whom she voted (this is known as receipt-freeness). Thereby, both coercion and vote-selling can be avoided. More formally, as defined by Juels, Catalano and Jakobsson [START_REF] Juels | Coercion-resistant electronic elections[END_REF], the coercionresistance experiment between a PPT static1 adversary A and a voter V O targeted by A for a coercion attack is detailed in Figure 8.1 where:

-n V , n C and n A respectively denote the total number of eligible voters, the number of candidates and the number of corrupted voters (i.e. under the control of the adversary A). Thus, the number of uncertain votes (i.e. honest ones) is n U = n V -n A -1.

-V and → X respectively denote the set of corrupted voters and the election outcome; -D n,n C denotes a probability distribution that models the state of knowledge of the adversary about honest voters' intentions;

fakekey(pk R , sk j , pk j ) is a function that takes as input the public key of the registration authorities and the private/public key pair (i.e. voting credential) of the voter j. It outputs a fake key sk; -B j = Voting{(sk j , pk T , n C , β)} represents a ballot cast using the voting key sk j and according to the distribution D n,n C , and where the selected choice is β.

More precisely, a coin is flipped and its outcome is represented by a bit b. The behavior of the coerced voter V O depends on the value of b. If b = 0, then V O (who is modeled as a function that selects a ballot either from a slate representing all the n C candidates or a blank ballot denoted by ∅) casts a ballot encrypting the choice β (which was specified by A) and provides A with a fake voting key (i.e. she attempts to evade the coercion attack). If b = 1, the voter provides A with her "real" voting key and does not cast any ballot (i.e. she submits to A's coercion). where Exp c-resist-ideal

ES,A
is the ideal coercion-resistance experiment depicted in Figure 8.2. In the latter, the adversary denoted by A cannot cast ballots by himself but rather enumerates the choices of corrupted voters. Furthermore, all what A sees is the vote outcome. The experiment Exp c-resist-ideal ES,A involves an ideal function denoted ideal -Tallying, which tallies ballots cast by honest voters in a normal manner and tallies the ballots cast by A in a special way. Indeed, for each ballot A has cast, it determines the underlying private key sk i and if it turns out that sk i 12. Return 0.

Our Coercion Resistant Electronic Voting Scheme

In this section, we first provide an overview of our coercion-resistant voting scheme. Then, we detail its different phases while explaining how it enables multiple elections as well as credentials revocation.

Overview

To be able to vote, an eligible voter must first register by proving her identity. Once done, she obtains a unique and valid credential σ that is associated to a secret s only known to her (i.e. the voter). This credential, which is made publicly available, is issued by the registration authorities.

Using it, as well as the associated secret, the voter can generate a ballot B that contains her choice in an encrypted form. More precisely, the ballot consists of a randomized version of the voter's credential, the ciphertext of her choice as well as two NIZKPKs proving the validity of the ballot. Upon its generation, the ballot is cast via an anonymous channel. If the voter is under coercion, she can cast a fake ballot using an invalid secret s without the adversary being able to distinguish it from a valid one. Before tallying votes, some pre-verifications must be carried out so as to remove both erroneous ballots (i.e. ballots with invalid ZKPKs) as well as duplicate votes. Once done, vote tallying may be performed. To do so, the talliers first send the ballots that got through the pre-verification phase to a verifiable Mix-net [Cha81, JJR02] and then anonymously identify valid ones (i.e. ballots published with valid credentials). Finally, they cooperatively decrypt the associated ciphertexts to recover valid votes and publish the election result on the WBB.

Our Efficient Coercion-resistant Voting Scheme

Setup

Let O be the set of eligible options (candidates) and v ∈ O, one of these options. Let G be a cyclic group with a prime order p and g 1 , g 2 , o ∈ G be three generators such that o is the public generator selected for this election. The talliers share the threshold Modified ElGamal key pair (sk T , pk T ) where sk T = (y 1 , y 2 ) ∈ R Z * p and pk T = (g 1 , g 2 , h = g y 1 1 g y 2 2 ). As for the registrars, they jointly select and share a secret key sk R = (x 0 , x 1 ) ∈ R Z * p 2 associated to the public values (C x 0 , X 1 = h x 1 ) where C x 0 = g x 0 h x such that x ∈ R Z * p . This key is also shared among talliers.

Registration

Once her eligibility proved (using her electoral card for example), the voter obtains a unique and valid voting credential σ generated as follows. After cooperatively choosing s ∈ R Z p and u ∈ R G\{1}, the registrars jointly compute σ = (u, u ) where u = u x 0 +sx 1 . It is then provided, through an untappable channel, to the voter along with the secret value s and a Designated Verifiable Proof (DVP) that σ is a valid credential on s. As previously mentioned in Section 3.3.5.1, a DVP can only convince the corresponding voter and nobody else. So, it is completely useless in case of coercion and even for vote-selling. Concurrently, the credential σ is stored in the database DB, which contains all the valid credentials, while s is kept as a secret only known to the voter. In case of coercion, the voter would deceive the coercer by revealing her credential along with a fake value s without the coercer noticing it. Indeed, as shown hereinafter in Lemma 8.1, under the DDH assumption, the coercer cannot decide whether s is valid with respect to the voter's credential σ or not (i.e. decide if a given triplet (s , u, u = u x 0 +sx 1 ) is a valid MAC on s or not). It is worth mentioning that the generic technique proposed in [START_REF] Araújo | A practical coercion resistant voting scheme revisited[END_REF] can be subsequently used Chapter 8 : An Efficient Coercion-Resistant Remote Electronic Voting Scheme so as to detect any vote cast with a valid, but illegitimate, credential that is computed by a set of colluding malicious registrars. Lemma 8.1. Under the DDH assumption, it is infeasible to decide whether s ? = s mod p from s , C x 0 = g x 0 h x , X 1 = h x 1 , u = h b , u = u x 0 +sx 1 where s, s , x, x 0 , x 1 , b ∈ R Z * p and g, h are two random generators of G.

Proof (sketch). Suppose that we have an oracle deciding whether s ? = s mod p, given s , X 1 = h x 1 , C x 0 = g x 0 h x , u = h b , u = u x 0 +sx 1 , for s, s , x, x 0 , x 1 , b ∈ R Z * p and g, h are two random generators of G. Then, we show how to decide whether c ? = x 1 b mod p given h, α = h x 1 , β = h b and γ = h c for x 1 , b, c ∈ R Z * p , hence contradicting the DDH assumption. The reduction is as follows. Set C x 0 = g x 0 h x for x 0 , x ∈ R Z * p , choose s ∈ R Z * p and give s , C x 0 , X 1 = α, u = β, u = u x 0 γ s to the oracle. We have the following two cases:

-Case 1. If c = x 1 b mod p, then u = u x 0 +s x 1 .

-Case 2. If c = x 1 b mod p, then c = x 1 b(1 + c ) for some c = 0 mod p (since x 1 = 0 and b = 0) and u = u x 0 +sx 1 with s = s (1 + c ) = s (since s = 0). Therefore, given s , C x 0 , X 1 = α, u = β, u , the oracle will tell whether s ? = s, from which we can decide whether c ? = x 1 b. In the particular case where s = 0, even a computationally unbounded adversary will not be able to figure out whether u ? = u x 0 . This is due to the fact that the Pedersen's commitment C x 0 = g x 0 h x perfectly hides the value x 0 .

Voting (First Election)

To vote in a first election, the voter first picks a random r ∈ R Z p and generates σ r = (u r , u r ) = (w, w ), a randomized version of her credential σ. Then, she chooses her candidate v ∈ O and casts her vote which consists of the ballot B = E T [v], w, w , E T [w s ], o s , P where P is a set of NIZKPKs ensuring that the ballot is well formed whereas E T [v] and E T [w s ] denote the Modified ElGamal encryptions of respectively v and w s using the talliers' public key pk T . As for P , it includes both π 1 = P oK{α : B 4 = E T [w α ] ∧ B 5 = o α } related to the knowledge of s and π 2 = P oK{β : B 1 = E T [β] ∧ β ∈ O} proving that v belongs to the set O.

Pre-Verification

This phase should be performed by Talliers prior to the tallying one detailed later on. It aims to verify votes posted on the WBB so as to remove ballots with invalid ZKPKs as well as duplicate votes. It is, however, worth mentioning that, during this phase, ballots with invalid credentials are not discarded yet. More precisely, this phase is composed of the following four steps:

1. Verifying proofs. For each posted ballot, the proofs P are verified to remove ballots with invalid proofs.

2. Removing duplicates. By comparing all o s values, duplicates votes (i.e. ballots published using the same secret s) are removed. The policy, in this case, could be to keep the last one.

3. Reconstruction of the credential. For each ballot, the talliers cooperatively compute the modified ElGamal ciphertext E T [w] of w. Owing to ElGamal homomorphic property and through the use of E T [w] and E T [w s ] as well as the shared secret values x 0 and x 1 , the ciphertexts E T [w x 0 ] and E T [(w s ) x 1 ] can be jointly computed. Thereby, the talliers can 8.6. Security Analysis

Hereinafter, we prove coercion-resistance using Shoup's game hopping technique [START_REF] Shoup | Sequences of games: a tool for taming complexity in security proofs[END_REF]. We only provide a rather high level description of the initial game (Game 0) along with brief descriptions of the transitions between successive games.

Game 0: It corresponds to the real attack game with respect to an efficient adversary A. 1. Setup: The Simulator S randomly chooses the system public parameters (G, p, h, g, o) and selects a randomized candidate slate O = {v i } n C i=1 as well as two random values x 0 , x 1 ∈ R Z * p as the registrars secret key sk R . The values C x 0 = g x 0 h x and X 1 = h x 1 , where x ∈ R Z * p , are published. S also randomly picks the talliers private key sk T and computes the associated public key pk T .

2. Register(ID v i ): S uses the private key sk R = (x 0 , x 1 ) to generate a credentials (u, u = u x 0 +s i x 1 ) associated to a random secret s i . Note that S keeps a list L of all generated credentials and their associated secrets.

Adversarial corruption:

The adversary A selects V , the set of n A voters that he wants to corrupt, the voter j to be coerced as well as the target vote β. If any of them is not correctly selected (for instance, |V | > n A ), then the simulation aborts.

Coin flip:

A coin b ∈ {0, 1} is flipped.

5. Credential disclosure: S provides A with the set of credentials {σ i } i∈V and associated secrets as well as the credential σ j = (u j , u j ) and an associated secret s for the targeted voter j (i.e. the voter who will be coerced). If b = 1, then s = s j , otherwise s is chosen at random.

6.

Honest voter simulation: S uses the public key pk T = (g 1 , g 2 , h) of the modified ElGamal cryptosystem to generate the ballots of the honest voters. It also provides the NIZK proofs.

7. Adversarial ballot posting: A posts a set of ballots B 0 .

8. Decrypting A's ballots: S first verifies the NIZK proofs associated to each ballot. Let B 1 be the set of ballots with valid proofs. For each credential whose associated secret is known to A, S decrypts the ballot. 9. Pre-verification simulation: S simulates the behavior of honest tallying authorities as follows:

-Proof checking: Let E 0 = B 1 ∪ A 0 where A 0 are the ballots cast by honest voters. S behaves as an honest tallier by discarding ballots with invalid proofs. Let E 1 be the set of ballots with valid proofs.

-Removing duplicates: S simulates the elimination of duplicate ballots. Let E 2 be the resulting ballot list.

-Credential reconstruction: As it holds the keys (x 0 , x 1 ), S can reconstruct credentials through the use of ElGamal homomorphic property.

-PET pre-test: S performs plaintext equivalent test on credentials. Game 1: This is the same game as Game 0 except that we modify the way the challenger generates the ballots of honest voters. The latter are generated as follows. S chooses a random value τ in Z * p and computes h 1 = g τ 1 and h 2 = g τ 2 . Thus, the quadruple (g 1 , g 2 , h 1 , h 2 ) is a DH quadruple. Using this quadruple and h, S generates the ballots of honest voters. More precisely, it creates each ciphertext of the ballot as follows: for instance, to create the ciphertext encrypting the voting option v k = g t k 1 , S chooses s i ∈ R Z * p at random and sets (c 1 = h s i 1 , c 2 = h s i 2 , c 3 = h s i y 1 1 h s i y 2 2 v k ). Since the quadruple (g 1 , g 2 , h 1 , h 2 ) is a DH quadruple, then this ciphertext has the right distribution. Thus, we have The probability Pr[F ] is bounded by the knowledge error of the proofs of knowledge (which is a negligible quantity denoted by v(k)). Therefore, we have

|Pr[S 2 ] -Pr[S 1 ]| ≤ v(k) (8.5)
Note that we tacitly assumed that the ballots are cast sequentially rather than concurrently so as to enable the rewinding of A in order to extract the secrets. In a concurrent setting, we could use verifiable encryption.

Game 3: This is the same game as Game 2 except that S outputs ⊥ and aborts if at least one of the extracted secret and associated credential (i.e. u, u , s where u = u x 0 +sx 1 ) have not been issued by S or belong to an honest voter. That is, S aborts if A succeeds in forging a valid credential and its associated secret. We recall that the credentials correspond to a MAC GGM on a secret s. Since the MAC GGM scheme, which is due to Chase et al. [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF], is proven UF-CMVA, we have that

|Pr[S 3 ] -Pr[S 2 ]| ≤ Adv MAC GGM U F -CM V A (1 k ) (8.6)
Game 4: This is the same game as Game 3 except that, instead of using a DDH quadruple, S uses a random quadruple (g 1 , g 2 , h 1 , h 2 ) to generate the ballots of honest users. That is, h 1 and h 2 are defined as h 1 = g τ 1 and h 2 = g δ 2 with τ = δ (mod p). Under the DDH assumption, A cannot distinguish this change. Indeed, we can easily construct a DDH distinguisher D 1 with an advantage of solving the DDH problem satisfying

|Pr[S 4 ] -Pr[S 3 ]| ≤ Adv D 1 DDH (1 k ) (8.7)
Note that, with such a change, the view produced by the simulation does not give any information (in a strong information theoretic sense) about the votes posted by honest parties (as modified ElGamal is semantically secure). Indeed, for any ṽ = g t 1 , there exists a private key (ỹ 1 , ỹ2 ) corresponding to the public key h such that the decryption algorithm on input a ciphertext (c 1 , c 2 , c 3 ) outputs ṽ. Let z denote the discrete logarithm of h in base g 1 (i.e. h = g z 1 = g ỹ1 1 g ỹ2 2 ), λ be the discrete logarithm of g 2 in the base g 1 (i.e. g 2 = g λ 1 ), s the common discrete logarithm of c 1 , c 2 in bases h 1 and h 2 , and γ the discrete logarithm of c 3 in base g 1 (i.e. c 3 = g γ 1 ). To find the private key (ỹ 1 , ỹ2 ), we have to solve a system of linear equations: ỹ1 + λỹ 2 = z (8.8)

Conclusion

τ sỹ 1 + λδsỹ 2 = γ -t (8.9)

The equation (8.8) results from the fact that we should have h = g z 1 = g ỹ1 1 g ỹ2 2 whereas equation (8.9) is due to the fact that (c 1 , c 2 , c 3 ) is an encryption of ṽ and, in particular, that c 3 = h sỹ 1 1 h sỹ 2 2 ṽ. The determinant of this system is equal to λs(δ -τ ) which is different from 0, since (g 1 , g 2 , h 1 , h 2 ) is not a DH quadruple (and thus τ = δ (mod p)) and by definition, λ and s are different from 0 (mod p). Consequently, there must exists a solution to the above system. Game 5: In case b = 0, instead of sending a fake credential to A, S sends him a valid one (but the ballot cast by A using this credential will not be included in the final tally). Under the DDH assumption, A cannot distinguish this change. Thus, we have ) Therefore, we can conclude that our electronic voting system satisfies the coercion-resistance requirement in the ROM under the DDH assumption and the UF-CMVA security of the MAC GGM .

Conclusion

In this chapter, we proposed an efficient coercion-resistant electronic voting scheme which has linear time complexity while supporting both credentials revocation as well as multiple elections.

To do so, we rely on credentials generated using Chase et al. algebraic MAC scheme [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF]. In order to allow revocation and multiple elections, voters' credentials are updated using our sequential aggregate MAC scheme introduced in Section 4.3.

Chapter 9 Conclusion

In this thesis, we aimed to combine two security properties, namely authentication and privacy, while dealing with resource constrained environments such as SIM cards. In this context, we introduced five cryptographic primitives, namely a partially blind signature scheme, an algebraic Message Authentication Code (MAC) scheme and a sequential aggregate MAC scheme as well as two Direct Anonymous Attestation schemes. Based on them, we designed four practical privacypreserving protocols that are both efficient and suited for SIM cards.

First, we looked into the privacy issue of electronic payment systems for applications such as electronic Toll (eToll) and Electric Vehicle Charging (EVC) which have already attracted a lot of interest. Unfortunately, existing proposals have some shortcomings: they are either inefficient, or unsuitable for resource constrained environments, or do not support flexible prices. Therefore, we proposed a new electronic Cash system intended for this particular kind of applications, in which the same entity acts as both merchant and bank, referred to as private eCash. To this end, we designed a new partially blind signature scheme which, unlike previous proposals, allows multiple presentations of the same signature in an unlinkable way. Thanks to it, our eCash ensures the necessary security and privacy requirements while being efficient, suitable for SIM cards and enabling flexible prices. Indeed, its implementation on a standard SIM card showed that a transaction can be performed in only 205 ms.

Then, we focused on anonymous credentials, and more precisely on keyed-verification anonymous credentials. The latter are the secret key analogue of traditional anonymous credentials, where users obtain a credential, then prove its possession in an unlinkable way. In this respect, we proposed a practical Keyed-Verification Anonymous Credential system that can be easily turned into an efficient public-key anonymous credential system. To build it, we designed a new algebraic MAC scheme based on Boneh Boyen signature scheme where MACs can be publicly verifiable. Our KVAC system is many times faster than Idemix and almost as efficient as Microsoft's U-Prove whilst, contrary to U-Prove, providing multi-show unlinkability. Furthermore, unlike both KVAC systems introduced at CSS 2014 [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF], its presentation proof is of complexity O(1) in the number of group elements. Last but not least, it only requires the issuer to hold a single private key regardless of the number of attributes.

Next, we dealt with one of the most practical applications of anonymous signatures, namely Direct Anonymous Attestation (DAA). Our goal was to design an efficient DAA scheme which requires neither pairing computations, nor computations in G 2 or G T , on the platform side in order to be suitable for SIM cards. With this aim in mind, we introduced two efficient DAA schemes where all computations on the platform side can be entirely carried out by the TPM. The first proposal is based on an algebraic MAC scheme due to Chase, Meiklejohn and Zaverucha, whereas the second is built upon a pairing-free variant of the Boneh and Boyen's signature scheme. Using the latter as a building block, we proposed a privacy-preserving authentication protocol for embedded SIM so as to cope with a real issue that has arisen at the GSM Association (GSMA). Thereby, we showed how our DAA schemes can be of particular interest for M2M applications that involve a Secure Element (SE) such as a SIM card. We also demonstrated its efficiency by implementing it on a GlobalPlatform compliant SIM card.

Finally, we considered another application of anonymous credentials, specifically remote electronic voting systems. Our main purpose was to provide an efficient coercion-resistance remote electronic voting system that supports credentials revocation (e.g. those of voters who are no longer eligible to vote) as well as multiple elections. To do so, we proposed an efficient sequential aggregate Message Authentication Code scheme. Using it, legitimate voters' credentials can be efficiently updated so as to enable them to vote in new elections without having to revisit the registration place. Unlike other coercion-resistant electronic voting schemes, our proposal really combines practicality and linear time complexity whilst supporting multiple elections.

Our cryptographic schemes as well as privacy-preserving protocols are formally proven to ensure the necessary security and privacy requirements under classical computational assumptions.

Perspectives. In this thesis, we introduced some improvements to a set of cryptographic primitives and privacy-preserving protocols in order to enable their use when dealing with constrained environments such as SIM cards. Unfortunately, some M2M devices (i.e. sensors) are not as "powerful" as resource constrained SIM cards. So, it would be interesting to investigate potential additional enhancements of these primitives so as to adapt them, if possible, for such devices. One solution would consist in delegating the heaviest computations to a more powerful entity (e.g. a smartphone), if such an entity is available, without decreasing the security and privacy levels of the entire solution. Still, if the latter entity is not trusted, the device must verify that the computations were correctly performed. Thus, the computational cost of the result verification ought to be lower than that of computing it.

Furthermore, another M2M application, that is raising serious privacy concerns, is smart metering. Indeed, smart meters, which are currently being rolled-out, may enable the disclosure of several personal information such as sleeping routines, the type of devices being used by the user and even the TV channel he is viewing. So, it would be paramount to study this use case and see whether our proposals could be used to protect user's privacy.

Contents

2. 1

 1 M2M Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.1 Automotive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 eHealth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Smart Metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Smart City . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5 Smart Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 ETSI M2M Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1 High Level Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Service Capability Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 M2M Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 ETSI Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Embedded SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.1 eUICC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 GSMA Remote SIM Provisioning Architecture . . . . . . . . . . . . . . . 2.3.3 Procedures Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 M2M Security Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.1 Physical Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Logical Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Data Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6 M2M Characteristics and Key Challenges . . . . . . . . . . . . . . . . 21 2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 2 .

 2 Figure 2.1: M2M Applications

Figure 2 . 2 :

 22 Figure 2.2: Typical M2M Architecture

Figure 2 . 3 :

 23 Figure 2.3: ETSI interfaces according to deployment scenario [ETS13]

Chapter 2 :

 2 M2M Characteristics and Security Issues

Figure 2 . 4 :

 24 Figure 2.4: High-Level Representation of an eUICC [GSM16c]

Figure 2 . 5 :

 25 Figure 2.5: Remote SIM Provisioning Architecture [GSM16b]

Chapter 2 :( 2 )

 22 M2M Characteristics and Security Issues (1) Protected Profile Generation Procedure MNO SM-DP+ Order P rof ile Creation -----------------------→ Generate and Store Protected Profile Register Profile Conf irm P rof ile Creation ← -----------------------Notification Registration Procedure SM-DP+ SM-DS Send Register N otif ication ------------------------→ (EID, SM-DP+ address, notif-ID)

Figure 2 . 6 : 4 .

 264 Figure 2.6: Profile Generation and Notification Registration/De-registration Procedures

Figure 2 . 7 :

 27 Figure 2.7: Discovery Request and Profile Download Procedures

3. 1

 1 .1 Mathematical Tools 3.1.1.1 Group Definition 3.1 (Group). A group (G, •) consists of a nonempty set G and a binary operation • : G × G → G satisfying the following properties.

Chapter 3 :

 3 Mathematical Tools and Cryptographic Building Blocks -Identity element: ∃ e ∈ G such that ∀x ∈ G, x • e = e • x = x. e is unique and is called the identity element of G, denoted by 1 G .

Chapter 3 :

 3 Mathematical Tools and Cryptographic Building Blocks

Figure 3 . 1 :

 31 Figure 3.1: Addition of two distinct points P and Q on an elliptic curve

Definition 3 .

 3 10 (Polynomial Time Complexity). Let T M (n) = sup{T M(I) , |I| = n} where M is a Turing Machine. The time complexity of M is said to be polynomial if

Figure 3 . 2 :

 32 Figure 3.2: UF-CMA Security

3 .Figure 3 . 3 :

 333 Figure 3.3: EUF-CMA Security

Figure 3 . 4 :

 34 Figure 3.4: Traceability Security Experiment

Figure 3 . 5 :

 35 Figure 3.5: Anonymity Security Experiment

Figure 3 . 6 :

 36 Figure 3.6: Non-Frameability Security Experiment

-

  Enc(pp, pk, m): randomly selects a random r ∈ Z * p . The encryption of a message m ∈ G consists of the pair (c 1 , c 2 ) where c 1 = g r mod p and c 2 = m • pk r . -Dec(pp, sk, c 1 , c 2 ): using the private key sk, it decrypts the ciphertext (c 1 , c 2 ) by computing m = c 2 c sk 1 . The ElGamal cryptosystem is semantically secure under the DDH assumption defined in Section 3.1.3. Besides, it is multiplicatively homomorphic. Indeed, given two ciphertexts C 1 = (c 1 , c 2 ) and C 2 = (c 1 , c 2 ) of two messages m 1 and m 2 , one can efficiently compute the ciphertext of the product m 1 m 2 of the two original messages as C = (c 1 = c 1 c 1 , c 2 = c 2 c 2 ).

Paillier.

  The Paillier asymmetric encryption scheme [Pai99] works as follows: -KeyGen: randomly chooses two different prime numbers a and b such that a, b > 2, |a| = |b| and gcd(ab, (a -1)(b -1)) = 1. Then, it computes n = ab, λ = lcm(a -1, b -1), µ = λ -1 mod n and g P = n + 1. The private key is sk = (a, b) and the corresponding public key is pk = (n, g P ).

Figure 4 .

 4 Figure 4.1: Issuance of a partially blind signature

,

  info i ). Therefore, B gets L + 1 valid ( → m , σ) pairs on L + 1 distinct messages where → m = (m 1 , m 2 , . . . , m n + inf o); hence breaking the assumption 1.

1y+r.

  It can thus check the validity of the quadruple (A, r, s, → m) by verifying whether à ? = A.

4. 4 . 3 . 1

 431 Security of our MAC GGM -based Pre-DAA Scheme Theorem 4.6. Our MAC GGM -based pre-DAA scheme is traceable, in the ROM, under the assumption 1 introduced in [PS16] (see Section 3.23).

-

  OJoin U (i) requests: C computes C s i 1 and C s i 2

Chapter 5 A

 5 Practical Private eCash System Contents 5.1 Electronic Cash (eCash) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Private eCash System Framework: The eToll use case . . . . . . . . . 5.3.1 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Trust Assumptions and Performance Requirements . . . . . . . . . . . . . 5.3.3 System Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Security and Privacy Models . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Privacy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Our Private eCash System . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 Description of the Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Unforgeability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2 Non-frameability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.3 Unlinkability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Performance Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Testbed Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.2 Implementation Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . 5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

  cheat in order to pay less toll charges than what it has to. More formally, the unforgeability experiment Exp unforg A (1 k ) is defined in Figure 5.1. The advantage Adv unforg A (1 k ) of the adversary is defined as Pr[Exp unforg A

Figure 5 .

 5 Figure 5.1: Unforgeability Security Experiment

4 .Figure 5 . 2 :

 452 Figure 5.2: Non-Frameability Security Experiment

7 .

 7 If OCorrupt(IDu 0 ) or OCorrupt(IDu 1 ) then output ⊥.

8 .

 8 If OIDRetrieve(transcb) or OIDRetrieve(transc 1-b ) then output ⊥.

9.Figure 5 . 3 :

 53 Figure 5.3: Unlinkability Security Experiment

Chapter 5 :

 5 A Practical Private eCash System More formally, our unlinkability experiment Exp unlink-b A (1 k ) is detailed in Figure 5.3. The advantage Adv unlink-b A (1 k ) of the adversary is defined as Adv unlink-b A

Figure 5 . 4 :

 54 Figure 5.4: The Token Issuance Protocol

Figure 5 . 5 :

 55 Figure 5.5: The Access Control Protocol

Figure 5 . 6 :

 56 Figure 5.6: The Toll Computation Protocol

Game( 0

 0 ,b): It is the same game as Game 0 except that, when running the AccessControl protocol with u b , we replace the ElGamal ciphertext E b by an encryption of a random value and simulate the proof π b 3 . Such a proof can be easily simulated in the random oracle model through the use of classical techniques. Under the DDH assumption, the adversary cannot detect this change. In fact, one can easily construct a DDH distinguisher D with an advantage of solving the DDH problem, Adv DDH , satisfying |Pr[S 0 ]-Pr[S (0,b) ]| ≤ Adv DDH (1 k ). Game(0,1-b): It is the same game as Game (0,b) except that, when executing the AccessControl protocol with u 1-b , we replace the ElGamal ciphertext E 1-b by an encryption of a random value. Then, we simulate the proof π 1-b 3 . Such a proof can be easily simulated in the random oracle model through the use of standard techniques. Under the DDH assumption, the adversary cannot detect this change. In fact, one can easily construct a DDH distinguisher D with an advantage of solving the DDH problem, Adv DDH , satisfying |Pr[S (0,b) ] -Pr[S (0,1-b) ]| ≤ Adv DDH (1 k ).

3 . 3 . 3 .

 333 Game(k,b): It is the same as Game k = Game (k-1,1-b,1-b) except that, when executing the AccessControl protocol with u b , we replace the ElGamal ciphertext E k b by an encryption of a random value and simulate the proof π b k Game(k,1-b): It is the same game as Game (k,b) except that, when executing the AccessControl protocol with u 1-b , we replace the ElGamal ciphertext E k 1-b by an encryption of a random value and simulate the proof π (1-b) k Game(k,1-b,b): It is the same game as Game (k,1-b) except that, when executing the AccessControl protocol with u b , we replace the value of T b k i by a random value and simulate the proof π b k Game(k,1-b,1-b): It is the same game as Game (k,1-b,b) except that, when executing the AccessControl protocol with u 1-b , we replace T (1-b) k i by a random value and simulate the proof π (1-b) k 3

2 .

 2 Figure 7.1: Remote Profile Provisioning Procedure (Automotive use case)

  A's goal is to guess the value of b (i.e. determine if V O has, indeed, cast a ballot or not).The adversary's advantage Adv c-resist ES,A is defined asAdv c-resist ES,A = |Pr[Exp c-resist ES,A = 1] -Pr[Exp c-resist-ideal

7 .

 7 Exp c-resist ES,A, (1 k , n V , n A , n C ) 1. BB ← ∅; V ← A(voter names) 2. For i ∈ {1, . . . , n V }, (sk i , pk i ) ← register(sk R , i) 3. (β, j) ← A({sk i } i∈V ) 4. If |V | = n A or j / ∈ {1, 2, . . . , n V } \ V or β / ∈ {1, 2, . . . , n C } ∪ ∅, then return 0 5. b ∈ {0, 1}6. If b = 0, then sk ← fakekey(pk R , sk j , pk j ) and BB ← BB ∪ {B j } where B j = Voting{(sk j , pk T , n C , β)} else, sk ← sk j For i ∈ {1, . . . , n V } \ V and such that i = j, BB ← BB ∪ {B i } whereB i = Voting{(sk i , pk T , n C , Dn U ,n C )}8. BB ← BB ∪ { B} ∪ {B k } k∈V where B = A( sk, BB) and B k = Voting{(sk k , pk T , n C , Dn U ,n C )} 9. ( → X, P ) ← Tallying(sk T , BB, n C , {pk i } b = b, then return 1.

Figure 8 . 7 . sk ← sk j 8 .

 878 Figure 8.1: Coercion-Resistance Security Experiment

Figure 8 . 2 :

 82 Figure 8.2: Coercion-Resistance-Ideal Security Experiment

10.

  Tallying simulation: Using the key sk T , S perfectly simulates this phase. At the end of the game, A outputs a bit b . Let S 0 denote the event that b = b in this game and S i be the event that b = b in Game i. We have Pr[S 0 ] = Pr[Exp c-resist ES,A = 1] (8.2)

. 3 ) 2 :

 32 Pr[S 1 ] = Pr[S 0 ]. (8Game This is the same game as Game 1 except that for each ballot in E 1 , S runs the extractor for the associated proofs of knowledge to extract the secret s associated to the randomized credential (w, w ). If the extractor fails, then S outputs ⊥ and aborts. Let us denote by F this failure event. By the Difference Lemma [Sho04], we have |Pr[S 2 ] -Pr[S 1 ]| ≤ Pr[F ] (8.4)

|Pr[S 5 ]

 5 -Pr[S 4 ]| ≤ Adv DDH (1 k ) (8.10)The view produced by this last game gives no information, in a strong information theoretic sense, about the votes posted by honest voters. The only information that the adversary obtains is the final tally → X of votes cast by the honest voters as well as the number of ballots discarded due to invalid proofs. Furthermore, in both cases (i.e. when b = 0 or b = 1), A receives a valid credential. Thus, we havePr[S 5 ] = Pr[Exp c-resist-ideal ES,A = 1] (8.11)It results from the above thatAdv c-resist ES,A = |Pr[Exp c-resist ES,A = 1] -Pr[Exp c-resist-ideal ES,A= 1]| = |Pr[S 0 ] -Pr[S 5 ]| Thus, we can give the following upper bound for the adversary's advantage Adv c-resist ES,A ≤ j=4 j=0 |Pr[S j+1 ] -Pr[S j | ≤ v(k) + Adv MAC GGM U F -CM V A (1 k ) + 2 Adv DDH (1 k

Table 2

 2

		.1: M2M Applications Characteristics and Requirements
	Application	Type of communication	Delay constraint	Limited energy	Privacy
	eHealth
	eCall
	Smart Home	Many-to-One
	Monitoring
	Smart Grid
	PAYD
	eToll	One-to-One
	bCall
	Fleet management	One-to-One (for UL)
	Smart metering	One-to-Many (for DL)
	EVC	Many-to-One
	Smart City	Many-to-Many

  Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Mathematical Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Basic Functions and Complexity Definitions . . . . . . . . . . . . . . . . . 3.1.3 Computational Hardness Assumptions . . . . . . . . . . . . . . . . . . . . 3.2 Provable Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.1 Reductionist Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Game-based and Simulation-based Security . . . . . . . . . . . . . . . . . Proofs of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

	Chapter 3
	Mathematical Tools and
	Cryptographic Building Blocks
	Contents
	3.1 3.2.3 Security Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	3.3 Cryptographic primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	3.3.1 Message Authentication Code . . . . . . . . . . . . . . . . . . . . . . . . .
	3.3.2 Digital Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	3.3.3 Public Key Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	3.3.4 Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	3.3.5

  y is unique and is called the inverse of x, denoted by x -1 .

	Definition 3.2 (Subgroup). Let (G, •) be a group and H a subset of G. (H, •) is a subgroup of
	(G, •) if the following three requirements are satisfied.

  4.1 A Perfectly Unlinkable Partially Blind Signature Scheme . . . . . . . 57 4.1.1 Scheme Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.1.2 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.2 An Improved Algebraic MAC Scheme . . . . . . . . . . . . . . . . . . . 60 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.2.1 Scheme Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.2.2 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3 A New Sequential Aggregate MAC Scheme . . . . . . . . . . . . . . . 64 4.3.1 Scheme Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.2 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.4 Practical Pre-Direct Anonymous Attestation Schemes . . . . . . . . . 66 4.4.1 Schemes Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4.2 Efficiency Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.4.3 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.5

  .2. An Improved Algebraic MAC Scheme = (m 1 , . . . , m n ) and picks r, s ∈ R Z p so as to compute A = (g m 1 1 g m 2 2 . . . g mn n g s h) , r, s, y) checks the validity of the MAC with respect to the block of messages

	MAC(
	1
	y+r . The MAC on
	Verify(	→ m.
	The MAC is valid only if (g m 1 1 g m 2 2

→ m, y) takes as input a block of n messages → m → m consists of the triple (A, r, s). → m, A

Table 4 .

 4

1: DAA schemes efficiency comparison

  Anonymous Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Keyed-Verification Anonymous Credentials Systems . . . . . . . . . . 6.3.1 Overview on KVAC systems . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Security Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 A Keyed-Verification Anonymous Credentials System based on MAC n BB 6.4.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 Blind Issuance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.4 Credential Presentation (i.e. Show) . . . . . . . . . . . . . . . . . . . . . . 6.5 From Keyed-Verification to Public Key Anonymous Credentials . . . 6.6 Efficiency Comparison and Performance Assessment . . . . . . . . . . 6.6.1 Presentation proof computational cost . . . . . . . . . . . . . . . . . . . . 6.6.2 Complexity in the number of group elements . . . . . . . . . . . . . . . . 6.6.3 Implementation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7.1 Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7.2 Unforgeability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7.3 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7.4 Blind Issuance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7.5 Key-parameter consistency . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	Chapter 6
	A Practical Keyed-Verification
	Anonymous Credentials System
	Contents
	6.1

  Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7.6 Performance Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7.6.1 Testbed Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.6.2 Implementation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Contents 7.1 Embedded SIM (eSIM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 7.2 System Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.3.1 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.3.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.4 Our anonymous authentication and identification protocol for eSIM . 118 7.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 7.4.2 Protocols description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 7.5

Table 7 .

 7 1: Timings ((min-max) average) in milliseconds (ms) of the implementation of the Discovery Request protocol

		Off-line part (card)
	Battery-On	Battery-Off
	(741-767) 754 ms	(2294-2362) 2331 ms
		On-line part
	Signature generation (card)	Signature verification (PC)
	Battery-On (180-191) 186 ms	Battery-Off (434-464) 446 ms	(4-13) 6 ms
		Total On-line part
	Battery-On	Battery-Off
	(184-204) 192 ms	(438-477) 452 ms

  Remote Electronic Voting . . . . . . . . . . . . . . . . . . . . . . . . . . 123 8.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 8.3 Remote Electronic Voting System Framework . . . . . . . . . . . . . . 125 Security and Privacy Requirements . . . . . . . . . . . . . . . . . . . . 126 8.4.1 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.2 Privacy Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Our Coercion Resistant Electronic Voting Scheme . . . . . . . . . . . 129 8.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.2 Our Efficient Coercion-resistant Voting Scheme . . . . . . . . . . . . . . . 8.5.3 Multiple Elections and Credentials Revocation. . . . . . . . . . . . . . . . 8.6 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 8.6.1 Verifiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.2 Eligibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.3 Coercion-Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

	Chapter 8
	An Efficient Coercion-Resistant
	Remote Electronic Voting Scheme
	Contents
	8.1

8.3.1 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 System Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4

  8.4. Security and Privacy Requirements8.4.1.2 EligibilityRoughly speaking, eligibility ensures that the following two statements are met: (1) only eligible voters can cast a vote, and (2) every voter can cast one, and only one, vote. Thereby, ballot stuffing is avoided. It is noteworthy to mention that everyone should be able to check these two statements.

	8.4.2 Privacy Requirements
	8.4.2.1 Coercion-Resistance

Un système de vote électronique résistant à la coercition. Finalement, dans le chapitre 8, nous proposons un système de vote électronique pratique et permettant de rendre inutile toute tentative de coercition à l'encontre d'un votant. Ce système repose sur l'utilisation d'accréditations anonymes afin de permettre à un électeur, dûment inscrit sur les registres électoraux, de voter de manière anonyme. Grâce à l'utilisation de notre schéma de MAC séquentiellement aggrégés détaillé dans le chapitre 4, les accréditations des électeurs peuvent être efficacement mises à jour afin de leur permettre de prendre part, ultérieurement, à d'autres élections. En outre, les accréditations de certains électeurs (par exemple ceux ne pouvant pas prendre part à l'élection car déchus de leur droit de vote) peuvent être révoquées. Ces travaux ont fait l'objet de l'article "Remote Electronic Voting can be Efficient, Verifiable and Coercion-Resistant" [ABBT16] à VOT-ING'16.

Recall that sUF-CMVA refers to strong UF-CMVA where the adversary wins even if he outputs a new valid pair (m, τ ) on a message m that has already been queried to the OMAC oracle.

Hereinafter, we will consider the MAC GGM scheme in the case of a single message.

Even though this request has not been initiated by A, m = 0 is considered as one of the messages that A has queried to OMACGGM. Otherwise, A would trivially win.

That is, no restrictions are made on A's access to the TollCompute protocol.

For concurrent security, we could use the Dåmgard protocol[START_REF] Damgård | Efficient concurrent zero-knowledge in the auxiliary string model[END_REF] which converts any Σ protocol into a three-round interactive ZKPK secure under concurrent composition.

Such a simulated proof can be easily done in the ROM, using standard techniques.

This is a realistic assumption since eSIM subscription changes are not as frequent.

He selects the voters to corrupt before the execution of the protocol.

A PET aims to check if two ciphertexts correspond to a same plaintext or not, without revealing it.

Acknowledgments

Chapter 1 : Introduction Chapter 4 : Design of Efficient Cryptographic Primitives with probability ε n , where ε is the probability that A breaks the unforgeability of MAC n BB . If B can break the discrete logarithm DL problem then, it can break the MAC BB scheme (by finding the discrete logarithm of Y in the base g 0 ).

We can guess which of the two forgers a particular adversary A is with probability 1/2. So, assuming the most pessimistic scenario (case 2), B can break the unforgeability of MAC BB with probability ε/2n.

A New Sequential Aggregate MAC Scheme

As mentioned in Section 3.3.2.4, a sequential aggregate signature scheme is a particular type of aggregate signature schemes where the final signature is created sequentially with each signer signing the aggregate signature in turn. The secret key analogue of these signature schemes is referred to as sequential aggregate Message Authentication Code (MAC) schemes [START_REF] Katz | Aggregate message authentication codes[END_REF].

Hereinafter, based on the MAC GGM scheme due to Chase et al. [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF], we design an efficient sequential aggregate MAC scheme which supports n users with n different messages.

Scheme Description

Our sequential aggregate MAC scheme is defined through the following four algorithms: Setup, KeyGen, AggMAC and Verify. For the sake of clarity, we detail it in the case of two users denoted by U 1 and U 2 .

Setup(1 k ) creates the system public parameters denoted by pp = (G, q, g, h, Y 0 ) where G is a cyclic group of prime order q, a k-bit prime, g and h are two random generators of G such that log g h is unknown, and Y 0 = g x 0 .

KeyGen(pp) generates the secret key sk 1 = x 1 ∈ R Z * q of the first user U 1 , and sk 2 = x 2 ∈ R Z * q of the second user U 2 . The corresponding public parameters, denoted params, are respectively X 1 = h x 1 and X 2 = h x 2 .

AggMAC(pp, U 1 (sk 1 , m 1 ), U 2 (sk 2 , m 2 )) produces an aggregate MAC on both messages m 1 and m 2 sequentially by users U 1 and U 2 . First, U 1 randomly selects t 1 ∈ Z * q and generates the MAC σ 1 = (u, u ) on the message m 1 where u = g t 1 and u = (g m 1 x 1 Y 0 ) t 1 = u x 0 +m 1 x 1 . Then, he provides U 2 with σ 1 as well as a ZKPK π 1 that u was correctly computed. π 1 is defined as The condition 7 should also be true. Thus, ∃b ∈ {0, 1} such that Link(gmpk, σ 0 , m 0 , σ 1 , m 1 , bsn b ) = 1. Without loss of generality, let us assume that b = 0. From the validity of this assertion, we can deduce that T 0 = H(bsn 0 ) s 0 1 = T 1 = H(bsn 0 ) s 1 1 (4.2) This implies that s 0 1 = s 1 1 (mod p) (4.3)

For A's forgery to be successful, either condition 8 or 9 should be true. Suppose that assertion 8 is true. This implies that T 0 = H(bsn 0 ) s1 (4.4)

and

This is impossible. Indeed, (4.2) and (4.4) imply that s 0 1 = s1 . Thus, from (4.3), we have s 0 1 = s1 = s 1 1 . From (4.1), we also know that T 1 = H(bsn 1 ) s 1 1 = H(bsn) s1 , which contradicts (4.5).

Let us now assume that condition 9 is true, i.e. that bsn 0 = bsn 1 . (4.1) and (4.2) imply that T 1 = H(bsn 1 ) s 1 1 = H(bsn 0 ) s 1 1 , hence H(bsn 0 ) = H(bsn 1 ) where bsn 0 = bsn 1 . This would imply that A broke the second pre-image resistance property of the hash function H which is unfeasible in the ROM.

Therefore, a Type-2 forgery can never occur.

Consequently, under the OMDL assumption, our MAC GGM -based pre-DAA scheme ensures the non-frameability requirement. Theorem 4.8. Our MAC GGM -based pre-DAA scheme satisfies the anonymity requirement, in the ROM, under the XDH assumption.

Proof (sketch). Let A be an adversary against the anonymity requirement of our MAC GGM -based Pre-DAA scheme. Using Shoup's game hopping technique, where proofs are organized as sequences of games, we prove that our Pre-DAA scheme ensures the anonymity requirement under the XDH assumption. Hereinafter, we provide a high level description of the initial game (Game 0) along with a brief description of the transition between Game 0 and Game 1.

Game 0: It corresponds to the real attack game with respect to an efficient adversary A.

The Challenger C randomly chooses the system public parameters pp = (G 1 , G 2 , G T , p, H, e) as well as the issuer's private key gmsk = (x 0 , x 1 , x 2 ) and computes the associated public key gmpk = (C x 0 = g x 0 h x0 , X 1 = h x 1 , X 2 = h x 2 , X0 = hx 0 , X1 = hx 1 , X2 = hx 2 ) where h ∈ R G 1 and x0 ∈ R Z q . Then, it provides A with gmsk = (x 0 , x 1 , x 2 ) and answers his requests as follows:

-OAdd(i) requests: C creates a new user i and picks a random value s i 1 ∈ R Z * p as his secret key sk i . C also generates user's i public/private endorsement key pair denoted by (esk i , epk i ).

-OAddCorrupt(i) requests: C does nothing.

-OJoin U (i) requests: C computes C s i 1 , C s i 2 and C i , then builds π 1 to obtain the group signing key gsk i .

-OCorrupt(i) requests: C provides A with the secret key sk i and the group signing key gsk i of user i.

Chapter 4 : Design of Efficient Cryptographic Primitives

If c mode = 2: A eventually outputs two valid signatures σ 0 and σ 1 , on respectively m 0 and m 1 , that are linkable even though they should not. That is, they were either generated using two different keys (sk 0 and sk 1 ) or/and are for different basenames (bsn 0 and bsn 1 ).

Let sk b = (s b 1 , s b 2 ) denote the key used to generate σ b and sk = (s 1 , s2 ) the key output by A. If A's attack against the non-frameability property is successful, then this implies that condition 6 of the non-frameability experiment is true. In particular, owing to the completeness of π 3 , we have

The condition 7 should also be true. Thus, ∃b ∈ {0, 1} such that Link(gmpk, σ 0 , m 0 , σ 1 , m 1 , bsn b ) = 1. Without loss of generality, let us assume that b = 0. From the validity of this assertion, we can deduce that

This implies that

For A's forgery to be successful, either condition 8 or 9 should be true. Suppose that assertion 8 is true. This implies that T 0 = H(bsn 0 ) s1 (4.9)

and

This is impossible. Indeed, (4.7) and (4.9) imply that s 0 1 = s1 . Thus, from (4.8), we have s 0 1 = s1 = s 1 1 . From (4.6), we also know that T 1 = H(bsn 1 ) s 1 1 = H(bsn) s1 , which contradicts (4.10).

Let us now assume that condition 9 is true, i.e. that bsn 0 = bsn 1 . (4.6) and (4.7) imply that T 1 = H(bsn 1 ) s 1 1 = H(bsn 0 ) s 1 1 , hence H(bsn 0 ) = H(bsn 1 ) where bsn 0 = bsn 1 . This would imply that A broke the second pre-image resistance property of the hash function H which is unfeasible in the ROM.

Therefore, a Type-2 forgery can never occur. Thus, under the OMDL assumption, our BBbased pre-DAA scheme ensures the non-frameability requirement.

Theorem 4.11. Our BB-based pre-DAA scheme satisfies the anonymity requirement, in the ROM, under the XDH assumption.

Proof (sketch). Let A be an adversary against the anonymity requirement of our BB-based Pre-DAA scheme. Using Shoup's game hopping technique, where proofs are organized as sequences of games, we prove that our Pre-DAA scheme ensures the anonymity requirement under the XDH assumption. Hereinafter, we provide a high level description of the initial game (Game 0) along with a brief description of the transition between Game 0 and Game 1.

Game 0: It corresponds to the real attack game with respect to an efficient adversary A.

The Challenger C randomly chooses the system public parameters pp = (G 1 , G 2 , G T , p, H, e) as well as the issuer's private key y and computes the associated public keys Y = g y 0 and W = gy 0 . Then, it provides A with gmsk = y and answers his requests as follows:

-OAdd(i) requests: C creates a new user i and picks two random values s i 1 , s i 2 ∈ R Z * p as his secret key sk i . C also generates user's i public/private endorsement key pair denoted by (esk i , epk i ).

-OAddCorrupt(i) requests: C does nothing.

Chapter 5 : A Practical Private eCash System while π 4 is rather checked during the idle time of the SIM card. Concurrently, (E, T i := g su i ) is saved in the database of transactions DB AC . Note that, to provide full unlinkability, one may add randomness in T i using a pseudo-random function as in [ALT + 15].

User U

Toll Company T C Public Input: pp, X 1 and X 2 Public Input: pp Private Input: (u, u ), su, m and F Private Input: access control (e.g. for national security reasons). To do so, T C sends to RAs the ElGamal encryption E of g su . At least t of them should collaborate to recover g su . Using the information stored in DB REG , T C identifies the corresponding user. In the latter, the aim is to revoke a token following, for example, the loss or theft of the user's badge. To this end, RAs are provided with the Paillier encryption D of the secret s that they jointly decrypt. Thereby, T C can compute s u = s + s and thus blacklists all the values {T i := g su i } Nmax i=1 .

Security Analysis

In this section, we formally prove that our private eCash system satisfies the required security and privacy properties defined in section 5.4. To do so, we will extensively use the following Forking Lemma which applies to signature schemes derived from three-move identification schemes through the use of the Fiat-Shamir technique [START_REF] Fiat | How to prove yourself: Practical solutions to identification and signature problems[END_REF] in the ROM.

Forking Lemma. The Forking lemma, which was introduced by PointCheval and Stern [START_REF] Pointcheval | Security arguments for digital signatures and blind signatures[END_REF], states that if an adversary A can produce, with non negligible probability, a valid signature (m, σ 1 , h, σ 2 ), then A is able to output, with non negligible probability, two valid signatures (m, σ 1 , h, σ 2 ) and (m, σ 1 , h , σ 2 ) such that h = h . In our proofs, we use the Forking Lemma to prove that an adversary A is unable to produce a valid access control transcript Transc ACi or a valid Schnorr signature S 1 unless he knows all the underlying secrets, namely (s u , m, w, w ) and sk u respectively.

Unforgeability

Theorem 5.1 (Unforgeability). Our eCash system is unforgeable, in the random oracle model, under the assumption that MAC GGM is UF-CMVA.

Proof (sketch). Let A be an adversary that breaks the unforgeability requirement of our eCash system with non negligible probability. Using A as a subroutine, we will construct a reduction B against the UF-CMVA security of the MAC GGM scheme. B receives on input from its challenger, denoted C, the public parameters of the UF-CMVA challenge pp = (G, g, h, C x 0 , X 1 , X 2 ) and has access to the OMAC and OVerify oracles. As for the remaining generators, they can be randomly selected. C chooses the private key

Performance Assessment

Thus, we can conclude that under the DDH, q -DDHI and DCR assumptions, the advantage of a Type-(N max -1, N max -1) adversary is negligible. Consequently, so is the advantage of any Type-(i, j) adversary where i ≤ N max -1 and j ≤ N max -1. Thereby, our private eCash system satisfies the unlinkability' requirement, in the random oracle model, under the DDH, q -DDHI and DCR assumptions.

Performance Assessment

To show that our private eCash system is not only secure and privacy-friendly but also efficient, we implemented the user's side of the Access Control, which is the most time critical phase, on an NFC-enabled SIM Card. In what follows, we provide more details about our testbed environment and the obtained timing results.

Testbed Environment

The user's side of the Access Control protocol was implemented on a Javacard 2.2.2 SIM card, GlobalPlatform 2.2 compliant, which is embedded in a Samsung galaxy S3 NFC smartphone. The only particularity of the used SIM card, compared to the Javacard specifications, is some additional API provided by the card manufacturer enabling modular and elliptic curve operations. Even though the used SIM card is more powerful than most SIM cards, as it requires a cryptoprocessor to be able to handle asymmetric cryptography, it is worth emphasizing that such powerful SIM cards with cryptoprocessors are already widely deployed by some mobile phone carriers, such as Orange in France, to provide NFC-based services.

The toll company (T C) side of the Access Control protocol was run on a PC (Quad-Core Intel Xeon CPU @3.70GHz). Since our private eCash system is not only intended for eToll but also for EVC and public transport, communications between the SIM card in the smartphone and the PC (acting as T C) was done in NFC using a standard PC/SC reader (an Omnikey 5321).

The implementation uses a 256-bit Barreto-Naehrig elliptic curve [START_REF] Paulo | Pairing-friendly elliptic curves of prime order[END_REF] which is of embedded degree k = 12, and hence is not prone to the MOV attack [START_REF] Menezes | Reducing elliptic curve logarithms to logarithms in a finite field[END_REF]. To have the fastest possible verification on card, T C uses a 2048 bits RSA signature with a short public verification exponent. Table 5.1 above gives timing results of the implementation of the Access Control protocol. "Battery-Off" denotes a powered-off mobile phone either by the user or because its battery is flat. In such a case, as stated by NFC standards, NFC-access to the SIM card is still possible, but with slightly degraded performances. During Access Control, the off-line computations (steps 1 and 5) are launched from the smartphone (battery-on) whereas on-line computations concern steps 2, 3 and 4. The latter can potentially be done with a battery-off smartphone. On average, Chapter 5 : A Practical Private eCash System the on-line part of the Access Control protocol is very fast, even with a powered-off phone. In fact, data exchange is the most time-consuming task.

Implementation Benchmarks

Conclusion

In this chapter, using our partially blind signature scheme introduced in Section 4.1 as the main building block, we designed a private eCash system that only requires users to hold a unique reusable token while preserving their privacy. Through its refund process, our proposal supports flexible prices as well as post-payments. Furthermore, we have formally proven that it meets the required security properties. Finally, we showed its efficiency even when implemented on constrained environments such as SIM cards. More precisely, a transaction can be performed in 205 ms when the smartphone is switched on, and 315 ms otherwise.

In the next chapter, we rely on our algebraic MAC n BB scheme introduced in Section 4.2 so as to build an efficient Keyed-Verification Anonymous Credentials (KVAC) systems that can be easily turned into a traditional public-key anonymous credential system.

for Φ and U, if for all (m 1 , . . . , m n ) ∈ U, for all sufficiently large k,

Unforgeability

A credential presentation protocol (i.e. Show) for KVAC defined through (CredKeyGen, Issue) satisfies unforgeability if for all Probabilistic Polynomial Time (PPT) adversaries A, there exists a negligible function ν such that, for all k:

where Q is the list of all attribute sets (m 1 , . . . , m n ) queried to the OIssue(sk, •) oracle, and all executions of OShowVerify are sequential.

Anonymity

A credential presentation protocol (i.e. Show) for KVAC defined through (CredKeyGen, Issue) satisfies anonymity if for all PPT adversaries A, there exists an efficient algorithm SimShow, and a negligible function ν such that for all k, for all φ ∈ Φ and (m 1 , . . . , m n ) ∈ U such that φ(m 1 , . . . , m n ) = 1, and for all pp R ← -Setup(1 k ) and all (pk, sk) R ← -CredKeyGen(pp), for all σ such that CredVerify(sk, (m 1 , . . . , m n ), σ) = 1 :

i.e., A's view can be simulated by SimShow given only φ and a valid secret key corresponding to pk.

It is noteworthy that the anonymity property defined above ensures user's anonymity, unless information revealed in φ enable to identify him.

Blind Issuance

We consider a setting where the user wishes to obtain credentials for attributes (m 1 , . . . , m n ) from an issuer that only knows some subset S of those attributes. Then, we consider a function f defined as f ((S, pp, pk), (sk, r), (m 1 , . . . , m n )) on shared input (S, pp, pk), issuer input (sk, r) and user input (m 1 , . . . , m n ). f returns:

-⊥ to the issuer and "pp error" to the user if (sk, pk) does not belong to the range of CredKeyGen(pp);

-⊥ to the issuer and "attributes error" to the user if S does not agree with (m 1 , . . . , m n ); -σ R ← -Issue(sk, (m 1 , . . . , m n ); r) if neither of these errors occurs where Issue(sk, (m 1 , . . . , m n ); r) indicates the execution of Issue(sk, (m 1 , . . . , m n )) with randomness r.

An issuance protocol BlindIssue ensures blind issuance for Issue if it is a secure two-party computation [START_REF] Goldreich | Foundations of Cryptography: Volume 2, Basic Applications[END_REF] (against malicious adversaries) for the above function.

Key-parameter consistency

The key generation algorithm CredKeyGen satisfies key-parameter consistency if for any PPT adversary A, the probability that A, given pp R ← -Setup(1 k ) can produce (pk, sk 1 , sk 2 ) such that (pk, sk 1 ) and (pk, sk 2 ) are both in the range of CredKeyGen(pp), is negligible (where the probability is over the choice of pp and the random coins of A).

Note that, correctness, blind issuance and key-parameter consistency ensure that if the user receives a credential through BlindIssue, then the resulting credential will be accepted by CredVerify for the one secret key, corresponding to pk, that the issuer knows. Then, anonymity guarantees that Show will not allow the issuer to learn any information beyond φ.

Secure keyed-verification credential system

We say that (CredKeyGen, CredVerify, Issue, BlindIssue, Show, ShowVerify) is a secure keyedverification credential system if these algorithms satisfy the correctness, unforgeability, anonymity, blind issuance and key-parameter consistency properties defined above.

A Keyed-Verification Anonymous Credentials System based on MAC n

BB

Based on the designed MAC n BB scheme, we construct a KVAC system involving a user U, an issuer I and a verifier V. Our KVAC system consists of the following four phases. The two main phases (BlindIssue and Show) are depicted in Figure 6.1.

Setup

Generate the public parameters pp = (G, p, g 1 , g 2 , . . . , g n , g, h, g 0 , f ) where G is a cyclic group of prime order p, a k-bit prime, and (h, g, g 0 , {g i } n i=1 , f ) are random generators of G where DDH is hard. For i ∈ {1, . . . , n}, g i is associated with a specific type of attributes (e.g. age, gender, etc.). This allows us to differentiate attributes and avoid any ambiguity. Note that, in the sequel, all computations on exponents are computed modulo p (i.e. mod p).

Key Generation

Choose a random value y ∈ R Z p as the issuer's private key and compute the corresponding public key Y = g y 0 . Each user U is also provided with a private key sk u and the associated public key pk u which may be used to authenticate the user during the issuance of his credentials.

Blind Issuance

To issue a credential on the attributes (m 1 , . . . , m n ), the issuer and the user (who has already been authenticated) engage in the following protocol. First, the user U builds a commitment C m = g m 1 1 . . . g mn n g s on his attributes, where s ∈ R Z * p . Then, he sends it to the issuer I along with a ZKPK π 1 defined as

He may also build a ZKPK π 2 ensuring that the credential is well-formed. Such a proof is defined as

Then, he provides U with the triple (A, r, s ) along with the proof π 2 . Upon receiving them, U first verifies the validity of π 2 , then computes Cm = C m g s h as well as s u = s + s , which is a secret value only known to U. Finally, he sets his anonymous credential σ as σ = (A, r, s u , Cm ).

A Keyed-Verification Anonymous Credentials System based on MAC n

BB

Note that in case where U does not mind revealing his attributes (or a subset of them), he just sends them without using any commitment (respectively, only commits to the attributes that he does not want to reveal). To anonymously prove that he holds a credential on the attributes (m 1 , . . . , m n ), the user engages in an interactive protocol with the verifier V. First, he randomly selects l, t ∈ R Z * p and computes B 0 = A l , a randomized version of his credential. He also computes C = Cl m B -r 0 as well as

. . . g lmn n g lsu h l . Hence, C is simply equal to A ly = B y 0 . U also builds a ZKPK π 3 to prove that he really holds a valid credential (i.e. he knows the associated attributes/secrets and the value committed in E is different from zero). π 3 is defined as

Once the required values have been computed, U provides V with B 0 , C and E along with π 3 1 .

Upon their receipt, V first computes C = B y 0 , then verifies that C = C . If so, he checks that π 3 is valid. V is convinced that U really holds a valid credential on attributes (m 1 , . . . , m n ) if, and only if, both checks succeed.

Before detailing how our KVAC system can be easily turned into a traditional anonymous credential system, we prove in what follows that, when C = B y 0 , π 3 is a ZKPK of a MAC n BB (A, r, s u ) on a block of messages (m 1 , . . . , m n ).

1 π3 is detailed in section 6.4.4.1

From Keyed-Verification to Public Key Anonymous Credentials

Let us now prove that α = 0. We know that

• If the prover does not know the discrete logarithm of C in the base f , this implies that it only knows one representation (0, 0) of 1 in the base (C, f ) [START_REF] Brands | An efficient off-line electronic cash system based on the representation problem[END_REF]. Therefore, αθ = 1 which implies that α = 0.

• Suppose now that the prover knows the discrete logarithm χ of C in the base f (i.e. C = f χ ) and that α = 0. Since C = B y 0 , we have B y 0 = f χ and then B 0 = f χ y (since Y = g y 0 = 1, this implies that y = 0 mod p). From (8.8) and since α is supposed to be equal to 0, we have that

y . So, the issuer could use the prover as a subroutine to compute a representation of h in the base (g 1 , g 2 , . . . , g, f ). As (g 1 , g 2 , . . . , g, f ) are random generators of G, this is impossible under the DL assumption [START_REF] Brands | An efficient off-line electronic cash system based on the representation problem[END_REF]. Therefore, this means that either P * does not know the discrete logarithm of C in the base f or α = 0. Both cases imply that α = 0. We therefore conclude that α = 0 and so the prover knows a valid MAC n BB (A, r, s u ) on a block of messages (m 1 , . . . , m n ).

Finally, to prove (honest-verifier) zero-knowledge, we construct a simulator Sim that will simulate all interactions with any (honest verifier) V * .

1. Sim randomly chooses l ∈ R Z * p and a random generator E ∈ R G and then computes

Since G is a prime-order group, then the blinding is perfect in the first step. Indeed, there exists x ∈ Z p such that for a valid MAC n BB (A, r, s u ) on (m 1 , . . . , m n ): A = g x 0 . For a random value l ∈ Z * p , we therefore have B 0 = A l = g lx 0 = g l 0 for l = lx. This also implies that C = A ly = Y l . Moreover, there exists t such that E = C 1 l f t . Therefore S and V * 's view of the protocol are statistically indistinguishable.

From Keyed-Verification to Public Key Anonymous Credentials

In this section, we explain how to turn our KVAC system into a public key anonymous credentials system. Thereby, a user would be able to prove possession of a credential to any entity (i.e. even one that does not know the issuer's private key). For that, our system should be defined in bilinear groups (see Section 3.1.1.4).

In such a case, the system public parameters are defined as pp = (G 1 , G 2 , G T , p, e, g 1 , . . . , g n , g, h, g 0 , f, g0 ) where G 1 , G 2 and G T are three cyclic groups of prime order p, e is a bilinear map e : G 1 × G 2 → G T , (h, g, g 0 , {g i } n i=1 , f ) are random generators of G 1 and g0 is a random generator of G 2 . The other phases are updated as follows.

Key Generation. The issuer publishes a second public key W = gy 0 associated with his private key y.

Blind Issuance. This phase does not require any change.

Chapter 6 : A Practical Keyed-Verification Anonymous Credentials System Credential Presentation. As the verifier V does not hold the private key y, some changes are required on his side. More precisely, he must compute two pairings e(C, g0 ) and e(B 0 , W ).

V is convinced that the user really holds a valid credential on (m 1 , . . . , m n ) only if e(C, g0 ) = e(B 0 , W ) and π 3 is valid.

Efficiency Comparison and Performance Assessment

We first compare the efficiency of our KVAC system to that of the main existing anonymous credentials schemes (i.e. U-Prove, Idemix, Bilinear CL, MAC GGM and MAC DDH ) both in terms of credential size and computational cost related to the creation of a presentation proof since it is the most time-critical phase. Next, we focus on the complexity, in the number of group elements, of KVAC systems presentation proofs. Finally, we provide timing results of the implementation of our Credential presentation protocol on a standard NFC SIM card.

Presentation proof computational cost

We compare in Table 6.1 the estimated cost of creating a presentation proof in terms of total number of multi-exponentiations. We use the same notation as [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF] where l-exp denotes the computation of the product of l powers and l -exp(b 1 , . . . , b l ) corresponds to the computation of the product of l powers with exponents of b 1 , . . . , b l bits (for Idemix). The number of multiexponentiations depends on three parameters: n, r and c which respectively denote the number of attributes in a credential, the number of revealed attributes and the number of attributes kept secret. Table 6.1 shows that our KVAC system is competitive with U-Prove (which does not provide multi-show unlinkability) and MAC GGM (which requires the verifier to know the issuer's private key and thus does not allow public verifiability). When most of the attributes are not disclosed, our proposal outperforms MAC GGM . It is worth mentioning that all schemes use a 256-bit elliptic curve group, except Idemix which uses a 2048-bit modulus.

Complexity in the number of group elements

As it only requires a multi-commitment to all undisclosed attributes, our presentation proof is of complexity O(1) in the number of group elements. This makes our KVAC system more efficient than Chase et al. systems (i.e. MAC GGM and MAC DDH [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF]) whose presentation proof is of complexity O(c). Indeed, both of their proposals presentation proof needs c commitments (one for each unreavealed attribute).

6.6. Efficiency Comparison and Performance Assessment

Implementation results

To show the efficiency of our anonymous credentials system, we implemented the user's side of the Credential presentation phase (i.e. Show protocol), which is the most time critical phase, on an NFC-enabled SIM Card. In what follows, we provide more details about our testbed environment and the obtained timing results.

Testbed Environment

Similarly to our eCash system, the user's side of the Show protocol was implemented on a Javacard 2.2.2 SIM card, GlobalPlatform 2.2 compliant, which is embedded in a Samsung galaxy S3 NFC smartphone. As mentioned in Chapter 5, the only particularity of our card (compared to the javacard specifications) is some additional API provided by the card manufacturer enabling operations in modular and elliptic curve arithmetic. To be able to handle asymmetric cryptography on elliptic curves, the used card is equipped with a cryptoprocessor. This makes it more powerful than most cards. It is, however, worth to emphasize that such SIM cards are already widely deployed by some phone carriers to provide NFC based services.

As for the verifier side of the Show protocol, it was run on a PC (Quad-Core Intel Xeon CPU @3.70GHz) and communication between the SIM card, in the smartphone, and the PC (acting as the verifier V) was done in NFC using a standard PC/SC reader (an Omnikey 5321).

Implementation Benchmarks

Table 6.2 gives timing results of the implementation of our Show protocol when a 256-bit prime "pairing friendly" Barreto-Naehrig elliptic curve is used.

In our implementation, the Show protocol is split into two parts: an off-line part that can be run in advance by the card (during which all the values necessary for an execution of the Show protocol in the worst case scenario, i.e. no revealed attributes, are computed) and an on-line part that needs to be performed on-line as it depends on the verifier's challenge. Indeed, in our implementation, the proof π 3 is made non-interactive: the verifier sends to the prover a challenge Ch which is included in the computation of the hash value c. Timings are given for n = 3, r = 2 and c = 1. The presentation proof by the card actually refers to the total time, from the applet selection to the proof reception, including the sending of the challenge by the verifier, but excluding the proof verification. "Battery-Off" denotes a powered-off phone either by the user, or because its battery is flat. In such a situation, as stated by NFC standards, NFC-access to the SIM card is still possible, but with degraded performances. Off-line computations are assumed to be automatically launched by the smartphone (battery-On) after a presentation proof, in anticipation for the next one. It is noteworthy that all computations are entirely done by the card: the smartphone is only used to trigger the Show protocol and to power the card. On-line computations refer to computations of R i values and the hash c involved in the proof π 3 (see Section 6.4.4.1), and Chapter 6 : A Practical Keyed-Verification Anonymous Credentials System can be potentially carried out even by a battery-Off phone. On average, the On-line part of the presentation proof is very fast even when the phone is powered-off. Actually, data exchange is the most time-consuming task.

Security Analysis

Theorem 6.1. Our KVAC system is unforgeable under the assumption that MAC n BB is sUF-CMVA, perfectly anonymous and ensures blind issuance as well as key-parameter consistency in the Random Oracle Model.

Correctness

As previously explained, we need to show two properties. The first follows directly from the correctness of our MAC n BB . For the second, we prove it in what follows. The Issue(sk, (m 1 , . . . , m n )) algorithm generates credentials of the form (A, r, s u , Cm ) such that A y+r = g m 1 1 g m 2 2 . . . g mn n g su • h. Then, if Show is executed honestly on both sides, the proof π 3 is accepted owing to the completeness of the proof system. Also, during the Show protocol, the following values are computed: B 0 = A l where l ∈ R Z p and,

Thus, the verifier's check on C (i.e. C ? = B y 0 ) will succeed and it will accept.

Unforgeability

Here, we prove unforgeability when A is given credentials generated by the BlindIssue protocol.

We have shown (see Theorem 4.4) that MAC n BB is unforgeable under the gap q -SDH assumption. Suppose there exists an adversary A who can break the unforgeability property of our anonymous credentials system. We will show that A can be used to construct an algorithm B that breaks the unforgeability of MAC n BB . B receives pp = (G, p, g 1 , . . . , g n , g, h, g 0 ) from its MAC n BB challenger along with Y , the issuer's public key. It sends pp and Y to A and answers his requests as follows:

-When A queries the OBlindIssue oracle: A sends C m and gives a proof π 1 . If π 1 is invalid, B returns ⊥. Otherwise, B runs the proof of knowledge extractor to extract {m i } n i=1 and s. B then queries its MAC n BB oracle on {m i } n i=1 which returns a tag (A, r, s u ) to B. Finally, B simulates the corresponding proof 3 π 2 and forwards the tag (A, r, s u -s) along with π 2 to A.

-When A queries the OShowVerify oracle: A sends B 0 , C, E along with a proof π 3 . If the proof π 3 is invalid, B returns ⊥. Otherwise, B runs the proof of knowledge extractor to extract α, β, λ, δ 1 , δ 2 , . . . , δ n+1 , γ and θ. If α = 0, B returns 0 to A. Otherwise, B computes A = B α 0 , r = -λ α and s = δ n+1 . Finally, it queries its Verify oracle with ((δ 1 , δ 2 , . . . , δ n ), (A, r, s)) and returns the result to A.

Security Analysis

In the final Show protocol, B again extracts α, β, λ, δ 1 , δ 2 , . . . , δ n+1 , γ, θ and outputs ((δ 1 , δ 2 , . . . , δ n ), (B α 0 , -λ α , δ n+1 )) as its forgery. First, note that B's response to OBlindIssue queries are identical to the ones of the honest OBlindIssue algorithm. Then, we argue that its response to ShowVerify queries are also, with overwhelming probability, identical to the output of a real ShowVerify algorithm. To see this, note that the proof of knowledge property guarantees that the extractor succeeds in producing a valid witness with all but negligible probability. Furthermore, if the extractor gives valid (α, β, λ, δ 1 , δ 2 , . . . , δ n+1 ), we have from

Note that α is necessarily different from 0, otherwise B α 0 = 1 and would have been rejected by the MAC n BB Verify oracle. Thus, the honest verifier algorithm accepts, if and only if, (B α 0 , -λ α , δ n+1 ) would be accepted by the MAC n BB Verify algorithm for message (δ 1 , . . . , δ n ). Similarly, we can argue that B can extract a valid MAC from the final Show protocol whenever α = 0 and ShowVerify would have output 1. Thus, if A can cause ShowVerify to accept for some statement φ that is not satisfied by any of the attributes sets queried to OBlindIssue, then B can extract a new message (δ 1 , . . . , δ n ) and a valid tag for that message.

Anonymity

Suppose the user is trying to prove that he has a credential for attributes satisfying some statement φ. We want to show that there exists an algorithm SimShow that, for the adversary A, is indistinguishable from Show but that only takes as input the statement φ and the secret key sk.

Let φ ∈ Φ and (m 1 , . . . , m n ) ∈ U be such that φ(m 1 , . . . , m n ) = 1. Let pp be the system public parameters, Y the issuer's public key and σ be such that CredVerify(sk, σ, (m 1 , . . . , m n )) = 1. So, σ consists of a quadruple (A, r, s u , Cm ) ∈ G × Z p × Z p × G satisfying A y+r = g m 1 1 . . . g mn n g su h. SimShow(sk, φ) behaves as follows: it chooses random values l ∈ R Z * p as well as a random generator E ∈ R G. It then computes B 0 = g l 0 and C = Y l . It runs A with the values (B 0 , C, E) as the first message, simulates the proof of knowledge π 3 and outputs whatever A outputs at the end of the proof.

Let us first show that the values B 0 , C and E are distributed identically to those produced by Show. Note that since A = 1, there exists x ∈ Z p such that A = g x 0 . For a random value l ∈ R Z p , B 0 = A l = g lx 0 = g l 0 for l = lx. Therefore, we also have C = A ly = Y l . Moreover, there exists t such that E = C 1/l f t . Then, the values computed by SimShow are identical to those that the normal Show protocol would have produced. Owing to the zero-knowledge property of the proof of knowledge, we conclude that the resulting view is indistinguishable from that produced by the adversary interacting with Show.

Blind Issuance

Following [START_REF] Chase | Algebraic macs and keyedverification anonymous credentials[END_REF], we first consider the setting where all of the attributes are known to the issuer. If we consider the case where the user is corrupt, then our simulator Sim on shared input (S, pp, pk) receives the user's list of attributes (m 1 , m 2 , . . . , m n ) and forward it to the functionality. The functionality returns "attribute error" if S = (m 1 , . . . , m n ) and otherwise it returns σ. If the error does not occur, Sim then sends σ and runs the π 2 proof of knowledge simulator to simulate the proof of correctness for σ. By zero-knowledge, this is indistinguishable from the real world.

Next, we consider the case where the issuer is corrupt. In this case, our simulator Sim receives σ = (A, r, s ) from the issuer and runs the verifier for the proof system π 2 . If the proof is accepted, it runs the corresponding proof of knowledge extractor to extract sk = y (as well as r and s ). It sends (y, r, s ) to the ideal functionality. By the proof of knowledge properties, the credential sent in the real world is σ = ((g m 1 1 g m 2 2 . . . g mn n g s+s h)

1 y+r , r, s ) which is exactly what would be produced by the ideal functionality on input (y, r, s ) described above.

Then, we consider this time the BlindIssue protocol which keeps attributes hidden. In this setting, we define an ideal functionality F that takes (y, r, s ) as the issuer's input and (m 1 , . . . , m n , s, l) as the user's input. F returns a randomized credential σ l = (A l , s , r) to the user whilst nothing is returned to the issuer.

Consider the case where the user is corrupt. Then, our simulator Sim on shared input (S, pp, pk) receives a commitment C m and runs the verification of the proof of knowledge π 1 . If the proof is valid, it then uses the proof of knowledge extractor of π 1 to extract {m i } n i=1 and s, then sends them along with a random l and the set S to the functionality. The functionality returns σ l = (A l , r, s ). So, Sim sends σ and runs the π 2 proof of knowledge simulator to simulate the proof of correctness for σ. By the zero-knowledge property, this is indistinguishable from the real world.

Next, we consider the case where the issuer is corrupt. In this case, our simulator Sim on shared input (S, pp, pk) receives σ = (A, r, s ), C m and π 2 from the issuer and runs the verifier for the proof system π 2 . If the proof is valid, it runs the corresponding proof of knowledge extractor to extract sk = y, as well as r and s . Then, it sends (y, r, s ) to the ideal functionality. By the proof of knowledge property, a randomized version of the credential sent in the real world is σ l = (((C m • g s h) 1 y+r ) l , r, s ). The latter is indistinguishable from what would have been produced by the ideal functionality on input (y, r, s ).

Key-parameter consistency

Our KVAC scheme trivially satisfies this requirement. Indeed, our system public parameters pp consists of a cyclic group G of prime order p along with (n + 4) generators g 0 , g 1 , . . . , g n , g, h, f . The issuer's public key is a value Y ∈ G and the associated private key is the discrete logarithm of Y in the base g 0 . As this discrete logarithm is unique, an adversary cannot find two secret keys corresponding to a same public key Y .

Conclusion

In this chapter, based on our algebraic MAC n BB scheme, we designed a keyed-verification anonymous credentials (KVAC) system whose presentation proof is efficient both in terms of presentation cost and complexity (in the number of group elements). Our KVAC system provides multi-show unlinkability and, unlike Chase et al. KVAC systems, requires the issuer to hold a single private key regardless of the number of attributes. Through slight modifications (solely on the verifier side), our KVAC system can be easily turned into a quite efficient public key anonymous credentials system. Thereby, it can also be used even if the verifier does not hold the issuer's private key.

In the next chapter, based on our practical DAA scheme introduced in Section 4.4, we design a privacy-preserving authentication protocol for embedded SIM (eSIM) so as to cope with a real issue that has arisen at the Groupe Speciale Mobile Association (GSMA).

Chapter 7 : An Anonymous Authentication and Identification Protocol for eSIM

Our anonymous authentication and identification protocol for eSIM

In this section, we first give an overview on our authentication and identification protocol. Then, we detail its different phases while depicting the main ones (i.e. Certificate Issuance and Discovery Request) in Figure 7.2. Recall that our protocol is based on our BB-based Pre-DAA scheme which is proven secure in the random oracle model (see Chapter 4 and more precisely Section 4.4).

Overview

Our privacy-friendly authentication and identification protocol for eSIM mainly consists of the following four phases. (1) A Setup phase where the system public parameters as well as required keys are defined. (2) Upon the manufacture of an eSIM, a Certificate Issuance phase is triggered so as to provide the eSIM with a group membership certificate. The latter will enable the anonymous authentication of the eSIM to the different other entities. (3) At each new subscription, the MNO initiates the Profile Generation phase by asking the SM-DP+ to create a profile for the corresponding eSIM. Once the profile has been generated, the SM-DP+ notifies the discovery server (SM-DS) by providing it with a set S including legitimate identification values associated to the new subscription. (4) To get its new profile, the eSIM must first know which SM-DP+ holds it. To this end, it transmits an anonymous request to its default SM-DS. If the request is authenticated, the eSIM obtains the address of the corresponding SM-DP+ server (i.e. the one that has generated its new profile). This last phase is referred to as Discovery Request. Once it has been successfully completed, the eSIM can download its new profile by getting in touch with the relevant SM-DP+.

Protocols description

Hereinafter, we detail the different phases of our anonymous authentication and identification protocol. Its main building block is our BB-based Pre-DAA scheme detailed in Chapter 4 Section 4.4 and which requires no pairing computations on the platform side.

Setup

Let pp = (G 1 , G 2 , G T , p, g 1 , g 2 , h, g 0 , f, g0 , H, e) denote the system public parameters where G 1 , G 2 and G T are three cyclic groups of prime order p, a k-bit prime, (h, g 0 , g 1 , g 2 , f ) are random generators of G 1 and g0 is a random generator of G 2 , H : {0, 1} * → Z * p is a hash function and e : G 1 × G 2 → G T is a type-3 bilinear map. In the sequel, all computations on exponents are computed modulo p.

Each eUICC manufacturer (EUM) also selects a random value y ∈ R Z * p as its private key sk and compute the associated public key pk = (Y, W ) where Y = g y 0 and W = gy 0 . Indeed, each EUM holds a distinct public/private key pair and eSIMs are organized into groups according to their manufacturer which acts as a group manager (i.e. membership certificate issuer).

Certificate Issuance

As previously mentioned, each manufactured eSIM is uniquely identified by its eUICC identifier (EID). Upon its manufacture, the eSIM randomly selects s ∈ R Z * p then, computes C s 1 = g EID 1 and C s 2 = g s 2 where EID is a 160-bit identifier derived from EID. Next, it builds a ZKPK

} that it sends to the EUM along with C s 1 and C s 2 . Upon their receipt, the EUM first checks the validity of π 1 . If so, it randomly selects s , r ∈ R Z * p and computes A = (C s 1 C s 2 g s 2 h) 1 y+r . Then, it provides the eSIM with s , r and A as well as a ZKPK π 2 ensuring that A is well-formed. The proof π 2 is defined as π 2 = PoK{γ : B = A γ ∧ Y = 7.4. Our anonymous authentication and identification protocol for eSIM

If the check of π 2 validity succeeds, the eSIM stores the triple (A, r, s u ), where s u = s + s , as its membership certificate ζ. The latter will subsequently enable the eSIM to be anonymously authenticated to other entities.

Query database for an entry with T Details of the proof π 3 :

Choose a 1 , a 2 , . . . , a 7

Profile Generation

Following each subscription change, the MNO asks a given SM-DP+ server to generate the eSIM new profile. As soon as the profile is created, the SM-DP+ must notify the SM-DS that it holds a new profile for a given eSIM. This shall be done in a privacy-preserving way (i.e. the SM-DS should not be able to know the EID of the relevant eSIM).

To do so, the SM-DP+ computes the set S = {H(d s ) EID , H(d s +1) EID , . . . , H(d s +M ax) EID } such that d s and M ax respectively correspond to the subscription date and the time period during which the new profile remains available for download (for example, M ax = 7 for an availability of a week). Of course, the subscription date and time period during which the profile is available can be set according to different time units (e.g. hours, days, etc.). The set S along with Add SM -DP + , which denotes the address of the SM-DP+ that generated the new profile, are forwarded to the SM-DS.

Chapter 8 : An Efficient Coercion-Resistant Remote Electronic Voting Scheme

Registration

Register(V(ID v , pp), R(sk R , pp)): Given a voter's identity ID v , this probabilistic algorithm outputs a unique (and valid) credential σ associated to a secret s cooperatively chosen by the registrars R.

Voting

Voting(V(σ, s, v, O, pk T )): This algorithm, which is executed by a voting device, takes as input the public key of the talliers pk T , the candidate slate O, the voter's choice v as well as her credential σ and the associated secret s. It outputs a ballot B which includes an encrypted version of the voter's choice.

Pre-Verification

Pre-Verification(T (BB, sk T , n C )): This algorithm, which is performed by the talliers, takes as input the set BB of all ballots cast on the WBB. Once this algorithm performed, duplicate ballots and ballots with invalid proofs are discarded, "some parts" of the remaining ballots are removed as well. The set of remaining ballots is denoted by BB .

5.

Tallying

)): This algorithm, which is performed by the talliers, takes as input the remaining set of ballots BB . It tallies the valid votes and outputs the election result.

Security and Privacy Requirements

In this section, we recall the properties that a remote voting scheme must ensure to be both secure and privacy-friendly. In addition to the usual correctness property, which guarantees the proper functioning of the system, three main properties must be satisfied: verifiability, eligibility and coercion-resistance. In what follows, we briefly define them while focusing on the coercionresistance property as it is the most relevant to our work (see [JCJ02, CGK + 16] for formal definitions of correctness and verifiability).

Security Requirements

Verifiability

According to the considered entity, we can distinguish two types of verifiability, namely individual and universal. If both properties are satisfied and all voters are assured that the ballots they cast encrypt their real choices, then the scheme is said to provide end-to-end verifiability. Hereinafter, we briefly define both categories of verifiability.

Individual verifiability. Roughly speaking, individual verifiability enables the voter to verify that her ballot has been included in the election Web Bulletin Board (WBB), which is publicly accessible.

Universal verifiability. Informally, universal verifiability ensures that (1) only valid votes (i.e. votes cast by legitimate voters) are considered when computing vote outcome, and (2) the election result is consistent with the ballots published on the WBB (i.e. only invalid ballots have been discarded). As its name implies, this property may be checked by everyone. . Note that D is still kept encrypted to prevent any information leakage, especially in case of coercion.

Tallying

To compute election results, the talliers perform the following three steps:

1. Mixing tuples. The tuples D, E T [v] that succeeded all pre-verifications are sent to a verifiable Mix-net (which takes as input a set of ballots and shuffle them). The output is then published on the WBB.

2. Identifying valid votes. For each tuple, the ciphertext D is jointly decrypted. If the plaintext is equal to 1, then the credential σ r and the associated ballot are considered as valid.

Otherwise, the ballot is said invalid and is, thus, discarded.

3. Decrypting and counting votes. Finally, for each remaining valid ballot, E T [v] is cooperatively decrypted in order to count the votes. The obtained result is then published on the WBB.

For subsequent elections, or in the case where some voters are no longer eligible to vote, the authorities should be able to update eligible voters' credentials without requiring them to register again. In what follows, we explain how to efficiently update the credentials through the use of our sequential aggregate MAC scheme introduced in Section 4.3.

Multiple Elections and Credentials Revocation.

For every new election, the registrars must generate both a specific election identifier and a new pair of keys. For the ith election, this pair is defined as (x i , X i = h x i ) where x i ∈ R Z * p is shared among registrars and talliers. Hereinafter, we detail the case of a second election identified by e I and which associated key pair is (x 2 , X 2 = h x 2 ).

For each initial credential σ = (u, u ) ∈ DB belonging to an eligible voter, the registrars jointly select a random value t ∈ R Z p , compute σ 2 = (u t , (u u e I x 2 ) t ) = (w, w = w x 0 +sx 1 +e I x 2 ) and update DB. Then, the new database is published to enable eligible voters to get their new credential. These changes are irrelevant except for the pre-verification phase whose third step is henceforth defined as follows:

-Reconstruction of the credential. First, the talliers cooperatively encrypt w to get E T [w].

Then, as previously and thanks to ElGamal homomorphic property, they jointly compute the three ciphertexts: E T [w x 0 ], E T [w sx 1 ] and E T [w e I x 2 ] using e I , E T [w] and E T [w s ] as well as their shared secret keys x 0 , x 1 and x 2 . Thereby, the talliers can compute

. By dividing the second component of the ciphertext by w , they obtain C = E T [w x 0 +sx 1 +e I x 2 ]/w . For a valid credential, C should be equal to E T [1], a ciphertext of 1.

Security Analysis

In this section, we provide proof sketches ensuring that our remote electronic voting system satisfies the security and privacy requirements defined in Section 8.4.

Verifiability

Theorem 8.2. Our voting scheme provides the end-to-end verifiability requirement.

Proof (sketch). We recall that a scheme ensures end-to-end verifiability if ballots are cast as intended and both individual and universal verifiability are satisfied.

-Individual Verifiability: Recall that, during the registration phase, the voter is provided with a DVP which ensures the validity of her credential. Besides, since she knows (w, w , o s ) where o ∈ G is the generator associated to the election, w = u r and w = (u ) r , the voter can search in the WBB whether there is a ballot containing the same values (i.e. o s , w and w ). Thereby, she can verify if her ballot has been taken into account in the WBB or not. Thus, our scheme ensures individual verifiability.

-Universal Verifiability: Every step of the tallying phase (PET, Mix-net, ZKPK and duplicate removal) is publicly verifiable. Thus, anyone can check that the election outcome corresponds to the ballots published on the WBB and, in particular, that only invalid ballots with invalid credentials have been discarded. Therefore, our scheme provides universal verifiability.

Thus, since we assumed that votes are cast as intended, we can conclude that our voting scheme ensures the end-to-end verifiability requirement.

Eligibility

Theorem 8.3 (Eligibility). Our voting scheme satisfies the eligibility requirement, in the random oracle model, under the assumption that MAC GGM is UF-CMVA secure.

Proof (sketch). Intuitively, the first condition of eligibility (i.e. only an eligible voter can cast a vote) follows from the unforgeability of the MAC GGM and the fact that ballots with invalid proofs or credentials are discarded. The second condition (i.e. a voter can only cast one vote) is also satisfied since duplicates are removed in the second step of the pre-verification phase. Consequently, only one vote per credential (valid or fake) will be processed during the tallying phase. Therefore, our voting scheme ensures the eligibility requirement.

Coercion-Resistance

Theorem 8.4 (Coercion-Resistance). Our voting scheme satisfies the coercion-resistance requirement, in the random oracle model, under the DDH assumption.

Proof (sketch). Recall that the adversary's goal is to guess the behavior of the coerced voter V O during the run of the election system. That is, if (1) V O provided him with a fake voting key and cast a ballot with choice β, or (2) V O has revealed her "real" (i.e. valid) voting key and abstained from voting. To prove that an election system provides coercion-resistance, we must show that A succeeds with probability negligibly close to that of a PPT adversary A interacting with an ideal election system. In particular, A is a passive adversary and his only input is → X: the final tally of votes cast by honest voters, and the number of discarded ballots (i.e. ballots built with invalid credentials).

Thesis Publications

Here is the list of the papers published, at international conferences and journals, during this thesis. Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials.

International Conferences

List of Tables

Abstract

Machine to Machine (M2M) applications are increasingly being deployed so as to enable a better management of resources and provide users with greater comfort. Unfortunately, they also entail serious security and privacy concerns. In this thesis, we focus on M2M security, and particularly on the authentication and privacy issues of M2M applications involving a SIM card.

In the first part of this thesis, we design five new cryptographic primitives, that are of independent interest, and formally prove that they meet the expected security requirements. More precisely, they consist of a partially blind signature scheme, a sequential aggregate Message Authentication Codes (MAC) scheme, an algebraic MAC scheme and two pre-Direct Anonymous Attestation (pre-DAA) schemes. Some of the proposed schemes aim to achieve a particular property that was not provided by previous constructions whereas others intend to improve the efficiency of state-of-the-art schemes. Our five schemes do not require the user's device to compute pairings. Thus, they are suitable for resource constrained environments such as SIM cards.

In a second part, we rely on these primitives to propose new privacy-preserving protocols. More specifically, we design an efficient private eCash system where the user can settle expenses of different amounts using a single reusable payment token. We also propose a protocol enabling anonymous authentication and identification of an embedded SIM (eSIM) to a Discovery Server (DS). Thereby, eSIMs can be remotely provisioned with their new network profiles while protecting users' privacy against a malicious discovery server. Furthermore, we rely on our algebraic MAC scheme to build a practical Keyed-Verification Anonymous Credentials (KVAC) system. Finally, based on our sequential aggregate MAC scheme, we introduce a remote electronic voting system that is coercion-resistant and practical for real polls. The security of our protocols is formally proven in the Random Oracle Model (ROM) under classical computational assumptions.

Résumé

Les applications Machine-to-Machine (M2M) sont de plus en plus déployées afin de fournir plus de confort aux utilisateurs et permettre une utilisation optimale des ressources. Toutefois, ces applications ne présentent pas que des avantages pour les utilisateurs. En effet, ces dernières peuvent engendrer des problèmes de sécurité, voire porter atteinte à la vie privée de leurs utilisateurs. Dans cette thèse, nous nous intéressons à la sécurité des applications M2M, et plus précisément à l'authentification et la préservation de la vie privée d'utilisateurs d'équipements M2M dotés d'une carte SIM.

Dans la première partie de ce mémoire, nous proposons cinq nouvelles primitives cryptographiques, à savoir un schéma de signature partiellement aveugle, deux schémas de codes d'authentification de messages, ainsi que deux schémas d'attestations anonymes. Ces nouvelles primitives sont plus efficaces, voire fournissent des fonctionnalités nouvelles par rapport aux schémas de l'état de l'art et sont adaptées aux environnements limités en ressources telles que les cartes SIMs.

Dans la deuxième partie, nous nous appuyons sur ces primitives pour construire de nouveaux protocoles préservant la vie privée des utilisateurs. Plus précisément, nous introduisons un nouveau système de paiement anonyme efficace avec lequel les utilisateurs peuvent effectuer plusieurs paiements, de manière complètement intraçable, en utilisant un unique jeton de paiement. Nous proposons également un protocole d'authentification et d'identification anonyme pour la nouvelle génération de cartes SIM, connue sous le nom d'Embedded SIM (eSIM). Ainsi, une eSIM peut récupérer son nouveau profil réseau tout en préservant la vie privée de son détenteur. Par ailleurs, en se basant sur notre schéma de codes d'authentification de messages, nous construisons un système d'accréditations anonymes. Enfin, nous spécifions un système de vote électronique efficace rendant inutile toute forme de coercition à l'encontre d'un électeur. La sécurité de toutes nos contributions est prouvée dans le modèle de l'oracle aléatoire sous des hypothèses classiques.