Vers des protocoles de tolérance aux fautes byzantines efficaces et robustes

HAL Id: tel-01680714

https://tel.archives-ouvertes.fr/tel-01680714v2

Submitted on 11 Jan 2018

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

efficaces et robustes

Lucas Perronne

To cite this version:

Lucas Perronne. Vers des protocoles de tolérance aux fautes byzantines efficaces et robustes. Per- formance et fiabilité [cs.PF]. Université Grenoble Alpes, 2016. Français. �NNT : 2016GREAM075�.

�tel-01680714v2�

THÈSE

Pour obtenir le grade de

DOCTEUR DE L’UNIVERSITÉ GRENOBLE ALPES

Spécialité : Informatique

Arrêté ministériel : 25 mai 2016

Présentée par

Lucas P ERRONNE

Thèse dirigée par Pr. Sara Bouchenak

préparée au sein du Laboratoire d’Informatique de Grenoble

et de École Doctorale Mathématiques, Sciences et Technologies de l’Information, Informatique

Vers des protocoles de tolérance aux fautes Byzantines efficaces et robustes

Thèse soutenue publiquement le 8 décembre, 2016, devant le jury composé de :

Pr. Didier Donsez

Université Grenoble Alpes, LIG, Président

Pr. François Taiani

Université Rennes 1, IRISA, Rapporteur

Pr. Romain Rouvoy

Université Lille 1, LIFL, Rapporteur

MdC. Vania Marangozova

Université Grenoble Alpes, LIG, Invitée

Pr. Sara Bouchenak

INSA Lyon, LIRIS, Directrice de thèse

Remerciements

Je remercie tout d’abord Didier Donsez, Professeur ` a l’Universit´ e de Gre- noble 1, pour me faire l’honneur de pr´ esider le jury. Mes remerciements s’adressent

´

egalement ` a Fran¸cois Taiani, Professeur ` a l’Universit´ e de Rennes 1, et Romain Rouvoy, Professeur ` a l’Universit´ e de Lille 1 qui ont gracieusement accept´ e d’ˆ etre les rapporteurs de cette th` ese. Merci ´ egalement ` a Vania Marangozova, Maˆıtre de conf´ erence ` a l’Universit´ e de Grenoble 1, d’avoir accept´ e d’y assister en tant qu’invit´ ee.

Je souhaite remercier mon encadrante Sara Bouchenak, professeur ` a l’INSA Lyon, pour m’avoir soutenu pendant ces trois ann´ ees de th` ese, et sans qui je n’aurais pu me plonger dans l’univers de la recherche. Je tiens ´ egalement ` a remercier Damian Serrano, qui m’a guid´ e avec ferveur durant ma premi` ere ann´ ee de th` ese.

Mes remerciements s’adressent ´ egalement ` a Divya Gupta, pour une colla- boration efficace et un travail ayant permis la publication de plusieurs travaux de recherche.

Je remercie chaleureusement l’ensemble du personnel de l’´ equipe ERODS et de l’´ ecole doctorale MSTII, qui a su me conseiller avec discernement sur de nombreux points techniques et administratifs.

Je tiens ` a remercier Nicolas Palix, Emmanuel Promayon, Pascal Sicard et le personnel de Polytech Grenoble, qui m’ont permis d’enseigner pendant ces deux derni` eres ann´ ees, m’octroyant de fait la possibilit´ e de vivre une exp´ e- rience tr` es enrichissante.

Je remercie mes coll` egues doctorants et docteurs, pour leur bonne humeur et la motivation qu’ils m’ont apport´ ee lors de ces trois derni` eres ann´ ees.

Je remercie ma famille qui n’a jamais cess´ e de me soutenir, et en laquelle

je voue une confiance in´ ebranlable.

iii

R´ esum´ e

Au cours de la derni` ere d´ ecennie, l’informatique en nuage (Cloud Com- puting) suscita un important changement de paradigme dans de nombreux syst` emes d’information. Ce nouveau paradigme s’illustre principalement par la d´ elocalisation de l’infrastructure informatique hors du parc des entreprises, permettant ainsi une utilisation des ressources ` a la demande. La prise en charge de serveurs locaux s’est donc vue peu ` a peu remplac´ ee par la loca- tion de serveurs distants, aupr` es de fournisseurs sp´ ecialis´ es tels que Google, Amazon, Microsoft.

Afin d’assurer la p´ erennit´ e d’un tel mod` ele ´ economique, il apparaˆıt n´ e- cessaire de fournir aux utilisateurs diverses garanties relatives ` a la s´ ecurit´ e, la disponibilit´ e, ou encore la fiabilit´ e des ressources mises ` a disposition. Ces facteurs de qualit´ e de service (QoS pour Quality of Service) permettent aux fournisseurs et aux utilisateurs de s’accorder sur le niveau de prestation es- compt´ e. En pratique, les serveurs mis ` a disposition des utilisateurs doivent

´

episodiquement faire face ` a des fautes arbitraires (ou byzantines). Il s’agit par exemple de ruptures temporaires du r´ eseau, du traitement de messages cor- rompus, ou encore d’arrˆ ets inopin´ es. Le contexte d’informatique en nuage s’est vu n´ eanmoins propice ` a l’´ emergence de technologies telles que la virtualisation ou la duplication de machines ` a ´ etats. De telles technologies permettent de pal- lier efficacement ` a l’occurrence de pannes via l’impl´ ementation de protocoles de tol´ erance aux pannes.

La tol´ erance aux fautes byzantines (BFT pour Byzantine Fault Tolerance) est un domaine de recherche impl´ ementant les concepts de duplication de machines ` a ´ etats, qui vise ` a assurer la continuit´ e et la fiabilit´ e des services en pr´ esence de comportements arbitraires. Afin de r´ epondre ` a cette probl´ e- matique, de nombreux protocoles furent propos´ es. Ceux-ci se doivent d’ˆ etre efficaces afin de masquer le surcoˆ ut li´ e ` a la duplication, mais ´ egalement ro- bustes afin de maintenir un niveau de performance ´ elev´ e en pr´ esence de fautes.

Nous constatons d’abord qu’il est d´ elicat de relever ces deux d´ efis ` a la fois : les protocoles actuels sont soit con¸cus pour ˆ etre efficaces au d´ etriment de leur robustesse, soit pour ˆ etre robustes au d´ etriment de leur efficacit´ e. Cette th` ese se focalise autour de cette probl´ ematique, l’objectif ´ etant de fournir les instru- ments n´ ecessaires ` a la conception de protocoles ` a la fois robustes et efficaces.

Notre int´ erˆ et se porte principalement vers deux types d’attaques (d´ enis

de service) li´ es ` a la gestion des requˆ etes. La premi` ere attaque est caus´ ee par

la corruption partielle d’une requˆ ete lors de son ´ emission par un client. La

deuxi` eme est provoqu´ ee par l’abandon intentionnel d’une requˆ ete lors de sa

r´ eception par un r´ eplica. Afin de faire face efficacement ` a ces deux compor-

tements byzantins, plusieurs m´ ecanismes d´ edi´ es furent impl´ ement´ es dans les protocoles de BFT robustes. En pratique, ces m´ ecanismes engendrent d’im- portants surcoˆ uts, et contribuent par cons´ equent au d´ eclin des performances des protocoles robustes face aux protocoles efficaces. Ce constat nous permet d’introduire notre premi` ere contribution : la d´ efinition de plusieurs principes de conception g´ en´ eriques, applicables ` a de nombreux protocoles de BFT, et destin´ es ` a r´ eduire ces surcoˆ uts tout en assurant un niveau de robustesse ´ equi- valent.

La seconde contribution de cette th` ese illustre ER-PBFT, un nouveau pro- tocole appliquant ces principes de conception au consensus utilis´ e par PBFT, la r´ ef´ erence en mati` ere de tol´ erance aux fautes byzantines. S’ensuit une ´ eva- luation des performances de notre protocole, ainsi qu’une comparaison avec plusieurs protocoles robustes de l’´ etat de l’art. Nous d´ emontrons l’efficacit´ e de notre nouvelle politique de robustesse, ` a la fois en pr´ esence de comportements byzantins mais ´ egalement lors de sc´ enarios sans faute.

La troisi` eme contribution illustre ER-COP, un nouveau protocole orient´ e ` a la fois vers l’efficacit´ e et la robustesse, impl´ ementant nos principes de concep- tion sur COP, le protocole de BFT fournissant les meilleures performances ` a l’heure actuelle dans un environnement sans faute. Nous pr´ esentons ´ egalement une comparaison entre ER-COP et le prototype de COP original, afin d’´ eva- luer le surcoˆ ut engendr´ e par l’int´ egration de notre politique de robustesse.

Nous r´ ealisons finalement une ´ evaluation d’ER-COP en pr´ esence de divers

