Professional Documents
Culture Documents
Linux Magazine N°231 Novembre 2019 PDF
Linux Magazine N°231 Novembre 2019 PDF
0, 1/ St te candon ext euptcteur 28 | msn emigre te robotl.exp gainl/4; DApp sur le réseau Ethereum. Dans robot2.exp += gain2/2; notre cas, on ne va pas la faire migret bank [robot user] sur la vraie Blockchain Ethereum, car bank [robot2.user) ‘ela nous demanderait un vrai compte cet de vrais Ethers. On va plutot utiliser Ganache. Souvenez-vous que dans le Af (bank [robot user] < 200 ) _initializeaccount (rebotl user) ; ai CU msissas rests tasee ese eet eee fichier truffle-config.js, on a confi- ) guré un seul réseau (development) et else ( // Si le random est égal & 1a limite alors il y | _ si vous voulez migrer votre contrat sur a match nul Ethereum, vous allez devoir configu- robotl.exp += gainl/4 rer le réseau Ethereum dans le fichier robot2.exp += gain2/4: enit EndGane (robot! user, robot2.user, true) ; ) Pour faire une migration de notre smart contrac, il faut avoir créé un fichier de migration. Dans le dossier snigration il existe par défaut le fichier 1 initial_migration.js,ilsagit du fichier qui fat la migration du smart function fight() external requireAccount ( contract du fichier Migrations.sot if (fighter = 0) { // Lorsqu'il n'y a personne qui contenu dans le dossier contracts. size combattre fighter = userToRobot (msg. sender] truffle-config.js. ) Maintenant, on va définir une derniére fonction fight dans le smart contract RobotFight qui est disponible a Textérieur et qui permet 2 un joueur de fire tune demande de combat Voici le code contenu dans ce fichier else { // Lorsqu'il y a une personne qui désire const Migrations = artifacts. require ("Migrations combattre module.exports Af (fighter != userToRobot {msg.sender]) { // 11 faut function (deployer) ( stassurer que ce ne soit pas 1a méne personne qui deployer deploy (Migrations) ; désize le combat , Robot storage robot = robots userToRobot [msg. sender] - 1); Laméthode artifacts require() Robot storage robot2 ore Lansacer iat permet de créer un objet représentant int diff = int(robot1.exp) - int (robot2.exp) tun smart contract. Le paramétre Migra- if (ditt 0) // robot1 a moins d'expérience tions passé dans cette méthode est le _fight(robot1, robot2) ; ‘nom du smart contract qu'on souhaite else // robot! a plus d'expérience {aie migrer. Fits attention iIne ‘agit fight (robot2, robot) ; pas du nom du fichier, mais plutot le fighter = 0; // On réinitialise 1a valeur de from ch smartcondrack contenu [dan EUascaciea niin yctaissldctesaes tear un des fichiers du dossier contracts. iy La fonction module.exports qui est ) définie est la fonction qui sera exécu- tée lors de la migration. Elle prend un Super ! On a fini : notre DApp est enfin complete, on a écrit toutes les _ paramatre qui est deployer. Ce para~ fonctions et nos joueurs peuvent maintenant créer un compte, entrainer leurs métre est le médiateur entre JavaScript robots, changer le nom de leur robot et combattre. et Solidity, Cest ce parametre qui www.ed-diamond.com GNU/Linux Magazine France N°231 reyBLOCKCHAIN ACTUS & HUMEUR permet de faire le déploiement et aussi dienvoyer des pa~ Fametres au constructeur du smart contract que lon sou- haite déployer,siceluici en a besoin (dans notre cas, notre constructeur ma pas besoin de paramatres). Pour passer les parametres du constructeur, on les place comme pata: metres a la méthode deployer.deploy() ‘Avant de lancer le processus de migration, on va d'abord créer notre fichier de migration, qui va faire la migration de notre smart contract Cette commande va créer un fichier JavaScript dans le dossier migrations, dont le nom commence parle times {amp au moment de Vexécution de la commande. lest im- portant que les noms des fichiers dans ce dossier soient préfixés par un nombre, car ce nombre représente Fordre exécution de ces fichiers lors du processus de migration. Et voic le code de migration const RobotFight = artifacts require ("RobotFight") module.exports = function (deployer) ( deployer dep loy (RobotFight) bb Une fois que le code est présent, on va exécuter la com- ‘mande de migration, Et voici ce quill faut exécuter dans le terminal Si on veut spécifie le réseau sur lequel on veut migrer notre smart contract, on utilise le parametre network. Par exemple, imaginons que nous ayons defini un autre réseau nommé net dans le fichier truffle-config.js, alors pour spécifier Ie réseau sur lequel on souhaite migret, on va ta- per la commande suivante Quand on ne précise rien, Truffle va automatiquement prendre le réseau development et si ce réseau n’existe pas, il va créer un réseau lui-méme, avec des paramétres par défaut Une fois la commande exécutée, vous pourrez consta- ter dans Ganache que le compte dont ladresse a été réfé- rencée dans Vattribut from nia plus 100 ETH et quill y a de nouveaux blocs dans la Blockchain CONCLUSION La Blockchain est une technologie révolutionnaire, qui permet 3 un ensemble de personnes de s’échanger des in- formations en toute sécurité. Elle fit son apparition avec la premi¢re cryptomonnaie, le Bitcoin, mais ce qui nous fascine le plus, ce sont ses cas d'utilisation, qui ont ou- vert de nouveaux horizons en informatique. Notamment avec apparition d'Ethereum, on a eu doit encore & une nouvelle approche révolutionnaire : des applications qui tournent sur une Blockchain, Ethereum est donc une Block- chain futuriste, qui mérite vraiment quon lui accorde de Fattention, au risque sinon d'etre dépassé par les événe- ments dans un futur proche. ill REFERENCES [1] « Naivecoin : a tutorial for building a cryptocurrency > : tips://Ihartikk.github.io/ jekyll/update/2017/07/14/chapter!.himl [2] « Comment fonctionne Algorithme de Consensus de NEO ? » : hitps://www.ssaurel com/toutsurlebitcoin/comment-fonctionne: algo-consensus-neo.him [3] Site officiel de la suite Truffle huips://ruffleframework.com) [4] L. LAMPORT, R. SHOSTAK et M. PEASE, « The Byzamtine Generals Problem », ACM Transactions on Programming Languages and Systems, Vol. 4, N°3, July 1982 [5] M. BAILLY, « Node.JS » Du JavaScript sur votre serveur », GNU/Linux Magazine n°136, mars 2011 : hitps://connect.ed-diamond. com/GNU-Linux-Magazine/GLMF-136/Node js-du-Javascript-sur-votre-serveur [6] La documentation officielle de Solidity huip:/solidity.readthedocs.io/ [7] R. LOUBERT-ALEDO, « Solidity: chotsir le stockage ou la mémoire (storage vs memory) » htips://medium.com/cryptologic: memory-and-storage-in-solidity-4052c788ca86 24 © GNU/Linux Magazine France N°231 huips:/www.gnulinuxmag.comFi 219 t SS-Watewia = or esses . TON Till Cee! eres x : ped chez votre marchand de journaux et sur www.ed-diamond.com26 GNU/Linux Magazine France N°231 ERIC FILIOL [Professcur associé ENSIBS) ans de nombreux pro blames informatiques, il est nécessaire de déter- miner si un ou plusieurs éléments figurent dans un ensemble de données de référence, et ce, de maniere rapide (en particulier, en mi- nimisant les acces disques, ce qui de- vient difficile dans la pratique si Yen- semble de référence est grand). Dans bien des cas, usage classique des tables de hachage ne permet pas un tel traitement, en particulier dans des eenvironnements contraints comme ce- Tui du calcul embarqué. Dans cet ar tile, nous allons présenter une struc- Lure probabiliste, les filtres de Bloom, permettant de traiter efficacement ce type de probleme. Lidée mattresse est dintroduite une dose acceptable erreurs pour augmenter les perfor maneces, out en gérant les contraintes (temps et mémoire), mais sans dégra der la solution/décision finale. Apres la présentation d'une implémentation classique, nous verrons une implé- mentation optimisée, développée par huips:/www.gnulinuxmag.com‘auteur, utiisée dans un probleme de sécurité : la détec- | NOTE tion de comportement malicieux (malwares ou compor- ‘ements humains suspects) ou de patterns comportemen- taux admis ou interdits (par exemple, dans les applications de sécurité ou de prise de décision embarquées). Les filtres de Bloom : un peu de bruit pour beaucoup ! Ces codes ont t6 testés sur une machine Linux Debian (78 Wheezy 64 bits, gcc 47.2) et sur un Odroid XU4 Ubuntu 16.04.2 LTS (Xenial Xerus, gcc 5.4.0) QUELQUES NOTIONS DE COMPLEXITE D'ALGORITHME Pour évaluer la complexité d'un algorithme et surtout comparer deux algorithmes, on compte le nombre d'opérations dites « caractéri tiques » : ce sont celles dont le temps d’exécution influe significative- ‘ment sur le temps total d'exécution d'un algorithme. Ainsi, une addi- Se eee ene ae eee ee Pret een enor secure tents Perret ee a cae ee nes ed est davoir une mesure indépendante de la puissance de ordinateur. Liintérét est surtout de pouvoir comparer Vefficacité de deux algo- Seen cues eM anes oa ee nombre d'opérations pour une entrée de taille n. On dit qu'une fonction est en 0(g(n)) (ou de Vordre de grandeur de 9(n)) sil existe une constante ¢ {elle que f(n) = ¢.g(n). Autrement dit, asymptotiquement (dés que n devient grand), on peut approximer (0) par g(n) a un facteur prés (dans les faits, ¢ prend en compte la différence de puissance entre deux ordinateurs). Quand g(n) est une fonction polynomiale, le probleme est dit de complexité polynomiale, sinon il est de complexité exponentielle. Ainsi, f(n) =n + né + Lest en O(n) (quand nest grand, les termes n* et 1 deviennent négligeables CeO Cee aCe er a ay complexité ne dépend pas de la taille des données (temps constant). Prenons pour exemple e tride n objets. Ilexiste deux types dalgorithmes + les algorithmes « naifs » dans lesquels les objets sont comparés deux. re ean See ne eC eee UO ee) parr) On voit que quand n est grand, le tri naif devient impossible a utiliser Core Rome COR ene Set tee a ae timisé, l faut juste 2.107 opérations, soit 10 000 fois moins. Pour plus de détail sur la complexité des algorithmes, le lecteur consultera [2). a eee ere Dae eI cere eee CeO ea aa ae ee nt me eee ceckete oe) Pee ec de bien prendre en compte le type des ee arc Il est important également de noter CeO ene teed ee aoe ue moire) qui sont considérés selon la na- ence ce ee ee eee De Re on différentes instances d'un probleme sur une donnée d'une certaine taille. Elle n'est donc pas facile a obtenir. SECC aCe ase rité reposant sur des problémes com- Peet tae er cot (comme dans la cryptographic) doit Pe eee oe cri + Celle dite en « pire cas ». Cest celle Ore aoc ee ht impliquer qu'une part non négligeable Pee ei soudre). Elle est surtout préférée dans ae ees PC ne et eee ance crs qui calcule Fatterrissage d'un avion : Ce es ns souhaiter que la complexité ne soit pas élevée). GNU/Linux Magazine France N°231IA, ROBOTIQUE & SCIENCE Considérons deux cas pratiques pour illustrer le pro- bleme que nous voulons résoudre, Nous disposons pour - chacun deux d'un ensemble de référence § (la base de ré- {érence) de taille N + dans le cas du craquage de mots de passe, il siagit des - valeurs de hash des mots de passe ; + dans le cas de la détection d'un comportement ma- licieux (mafware ou comportement humain suspect, patterns comportementaux autorisés ou interdits.., il agit d'un vecteur binaire dans lequel chaque bit dé- crit la présence (valeur & 1) ou V'absence (valeur 2 0) | d'une caractéristique particuligre et d'intérét pour le probléme posé. Le probleme a résoudre est alors le suivant : tout now- - veau candidat doit étre testé pour déterminer s'il est déja présent dans la base. Dans nos deux cas + dans le cadre d'une attaque par dictionnaite, on teste - chaque mot de passe en produisant son hash (par exemple SHAI) et on regarde si le hash est déja connu ; dans ce cas, le mot de passe a été « craqué » (corres: pondance mot de passe/hash valide) + dans le cas de comportement malicieux (le cas qui | sera développé ici) le vecteur de comportement est construit pour un individu (extraction des caractéris- tiques) et Fon vérifie si le comportement correspon dant est référencé comme suspect ou non. Le probléme est que souvent, la taille N de ces bases - peut étre trés grande (plusieurs dizaines & plusieurs cen- taines de millers déléments). Le nombre de requétes, R, peut lui aussi étre tr8s important (plusieurs millions, par ‘exemple dans le cas du craquage de mots de passe), et ce, dans un contexte souvent oi le probleme doit recevoir une réponse en temps quasi réel (en particulier, dans le cas de la détection d'un comportement suspect). Quelles sont les principales techniques de résolution - possibles et leurs forces et faiblesses respectives (on sup~ [pose que N est trop grand pour étre stocké en rmémoire) ? + Chaque valeur testée pouvant tre représentée comme nents, ilest possible de trier la base de référence (en N.Log(N) opérations), puis pour chaque requéte, faire tune recherche dichotomnique (Log(N) opérations), Pour R requétes, nous avons donc N.Log(N) + R.Log(N), ALGO Asymptotiquement (quand N et R sont trop grands), Je nombre dopérations devient exorbitant, ainsi que le nombre daccés disque On utilise une table de hachage (voir section | et [3, sections 6.4 et 6.5)). Le nombre dopérations est de N. (construction de la table de hachage) plus R (lecture dans la table). On fait done beaucoup mieux en exé- ution. Toutefois en mémoire, la complexité est di- rectement proportionnelle a la taille H de la table. En pratique, cette taille devient vite incompatible avec la taille de la mémoire physique (en particulier dans Vembarqué), surtout lorsque la tale Nest importante. Utilser un filtre de Bloom. Lidée est de significative- ‘ment diminuer la taille de la table le filtre proprement it, en introduisant la possibilité davoir de faux posi- tifs en nombre trés limité. En effet, la construction du file permet lors d'une requéte concernant un candidat avec certitude, daffirmer que le candidat ne fi- ure pas dans ensemble $ (aucun faux négatif possible): — avec une certaine probabilité p, que le candidat peut étte présent dans ensemble (faux posit. On gagne en mémoire (de maniére significative) et pour les quelques faux posits, le travail de validation du candidat doit rester de complexité marginale (au pire, en .R.N.Log(N) opérations pour R requétes). Il siagit done d'un compromis efficace, permettant de considérablement réduire la taille d'une table de hachage classique, au prix lun surcoat marginal de calcul. A titre dexemple, dans Bloom [4] sur un cas pratique (recherche de regles de cé- sure de mots) avec N = 508 006, la taille H d'une table | de hachage est de H = 2 000 000 bits. En acceptant un © taux detreur de p = 0,0625, la taille du filtre nest que de H = 300 000 bits, soit prés de 7 fois moins et avec 84% daccés disque totaux en moins [5]. Nous allons done étudier deux constructions de filtres de Bloom et en détaller les performances. La premigre partie de Tarticle repose essentiellement sur la publica- © tion originale de Burton H. Bloom [4}, La partie histo- rique et les différentes techniques classiques de hashing ont 616 rédigées avec aide du magistral ouvrage de Donald Knuth 3, sections 6.4et 6.5]. Exceptées les libraries murmurhash3 ’Austin Appleby [3], tous les codes pré- © sentés ici sont de Fauteur, 28 © GNU/Linux Magazine France N°231 huips:/www.gnulinuxmag.comLes filtres de Bloom : un peu de bruit pour beaucoup ! 1. TABLE DE HACHAGE CLASSIQUE : RAPPEL Cette section est pour rappel seulement et pour fournir des éléments de ‘comparaison avec les filtres de Bloom. Le lecteur trouvera tous les détails al~ _gorithmiques et c'implémentation dans [3, sections 6.4 et 6.5] ou dans [7, cha pitre 17] et [8, section 7.5]. Iexiste de nombreuses techniques et variantes pour réaliser et utiliser des tables de hachage. Nous en présenterons deux : une présentée par Bloom [4] a titre de comparaison avec ses propres filtres, Fautre, plus classique, appelée table de hachage avec chainage. 1.1 Hachage classique Dans les deux cas, nous disposons d'une table de hachage T de taille H. Soit tune valeur K (une clef qui peut étre une chaine de caractéres, un entier..) de wa ensemble de référence S. Pour enregistrer K dans la table, nous utilisons une fonction de hachage & de la facon suivante Fig. 1 Table de hachage classique de taille 1. On géndre h(K) a partir de K avec h(K) € [0,... H - 2): (2 premier bit pour indiquer sila cel Tule est vide ou non, puis les b bits La fonction de hachage mest pas une fonction éponyme, au sens crypto- pour le message). Lutilisation de la ‘graphique du terme (pour lesquelles des propristés trés fortes de sécurité sont table est alors simple cexigées). La seule qualité demandée dans notre cas est de satistaire le mieux possible & une répartition uniforme des adresses produites : chaque élément K _ 1» On calcule h(K) pour une fone: doit avoir idéalement la méme probabilité de générer une adresse de hachage tion h donnée. (ou hash) donnée. 2. Keest stockée dans la case d’adresse h(K), soit TEh(K)] = K. 2. Si TEh(K)] est vide, on stocke Quand on véritie si un candidat K* est dans §, i suit de calculer h(K") et la valeur 2K (b + 2 bits), sinon de voir si T{h(K")] contient K* ou non. Le fonctionnement général est décrit oon réitére jusqu’a trouver une en figure | cellule vide Quelles sont les fonctions usuelles h utilisées ? Men existe de nombreuses, 3. Pour déterminer sik’ est dans $ mais les plus courantes sont les suivantes pour une table de taille W [3 sec- ou non, on calcule hk") et on tions 6.4 et 65] regarde le contenu de TEh(K*)] Siilest vide, K’ nest pas dans S, sinon on compare les b derniers bits avec ceux de K + h(K) = K mod H (on transforme la clef K en un entier d'un type au moins égal a celui de H). Le calcul est tres rapide. Il est important de ne pas prendre pour H des puissances de 2 (h(K) ne dépendrait sinon que d’une partie des bits de K), mais plut6t des nombres premiers éloignés de puis- Sances de.2 1.2 Hachage uniforme +k) = INGA = IK.ADJ avec 0 < A < 1. Selon Knuth, lavaleurk = avec chainage (WS ~ 1)/2 donne de bons résultats. Par exemple, si K = 1234567890 et H = 1 000 000 (pour cette valeur de A) alors h(K) = 43 924. es Paere an ease eae thode précédente (quelle que soit sa Dans larticle de Bloom [4, ensemble de référence $ contient Nmessagesde variante) est que la probabilité de co b bits (Clefs) La table T est de taille H > N, chaque cellule contenant b + 1 bits.” lisions n'est pas nulle. Autrement dit, www.ed-diamond.com GNU/Linux Magazine France N°231 r2IA, ROBOTIQUE & SCIENCE ae ilest possible d'avoir k et K* tels que h(K) = h(K'), Augmenter la taille Hne | 2. LES FILTRES DE permet que de réduire cette probabilté, au prix d'un coot mémoire exorbitant Pour gére les collisions, la technique consiste & utiliser des listeschainées, se- BLOOM lon le principe décrit en figure 2. Histoiquement, il sagit dune vo- riante de codage superposé (surimposed coding), codage découvert plusieurs an- rnées avant les techniques de hachage et dont le plus célebre est le Zatocoding dde Calvin Mooers, en 1951 [7] Le co- dage superposé avait été mis au point pour économiser de la place sur des cartes perforées (mécanographie). Le codage consiste 2 atribuer pour chaque aitvibut un code en forme de pattern de k bits pris parmi n. Un objet étant défini par un ensemble datrbuts, on construit ainsi un code spécifique pour chaque objet, Imaginons qu'un objet ddonné (que Ton cherche dans une liste) soit caractérisé par trois attributs&,, A, et A, codes respectivement (k = 2, 16) par 0016001000, 0600100100 et (0000001001. Alors, objet Xestcoxé par 010001000 v o900i00100 v En cas de collision, on insére la nouvelle clef concernée dans la liste adresse 9999001001 = 0010101101 ‘h(K). Lors d'une consultation de la table a la recherche d'un élément K*, on. parcourt la liste chainge a Tadresse h(K"). Celle technique permet de réduire | _ Selon les paramétres k et m ainsi au passage la taille H de la table et d’avoir une gestion plus fine de lamémoire. que le nombre d'attributs q maximal autorisé pour chaque objet, ce codage Quelles sont les complexités temps et mémoire pour ce type de hachage ? limite considérablement les faux po- En fait, il est nécessaire de voir les choses selon le principe du compromis sits (par exemple, n = 32, k = 3 et temps/mémoire : pour gagner du temps, il faut augmenter la taille de la table q = 6 donne une probabilité de faux (on diminue le risque de collisions et done, la longueur moyenne de chaque positifs de @.0000008). liste chainée) pour réduire la mémoire requise. il faut calculer plus (les listes chainées 3 parcourir sont en moyenne plus longue. Fig. 2: Table de hachage avec chatnage. 2.1 Principe général Soit un ensemble de référence $ de taille N. Un filtre de Bloom se com- pose de deux éléments Pour modéliser cela, on utilise le concept de « facteur de remplissage » de la table, défini par a=N/H (autrement dit, le nombre moyen de clefs stockées, dans une chaine ou longueur moyenne d'une liste chainée). Alors, nous avons, le résultat de complexité suivant [3, page 517] + un tableau T de booléens de taille + Une recherche infructueuse (le candidat K nest pas dans $) se fait en (indexation de @ AH = 1); 141/4.(exp(2a)-1-2a tests en moyenne. Quand la table est pleine, en ‘moyenne on fait 2,2 tests * de d fonctions de hachage hy, hh, telles que h:S > (0, H - * Une recherche positive (Ie candidat K est dans $) se fait en 1+(1/(8.a)). 1]. Autrement dit, 2.un élément (exp(2a)-1-2a)+(1/4).a tests er moyenne. Quand la table est pleine, de S, on associe un entier com- fen moyenne on fait 2,8 test. pris en Oct H 30 GNU/Linux Magazine France N°231 huips:/www.gnulinuxmag.comLes filtres de Bloom : un peu de bruit pour beaucoup ! {x % z} w Fig, 3: Illustration du principe du filtre de Bloom. Ki, $= (x.y, image Wikipedia) Dans une phase initiale, il est nécessaire de charger Ten= semble § dans le tableau T de la maniére suivante : pour tout élément s de § et pour i de 2a d, on calcule hs) eton met Tth,(s)] 22 Pour verifier si un élément s est dans $ ou non, alors; + soit s! € §, alors les d entrées TIh,(s")] sont 2.2 pour i allant de 13d; + sipourd < d nous avons T[h,(s")] = 0, alors s' €5. Diun point de vue calculatoire, ds le premier index 20, i est possible de décider. 2.2 Analyse des paramétres Trois paramatres principaux inter viennent dans le choix d'un filtre de Bloom + Le taux dierreur admissible. II détermine directement la complexité résiduelle pour déterminer sil sagit ou non dun faux positif (post-processing). + La taille H du tableau T, en bits. Il influe sur Foccu- pation mémoire + Le nombre d de fonctions de hachage utilisées. Il im- pacte le temps de calcul d'une requéte. Il est assez intuitif de comprendre que ces trois para- metres dpendent les uns des autres et que la taille N de ensemble de référence S intervient également. Soit on re- ‘cherche le compromis optimal, soit on fixe une priorité (ou Z}. On voit alors que l'élément w n'est pas dans S (Source tune contrainte) sur Tun des paramatres et Yon détermine les valeurs optimales pour les deux autres, Nous repre- rnons ici les résultats et discussions établis par Bloom [4 Dans ce qui suit, Log(x) représente le logarithme a base 2 et Un(x) le logarthme naturel 2.2.1 Probabilité de faux positifs Soit @ la proportion de bits a 0 dans le tableau de taille H aprés avoir inséré les éléments d'un ensemble de réfé- rence de taille N, Nous avons donc @=(1-d/H)" Un message s* sera un faux positf si et seulement si les d bits TTh(s')] sont a 1. La probabilité d'un tel mes- sage est donnée par P=(1-()* Par calcul et simplification (on suppose que d << H), nous avons alors P=(1-exp(-dN/H))* Annoter que cette formule n'est précise que pour des rap- ports H/N relativement faibles (en pratique H/N < 8). Pour des rapports plus important, il faut prendre en compte certaines dépendances statistiques [10]. 2.2.2 Taille du tableau En reprenant la formule de P,ilest possible alors de dé- terminer la taille H du tableau en fonction de P. Nous avons donc : H = N.(Log(P)). (Log(e)/(Log(@).Leg{1 - @)). Laencore, la dépendance vis-a-vis des autres paramétres 4 et sexprime via la donnée www.ed-diamond.com GNU/Linux Magazine France N°231 31IA, ROBOTIQUE & SCIENCE ae 2.2.3 Nombre optimal de fonctions de hachage Pour déterminer ce nombre, on cherche la valeur de d qui, & para- ‘mdtres W et H fixés, minimise la pro- babilité P (foujours pour des rapports W/W relativement faibles) {11}. Cela se produit pour d = (H/N).n(2), En ré= injectant cette valeur dans la formule de P, on obiient alors deux résultats intéressants SHEN, (Un(P)/(Ln(2)?) 2 H/ = -1.44,Log(P). Cela représente a quantité optimale d'informa- tion nécessaire par élément de S ; + Le nombre optimal d de fonctions de hachage est donné par d= = Un(P)/An(2) = -Log(P). Ces deux résultats sont trés forts, car ils montrent que d'une part, pour P fixg, la taille H du filtte est propor tionnelle aN (logique somme toute, ‘mais le facteur de proportionnalité est précisément défini). Diautre part, Je nombre de fonctions de hachage ne dépend que de la probabilité de fausse alarme P. Autrement dit, dans ‘un cas pratique, c'est le contexte opé- rationnel qui va permettre de fixer P (en particulier, le post-processing) et de la, les autres parametres. 2.3 Application : détection de patterns comportementaux. Nous allons utiliser les filtres de Bloom dans le cadre de la validation cde comportements ou de pattems com- portementaux (détection de malware, prise de décision dans un algorithme de détection embarqué..). On di pose d'une base de patterns compor- tementaux de taille N(comportements autorisés ou interdits, selon le contexte), Un « pattern comportemental » est | modélisé comme un vecteur de taille 64, chaque bit représentant un compor- tement basique, présent (bit a 2) ou non (bit a @). Pour chaque événement, un ‘pattern comportemental est extrait (par le moteur d'analyse antivirale, par une pplication embarquée alimentée par des capleurs..) et on recherche si ce pat- tem est dans la base ou non. Ici, les paramatres sont +R = 2 420 000 requétes ; comportements de référence. Les contraintes du probleme font que tout faux positi! a un impact lourd sur la gestion temps-réel (emps de post-processing). On veut done minimiser P que l'on fixe en O(2/R) (un faux positif en moyenne), soit P = 0,0000005. Avec ces contraintes, nous avons d = 22 etH = 1 500 000, & partir des for- mules des sections précédentes. La fonction de hachage de base sera MurmurHash3 [6], Son prototype est le suivant 3_x64_128 (uint64_t key, uint32_t seed Le tableau out contient deux entiers de 64 bits h, key) et h, (key), key étant la clef lata, ici nos vecteurs de 64 bits {12). Pour générer les autres fonctions de hachage & partir de ces deux valeurs, il existe de nombreuses propositions dans la littérature, Nous avons opté pour celles proposées dans [13] pour leurs. excellentes proprités statistiques duniformité hi(key) = h(key) + i.h,(key) + i? mod H avec i allant de 1.3 21. Voici le code source (version Debian non optimisée) limité aux parties im- portantes, dans un souci de concision. Pour tester Felficacité des paramatres choisis vis-a-vis du taux de faux positfs, nous avons volontairement pris un fichier de requétes ne contenant aucun élément de Fensemble de référence, [oss] /* Entéte C classique */ include "murmur.h" {define SALT_CONSTANT 0x97C29B3A /* Constante murmurhash3 */ int main(int argc, char * argv{]) { uint@_t * bfiltre; uint64_t ept_in, cpt_out, block: uint64_t * out, hi, 2, index; uint®_E ept_f, i, flag: FILE * fint, * £in2, * fout; clock_t tl, t2, ¢3; /s#ssT4+4+4 Initialisations diverses *#+t+s+#+#+4/ 7 argv{1] ensenble de référence, argv[2] fichier requéte */ finl = fopenargy(t), ""); fin2 = fopen(argvi2], "="): bfiltre = (uint8_t )calloc(0x200000L, sizeof (wint8_t)) : 32 GNU/Linux Magazine France N°231 huips:/www.gnulinuxmag.comLes filtres de Bloom : un peu de bruit pour beaucoup ! 7* on arrondit H & 0x200000L pour le calcul du modulo */ out = (uint64_t )calloc(2, sizeof (uint64_t)); /* Valeurs initiales de hash hi et h2 */ ept_in = OLLU; ept_out = OLLU; t1 = clock(); /+*** Traitement de l'ensemble de référence *#*++/ while (fscané (£in1,"$016LX", sblock) , ‘feof (fin1))( ept_t = 0; Murmurfash3_x64_128 (block, SALT_ CONSTANT, out); /* Calcul de hi et h2 en fonction de la clef */ hi = out(0]; h2 = out{1); for(i = Li < 22;444){ index = (hl + i * h2 + i%i) & Ox1FFFFFL; /* Ici le modulo se simplifie par un masque, d'oi le choix de la taille de 0x200000L pour # */ /* Verifie si le bit de coordonnées index vaut 1 ou 0 */ cpt_f + bfiltre| index) ; /* Force 41 le bit de coordonnées index “ bfiltre [index] = 1) ) /* On vérifie l'absence de collisions lors de 1a construction du filtre */ it(optt ept_intt; , printf ("Nombre de vecteurs en entrée siu\n", ept_in) ; printf ("Nombre de collisions = t1u\n", ept_out) ; ept_out = LLU; #2 = clock(); /+t¥4 Traitement des requétes while (Escané (£in2,"$016LX", sblock) , ‘feof (£in2)) ( ept_f = 0; MurmurHash3_x64_128 (block, SALT_ ConstaNT, out) ; 1 = out(0] ;a2 = out (1); flag = 0; for(i = Li < 22;444)( index = (hi +i * h2 + iti) & OxtFFFFFL; 22) ept_outt+; /* Si le bit est a zéro on quite la boucle ; le candidat n'est sienent pas dans Tiensenble de référence */ if(Ibfiltre[index]) (flag = 1;break;) /+ Verifie si le bit de coordonnées index vaut 1 ou 0 */ opt_f #= bfiltre(index] ; ) A£(Elag) continue; LE(ept_f == 22) ept_outt+; print € ("Nombre de faux positifs = $1u\n", ept_out) | #3 = clock() [...] /# Fin Classique programe */ Et le résultat est donné par ‘Aucun faux positifnvest & déplorer. Les performances: obtenues sont les suivantes (sans aucune optimisation) Linux Debian Linux Odroid Construction du filtre 0.01 secondes 0.0807 secondes Traitement des R equétes 0.44 secondes 2.314 secondes 3. OPTIMISATION ET APPLICATIONS DU FILTRE DE BLOOM LLimplémentation précédente, bien qu‘fficace, peut en- core étre considérée comme naive. Il est possible de faire encore mieux. Nous allons, avec les mémes valeurs de N et de R, réduire la valeur de H, sans toutelois modifier son occupation mémoire. Cela est particuligrement intéressant dans des environnements embarqués. Nous verrons ensuite deux applications du filtre de Bloom pour des opérations sur des fichiers, faces avec une simple ligne de commande pour un fichier de taille raisonnable, mais qui deviennent impossibles (temps et mémoire sur le disque) quand les fi- chiers deviennent énormes (plusieurs Gio & quelques Tio). www.ed-diamond.com GNU/Linux Magazine France N°231 33IA, ROBOTIQUE & SCIENCE ae 3.1 Une optimisation du filtre de Bloom lest possible de réduire la taille du file en observant que les valeurs du tableau sont des octets et que 7 bits sur 8 ne sont pas exploités. On va donc les utiliser 14}. Cette optimisation permet de gagner (hors optimisation par- ticulire) un peu de temps et de diviser la taille du filtre par 8. Voici les por- tions significatives modifiées dans le code précédent /* ta taille du filtre est réduite d'un facteur 8 au moins */ bfiltre = (uint8_t *)calloc(0x40000L, sizeof (uint®_t)); pest index = (hl + 4 * B2 + 444) 6 ORLFFRFEL; quo = (index >> 3); rem = (index & 7); [t For Je bit de coordonnées xen @ 1'index valant quo */ bfiltre(quo] |= (1 << rem) ; ‘Aucun faux positif nest & déplorer encore une fois. Les performances obte ‘ues pour cette version optimisée sont les suivantes (Sans aucune optimisation) Linux Debian Linux Odroid Construction du filtre 0.01 secondes 0.656 secondes Traitement des R requétes 0.31 secondes 2.145 secondes 3.2 Applications : quand la ligne de commande devient impuissante Imaginons un fichier de logs de traces dactivités humaines ou logiceles..Chaque ligne représente un pattern particulier. lest fréquent de vouloit, sur ce fichier + supprimer les patterns répétés ; + ou au contraie, identifier et compter les patterns intervenant plusieurs fos. Pour un fichier d'une taille relativement faible, on utilise souvent (par faci- ‘mais aussi du fait de leur puissance) Ti eer et Ee Oks c red Ces commandes sont vraiment pratiques, mais ds que la taille du fichier devient importante (quelques centaines de Mio, voire plusieurs Gio), elles de- viennent inuilisables a partie tri (en complexité n-L0g(n) pour n objets, la mé- ‘moire disque pour les fichiers temporaires, les accés disques..) consomme des ressources exorbitantes et finalement, le traitement nest simplement pas possible En revanche avec un filte de Bloom, traiter pour ces deux opérations un fichier de plusieurs Gio (cas rencontré par Tauteur) se fait tr&s rapidement (de quelques secondes & quelques minutes). lest toutefois important de bien choi- sir les bons parametres * pour supprimer les doublons toute valeur déja dans la table sera écartée, dans le cas contraire, elle sera imprimée dans un fichier ; pour compter des patterns inter venant plusieurs fois, au contraire toute valeur déja dans la table (donc existence d'une collision) sera imprimée dans un fichier. Ce fichier sera in fine wi (lest sou- vent beaucoup plus petit) avec la commande sort, puis traité avec la commande unig (on nioubliera pas de rajouter #1 a chaque effec tif, pour tenir compte de la pré- sence dans la table), Simple, maisextrémement effcace CONCLUSION La puissance des filtres de Bloom est telle que ses utilisations sont désor- mais nombreuses dans pratiquement tous les domaines du traitement de Finformation et de ta sécurité [15]. La rapidité de traitement les rend parti culiétement intéressants dans Tanalyse temps-téel de flux d'information (deep packet inspection, identification de pat- terns dangereux (URL malicieuses dans Chrome par exemple), synchronisation Bitcoin, analyse de logs Ethereum..). Leur utilisation dans le domaine des bases de données est devenue égale- ment fréquente (Cassandra, Hbase, Bigtable, PostgreSQL...) pour opti- miser les operations de recherche et ainsi, diminuer les accés disque. Les filtres de Bloom sont done un outil & ne jamais oublier, pour lequel il existe de nombreuses autres variantes et op- timisations [16], souvent un peu plus complexes & mettre en ceuvre, Notre souhait est que cet article vous donne envie de les explorer et de vous les ap- proprier facilement. Ml 34 GNU/Linux Magazine France N°231 huips:/www.gnulinuxmag.comLes filtres de Bloom : un peu de bruit pour beaucoup ! NOTES & REFERENCES {1] Allusion contraposée a une célebre comédie de William Shakespeare [2]M. R. GAREY, D. S. JOHNSON, « Computers and Intractability ~ A Guide to the Theory of NP-Completeness », Freeman, 1979. Le meilleur livre sur la théorie de la complexité, Incontournable ! [3] D. E. KNUTH, « The Art of Computer Programming, Vol Sorting and Searching », Addison Wesley, 1973, [4] B. H. BLOOM, « Space/Time Trade-offs in Hash Coding with Allowable Errors », Communications of the ACM, vol. 13, numero 7, juillet 1970, p. 422 a 426. [5] Les talles données ici peuvent paraftre ridicules, en comparaison des capacités disques, RAM et des vitesses des périphériques actuelles. Il faut se rappeler que le travail de Bloom a été publié en 1970. Les lecteurs, les plus agés et heureux possesseurs (dont lauteur fait partie) d'un ZX Spectrum Sinclair (1982) ou d'un Apple Ile se rappelleront que Von ne disposait que de 48 Kio de mémoire RAM (64 Kio pour Apple tle), de processeurs 8 bits lents et de mémoire de masse extrémement lentes. De nos jours, si les ordinateurs sont considérablement plus rapides, la taille des probleémes et des données a explosé en plus grande proportion. Le travail de Bloom reste donc particuligrement d'actualité [6] A. APPLEBY, « SMhasher », hlips://github.com/aappleby/smhasher I7IC. BLAESS, « Développement sysiéme sous Linux », Eyrolles, 2016. On ne présente plus ce livre ni son auteur ! [8] W. H. PRESS, S. A. TEUTOLSKY, W. T. VETTERLING, B. P. FLANNERY., « Numerical Recipes in C- The Art of Scientific Computing », Cambridge University Press, 2007. [9] C. MOOERS, « Zatocoding Applied to Mechanical Organization of Knowledge », American Documentation, 2, pp. 20-32, 1951 [10] K. CHRISTENSEN, A. ROGINKSY, M. JIMENO, « A New Analysis of the False Positive Rate of a Bloom Filter », Information Processing Letters, 110(21), pp. 944-949, 2010. [11] P. CAO, « Bloom Filter: the Math » : http://pages.cs.wisc.edu/~cao/papers/summary-cache/node8. html, 1998, [12] Dans le cas de clefs de plus de 64 bits, il faut itérer la fonction MurmurHash3 plusieurs fois. En utilisant tne variable statique flag, les variables hl et h2 sont initialisées avec le contenu du tableau out quand flag rest plus nul (lag est nul au premier appel et les variables hl, h2 sont initialisées avec le param@tre seed). [13] A. BRODER, M. MITZENMACHER, « Less Hashing, Same Performance: Building a Better Bloom Filler », Algorithms - ESA 2006, 110(21), pp. 456-467, Springer Verlag, 2006. [14] Il est possible de généraliser sur des entiers de 64 bits, avec un gain en termes de performance plus quappréciable. [15] A. KIRSCH, M. MITZENMACHER, « Network Applications of Bloom Filter: A Survey » Internet Mathematics, vol.1, Nr4, pp. 485-509, 2002. [16] L. LUO, D. GUO, R. T. B. MA, O. ROTTENSTREICH, X. LUO, « Optimizing Bloom Filter: Challenges, Solutions and Comparisons », ArXiv repository, 2018 : htip//arxiv.org/abs/1804.04777 www.ed-diamond.com GNU/Linux Magazine France N°231 35SYSTEME & RESEAU ISOLATION DE CONTENEURS : YOU ARE NOT SAFE DAVID BLASKOW [Rocketmonkey de Vhyperpod au service de Data Essential] MOTS-CLES : MICRO-VMS, QEMU-LITE, KUBERNETES, CLEAR, ISOLATION Col D uN OCD «Wewon’ tbe ableto pretend that we can protect ourselves anymore. It’s a huge danger, a giganticrisk, butit’s worth it, if only we can learn to take care of each other, then this awesome destructive new connection won't isolate us. It won't leave us in the end so totally alone. ». Cet extrait du manifeste « You are NOT safe » de Ryan Ray dans la série Halt and Catch Fire n’a jamais été autant @actualité ! “est un fait, il y a tant de vecteurs dattaque dans les systémes dinforma- tion actuels que nous ne pouvons pas seulement compter sur nos bonnes pratiques personnelles, pour nous mettre & labri, Les choses sont devenues si complexes ! Le Cloud ‘computing a mis en évidence ily a des années qu'un simple firewall ne sufi sait pas & mettre nos applications en sécurité; puis il y a eu Docker, avec Jequel nous avons pu exécuter un mil- lier de cette méme application sur la :méme machine ; et enfin Kubernetes, quia dispersé ces mémes applications sur des dizaines de serveurs... Nous ne savons méme plus od se trouve ce ‘que nous devons protéger. Par ailleurs, ily a tant de niveaux de sécurité, depuis la machine elle-méme jusqu’a TAPI que Fon présente sur le Web, en passant par le systeme d'ex- ploitation la communication entre les services, e réseau, encryption, Fauthen- tification, les autorisations... Un peu aide serait la bienvenue. Fort heureu- sement pour nous, Hashicorp Vault, Istio, SPIFFE et d'autres sont Id pour nous aider. El il y a aussi les micro- ‘VMs. Ces demigres sont aujourd'hui, 36 GNU/Linux Magazine France N°231 hutps:/wwwgnulinuxmag.com