comportement byzantins, afin de d´ emontrer sa capacit´ e ` a tol´ erer l’occurrence

de tels ´ ev´ enements.

v

Abstract

Over the last decade, Cloud computing instigated an important switch of paradigm in numerous information systems. This new paradigm is mainly illustrated by the re-location of the whole IT infrastructures out of companies’

warehouses. The use of local servers has thus being replaced by remote ones, rented from dedicated providers such as Google, Amazon, Microsoft.

In order to ensure the sustainability of this economic model, it appears necessary to provide several guarantees to users, related to the security, avai- lability, or even reliability of the proposed resources. Such quality of service (QoS) factors allow providers and users to reach an agreement on the expec- ted level of dependability. Practically, the proposed servers must episodically cope with arbitrary faults (also called byzantine faults), such as incorrect/cor- rupted messages, servers crashes, or even network failures. Nevertheless, the Cloud computing environment encouraged the emergence of technologies such as virtualization or state machine replication. These technologies allow cloud providers to efficiently face the occurrences of faults through the implementa- tion of fault tolerance protocols.

Byzantine Fault Tolerance (BFT) is a research area involving state ma- chine replication concepts, and aiming at ensuring continuity and reliability of hosted services in presence of any kind of arbitrary behaviors. In order to handle such threat, numerous protocols were proposed. These protocols must be efficient in order to counterbalance the extra cost of replication, and robust in order to lower the impact of byzantine behaviors on the system per- formance. We first noticed that tackling both these concerns at the same time is difficult : current protocols are either designed to be efficient at the expense of their robustness, or robust at the expense of their efficiency. We tackle this specific problem in this thesis, our goal being to provide the required tools to design both efficient and robust BFT protocols.

Our focus is mainly dedicated to two types of denial-of-service attacks in- volving requests management. The first one is caused by the partial corruption of a request transmitted by a client. The second one is caused by the inten- tional drop of a request upon receipt. In order to face efficiently both these byzantine behaviors, several mechanisms were integrated in robust BFT proto- cols. In practice, these mecanisms involve high overheads, and thus lead to the significant performance drop of robust protocols compared to efficient ones.

This assessment allows us to introduce our first contribution : the definition

of several generic design principles, applicable to numerous BFT protocols,

and aiming at reducing these overheads while maintaining the same level of

robustness.

The second contribution introduces ER-PBFT, a new protocol implemen- ting these design principles on PBFT, the reference in terms of byzantine fault tolerance. We evaluate the performance of our protocol, and compare it with several robust BFT protocols, in order to demonstrate the efficiency of our new robustness policy, both in fault-free scenarios and in presence of byzantine behaviors.

The third contribution highlights ER-COP, a new BFT protocol dedicated

to both efficiency and robustness, implementing our design principles on COP,

the BFT protocol providing for now the best performances in a fault-free en-

vironment. We also present a comparison between ER-COP and the original

COP implementation, in order to evaluate the additional cost introduced by

the integration of our robustness policy. Finally, we evaluate ER-COP in pre-

sence of various byzantine behaviors, in order to demonstrate its ability to

handle such events.

Table des mati` eres

1 Introduction 5

1.1 Contexte et Motivation . . . . 6

1.2 D´ efis Scientifiques . . . . 8

1.3 Contributions . . . . 9

1.4 Organisation du Manuscrit . . . . 10

2 Etat de l’Art 13 2.1 Contexte . . . . 14

2.1.1 Duplication de Machines ` a Etats . . . . 14

2.1.2 Tol´ erance aux Fautes Byzantines . . . . 19

2.2 Cat´ egorisation des Protocoles de Tol´ erance Aux Fautes Byzan- tines . . . . 25

2.2.1 Optimisation des Performances en Absence de Faute . 25 2.2.2 Minimisation de l’Impact des Comportements Byzantins 38 2.3 Synth` ese . . . . 45

3 Probl` emes Ouverts en Tol´ erance aux Fautes Byzantines 47 3.1 Attaques Consid´ er´ ees . . . . 48

3.1.1 L’Attaque MAC . . . . 48

3.1.2 L’indiff´ erence S´ elective du Primary . . . . 51

3.2 Le Prix d’une Tol´ erance aux Fautes Byzantines Robuste . . . . 53

3.2.1 Des Authentifications On´ ereuses . . . . 53

3.2.2 La Tol´ erance aux Fautes Byzantines en Pratique . . . . 56

4 Principes de Conception de Protocoles Efficaces et Robustes 59 4.1 Associer Efficacit´ e et Robustesse . . . . 60

4.1.1 D´ esactiver les Attaques MACs . . . . 60

4.1.2 Remplacer les Primaries Inactifs . . . . 60

4.1.3 Substituer les Primaries Malveillants . . . . 61

4.2 Gestion des Requˆ etes . . . . 61

4.3 Changement de Vues . . . . 62

4.3.1 Primaries Inactifs . . . . 62

4.3.2 Primaries Malveillants . . . . 63

4.3.3 Interactions entre Clients et Primary Corrects . . . . . 66

4.4 Synth` ese . . . . 66

5 Conception du protocole ER-PBFT 67 5.1 Motivation . . . . 68

5.2 Description du Protocole . . . . 68

5.2.1 Transmission des Requˆ etes . . . . 68

5.2.2 Consensus . . . . 69

5.2.3 Ex´ ecutions et R´ eponses . . . . 70

5.2.4 Changement de Vues . . . . 71

6 Evaluation du protocole ER-PBFT 73 6.1 Configuration exp´ erimentale . . . . 74

6.2 Evaluation . . . . 74

6.2.1 En absence de faute . . . . 75

6.2.2 En pr´ esence d’attaques MAC . . . . 75

6.2.3 En pr´ esence de primaries malveillants . . . . 77

6.3 Synth` ese . . . . 78

7 Conception du protocole ER-COP 79 7.1 Motivation . . . . 80

7.1.1 Task-Oriented Parallelization . . . . 80

7.2 Description du Protocole . . . . 81

7.2.1 Parall´ elisme et Robustesse . . . . 81

7.2.2 les Caract´ eristiques d’ER-COP . . . . 84

8 Evaluation du protocole ER-COP 87 8.1 Configuration exp´ erimentale . . . . 88

8.2 Evaluation . . . . 88

8.2.1 En absence de faute . . . . 89

8.2.2 En pr´ esence d’attaques MAC . . . . 89

8.2.3 En pr´ esence de primaries malveillants . . . . 91

8.3 Synth` ese . . . . 93

9 Conclusions et Perspectives 95 9.1 Conclusions . . . . 96

9.2 Perspectives . . . . 97

9.3 Publications . . . . 97

Table des mati` eres 3

Liste des Figures 101

Liste des Tableaux 103

Bibliographie 105

Chapitre 1

Introduction

Sommaire

1.1 Contexte et Motivation . . . . 6

1.2 D´ efis Scientifiques . . . . 8

1.3 Contributions . . . . 9

1.4 Organisation du Manuscrit . . . . 10

1.1 Contexte et Motivation

L’apparition de la premi` ere vague de services h´ eberg´ es sur le web remonte aux ann´ ees 2000. C’est dans cet environnement que l’informatique en nuage (Cloud Computing ) prit son essor. Le paradigme d’informatique en nuage re- pose sur la location et l’exploitation des capacit´ es de stockage et de calcul de serveurs informatiques distants. Ces serveurs sont lou´ es ` a la demande, en fonction des besoins exprim´ es par les clients. Le principal avantage d’un tel paradigme repose sur sa grande souplesse : le client peut se voir par exemple offrir la capacit´ e de g´ erer lui-mˆ eme son serveur, ou encore la possibilit´ e de b´ en´ eficier de surcouches logicielles afin d’en faciliter l’utilisation [1, 56]. Une fois la d´ elocalisation des services effectu´ ee, les clients b´ en´ eficient de nombreux avantages, en particulier l’adaptation automatique de la quantit´ e de ressources allou´ ees. Les clients se voient ainsi factur´ es en fonction de l’utilisation effective des services h´ eberg´ es [3]. L’adoption de ce paradigme s’est vue facilit´ ee par une augmentation consid´ erable de la puissance de calcul des ´ equipements in- formatiques, permettant ainsi aux fournisseurs (Cloud providers ) de proposer des tarifs de plus en plus comp´ etitifs. En pratique, l’informatique en nuage repose sur l’adoption de technologies telles que la virtualisation, l’architec- ture orient´ ee service (SOA), ou encore la parall´ elisation et la distribution des calculs.

Grˆ ace ` a l’´ emergence de l’informatique en nuage, une utilisation plus g´ en´ e-

rique de syst` emes d’information distribu´ es s’est rapidement propag´ ee, tels que

les r´ eseaux sociaux, infrastructures bancaires, etc. G´ erer de tels syst` emes est

rapidement devenu une tˆ ache complexe. Ceux-ci impliquent bien souvent de

nombreuses entit´ es h´ et´ erog` enes qui se doivent de coop´ erer dans des environ-

nements difficiles ` a contrˆ oler [17, 29, 61]. Il n’en demeure pas moins n´ ecessaire

que ces syst` emes garantissent un haut niveau de disponibilit´ e, malgr´ e la fia-

bilit´ e relative de l’environnement dans lequel ils se voient d´ eploy´ es. Il est en

pratique tr` es fr´ equent que les services h´ eberg´ es sur le nuage soient victimes

de pannes [2, 15, 35, 53]. Celles-ci peuvent se r´ ev´ eler b´ enignes [42], ou au

contraire entraˆıner de fortes pertes financi` eres, influen¸cant ` a la fois les clients

et les fournisseurs de services. Les pannes peuvent ˆ etre caus´ ees par des ph´ e-

nom` enes vari´ es tels des erreurs logicielles ou des impr´ evus m´ et´ eorologiques :

en 2012 par exemple, de violentes tempˆ etes en Virginie du Nord perturb` erent

temporairement le service EC2 d’Amazon Web Services, entraˆınant des p´ e-

riodes d’indisponibilit´ e sur les sites web de Reddit, Foursquare, Pinterest et

GitHub. Des ´ ev´ enements en apparence b´ enins, telle l’application d’une mise

1.1. Contexte et Motivation 7

`

a jour, peuvent d´ eclencher l’occurrence d’une panne. D´ eterminer en amont les causes derri` ere chaque p´ eriode d’indisponibilit´ e n’est pas toujours pos- sible. Les services h´ eberg´ es sur le nuage doivent ´ egalement faire face ` a des cyber-attaques, ou d´ enis de services, volontairement perp´ etr´ es afin de nuire aux utilisateurs.

La duplication de machine ` a ´ etats est une mani` ere efficace de renforcer la fiabilit´ e d’un syst` eme dans des environnements peu fiables [45, 63]. Cette tech- nique consiste en l’utilisation de plusieurs copies du syst` eme, appel´ ees r´ eplicas, et permet de masquer l’occurrence de fautes de mani` ere distribu´ ee. Une telle technique permet de fournir une r´ eponse ad´ equate ` a toute sortes de fautes, du crash ` a l’erreur logicielle, d` es lors que la proportion de r´ eplicas corrects demeure suffisante. Afin de b´ en´ eficier des propri´ et´ es fournies par la duplica- tion de machines ` a ´ etats, le syst` eme doit r´ epondre ` a plusieurs contraintes. Il doit tout d’abord ˆ etre impl´ ement´ e sous forme de machine ` a ´ etats ; autrement dit son ´ etat doit ´ evoluer en fonction des instructions ` a ex´ ecuter. Il se doit

´

egalement d’ˆ etre d´ eterministe, il fournira donc toujours la mˆ eme r´ eponse ` a une mˆ eme requˆ ete. Ces pr´ e-requis permettent de garantir que plusieurs copies d’un syst` eme r´ epondront de la mˆ eme mani` ere lors de l’ex´ ecution d’une re- quˆ ete, tout en conservant des ´ etats coh´ erents. Il existe en pratique diff´ erentes mani` eres d’impl´ ementer la duplication. Celle-ci peut ˆ etre active [44], auquel cas tous les r´ eplicas ex´ ecutent manuellement les requˆ etes, ou passive [6], au- quel cas un sous-ensemble de r´ eplicas ex´ ecute les requˆ etes, puis transmet les modifications apport´ ees aux r´ eplicas restants. Le nombre de r´ eplicas, associ´ e

`

a la mani` ere dont ceux-ci communiquent sont les deux principaux facteurs permettant de d´ eterminer quels types de fautes se verront tol´ erer. Ainsi, r´ e- duire le nombre de r´ eplicas ou de messages ´ echang´ es permettra au syst` eme d’ˆ etre plus performant, mais le privera de sa capacit´ e ` a tol´ erer certains types de fautes.

Cette th` ese se focalise sur la tol´ erance aux fautes byzantines, ou arbitraires.

Ce mod` ele de fautes g´ en´ erique assume la possible occurrence d’un quelconque

comportement ne r´ epondant pas aux sp´ ecifications du syst` eme. Un tel mo-

d` ele consid` ere par exemple l’occurrence d’´ ev´ enements tels l’arrˆ et brutal d’un

r´ eplica, l’envoi de r´ eponses corrompues, ou mˆ eme la prise de contrˆ ole totale

d’un r´ eplica en cas d’attaque [13]. Nous nous focalisons donc sur les proto-

coles de duplication de machines ` a ´ etats capables de tol´ erer les fautes byzan-

tines (´ egalement appel´ es protocoles de BFT, pour Byzantine Fault Tolerance )

[4, 21, 24, 28, 37, 43, 59]. De tels protocoles ont pour dessein d’assurer la coh´ e-

rence entre les ´ etats de chaque r´ eplica dans un environnement byzantin, tout

en conservant la capacit´ e de progresser vers des ´ etats futurs. Cette coh´ erence

entre r´ eplicas est capitale afin d’assurer la p´ erennit´ e du syst` eme dupliqu´ e, il

serait par exemple r´ edhibitoire qu’un compte bancaire se voit attribuer des soldes diff´ erents selon les r´ eplicas. Dans une mˆ eme optique, le compte doit de- meurer accessible afin d’autoriser des op´ erations de d´ ebit ou de cr´ edit. D’une mani` ere plus formelle, les protocoles de tol´ erance aux fautes byzantines se doivent d’assurer deux propri´ et´ es cruciales : (i) la propri´ et´ e de sˆ uret´ e (safety), qui stipule que l’´ etat de tout r´ eplica correct doit ´ evoluer de mani` ere coh´ erente, et (ii) la propri´ et´ e de vivacit´ e (liveness ), qui stipule que chaque requˆ ete cor- recte doit finir par se voir ex´ ecut´ ee, assurant ainsi la capacit´ e du syst` eme ` a progresser.

L’utilisation pratique de tels protocoles reste marginale [25]. La duplica- tion introduit tout d’abord un surcoˆ ut non n´ egligeable compar´ e ` a un mˆ eme syst` eme non dupliqu´ e ; plus encore lorsqu’elle se doit d’offrir une tol´ erance aux fautes byzantines. Le surcoˆ ut dont il est question provient des multiples

´

echange de messages entre r´ eplicas. Ces messages se doivent d’ˆ etre syst´ emati- quement authentifi´ es via l’utilisation de primitives cryptographiques d´ edi´ ees, afin de garantir l’´ evolution coh´ erente de l’´ etat des r´ eplicas dans un environ- nement hostile. Les protocoles de BFT se doivent donc d’ˆ etre efficaces pour masquer au mieux ce surcoˆ ut, tout en garantissant les propri´ et´ es de sˆ uret´ e et de vivacit´ e. D’autre part, ces protocoles doivent ´ egalement ˆ etre robustes, c’est-` a-dire capables de fournir des performances acceptables en pr´ esence de comportements byzantins. Par cons´ equent, la capacit´ e d’assurer les propri´ e- t´ es th´ eoriques de sˆ uret´ e et de vivacit´ e reste insuffisante si le d´ ebit fourni en pratique par le protocole chute drastiquement lors d’une attaque [7, 10, 26].

1.2 D´ efis Scientifiques

La tol´ erance aux fautes byzantines a suscit´ e l’int´ erˆ et de nombreux cher- cheurs durant les 15 derni` eres ann´ ees. La plupart des contributions propos´ ees peuvent ˆ etre cat´ egoris´ ees selon deux principaux objectifs. Le premier consiste en l’am´ elioration des performances en absence de faute [14, 27, 37, 43, 65, 70], autrement dit parfaire l’efficacit´ e des protocoles de BFT dans un environne- ment qui leur est favorable. Nous ferons par la suite r´ ef´ erence aux protocoles de cette cat´ egorie en tant que protocoles de BFT efficaces. Le second objectif est ` a contrario destin´ e ` a limiter l’impact des comportements byzantins sur les performances du syst` eme [7, 10, 26, 71], soit parfaire la robustesse des proto- coles de BFT dans un environnement qui leur est hostile. Nous ferons par la suite r´ ef´ erence ` a ces protocoles en tant que protocoles de BFT robustes.

Afin de tol´ erer efficacement l’occurrence de comportements byzantins de

plus en plus agressifs, les protocoles robustes partagent tous le mˆ eme objec-

tif : limiter l’impact que des entit´ es malveillantes pourraient engendrer sur les

1.3. Contributions 9

performances du syst` eme dupliqu´ e. Afin de r´ epondre ` a cette probl´ ematique, plusieurs propositions mettent en sc` ene des protocoles de BFT robustes, ren- forc´ es par de nombreux m´ ecanismes de tol´ erance sp´ ecifiques. Au cours de la derni` ere d´ ecennie, de nouveaux comportements byzantins furent isol´ es, et plusieurs solutions propos´ ees afin de leurs faire face efficacement. Ces com- portements byzantins impliquent l’occurrence d’´ ev´ enements telles que l’intro- duction intentionnelle de d´ elais (pre-prepare delay) [7], la saturation de bande passante (flooding) [10], ou encore une corruption partielle des messages [26].

Autant de nouveaux m´ ecanismes ` a int´ egrer pour maintenir un niveau de per- formance satisfaisant. In´ evitablement, ces m´ ecanismes engendrent un surcoˆ ut suppl´ ementaire, creusant l’´ ecart de performance entre protocoles efficaces et protocoles robustes en absence de faute. Cette contradiction repr´ esente le cœur du probl` eme abord´ e, nous cherchons donc ` a limiter les surcoˆ uts engendr´ es par l’int´ egration de m´ ecanismes de robustesse afin de permettre le design de pro- tocoles ` a la fois robustes et efficaces.

Afin de r´ epondre ` a cette probl´ ematique, notre attention s’est port´ ee sur plusieurs attaques li´ ees ` a la gestion des requˆ etes transmises par les clients.

Parmi ceux-ci l’attaque MAC (Message Authentification Code) [26], qui s’est vue responsable de l’abandon des codes d’authentification de messages au pro- fit de l’utilisation de signatures digitales par les protocoles robustes. L’analyse exp´ erimentale de l’impact de ce changement de paradigme cryptographique nous a permis d’isoler l’importance de l’utilisation des codes d’authentifica- tion de messages afin d’assurer un haut niveau de performance. Un des enjeux

´

etant d` es lors de supporter l’occurrence des attaques consid´ er´ ees en ´ evitant de recourir ` a l’utilisation syst´ ematique de signatures digitales.

1.3 Contributions

Cette th` ese se focalise sur les protocoles de duplication de machines ` a ´ etats satisfaisant les propri´ et´ es de tol´ erance aux fautes byzantines. Nous d´ ebutons ce manuscrit par une pr´ esentation d´ etaill´ ee de l’´ etat de l’art, n´ ecessaire ` a la mise en exergue des quatre contributions suivantes :

1. La d´ efinition de principes de conception g´ en´ eriques permettant le design de protocoles ` a la fois efficaces et robustes : Ces prin- cipes facilitent la conception de protocoles efficaces et robustes, et sont

´ egalement applicables ` a de nombreux protocoles de BFT existants, leurs

octroyant ainsi la capacit´ e de tol´ erer plus efficacement la pr´ esence de

comportements byzantins. Ces principes de conception permettent par

ailleurs aux protocoles auxquels ils sont appliqu´ es d’afficher un niveau

de performance sup´ erieur aux protocoles robustes contemporains.

2. La mise en œuvre d’un nouveau protocole : ER-PBFT : Nous illustrons l’impact de nos principes de conception sur le consensus utilis´ e par PBFT, la r´ ef´ erence en mati` ere de tol´ erance aux fautes byzantines [21]. le design de ER-PBFT nous permet ainsi de valider la pertinence de notre politique de tol´ erance aux pannes en pratique.

3. La conception d’ER-COP : un amalgame efficace et robuste : A l’heure actuelle, COP est le protocole de BFT fournissant les meilleures performances dans un environnement sans faute. Comme nombre de ses pairs, ce protocole privil´ egie l’optimisation des performances au d´ etri- ment de sa robustesse, il est donc vuln´ erable face ` a l’occurrence de com- portements byzantins. Nous avons choisi d’impl´ ementer ER-COP afin de d´ emontrer la fiabilit´ e de nos m´ ecanismes de tol´ erance aux pannes tout en ´ evaluant leurs surcoˆ uts face ` a l’impl´ ementation originale de COP.

4. L’´ evaluation comparative et exp´ erimentale de plusieurs proto- coles de BFT : De nombreuses ´ evaluations sont pr´ esent´ ees au cours du manuscrit. Dans un premier temps, nous confrontons analytiquement plusieurs protocoles de l’´ etat de l’art. Par la suite, nous comparons nos nouveaux protocoles en pr´ esence des diverses attaques consid´ er´ ees, ainsi qu’aux protocoles les plus robustes de l’´ etat de l’art.

1.4 Organisation du Manuscrit

La suite du document est organis´ ee sous diff´ erents chapitres, bri` evement d´ etaill´ es ci-dessous :

Chapitre 2 : Etat de l’Art. Ce chapitre introduit l’ensemble des concepts n´ ecessaire ` a la compr´ ehension du manuscrit. Parmi ceux-ci les concepts de du- plication de machines ` a ´ etats et de tol´ erance aux fautes byzantines. S’en suit une pr´ esentation plus approfondie des principales directions de recherches em- prunt´ ees au cours de la derni` ere d´ ecennie dans le domaine de la tol´ erance aux fautes byzantines.

Chapitre 3 : Probl` emes Ouverts en Tol´ erance aux Fautes By-

zantines. Ce chapitre expose la probl´ ematique abord´ ee. Il d´ ecrit la nature

des comportements byzantins consid´ er´ es, ainsi que les solutions propos´ ees par

l’´ etat de l’art afin de leur faire face. Nous ´ evaluons de mani` ere pratique le

surcoˆ ut associ´ e ` a ces solutions afin de d´ emontrer la n´ ecessit´ e d’adapter les

politiques de robustesse existantes.

1.4. Organisation du Manuscrit 11

Chapitre 4 : Principes de Conception de Protocoles Efficaces et Robustes. Nous proposons dans ce chapitre nos solutions d´ edi´ ees, sous la forme de plusieurs principes de conception g´ en´ eriques. L’objectif de cette contribution est de faciliter le design de protocoles de tol´ erances aux fautes byzantines ` a la fois efficaces et robustes.

Chapitre 5 : Conception du protocole ER-PBFT. Ce chapitre pr´ e- sente ER-PBFT, un nouveau protocole de tol´ erance aux fautes byzantines impl´ ementant nos principes de conception au consensus original utilis´ e par le protocole PBFT [21].

Chapitre 6 : Evaluation du protocole ER-PBFT. Ce chapitre est d´ edi´ e ` a l’´ evaluation de notre protocole ER-PBFT. Nous effectuons plusieurs comparaisons face aux protocoles de BFT robustes existants, afin de d´ emon- trer l’efficacit´ e et la robustesse d’ER-PBFT. Nous confrontons par la suite notre protocole aux diverses attaques consid´ er´ ees dans le chapitre 4.

Chapitre 7 : Conception du protocole ER-COP. Ce chapitre pr´ e- sente ER-COP, un nouveau protocole de BFT impl´ ementant nos principes de conception, ainsi que de nombreuses optimisations d´ edi´ ees ` a la performance.

ER-COP s’inspire respectivement des concepts de parall´ elisation utilis´ es par le protocole COP, propos´ e par Behl et al. [16].

Chapitre 8 : Evaluation du protocole ER-COP. Dans ce chapitre, nous comparons ER-COP au protocole COP original, afin d’´ evaluer le sur- coˆ ut de notre politique de robustesse. Finalement, une ´ evaluation d’ER-COP en pr´ esence de divers comportements byzantins nous permet de d´ emontrer la capacit´ e de notre protocole ` a tol´ erer ces attaques.

Chapitre 9 : Conclusions et Perspectives. Pour clore ce manuscrit,

nous dressons un bilan g´ en´ eral, puis nous pr´ esentons plusieurs perspectives

envisageables quant ` a la poursuite de ces travaux.

Chapitre 2

Etat de l’Art

Sommaire

2.1 Contexte . . . . 14

2.1.1 Duplication de Machines ` a Etats . . . . 14

2.1.1.1 Machines ` a Etats . . . . 15

2.1.1.2 Vue d’Ensemble . . . . 15

2.1.1.3 Le Probl` eme du Consensus . . . . 18

2.1.2 Tol´ erance aux Fautes Byzantines . . . . 19

2.1.2.1 Le Probl` eme des G´ en´ eraux Byzantins . . . . 19

2.1.2.2 Mod` ele de Fautes Byzantines . . . . 21

2.1.2.3 PBFT : une Tol´ erance aux Fautes Byzantines Pratique . . . . 21

2.2 Cat´ egorisation des Protocoles de Tol´ erance Aux Fautes Byzantines . . . . 25

2.2.1 Optimisation des Performances en Absence de Faute . 25 2.2.1.1 Protocoles Sp´ eculatifs . . . . 25

2.2.1.2 Protocoles Evolutifs . . . . 29

2.2.1.3 Virtualisation et Parall´ elisme . . . . 32

2.2.1.4 Reformulation du Probl` eme . . . . 34

2.2.2 Minimisation de l’Impact des Comportements Byzantins 38 2.2.2.1 Comportements Byzantins . . . . 38

2.2.2.2 Protocole Robustes . . . . 39

2.3 Synth` ese . . . . 45

Nous introduisons dans ce chapitre les concepts de duplication de machines

`

a ´ etats et de tol´ erance aux fautes byzantines (section 2.1). Ces concepts sont mis en pratique via des protocoles de tol´ erance aux pannes dont la fonction consiste ` a masquer l’occurrence de fautes arbitraires. S’en suit une caract´ e- risation des diff´ erentes contributions de l’´ etat de l’art. Nous r´ epartissons ces contributions selon leurs deux principaux objectifs : l’optimisation des perfor- mances en absence de faute (cf. section 2.2.1), et la d´ epr´ eciation de l’impact des comportements byzantins (cf. section 2.2.2). Nous pr´ esentons les princi- pales caract´ eristiques de nombreux protocoles en d´ etail, ainsi que les directions de recherches emprunt´ ees dans le contexte g´ en´ erique de la tol´ erance aux fautes byzantines.

2.1 Contexte

Nous pr´ esentons dans ce chapitre les concepts de duplication de machines

`

a ´ etats et de tol´ erance aux fautes byzantines. Nous introduisons d’abord le concept de machine ` a ´ etats, ainsi que son utilisation pratique dans le cadre des protocoles de duplication. Nous d´ ecrivons par la suite le probl` eme du consensus, qui t´ emoigne des principaux enjeux abord´ es par la duplication, ainsi que son adaptation au mod` ele de fautes byzantines. Nous clˆ oturons ce chapitre par l’illustration des concepts associ´ es au protocole PBFT [21], le premier protocole destin´ e ` a fournir une solution pratique et efficace face ` a l’occurrence de fautes byzantines.

2.1.1 Duplication de Machines ` a Etats

La duplication de machines ` a ´ etats (SMR pour State Machine Replication) est une technique permettant l’impl´ ementation de services tol´ erants les pannes via leurs duplications sur un ensemble de serveurs [45, 63, 64]. Sp´ ecifiquement, plusieurs copies d’un service sont d´ eploy´ ees sur diff´ erents nœuds qui commu- niquent entre eux par l’interm´ ediaire de protocoles d´ edi´ es. Cette approche repose essentiellement sur la coop´ eration des diff´ erents r´ eplicas, connect´ es par un r´ eseau de communications. Une telle technique permet de masquer l’oc- currence de fautes en tout genre, afin d’assurer le disponibilit´ e du service.

N´ eanmoins, la duplication de machine ` a ´ etats ` a elle seule ne permet pas d’as- surer une tol´ erance aux pannes ; elle doit en effet ˆ etre associ´ ee ` a un protocole de communication, charg´ e d’assurer la coh´ erence entre les ´ etats des r´ eplicas.

Le protocole de communication, associ´ e au nombre de r´ eplicas utilis´ es permet

de d´ efinir le degr´ e de tol´ erance du syst` eme.

2.1. Contexte 15

2.1.1.1 Machines ` a Etats

Une machine ` a ´ etats consiste en la repr´ esentation d’un syst` eme sous forme d’automate. Une telle repr´ esentation facilite la mod´ elisation de nombreux sys- t` emes, et permet d’en simplifier l’´ etude. Le fonctionnement d’une machine ` a

´

etats repose sur deux concepts essentiels : celui d’´ etat et celui de transition.

Un ´ etat d´ ecrit la configuration d’un syst` eme. Une transition est une s´ equence d’instructions ` a ex´ ecuter lorsqu’une condition particuli` ere est remplie, ou lors- qu’un ´ ev´ enement sp´ ecifique survient. Une machine ` a ´ etats est donc caract´ eris´ ee par un ensemble d’´ etats et un ensemble de transitions (cf. figure 2.1).

Figure 2.1 – Illustration d’une machine ` a ´ etats, compos´ ee de deux ´ etats distincts

Une machine ` a ´ etats peut ˆ etre utilis´ ee pour mod´ eliser des syst` emes d´ eter- ministes ou non. Dans le cadre d’une tol´ erance aux pannes via duplication, notre focus se tourne vers les machines ` a ´ etats d´ eterministes. Une machine de ce type empruntera toujours la mˆ eme transition lors de l’occurrence d’un

´

ev´ enement sp´ ecifique depuis un ´ etat donn´ e. Cette caract´ eristique permet de garantir la coh´ erence des ´ etats de plusieurs copies du syst` eme lorsque ceux-ci empruntent les mˆ emes transitions depuis les mˆ emes ´ etats.

2.1.1.2 Vue d’Ensemble

La duplication de machines ` a ´ etats consiste donc en l’utilisation de plu- sieurs copies d’un service (cf. figure 2.2). Chacune de ces copies, appel´ ee r´ e- plica, est impl´ ement´ ee sous la forme d’une machine ` a ´ etats d´ eterministe. Le nombre de r´ eplicas requis d´ epend de la nature des fautes ` a tol´ erer, ainsi que de leur nombre d’occurrences simultan´ ees.

Consid´ erons N le nombre total de r´ eplicas pr´ esents dans le syst` eme. Intui-

tivement, la duplication de machines ` a ´ etats ne saurait tol´ erer plus de N − 1

r´ eplicas fautifs simultan´ ement. En pratique, pour un nombre f de r´ eplicas fau-

tifs, le nombre total de r´ eplicas N d´ epend de la nature des fautes ` a tol´ erer. Par

exemple, N = 2f +1 r´ eplicas sont suffisants pour tol´ erer l’arrˆ et inopin´ e (crash)

de f r´ eplicas [49], alors que N = 3f + 1 r´ eplicas sont n´ ecessaires pour tol´ erer

l’occurrence de f fautes byzantines [21, 22, 49]. Ainsi, tol´ erer l’occurrence de plusieurs fautes simultan´ ement requiert l’utilisation de davantage de r´ eplicas.

Dans le contexte de la duplication de machines ` a ´ etats, le nombre total de r´ eplicas N est fonction du nombre maximal de r´ eplicas fautifs simultan´ ement f .

Figure 2.2 – Duplication de machines ` a ´ etats. Le syst` eme est compos´ e de 4 r´ eplicas (impl´ ementant des machines ` a ´ etats d´ eterministes) et d’un protocole de communication

Afin d’assurer l’ind´ ependance de l’occurrence de fautes entre r´ eplicas, il est pr´ econis´ e de recourir au paradigme de N-version programming [11, 12, 23].

Ce paradigme implique le recours ` a diff´ erentes impl´ ementations du protocole utilis´ e sur chacune des r´ eplicas. Une telle technique est destin´ ee ` a diss´ eminer l’impact d’hypoth´ etiques erreurs de programmation, afin d’´ eviter ` a un bug de se voir d´ eclencher sur plusieurs r´ eplicas ` a la fois. Dans une mˆ eme optique, l’utilisation de mat´ eriels divers, associ´ es ` a diff´ erents syst` emes d’exploitation, contribue ` a minimiser l’improbable occurrence de plusieurs fautes simultan´ e- ment. Lorsqu’un r´ eplica se voit victime de l’occurrence d’une faute, plusieurs m´ ecanismes lui permettent de retrouver un ´ etat coh´ erent, parmi lesquelles la mise en place de points de sauvegarde (checkpoints), ou encore le partage de l’historique des ´ ev´ enements locaux (local histories) de chaque r´ eplica [22].

L’´ etat du service dupliqu´ e ´ evolue suite ` a la r´ eception de requˆ etes, trans-

mises par les utilisateurs (´ egalement nomm´ es clients). Ces requˆ etes engendrent

l’ex´ ecution de s´ equences d’instructions, qui permettent aux r´ eplicas d’´ evoluer

vers des ´ etats futurs. Afin d’assurer la p´ erennit´ e du syst` eme dupliqu´ e, la du-

plication de machines ` a ´ etats doit assurer deux propri´ et´ es distinctes : la sˆ uret´ e

(safety) et la vivacit´ e (liveness), d´ efinie ci-dessous :

2.1. Contexte 17

— Sˆ uret´ e. L’´ etat de chaque r´ eplica correct doit ´ evoluer en ad´ equation avec l’´ etat des autres r´ eplicas corrects. Le syst` eme dupliqu´ e dans sa globa- lit´ e doit donc ´ evoluer comme le ferait un mˆ eme syst` eme non-dupliqu´ e exempt de faute.

— Vivacit´ e. Toute requˆ ete instanci´ ee par un utilisateur correct doit ˆ etre ex´ ecut´ ee. L’indubitable ex´ ecution de chaque requˆ ete valide permet au syst` eme dupliqu´ e de conserver sa capacit´ e ` a progresser dans des ´ etats futurs.

Plus sp´ ecifiquement, Schneider d´ etermine que la duplication de machines

`

a ´ etats doit r´ epondre ` a trois imp´ eratifs [64], n´ ecessaires afin d’assurer une

´

evolution coh´ erente de l’´ etat des diff´ erents r´ eplicas ; (i) La coh´ erence de l’´ etat partag´ e initialement entre chaque r´ eplica se doit d’ˆ etre garantie. (ii) Chaque r´ e- plica doit g´ en´ erer le mˆ eme r´ esultat suite ` a l’ex´ ecution d’une mˆ eme instruction.

(iii) Chaque r´ eplica doit ex´ ecuter les instructions dans le mˆ eme ordre. Afin de forcer l’ex´ ecution des requˆ etes dans le mˆ eme ordre, nombre de protocoles requi` erent la pr´ esence d’un r´ eplica sp´ ecifique, d´ enomm´ e primary ou leader.

Ce primary sera tout d’abord charg´ e d’associer ` a chaque requˆ ete l’ordre dans lequel elle se devra d’ˆ etre ex´ ecut´ ee, puis diffusera cette information aux autres r´ eplicas. S’accorder sur la validit´ e de cet ordre d’ex´ ecution repr´ esente l’essence mˆ eme du probl` eme, la diffusion d’une telle information requiert donc l’utilisa- tion d’une primitive de communication d´ edi´ ee, nomm´ ee diffusion ` a ordre total (total-order broadcast ou atomic broadcast ) [30, 39]. Cette primitive doit as- surer la r´ eception fiable des messages par tous les participants. Pour ce faire, elle doit fournir plusieurs propri´ et´ es : (i) Si un r´ eplica correct diffuse un mes- sage, tous les r´ eplicas corrects recevront ce message. (ii) Si un r´ eplica correct ex´ ecute une s´ equence d’instructions suite ` a la r´ eception d’un message, tous les r´ eplicas corrects ex´ ecuteront cette s´ equence d’instructions. (iii) Chaque s´ e- quence d’instructions n’est ex´ ecut´ ee qu’une seule fois, et seulement suite ` a la r´ eception du message associ´ e. (iv) Si deux r´ eplicas r1 et r2 ex´ ecutent deux s´ e- quences d’instructions i1 et i2 suite ` a la r´ eception de deux messages distincts m1 et m2, r1 n’ex´ ecute i1 avant i2 si et seulement si r2 ex´ ecute lui aussi i1 avant i2.

Il existe deux approches fondamentales quant ` a l’ex´ ecution des instructions

par les r´ eplicas. Dans le premier cas, tous les r´ eplicas ex´ ecutent eux-mˆ eme les

requˆ etes, ce type de duplication est appel´ e duplication active (cf. figure 2.3)

[44]. Dans le second cas, un sous-ensemble de r´ eplicas ex´ ecute les requˆ etes, puis

transmet les modifications apport´ ees aux r´ eplicas restants, il s’agit de dupli-

cation dite passive (cf. figure 2.4) [6]. L’utilisation de la duplication passive

peut se r´ ev´ eler probl´ ematique selon la nature des fautes auxquelles le syst` eme

est confront´ e. Si par exemple un unique r´ eplica est responsable de l’´ ex´ ecution

Figure 2.3 – Exemple de duplication de machines ` a ´ etats active

Figure 2.4 – Exemple de duplication de machines ` a ´ etats passive des requˆ etes, et d´ ecide de transmettre des modifications erron´ ees aux autres r´ eplicas, la coh´ erence du syst` eme tout entier se voit remise en question. Nous discutons ce genre de comportements byzantins en d´ etail dans la section 3.1.

2.1.1.3 Le Probl` eme du Consensus

Nous avons mentionn´ e dans la section pr´ ec´ edente la n´ ecessit´ e d’une primi- tive de communication d´ edi´ ee ` a la diffusion de l’ordre d’ex´ ecution des requˆ etes.

En pratique, le choix et la diffusion de l’ordre dans lequel les requˆ etes doivent ˆ

etre ex´ ecut´ ees peut ˆ etre assimil´ e au probl` eme du consensus. Ce probl` eme re- pr´ esente un challenge fondamental dans le contexte g´ en´ erique des syst` emes distribu´ es : plusieurs processus (il s’agit dans notre cas des r´ eplicas) doivent s’accorder sur le choix d’une valeur unique. Afin d’assurer la fiabilit´ e d’un protocole s’attaquant au probl` eme du consensus, il doit fournir les propri´ et´ es suivantes : (i) la valeur choisie doit avoir ´ et´ e propos´ ee par un r´ eplica correct, (ii) deux r´ eplicas corrects ne peuvent pas choisir une valeur diff´ erente, (iii) un r´ eplica correct ne se prononce qu’en faveur d’une unique valeur, (iv) une valeur doit ˆ etre choisie ` a terme.

Le th´ eor` eme ´ enonc´ e par Fischer, Lynch et Patterson [34], connu en tant que

FLP impossibility result d´ etermine que la r´ esolution du probl` eme de consensus

est impossible dans un environnement asynchrone en pr´ esence d’un processus

fautif. Ce constat est une cons´ equence de l’incapacit´ e ` a diff´ erencier un pro-

cessus fautif d’un r´ eseau d´ efectueux. Consid´ erons par exemple un processus p

2.1. Contexte 19

en attente d’un message m qui lui est n´ ecessaire pour progresser dans un ´ etat futur. Il est impossible pour p de d´ eterminer si l’´ emetteur de m est fautif, ou si le r´ eseau est responsable de l’absence de m. Afin de r´ esoudre ce probl` eme, p peut soit d´ ecider d’attendre davantage, soit d´ ecider de choisir une valeur sans le message m. Quelle que soit la d´ ecision prise par p, les propri´ et´ es n´ ecessaires pour garantir le succ` es du consensus ne sont plus respect´ ees. Afin d’apporter des solutions pratiques au probl` eme du consensus, de nouvelles hypoth` eses relatives ` a la fiabilit´ e du r´ eseau et ` a la nature des fautes rencontr´ ees furent consid´ er´ ees [33, 50]. Les premi` eres tentatives pour r´ epondre au probl` eme de consensus d’un point de vue pratique furent propos´ ees il y a de cela 25 ans, dans le contexte des bases de donn´ ees distribu´ ees [36, 69]. Depuis, de nom- breux travaux on ´ et´ e effectu´ es dans ce domaine, parmi lesquels les protocoles de la famille Paxos tol´ erants les arrˆ ets inopin´ es (crashs)[19, 46, 54], et les pro- tocoles d´ edi´ es ` a la tol´ erance aux fautes byzantines [4, 21, 28]. C’est vers cette seconde cat´ egorie de protocoles que se tourne notre int´ erˆ et.

2.1.2 Tol´ erance aux Fautes Byzantines

Alors que la duplication offre une solution ad´ equate pour assurer un haut degr´ e de fiabilit´ e dans les services d’informatique en nuage, la nature des me- naces auxquelles ceux-ci se voient confront´ es ne cesse de se diversifier. Il est primordial pour les fournisseurs de garantir le fonctionnement des services h´ e- berg´ es quelque soit la nature des pannes rencontr´ ees. Ainsi, il est n´ ecessaire de disposer de m´ ecanismes permettant de tol´ erer l’occurrence de fautes logi- cielles, crashs, pertes de messages ou encore de comportements malveillants remettant en cause la qualit´ e de service fournie par le syst` eme. Alors que les protocoles comme Paxos [47] permettent de faire face ` a des fautes b´ enignes (fail-stop) [48, 58], tol´ erer un panel de fautes plus large n´ ecessite le recours

`

a une classe de protocoles particuliers, nomm´ es protocoles de tol´ erance aux fautes byzantines. Ces protocoles sont en effet destin´ es ` a assurer la p´ erennit´ e du service dupliqu´ e face ` a toutes sortes de dysfonctionnements. Nous ferons par la suite r´ ef´ erence ` a ces dysfonctionnements en tant que fautes arbitraires, ou byzantines.

2.1.2.1 Le Probl` eme des G´ en´ eraux Byzantins

Le probl` eme abord´ e par ces protocoles fut pr´ esent´ e en 1982 par Lamport sous l’appellation de probl` eme des g´ en´ eraux byzantins [50]. Il fait r´ ef´ erence

`

a une instance particuli` ere du probl` eme de consensus et s’´ enonce de la ma-

ni` ere suivante : A l’or´ ee d’une bataille, tous les g´ en´ eraux d’une arm´ ee doivent

s’accorder sur une d´ ecision commune pour remporter la victoire : attaque ou

retraite. Ceux-ci ne peuvent communiquer que par l’interm´ ediaire de messa- gers, et un certain nombre de g´ en´ eraux peuvent s’av´ erer ˆ etre des traˆıtres, dont l’objectif est de fausser le plan de bataille. Concr` etement, consid´ erons qu’un premier g´ en´ eral loyal estime que l’attaque doit ˆ etre men´ ee, et qu’un second g´ en´ eral loyal estime que la retraite serait pr´ ef´ erable. Si un troisi` eme g´ en´ eral malveillant se prononce en faveur de l’attaque aupr` es du premier, et en faveur de la retraite aupr` es du second, seul le premier g´ en´ eral attaquera, alors que les deux g´ en´ eraux loyaux penseront s’ˆ etre accord´ es sur la marche ` a suivre.

Ce probl` eme est d’autant plus difficile ` a r´ esoudre compte tenu du mode de communication par messagers, car ceux-ci peuvent potentiellement ´ echouer ` a d´ elivrer les messages, ce qui ne serait pas le cas si les g´ en´ eraux s’accordaient de vive voix. La figure 2.5 illustre une instance du probl` eme des g´ en´ eraux byzantins impliquant trois g´ en´ eraux : si un g´ en´ eral malveillant remet en cause la parole d’un autre g´ en´ eral, il est impossible pour le troisi` eme de d´ eterminer qui dit la v´ erit´ e.

Figure 2.5 – Le dilemne des g´ en´ eraux byzantins : au vu des informations qui lui parviennent, le g´ en´ eral N ° 3 ne sait pas si le traˆıtre est le g´ en´ eral N ° 1 ou le g´ en´ eral N ° 2

Dans de telles conditions, obtenir un consensus en pr´ esence de f traˆıtres

n’est possible que si le nombre total de g´ en´ eraux N est suffisamment ´ elev´ e,

respectivement si N > 3f , et si les g´ en´ eraux s’´ echangent les propositions des

autres protagonistes. Une logique analogue s’applique au contexte de duplica-

tion de machine ` a ´ etats, o` u une proportion de r´ eplicas malveillants cherche ` a

corrompre la coh´ erence des r´ eplicas corrects. Un tel comportement est donc

reconnu en tant que comportement byzantin. Dans le cadre d’un syst` eme dis-

2.1. Contexte 21

tribu´ e, est consid´ er´ e comme comportement byzantin tout comportement ne r´ epondant pas aux sp´ ecifications du syst` eme, tels l’envoi de messages corrom- pus, la g´ en´ eration de r´ eponses incorrectes, ou toutes tentatives de d´ eni de service telle la saturation de bande passante (flooding).

2.1.2.2 Mod` ele de Fautes Byzantines

Pour r´ esumer, le nombre de r´ eplicas requis afin d’assurer la fiabilit´ e d’un syst` eme d´ epend intrins` equement des hypoth` eses induites par l’environnement consid´ er´ e. Ainsi, la nature des fautes envisag´ ees ou encore le degr´ e de fiabilit´ e du r´ eseau influencent consid´ erablement la conception des protocoles de tol´ e- rance aux pannes [52]. Dans le cadre mˆ eme de la tol´ erance aux fautes byzan- tines, un large ´ eventail d’hypoth` eses peut ˆ etre ´ etabli. Le protocole OBFT [66], contrairement ` a ses pairs, consid` ere que les clients ne peuvent ˆ etre instigateurs de comportements byzantins. Dans une mˆ eme optique, certains protocoles re- qui` erent la pr´ esence de composants fiables sur chaque r´ eplica [27, 40, 72], remaniant ainsi la nature du probl` eme trait´ e.

Nous d´ ecrivons ci-dessous le mod` ele consid´ er´ e dans ce manuscrit, ce mo- d` ele pr´ esente les hypoth` eses commun´ ement admises dans l’´ etat de l’art. Le syst` eme est compos´ e de N r´ eplicas, dont au plus f peuvent ˆ etre responsables de comportements byzantins. Une quantit´ e ind´ etermin´ ee de clients peut elle aussi ˆ etre l’instigatrice de comportements byzantins. L’ensemble de ces nœuds malveillants, qu’il s’agisse de clients ou de r´ eplicas, peuvent collaborer afin d’endommager le syst` eme dupliqu´ e. Il est toutefois impossible pour un nœud malveillant d’usurper l’identit´ e d’un nœud correct. Autrement dit, un nœud malveillant est incapable de contrefaire un code d’authentification de message, une signature, ou tout autre m´ ecanisme d’authentification utilis´ e. Le r´ eseau est ultimement synchrone, soit asynchrone avec des intervalles de synchronie du- rant lesquels les messages se verront d´ elivr´ es. Ces p´ eriodes de synchronies sont n´ ecessaires afin d’assurer la propri´ et´ e de vivacit´ e. Le r´ eseau respecte ´ egalement les propri´ et´ es du mod` ele d’Aguilera et al. [5] : les canaux de communication ne peuvent pas cr´ eer de message, mais peuvent dupliquer, corrompre, ou perdre les messages ´ echang´ es.

2.1.2.3 PBFT : une Tol´ erance aux Fautes Byzantines Pratique

En 1999, Miguel Castro et Barbara Liskov propos` erent PBFT[21, 22], la

premi` ere tentative pratique destin´ ee ` a offrir un protocole de duplication tol´ e-

rant l’occurrence de fautes byzantines en conditions r´ eelles. PBFT impl´ emente

en effet tout un ensemble de techniques permettant de r´ eduire le surcoˆ ut li´ e ` a la

duplication. Ce protocole garantit les propri´ et´ es de sˆ uret´ e et de vivacit´ e dans

un environnement ultimement synchrone. Il n´ ecessite pour ce faire N = 3f + 1 r´ eplicas pour tol´ erer la pr´ esence de f r´ eplicas fautifs simultan´ ement. Ce pro- tocole fait partie de la classe des protocoles de duplication active (tous les r´ eplicas ex´ ecutent manuellement chaque requˆ ete) et requiert la pr´ esence d’un primary en charge d’assurer l’ex´ ecution coh´ erente des requˆ etes sur chaque r´ e- plica. Le primary associe ` a chaque requˆ ete un ordre dans lequel elle se devra d’ˆ etre ex´ ecut´ ee. Les r´ eplicas restants (backups) doivent ensuite s’accorder sur l’ordre propos´ e. Si un consensus est obtenu, les requˆ etes seront donc toutes ex´ ecut´ ees dans le mˆ eme ordre sur chaque r´ eplica correct. Afin d’assurer la p´ e- rennit´ e du syst` eme en pr´ esence d’un primary malveillant, PBFT impl´ emente

´

egalement un m´ ecanisme de changement de vues (view-change ) permettant de remplacer le primary courant. Enfin, chacun des messages ´ echang´ es se voit sauvegard´ e par les r´ eplicas, afin de permettre ` a ceux-ci de recouvrir un ´ etat coh´ erent en cas de probl` eme.

Figure 2.6 – Mod` ele de communication de PBFT

Consensus. Le consensus effectu´ e par PBFT est pr´ esent´ e dans la figure 2.6.

Celui-ci est initi´ e par l’envoi d’une requˆ ete de la part d’un client au primary

(REQUEST). Cette requˆ ete doit ˆ etre authentifi´ ee afin d’assurer un contrˆ ole

d’acc` es au service dupliqu´ e. Le consensus d´ ebute lorsque le primary associe ` a la

requˆ ete re¸cue un num´ ero de s´ equence unique, qu’il diffuse ensuite aux backups

par l’interm´ ediaire d’un message PRE-PREPARE. Lors de la r´ eception d’un

message PRE-PREPARE, les backups prennent d` es lors connaissance de la

requˆ ete envoy´ ee par le client, ainsi que du num´ ero de s´ equence qui lui fut affili´ e

par le primary. La prochaine ´ etape du consensus consiste en la diffusion de

ce num´ ero de s´ equence par l’ensemble des backups (PREPARE). Cette ´ etape

permet ` a chacun des r´ eplicas de poss´ eder une vision globale des num´ eros de

s´ equence locaux associ´ es ` a la requˆ ete. Elle permet donc ` a chaque r´ eplica de

connaˆıtre d’hypoth´ etiques divergences quant aux num´ eros de s´ equence envoy´ es

par le primary. Lorsqu’un r´ eplica re¸coit suffisamment de messages PREPARE

(2f ) corroborant le num´ ero de s´ equence contenu dans le PRE-PREPARE re¸cu

2.1. Contexte 23

pr´ ec´ edemment, il peut conclure que 2f + 1 r´ eplicas se sont accord´ es sur un mˆ eme num´ ero de s´ equence, et diffuse un message COMMIT ` a tous les r´ eplicas.

Finalement, lorsqu’un r´ eplica re¸coit 2f + 1 messages COMMIT, il peut d` es lors ex´ ecuter la requˆ ete et r´ epondre au client. Un quorum de 2f + 1 r´ eplicas s’accordant sur un unique num´ ero de s´ equence est n´ ecessaire. En effet, un quorum de cette taille implique la pr´ esence d’au moins f + 1 r´ eplicas corrects qui consid` erent ce num´ ero de s´ equence comme ´ etant valide, rendant ainsi impossible le choix d’un num´ ero de s´ equence diff´ erent par d’autres r´ eplicas corrects (cf. figure 2.7).

Figure 2.7 – l’utilisation de quorums de taille 2f + 1 rend impossible la vali- dation de deux requˆ etes diff´ erentes associ´ ees ` a un mˆ eme num´ ero de s´ equence.

Seuls f parmi les f + 1 r´ eplicas peuvent ˆ etre fautifs : le r´ eplica correct ne peux pas se prononcer en faveur des deux requˆ etes

Changement de vues. Une vue repr´ esente la configuration du protocole de BFT ` a un instant donn´ e, elle nous renseigne sur l’identit´ e du primary, et par cons´ equent des backups. Afin d’assurer la continuit´ e du service dupliqu´ e en pr´ esence d’un primary malveillant, PBFT a recours ` a l’utilisation d’un m´ e- canisme de changement de vues. Ce m´ ecanisme a pour fonction de remplacer un primary d` es lors que ce dernier ne remplit plus son rˆ ole d’ordonnanceur.

Un changement de vue se voit d´ eclench´ e lorsque plusieurs conditions sont

remplies. Tout d’abord, si un client ne re¸coit pas une r´ eponse attendue, il re-

transmet sa requˆ ete, mais la destine cette fois ci ` a tous les r´ eplicas (` a la fois au

primary et aux backups). Lorsqu’un backup re¸coit une requˆ ete, il fait suivre

cette requˆ ete au primary et d´ emarre un minuteur d´ edi´ e. Si le primary est

innocent, la requˆ ete se verra ex´ ecut´ ee avant l’expiration du minuteur. Dans le

cas contraire, le backup d´ eclenche un changement de vue en diffusant un mes-

sage VIEW-CHANGE ` a tous les r´ eplicas, et cesse de participer aux consensus

instigu´ es par le primary actuel. Si suffisamment de backups estiment que le

comportement du primary ne r´ epond plus aux sp´ ecifications du syst` eme, il leur

sera possible de collecter 2f + 1 messages VIEW-CHANGE, soit le nombre suffisant pour r´ evoquer le primary actuel en faveur d’un nouveau primary.

Optimisations. Si PBFT fut reconnu comme le premier protocole de tol´ e- rance aux fautes byzantines pratique, ceci est dˆ u au faible surcoˆ ut engendr´ e par le protocole de duplication face ` a ses pr´ ed´ ecesseurs [41, 59]. PBFT im- pl´ emente l’optimisation de batching (traitement de lots de requˆ etes), soit la capacit´ e d’ordonner plusieurs requˆ etes via l’utilisation d’un unique message PRE-PREPARE. Cette optimisation permet de cr´ eer, d’authentifier, de trans- mettre et de v´ erifier moins de messages. Contrairement ` a ses pr´ ed´ ecesseurs, l’authentification des messages ´ echang´ es par PBFT n’est plus r´ ealis´ ee grˆ ace ` a l’utilisation de signatures digitales mais de codes d’authentification de mes- sages (MACs). Les processus de g´ en´ eration et de v´ erification d’un MAC n´ eces- sitent une quantit´ e de calcul tr` es inf´ erieure ` a ces mˆ emes op´ erations r´ ealis´ ees via signatures digitales, ce qui permet au protocole de fournir de meilleures performances pratiques. Si la taille des requˆ etes est trop importante, le client lui-mˆ eme est charg´ e de les faire parvenir aux diff´ erents r´ eplicas, afin d’´ evi- ter une surcharge du r´ eseau. De plus, d` es lors qu’une requˆ ete est parvenue ` a l’ensemble des r´ eplicas, celle-ci est remplac´ ee par son empreinte (digest). L’uti- lisation d’empreintes est ´ egalement pl´ ebiscit´ ee lors de l’envoi des r´ eponses aux clients. Ainsi, un unique r´ eplica correct peut envoyer la r´ eponse compl` ete, alors que les autres r´ eplicas peuvent se contenter d’envoyer l’empreinte concordante.

PBFT utilise ´ egalement le protocole de communication UDP, ainsi que la pri-

mitive de multi-diffusion (multicast ), ce qui contribue ´ egalement ` a r´ eduire le

trafic r´ eseau. Enfin, PBFT propose l’ex´ ecution provisoire de requˆ etes (tenta-

tive execution ). Il autorise ainsi les r´ eplicas ` a ex´ ecuter les requˆ etes d` es la fin

de l’´ etape PREPARE. Cette optimisation permet de s’affranchir de l’´ etape de

COMMIT, mais peut parfois impliquer le retour ` a un ´ etat pr´ ec´ edent (rollback).

2.2. Cat´ egorisation des Protocoles de Tol´ erance Aux Fautes

Byzantines 25

2.2 Cat´ egorisation des Protocoles de Tol´ erance Aux Fautes Byzantines

L’´ emergence de PBFT suscita l’int´ erˆ et de nombreux chercheurs, et de mul- tiples contributions furent propos´ ees au fil des ans. Celles-ci r´ epondent ` a deux principales th´ ematiques : le besoin d’efficacit´ e et le besoin de robustesse.

2.2.1 Optimisation des Performances en Absence de Faute

La tol´ erance aux fautes byzantines reposant fondamentalement sur les concepts de duplication de machines ` a ´ etats, une des principales pr´ eoccu- pations des chercheurs demeure le fait de masquer au mieux le surcoˆ ut li´ e

`

a cette duplication. Il s’agit en pratique de proposer des solutions permet- tant d’am´ eliorer la performance des protocoles de BFT, tout en conservant les propri´ et´ es de sˆ uret´ e et de vivacit´ e. Lampson pr´ econise qu’un syst` eme se doit d’ˆ etre rapide dans des conditions normales, et qu’il se doit de r´ ealiser des progr` es dans des conditions hostiles [51]. C’est en partageant cette op- tique que nombre de chercheurs se propos` erent d’am´ eliorer la performance des protocoles de BFT en se focalisant sur les p´ eriodes pendant lesquelles le syst` eme n’est pas confront´ e ` a l’occurrence de comportements byzantins [4, 18, 27, 28, 37, 38, 40, 43, 57, 68, 70, 73]. Les protocoles efficaces se fixent donc pour objectif d’optimiser les performances du syst` eme en absence de faute. Cela se caract´ erise g´ en´ eralement par le raffinement du mod` ele de com- munication inter-r´ eplicas, ou par l’int´ egration d’optimisations li´ ees ` a l’´ emer- gence de nouvelles technologies telles la virtualisation ou la parall´ elisation. Les protocoles mentionn´ es dans cette section s’inspirant de PBFT, ceux-ci impl´ e- mentent nombre de ses optimisations, en particulier l’utilisation de codes d’au- thentification de messages (MACs) afin de se d´ echarger du coˆ ut des signatures digitales.

2.2.1.1 Protocoles Sp´ eculatifs

les protocoles sp´ eculatifs ex´ ecutent les requˆ etes avant de s’accorder sur

l’ordre dans lequel elles se doivent d’ˆ etre ex´ ecut´ ees [4, 55]. En d’autres termes,

un r´ eplica ex´ ecutera localement les requˆ etes re¸cues sans avoir la certitude

que les autres r´ eplicas les ex´ ecuteront ´ egalement. Un tel paradigme remet en

cause la propri´ et´ e de sˆ uret´ e, car l’´ etat de diff´ erents r´ eplicas peut se r´ ev´ eler

temporairement incoh´ erent. Afin de rem´ edier ` a ce probl` eme, les protocoles

sp´ eculatifs impl´ ementent un m´ ecanisme de rollback, permettant ` a l’ensemble

des r´ eplicas de recouvrir un ´ etat coh´ erent.

Figure 2.8 – Mod` ele de communication de Q/U

Query/ Update (Q/U). Le protocole Query/Update (Q/U) fut pr´ esent´ e en 2005 et se destine ` a fournir un haut niveau de performance en absence de contention [4]. Contrairement ` a la plupart de ses pairs, Q/U requiert l’uti- lisation de 5f + 1 r´ eplicas pour tol´ erer f fautes byzantines. La figure 2.8 pr´ esente son mod` ele de communication, nous y constatons que Q/U n’utilise pas de primary, et qu’il s’affranchit de toute forme de consensus pr´ ec´ edant l’ex´ ecution d’une requˆ ete. Les requˆ etes sont en effet directement envoy´ ees aux r´ eplicas par les clients : les r´ eplicas les ex´ ecutent puis r´ epondent aux clients sans se concerter. Un tel mod` ele de communication implique peu d’´ echanges de messages et peu d’op´ erations d’authentification, il se montre donc parti- culi` erement performant si les conditions demeurent propices. En pr´ esence de contention (deux clients distincts qui envoient leurs requˆ etes au syst` eme de mani` ere concurrente) ou de tout autre ´ ev´ enement remettant en cause la pro- pri´ et´ e de sˆ uret´ e, les r´ eplicas peuvent r´ etablir la coh´ erence de leurs ´ etats via une proc´ edure de synchronisation. Celle-ci se voit d´ eclench´ ee lorsqu’un client ne parvient pas ` a r´ ecolter suffisamment de r´ eponses concordantes. Alors que Q/U parvient ` a r´ eduire consid´ erablement le nombre de messages requis par PBFT, il n’en reste pas moins tr` es vuln´ erable face ` a la contention ou ` a la pr´ esence de clients byzantins. Un client byzantin peut intentionnellement pro- voquer des divergences entre les ´ etats des r´ eplicas corrects via l’´ emission de requˆ etes contradictoires.

Zyzzyva. C’est en 2009 que Kotla et al. introduisirent Zyzzyva. Bien que

sp´ eculatif, Zyzzyva requiert la pr´ esence d’un primary contrairement ` a Q/U

[43]. Ce primary lui permet de tol´ erer efficacement l’occurrence de contention,

sans pour autant imposer le recours ` a un consensus syst´ ematique (cf. figure

2.2. Cat´ egorisation des Protocoles de Tol´ erance Aux Fautes

Byzantines 27

Figure 2.9 – Mod` ele de communication de Zyzzyva

2.9). Le mod` ele de communication de Zyzzyva ´ evolue en pr´ esence d’´ el´ ements fautifs, afin de garantir les propri´ et´ es de sˆ uret´ e et de vivacit´ e. Tout comme son pr´ ed´ ecesseur Q/U, Zyzzyva s’affranchit de l’´ etape de consensus. La pr´ esence d’un primary permet n´ eanmoins d’ordonner chaque requˆ ete de mani` ere cen- tralis´ ee et r´ esout de ce fait les probl` emes associ´ es ` a l’´ emergence de contention (PRE-PREPARE). Il convient de remarquer que, contrairement ` a PBFT (sec- tion 2.1.2.3), les ´ etapes PREPARE et COMMIT ne succ` edent pas ` a l’´ etape d’ordonnancement de Zyzzyva. Il en d´ ecoule une ex´ ecution sp´ eculative des requˆ etes ordonn´ ees par le primary, suivie par l’envoi imm´ ediat des r´ eponses aux clients. Un tel mod` ele de communication s’astreint de tout ´ echange de messages entre backups, les clients se voient donc responsables de maintenir une coh´ erence entre les ´ etats des diff´ erents r´ eplicas. Suite ` a l’´ emission d’une requˆ ete, un client s’attendra ` a recevoir 3f +1 r´ eponses identiques de la part des r´ eplicas. Si le client ne re¸coit pas suffisamment de r´ eponses concordantes, il les collecte puis les retourne aux r´ eplicas par l’interm´ ediaire d’un message COM- MIT, permettant ainsi aux r´ eplicas de prendre connaissance de l’´ etat de leurs pairs et d’´ evoluer en accord. Tout comme PBFT, Zyzzyva impl´ emente lui aussi un m´ ecanisme de changement de vue destin´ e ` a remplacer un primary fautif.

La nature sp´ eculative de Zyzzyva implique plusieurs variations conceptuelles quant ` a sa proc´ edure de changement de vue. En particulier, lorsqu’un r´ eplica se prononce en faveur d’un changement de vue, celui-ci continue d’ex´ ecuter les requˆ etes ordonn´ ees par le primary actuel jusqu’` a son ´ eviction. De plus, l’absence d’un consensus syst´ ematique impose le choix d’un ´ etat commun afin d’assurer l’initialisation coh´ erente de la vue ` a venir. Alors que Zyzzya parvient

`

a tol´ erer efficacement la pr´ esence de contention, il demeure particuli` erement vuln´ erable face aux attaques engendr´ ees par des clients byzantins. Un client malveillant peut par exemple forcer la g´ en´ eration de messages COMMIT afin d’entraˆıner le protocole dans une succession d’´ echanges de messages inutiles.

La pr´ esence de clients byzantins est d’autant plus dangereuse si ceux-ci col-

laborent avec un primary malveillant. L’absence de consensus permet ` a un

primary fautif de provoquer intentionnellement une divergence entre les ´ etats